Iljitsu, 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.
I guess your point is covered. Roque Sent from my HTC ----- Reply message ----- From: "Iljitsch van Beijnum" <iljit...@muada.com> To: "Sandra Murphy" <sa...@tislabs.com> Cc: "i...@ietf.org wg" <i...@ietf.org>, "g...@apnic.net" <g...@apnic.net>, "sidr@ietf.org" <sidr@ietf.org> Subject: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Date: Tue, Apr 28, 2015 20:02 On 28 Jan 2015, at 23:38, Sandra Murphy <sa...@tislabs.com> wrote: > idr folk, your attention and comments would be appreciated as well. Since you ask... I'm sending this to both idr and sidr as I think this needs broader input than just sidr. (And it seems I'm no longer on the sidr list.) I read draft-ietf-sidr-bgpsec-protocol-11 and draft-lepinski-bgpsec-overview-00.txt as well as RFC 6483. I think what's lacking here is any discussion of what happens when certificates etc expire. Please stay with me for a bit: RFC 6483 talks about RPKI route validation, which suggests that there are three possible states: valid unknown invalid where valid is preferred over unknown and unknown over invalid, and: "It is a matter of local routing policy as to whether routes with an "invalid" validity state are considered to be ineligible for further consideration in a route selection process." Actually, I think the only reasonable approach is to filter out invalids and prefer valids over unknowns. The important part here is that if there's a ROA for 193.0.0.0/21 and then someone announces a more specific like 193.0.7.0/24, that /24 will be "invalid", so even in partial deployment RPKI users are protected against malicious or accidental more specifics. But if invalids are accepted, even with a very low preference, then they still get to divert traffic. So far, so good. 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 However, unless this is specified in one of the related documents other than the three mentioned above, this seems to be an implementation choice. I think the above issue needs to be discussed in an update of RFC 6483 or in one of the BGPsec documents. 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.) _______________________________________________ Idr mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/idr
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
