>> and here i thought that detecting that they differ, as an attack, is >> the core goal of as-path validation. > I thought it was to prevent an AS from announcing an update that it > was not authorised to.
nope. that is rpki-based origin validation. we are now talking about as-path validation. from a note to some gov folk: To be clear, as people keep calling BGP security 'RPKI' In the current taxonomy, there are three pieces, the RPKI, RPKI-based origin validation, and then path validation. RPKI is the X.509 based hierarchy with is congruent with the internet IP address allocation administration, the IANA, RIRS, ISPs, ... It is the substrate on which the next two are based. It is currently deployed in four of the five administrative regions, ARIN in North America being the sad and embarrassing exception. RPKI-based origin validation uses some of the RPKI data to allow a router to verify that the autonomous system announcing an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it prevents the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakastani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from Cisco, and will be shipping by Juniper soon. Path validation uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to formally cryptographically validate that the originating autonomous system was truely authorized to announce the IP address prefix, and that the systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. Sorry to drone on, but these three really need to be differentiated. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr