[routing-wg] NTT/AS2914 enabled RPKI OV 'invalid = reject' EBGP policies

A very big step forward, Congrats.

On Sat, Apr 4, 2020 at 9:05 PM Job Snijders <job at ntt.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/routing-wg/attachments/20200404/43f0eed6/attachment.html>