draft-ietf-sidr-roa-formatdraft-ietf-sidr-arch

Matt LepinskiBBN 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 TextFor 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 ArchitectureFinished working group last call following IETF 76Numerous editorial improvements and minor bug

fixes suggested E.g., RSYNC bug, cite to rescerts-provisioning, fix to

repository access protocol text, etcOne issue related to origination validation and

partial deployment that requires additional discussion

6

SIDR Architecture : Open IssueCurrently, 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 : StrawmanIf 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