AT&T/as7018 now drops invalid prefixes from peers

Wed Feb 13 09:20:15 UTC 2019

> 
> 1/ For instance AT&T does not accept BGP UPDATES with 2914 anywhere in the AS_PATH except on the direct EBGP sessions between 7018 and 2914. This means that you can craft BGP UPDATES with 2914 all you want, but 7018 won't accept them. You can't inject yourself between AT&T and NTT using spoofing.

Sure, but RPKI plays no role in this. 

> 2/ Many networks give all their peering partners the same LOCAL_PREFERENCE, so you'll have to not only spoof the BGP Origin ASN but also compete & win for the shortest path in order for your hijack to arrive at the intended location.

Also utterly and completely unrelated to ROAs. 

> We as industry essentially already have path validation for paths of length 1. This may not seem much, but since people in this industry tend to peer directly with networks that matter to them. The majority of Internet traffic flows over paths that have an AS_PATH length of 1.

I would buy this argument with length 1-3, but I’m not completely convinced of “1”. 

Owen