[sdnog] Can not get the real ASNs using traceroute -a

[Nishal Goburdhan]

On 24 Sep 2020, at 12:36, Sara Alamin wrote:

> Hello sdnog community.
> hope you all are safe and well.
>
> Why when I do “traceroute -a”  (-a option means get the ASN  for 
> each hop encountered) I don’t get the real ASNs for each hop? I 
> thought this will check each IP address and which ASN this IP address 
> belongs to, using WHOIS database.

hi sara,

the “whois” lookup that you refer to, does indeed happen, but it’s 
a whois lookup to radb.net.  if you:  whois -h whois.radb.net 
197.254.230.177 you will see two entries for this prefix, one with an 
origin of AS37313 which is the match you refer to in your traceroute 
output.  you could either submit a patch to traceroute, but that’s a 
lot more difficult because … $reasons, or, you could petition RADB to 
clean this up.  i would suggest going with the latter.

if i worked at canar, this would worry me.  since the function of the 
RADB is to act as a database that reflects what prefixes should be in 
BGP, an entry in the RADB is a “hint” to the rest of the networking 
community that, they should expect to see prefix P, with an origin-as of 
X.  so today, there is a RADB entry for 197.254.224.0/19 with origin 
ASNs AS37313 (incorrect) and AS33788.  imagine, if you worked at 
AS37313;  you could easily create a “fake” routing advert for this 
prefix to hijack the address block, and all that this would do, would be 
to disrupt services to the legitimate holder of that address space.
and, since registries, like the RADB, allow you to register _anything_ i 
could register 197.254.224.0/19 with an origin-as of 37474 (which is one 
of my ASNs in johannesburg).  i could then go to my upstream and say: 
please accept this, there’s a RADB entry for it.  they would check, 
and .. accept the prefix advertisement from me, and pass this on to 
their peers and transt - again, disruption for the legitimate holder of 
the prefix.
and, if you think it’s difficult to do all this, you are wrong;  it 
would me take less time to fake a routing advert, than it is taking for 
me to write this mail  :-)

the fix for this is easy.
#1
# canar write to the person/people that registered the wrong prefixes 
(well they are not wrong;  they were just registered a long time ago, 
and never cleaned up)
# canar begs and pleads with them to remove the entries.   for this, i 
wish you good luck.  my personal success rate at having people who have 
old entries simply “Do The Right Thing” is very, very low.

or

#2
# canar should ask RADB to remove the old entry.  RADB will ask for 
proof that the prefixes are theirs, and that this is the intended 
origination path, etc. .. that’s .. a lot of email back and forth.  it 
can certainly work, but, it will take a long time.

or

#3
# canar works with afrinic to get RPKI ROAs for their prefixes
# canar then shows RADB cryptographic proof that these prefixes belong 
to them  (ie. the RPKI ROAs)
# RADB recognises the ROAs (because this is industry standard) and they 
remove the old, unused prefixes.
# networks that implement RPKI path validation will see ROAs from canar, 
and automatically drop attacks like the one i mentioned above.

if i was a manager at canar, i know what i would choose.   (hint:  
that’s #3  ;-))

RPKI is not a perfect solution;  much like IPv6, it has flaws.  but, the 
flaws that people are likely telling you about (eg. if you are on the 
afrinic RPD list there are a whole lot of chinese-nigerian bots that are 
talking absolute nonsense about RPKI) are not the reasons that you 
don’t want to think about using this.  the truth is, that, at this 
point in our history, it’s the best tool we currently have to secure 
your routing advertisements, and, at least for the ROA part, it is 
really *not* difficult to deploy at all.  also, if you need help, there 
are many people on list that can help.  iirc, the afrinic staff on this 
mailing list even offered help with remote RPKI registration   (and, 
they get paid to do this, so, don’t think it’s a favour - use them, 
or get less value for your expensive membership fees!)

personally, i would *love* to see the networks operators in sudan (there 
are not a lot of you, so this is easy, imho) say:
# we, as a group, want sudanese network prefixes to be as safe as we can 
make them on the internet
# we, as a group, agree to sign all our prefixes
# we, as the community that interconnects in sudan, want our IXP(s) to 
implement origination validation

this automatically makes you immune to a large number of attacks against 
your address space.  and there is no good reason for you to *not* 
register your ROA, today!  it costs no no money, and just a little time. 
  right now only about 4.8% of sudan’s IP space is protected.  see:  
https://www.nlnetlabs.nl/projects/rpki/rpki-analytics/.  there is *NO* 
good reason that a smart netops does not have prefixes.   sifer  (zero)!

there are two more parts to this story.
origin validation:  registering your ROAs, simply means that _other_ 
networks can validate your prefixes against current routing 
advertisements.  if you want to be safer, you will want to validate 
_other_ networks’ prefixes too.  that’s a little more work, and 
requires effort and co-ordination inside your network.  and, honestly, 
if the IXPs that you connect to, as well as your transits do route 
validation, then, there’s no rush for you to get this done.

path validation:  there’s still the possibility that, even with a 
signed prefix, someone could intercept the network _path_ that your 
prefix is routed along.  this is a much longer discussion, and again, 
probably not what you’re ready to do now, since this is most likely 
going to involved spending money on routing equipment that can support 
crypto.

but again, that’s is no reason you should not get your ROAs done.  
today.

if you’re interested in RPKI, a good place to start reading is:  
https://rpki.readthedocs.io.   or, ask questions here :-)

—n.