> >If there's junk in the as path of one form or another - e.g. weird confed >stuff, private intermediate ASNs, upstream monopoly providers doing strange >things with customer ASNs, asn typos, as23456, etc - does this make a >meaningful statement about the legitimacy of the prefix?
Obligatory mention of the Kapela Pilosov attack, despite it being an edge-case. https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf The attack is concealed from the mid-points because they automatically discard updates with their own ASN in the path, because the RFC suggests they don't accept these (RFC4271 9.3) but does not go as far as to mandate such. Some people turn off this filtering (I.e "allow-as in" in IOS) for legitimate reasons (knowing that they have other mechanisms of loop protection) and thus are not hoodwinked by K-P updates and may even accept them, revealing a K-P attack. IF you do accept your own ASN in the path (and this is the point of my mail), then make sure you know where you expect it to be, making good use of the as-path filtering regular expressions to anchor it suitably. Dave.
