Re: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11

[Iljitsch van Beijnum <[e-mail]>]

On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) <[e-mail]> wrote:

> It is not an implementation choice, it is by design. If a signed object does not validate (based on whatever reason not just expiration), it is like if did not existed. 

No...

Suppose:

ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430

BGP table 29 april:

193.0.0.0/21   3333 -> valid
193.0.0.0/21   4444 -> invalid
193.0.7.0/24   3333 -> invalid
192.0.0.0/16   5555 -> unknown

But, two days later, after the ROA expires, do we have this:

193.0.0.0/21   3333 -> unknown
193.0.0.0/21   4444 -> unknown
193.0.7.0/24   3333 -> unknown
192.0.0.0/16   5555 -> unknown

or this:

193.0.0.0/21   3333 -> invalid
193.0.0.0/21   4444 -> invalid
193.0.7.0/24   3333 -> invalid
192.0.0.0/16   5555 -> unknown

?

You seem to be saying the second, but that wouldn't work, as a simple mistake would make AS 3333 unreachable. And since you need to connect to the internet in order to get a new certificate/ROA so you can connect to the internet...

The NANOG link I posted says it's the first case, which would be much more workable in practice: in that case, if a certificate expires before a new one is installed, you lose security but not connectivity. As we've successfully run BGP for 25 years without security, that's bad, but preferable to being unreachable.

Note also that the approach suggested in RFC 6483 and Cisco and Juniper documentation, where valid > unknown > invalid is not workable because then can still have traffic flow towards more specific prefixes even though they're invalid and have a very low local preference. The nice thing about RPKI is that you can deploy it TODAY if you filter invalids with the huge upside that you get rid of unauthorized more specifics, incurring only the very small risk that someone creates ROAs that conflict with their advertisements.

But the real issue is that this isn't written down anywhere as far as I can tell, so we're dependent on implementers all independently coming up with the preferred way to handle this. That's never good business for a standards organization.