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