<div dir="ltr">A very big step forward, Congrats.</div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 4, 2020 at 9:05 PM Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Tijn, I didn't fully answer your email, more below. On Sat, Apr 04, 2020 at 10:20:38AM +0200, Tijn Buijs wrote: > And doesn't this make enabling it on the rest of the validation less > useful? Because if an invalid announcements is received on an EBGP > session without RPKI validation, doesn't it propagate trough the rest > of the network via iBGP, and thus make the hijack reachable for all of > NTT? Certainly good questions. When a RPKI Invalid announcement comes in via a EBGP session where RPKI is not enabled, the route cannot be marked as RPKI invalid because the Origin Validation is not applied in the routing policy associated with that specific EBGP ingress attachment point. NTT performs Origin Validation only in "ebgp-in" policies. Other protection mechanisms still apply: maximum prefix limits, routes that have bogon ASNs anywhere in the AS_PATH are rejected, if a Peerlock protected ASN shows up anywhere in the AS_PATH the route is blocked, and of course prefix-list filters generated from IRR data are still in use. > I'm sure you guys thought about this, but I'm just wondering what you > did to prevent the scenario I just described :). In the general case we can assume your BGP peers have a backbone and will announce all their routes to you at every interconnection point. One way to look at RPKI deployment progress is to view it as incremental reduction of your risk surface. For each peer ASN where the operator applies Origin Validation on every individual BGP session with that specific ASN, the needle is moved a little bit. I observed one interesting situation that might be good to share with the group: there was one specific BGP session (with one of our larger peering partners) on which we were not anble to enable RPKI Origin Validation for technical reasons. I reached out to the peer to discuss what could be done because NTT was receiving a substantial amount of routing information via this session (all of valid, invalid, and not-found). It would be suboptimal if we manage to block a hijack on 29 out of the 30 BGP sessions yet still end up carrying the incorrect route because of that 30th session. The peering partner isn't there yet for full scale global deployment in their whole network, but they did already have some experience with RPKI. The solution they came up with was to enable RPKI OV on that one session in the /outbound/ direction (their 'ebgp-out' policy, the announcements from that peer towards NTT). This closed that tiny gap through which invalids could still propagate from this peer's customer cone into NTT's network. Peers scratching each other's back :-) Kind regards, Job </blockquote></div> <div> </div>-- <div dir="ltr" class="gmail_signature"><a href="http://about.me/AphroditeEmpire" target="_blank">http://about.me/AphroditeEmpire</a></div>