draft-ietf-sidr-roa-format draft-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)

Thank You