A very big step forward, Congrats. On Sat, Apr 4, 2020 at 9:05 PM Job Snijders <[email protected]> wrote:
> 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 > > -- http://about.me/AphroditeEmpire
