On Jan 8, 2010, at 2:12 PM, Matt Lepinski wrote: > II) Ticket #12 on the SIDR issue tracker. We envision that relying parties > will eventual use ROAs as an input to routing decisions. We received feedback > that cautionary text should be added to ensure proper relying party behaivor > in the case where a previously valid ROA becomes invalid. For example, if a > certifaction authority revokes a ROA containing many prefixes and at the same > time issues a new ROA covering a subset of those prefixes (for the same AS) > then nothing should break for the prefixes covered by both the old and the > new ROA. Therefore, we added the following new text at the end of Section 3: > > "Note that a previously valid ROA will cease to be valid when the associated > end-entity certificate ceases to be valid. (For example, when the end of the > certificate’s validity period is reached, or when the certificate is revoked > by the authority that issued it. See [RESCERTS] for a complete specification > of resource certificate validity.) However, when ROAs are used as an input > for routing decisions, a relying party must fetch new ROAs from the > repository system before taking any routing action in response to a > previously valid ROA becoming invalid."
Matt, While I understand the issue and mostly agree with the crux of it (i.e, if someone deletes a policy make sure a corresponding new one wasn't added before taking some action that might break something), I'm not sure why any such prescriptive text for relying party operational procedures should exist as a MUST (well, "must"[?]) here, particularly in a standards track document about ROA profiles. I remain concerned that coupling the RPKI repository functions so closely to routing is going to wind up unnecessarily constraining how the RPKI system might be employed, either directly or indirectly by the routing system - or scaled, and possibly even limit or gate deployability or new functions (e.g., how to incorporate SWIPs that introduce no new routing semantics) as a result. I believe a framework for incremental deployment and dependencies during that deployment, giving heavy consideration to how employment of an RPKI might happen outside of a direct tie-in to secure routing protocols, would be worth undertaking by the working group. Else we're likely to end up with dependencies or race conditions that might well be avoided. -danny _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
