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

[Geoff Huston <[e-mail]>]

Hi Iljitsch,

> But now what if a certificate expires? We know from the web that this is extremely common. If an expired certificate means the prefixes involved are marked invalid, this means that filtering invalids becomes very problematic: not only will prefixes randomly drop off the net as people forget to generate or install certificates or RPKI caches get stale, but if things get really bad the resulting lack of connectivity makes it impossible to correct the problem…
> 
> So what we need is for expired certificates to make the affected prefixes revert to unknown rather than invalid. Turns out, that's what happens today:
> 
> http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html
> 


yup, becuase an expired certificate is not used for validation of ROAs, so a route object that is only referred to by a ROA that cannot be validated is “unknown” in this taxonomy. It is not “invalid" by virtue of an expired certificate.


> However, unless this is specified in one of the related documents other than the three mentioned above, this seems to be an implementation choice.


to quote RFC6483: 

  "It is assumed here that a relying party (RP) has access to a local
   cache of the complete set of valid ROAs when performing validation of
   a route.  (Valid ROAs are defined as ROAs that are determined to be
   syntactically correct and are signed using a signature that can be
   verified using the RPKI, as described in [RFC6482].)

i.e. the route validation process that produces this set of valid, invalid and unknown outcomes is based on the set of valid ROAs. ROAs that cannot be validated (i.e. due to expired certificates and other causes) are not considered in the route validation process described in RFC6483.

 
> 
> I think the above issue needs to be discussed in an update of RFC 6483 or in one of the BGPsec documents.


It’s not clear to me that any further text needs to be added to RFC6483. The underlying process is one based on examination of the route feed and comparing each received route object to a collection of attestations and authorities that have been validated by the relying party as trustable.

> 
> And there's probably a bit more to think about: wouldn't it make sense to be able to filter on the signature algorithm at some point during the transition from one algorithm to the next? Or to be able to filter on "expired" explicitly? A binary valid/invalid isn't enough. Valid/unknown/invalid is workable, but maybe four or five levels is even better.
> 
> (And have a look at how this works in practice: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html search for PEX.)
> 


regards,

   Geoff