10 Mar 2008, 1740 - 1950
Geoff Huston & Sandy Murphy
Russ Mundy
Administrivia
SIDR and Origin Validation - Geoff Huston
Certificate Policy and CPS drafts - Steve Kent
Certificate Policy
http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-03.txt<
CPS for ISPs
http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-isp-02.txt
CPS for Registries
http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-03.txt
RPKI Architecture Update - Matt Lepinski
http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-03.txt
Route Originations - Matt Lepinski
http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-02.txt
Repository Structure - George Michaelson
http://www.ietf.org/internet-drafts/draft-huston-sidr-repos-struct-01.txt
ROA Validation - George Michaelson
http://www.ietf.org/internet-drafts/draft-huston-sidr-roa-validation-00.txt
Bogon Origin Attestations - Geoff Huston
http://www.ietf.org/internet-drafts/draft-huston-sidr-bogons-00.txt
The WG agenda items covered the overall approach being used by the WG to address the issues of origin validation and then examined a number of specific aspects of routing origination attestations in relation to a Resource PKI.
Following a report to the WG from RPSEC on requirements for BGP routing security, it was noted that no clear guidance on the topic of AS Path validation was forthcoming. SIDR should undertake a solution for AS Path validation. The AD suggested that the charter revision should be done by IETF72.
One general comment at the end of the meeting was that it would be useful to have a roadmap for the relationship and anticipated timing of completion of the various work items discussed during the meeting. The co-chairs acknowledged that this might be useful, but should be discussed further on the WG mailing list.
SIDR and Origin Validation
Geoff Huston presented a status report on the SIDR Working Group activities relating to origination validation in inter-domain routing.
The presentation provided a summary of the reason for creation of SIDR and set of requirements for the working group. The main focus of the working group is the specification of a PKI that supports validation of origination information contained in the routing system, and the manner in which validation tools could be incorporated into the routing architecture.
Questions / Comments:
There was no controversy related to the presentation but the AD asked where the information was described. Geoff acknowledged that he needed to write an RFC to document much of what he presented in his summary.
During the presentation, there was also a discussion about the SIDR requirements and work being "locked to RPSEC". The general sense of the room was that this should be changed in the SIDR charter - no one in the room objected to this change. Part of this discussion of SIDR working group scope was taking on solving the problem of path validation. The sense of the room was that SIDR should undertake a solution for path validation. The AD suggested that the charter revision should be done by IETF 72.
ACTIONS:
Certificate Policy and CPS drafts
Steve Kent presented on three CP and CPS drafts. The most significant changes since the previous WG meeting has been with the CPS template for RIRs. The majority of this work focused on enhancing the template so that less work will be needed on the part of RIRs using the templates. Steve has worked with APNIC in completing their CPS, which they were able to do in two days. One important aspect pointed during the presentation was that a business PKI that is separate from the resource PKI will be required.
Questions / Comments:
During the discussion from the floor, there was a suggestion that a complete template be created that could be used by ISPs. This was accepted as a good suggestion.
Another comment was that it would be useful to have a template that says the ISP has no liability of any sort.
RPKI Architecture Update
Matt Lepinski presented on the RPKI architecture. The opening request is for everyone to read and comment on the draft. Matt considers the current text is to be inadequate in certain areas, and requests inputs with specific, new text.
Questions / Comments:
There was some discussion about changing the scope of this document so that it would align with the expected charter changes. The general sense of the room was to keep the current scope and focus on completing the document. The document probably needs some clarification regarding intended scope. Additionally, the document is intended to provide examples rather than explicit directions so some words need to be updated.
ACTIONS:
Route Originations
Matt Lepinski presented on the current ROA specification document and the current issue relating to whether to add the capability for multiple signatures into a ROA or not. A specification as to how multiple signatures could be included in the ROA was presented.
Questions / Comments:
There was a significant discussion about the ROA format and number of signatures on a ROA. There were generally two (opposing) views expressed there were largely the same as have been expressed on the mail list. The minute takers' general summary of the issue is:
During the discussions, some new ideas such as specifying the use of multiple signatures on a ROA but defining that only one signature will be used initially on a ROA - a request was made for Jeffrey Hass write up this idea for the WG.
There was also a suggestion that if multiple signatures were used, they should only be applied when multiple parties were involved.
Geoff suggested that it might be useful to specify that validation of a ROA would not be done over any larger address space than contained in the ROA. A ROA cannot be used to validate any object that is larger than the span of the address in the ROA. The implication of this limitation is that if it is required to sign an aggregate address object where the components are drawn from distinct validation paths, then multiple signatures in the ROA would be necessary.
ACTIONS:
Repository Structure
George Michaelson next presented on the Repository Structure draft. The draft has been pretty much rewritten since the -00 draft, in response to a batch of inputs. The slides provide a summary of the changes from the 00 version.
The authors believe that the 01 version incorporates the comments they received to date. They would also like to have further review and comments on the draft.
Questions / Comments:
During this presentation, a member of the working group asked if this was the right time to discuss the issues around the use of rsync as defined in the specification. There have been discussions about this on the WG list but they have not been conclusive. After some discussion in the meeting, Sandy took an action to write a description and summary of the rsync related issues and send it to the WG list and AD. At this point, it sounds like the working group members in the room see the need to have specific agenda time to discuss these issues at the IETF72 SIDR WG meeting.
ACTIONS:
ROA Validation
George Michaelson presented on ROA Validation. The list of issues in the last slide of the presentation may not be complete but are likely the ones that need to be worked on first - comments are solicited.
Questions / Comments:
Some of the substantive comments that were raised from WG members in the room related to operational timeliness and the amount of time needed to effect changes to signed originations, e.g., an ISP moves all traffic from one link to another (changing origination point and issuing a new ROA) but their traffic is not being delivered everywhere since some places are validating on the old ROA - a 24 hour cycle to get the new information in place is not operationally acceptable. Geoff & Steve both pointed out that relying parties can update information more frequently than 24 hours but there is no way to force people to update information on any particular period of time. The generic response to this was to pre-provision the necessary security credentials in the RPKI in advance of the use of a particular origination arrangement in the routing system.
There was also discussion about approaches that were needed during the transition period of particular adoption, when ROAs are being issued for some but not all originations. Some ideas are included in the draft and summarized in the slides. The working group was asked to think about transition and contribute additional ideas.
Bogon Origin Attestations
Geoff Huston presented on Bogon Origin Attestations. The concept motivating the BOA idea is to provide a mechanism for legitimate holders of resources to make an authenticatable statement the certain resources should not be appearing in the routing system. In general, BOAs are modeled after ROAs but if a relying party encounters both a ROA and a BOA for a given space, the ROA will always override a BOA.