draft-ietf-sidr-roa-format draft-ietf-sidr-arch

1. draft-ietf-sidr-roa-formatdraft-ietf-sidr-arch Matt Lepinski BBN Technologies

2. ROA Format : Final Open Issue • Finished working group last call following IETF 76 • One open issue remains • When the architecture document describes the relationship between ROAs and EE certs, it includes cautionary text that roughly says: • Make sure you issue a new ROA for a prefix before you go and revoke the EE cert associated with the old ROA for that prefix (provided, of course, that you want to prefix to continue to be routed) • That is, ROAs can potentially affect routing, so “make before break” • We received a comment during last call that similar text should be added to the ROA-Format document

3. ROA Format : Final Open Issue • I took a stab at writing such text and posted it to the list • Feedback = The text I posted did not belong in ROA Format • Two options to close out this document: • Working group consensus that the “make before break” message is inappropriate in the ROA Format document • Working group consensus on appropriate text to deliver the “make before break” message in the ROA Format document • The following slide has strawman text • Please comment if you have a strong opinion on this issue • Let’s get this resolved soon so that we can progress the document

4. ROA Format : Strawman Text • For Section 3 (ROA Validation) “The validity of a ROA may potentially affect the routing of packets on the Internet. Therefore, one should exercise caution in revoking the EE cert included in a ROA (which causes the ROA to become invalid). It is RECOMMENDED that one issue a new ROA for a prefix prior to revoking an old ROA for the prefix to ensure that no interruption of routing to that prefix occurs.”

5. SIDR Architecture • Finished working group last call following IETF 76 • Numerous editorial improvements and minor bug fixes suggested • E.g., RSYNC bug, cite to rescerts-provisioning, fix to repository access protocol text, etc • One issue related to origination validation and partial deployment that requires additional discussion

6. SIDR Architecture : Open Issue • Currently, the architecture document describes the RPKI ecosystem (certificates, ROAs, manifests, etc) at a high-level, and describes what an address holder needs to do to participate in the RPKI. • The document is silent on how a relying party actually uses RPKI data (e.g., for origin validation). • Comments received during last call suggest that some would appreciate a discussion of the use of RPKI data (particularly, in a partial deployment scenario). • The following slide outlines one possible approach to resolving this issue

7. SIDR Architecture : Strawman • If there were working group consensus on the high-level approach currently specified in sidr-roa-validation • Then the architecture document could have text: • Describing the incremental deployment scenario • Providing a high-level description of “valid”, “unknown” and “invalid” and providing a pointer to sidr-roa-validation • Emphasizing that the use of RPKI data in route selection is a matter of local policy (and referencing any drafts that provide appropriate mechanisms for implementing such policy)

8. Thank You