[sdnog] Can not get the real ASNs using traceroute -a
nishal at controlfreak.co.za
Thu Sep 24 14:02:08 SAST 2020
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.
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
184.108.40.206 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 220.127.116.11/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 18.104.22.168/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
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.
# 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.
# 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.
# 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
but again, that’s is no reason you should not get your ROAs done.
if you’re interested in RPKI, a good place to start reading is:
https://rpki.readthedocs.io. or, ask questions here :-)
More information about the sdnog