Re: [sidr] draft IETF 75 meeting minutes uploaded

[Sandra Murphy <[e-mail]>]

On Tue, 25 Aug 2009, Geoff Huston wrote:

>
> On 25/08/2009, at 7:48 AM, Sandra Murphy wrote:
>
>> The draft of the minutes (thanks, Roque) has been uploaded to the IETF75 
>> meeting materials page at 
>> http://www.ietf.org/proceedings/75/minutes/sidr.txt.
>> 
>> Please review these minutes and provide comments or corrections to the 
>> list.
>> 
>
>
> Hi,
>
> The audo recordings of the meeting provide a good record of what was said, so 
> it might make sense for the minutes to attempt to provide a summary of 
> discussion and note actions and outcomes.

I recognize that the audio recordings are complete and accurate (as far as 
the quality allows).  However, review of the audio recording is difficult, 
as it is strictly sequential access.

I believe that the minutes record of the discussion has value over the
audio recording.  The minutes should indeed record actions agreed to in
the meeting and any consensus, and it should also record the opinions 
expressed, so that those unable to attend know what was considered.


>
> So I've taken the liberty of reviewing Roque's notes and editing them a 
> little - I hope this is useful

I appreciate the more compressed report style of what you propose, but I 
do not think that they should replace the minutes taken during the 
meeting.  Not only are the details beneficial (without listening to the 
entire audio recording, as I said above), but the summary style you 
propose requires effort I don't want to require of the minutes taker.

I'm appreciate that you put some effort into this summary and I don't want 
to lose the results.  Would you prefer to leave this summary archived in 
the mailing list, or would you prefer to see it appended to the minutes 
for the proceedings?

--Sandy

>
> thanks,
>
>  Geoff
>
> -----------------
>
>
> IETF75
>
> SIDR WG
> Thursday, July 30, 2009     0900-1130
>
> Chairs: Sandy Murphy, Geoff Huston
> Minutes: Roque Gagliano.
>
> Actions:
>
> WG consideration of a document that specifies algorithm and key
> sizes for all RPKI components
>
> Revise the CP to include text that limited the applicability of the
> RPKI such that validly signed objects would need to be specified in
> an IETF Standards track document.
>
> The RPKI CP should stay within the IETF process, as a BCP.
>
> The WG Chairs will consult the AD for guidance on the topic of the
> WG charter and the program of future activity for this WG.
>
> Notes:
>
> 1. Updated Drafts
>
> 1.1 ROA Format
>    A Profile for Route Origin Authorizations (ROAs)
>    draft-ietf-sidr-roa-format-05.txt
>    presenter: Matt Lepinski
>
> On the issue of algorithm agility, it was note that algorithm and
> key length specifications have been included in all RPKI documents
> up until now. This version of the ROA profile draft has replaced
> this with a reference to the CP document as an initial suggestion as
> to how to centralise all the references to a single specification
> document. The CP has been nominated as the appropriate document to
> carry the RPKI algorithm and key length specification, but this is a
> matter for discussion by the WG. The other option is a separate WG
> document which carries only this common algorithm and key length
> specification, as is proposed by Geoff Huston.
>
> Discussion:
>
>   Russ Housley noted that many WG have make this mistake. The issue
>   here is that in order to subsequently change algorithms, there is
>   a need to update all the documents. In this case, if you use the
>   CP, you need to update the complete CP. This has delayed other
>   work in the Security Area in the past. Russ recommends the WG
>   adopting a dedicated document that described algorithms, and this
>   document is to be referenced in the other documents.
>
>   Sandy Murphy commented that Roque Gagliano realized that one of
>   the problem is that you can get inconsistencies between documents.
>
>   Rob Austein commented that on problem with putting the algorithm
>   profile in the CP was that it was a lengthy and detailed document
>   was was eye-glazing for a reader, and Rob was unsure that
>   implementers will read it. Rob noted that he had no problem with a
>   single document to specify a common algorithm profile for the
>   RPKI, but it should not be the CP.
>
>   Roque Gagliano noted that the CP is intended to be maintained by
>   different organizations revisions to the CP in the case of a
>   technical requirement for algorithm change, and the organizational
>   review process of the CP may be inappropriate for such a
>   task. Roque concurs on having a dedicated document for this
>   specification.
>
>   Sandy Murphy, as Chair, thanked Roque for noticing the problem
>   with the key length in different documents.
>
>
> 1.2 RPKI Architecture
>    An Infrastructure to Support Secure Internet Routing
>    draft-ietf-sidr-arch-07.txt
>    presenter: Matt Lepinski
>
> The change to this document was that the Certificate's Subject Name
> has been specificed as not intended to be meaningful across the
> entire RPKI, and the exception noted RIR and other entities have
> been removed from the draft. Subject Names are not intended to
> convey meaningful information and must be unique. The WG was
> requested to review the most recent draft of this document.
>
> Discussion:
>
>   Sam Weiler asked in IANA was to remain a special case in this
>   respect. Matt indicated that this was not the case.
>
> 1.3 Certificate Policy
>    Certificate Policy (CP) for the Resource PKI (RPKI)
>    draft-ietf-sidr-cp-06.txt
>    Presenter: Stephen Kent
>
> Steve Kent noted that Andrei Robachevski, as a representative for
> the RIRs, gave the document's editors substantial feedback arising
> from an RIR staff review. The changes applied as a result of these
> comments are noted in the presentation. The revision has removed CP
> approval procedures to be made by the organizations administering
> the CP, although it was noted that this may need further review, as
> the also CP relates to ISPs and other organizations who undertake a
> CA role in the context of the RPKI.
>
> Discussion:
>
>   Randy Bush inquired as to the current recommendations regarding
>   management of the CP document, and it was noted that the current
>   draft of the CP called on the RIRs and IANA to manage the process
>   of updates to the CP.
>
>   Steve Kent noted that there was a confident expectation that the
>   algorithm and key size may change over time, and if this
>   specification was to be placed into the CP, then the process
>   regarding changes to the CP would need to take this into
>   account. Steve noted that he agreed with Geoff and Russ about
>   having a different document for algorithm and key profile for the
>   RPKI to address this.
>
>   Russ Housley spoke to question of the CP update process and which
>   party was placed in the role of approval of changes to the
>   CP. Russ noted that topics that are local RIR and ISP policies
>   have impact beyond the CP, and would normally be left to the
>   CPS. Russ was in favour of a position where the RPKI CP should
>   stay within the IETF process, as a BCP, and other parties,
>   including the RIRs and ISPS, would maintain their CPS documents
>   regaring local policies.
>
>   Randy Bush raised the question of the scope of the RPKI in terms
>   of the validity of arbitrary documents signed using signatures
>   that are validated within the RPKI. Steve Kent noted that one
>   response to this concern was the possible inclusion of text in the
>   CP that limited the applicability of the RPKI such that validly
>   signed objects would need to be specified in an IETF Standards
>   track document.
>
>
> 1.4 RPSL with RPKI Signatures
>    Securing RPSL Objects with RPKI Signatures
>    draft-ietf-sidr-rpsl-sig-01.txt
>    Presenter: Robert Kisteleki
>
> It was noted that the document had been revised with minor changes,
> including text on URL safeness, modifications to the procedure to be
> used for text normalization modified, additional text on number
> resource coverage, and the general caveat that the certificate that
> signs an RPSL object must have some verifiable relationship with the
> content of that object.
>
> Future plans for this draft include the use of normative text, a
> worked example as an appendix, and running code for next IETF.
>
> Discussion:
>
> Steve Kent noted that more precision would be helpful in describing
> the intended limitations on the certificate that signs the RPSL
> object, and voiced a more general observation that in his view many
> things in RPSL are orthogonal to RPKI, and this may have an impact
> on the consistency with the CP. Robert Kisteleki noted in response
> that he believed that this intended approach was consistent with the
> CP, in that in this context a resource holder is signing an
> attestation relating to the intended use of a resource.
>
> 1.5 BGP Considerations
>    BGP Prefix Origin Validation
>    draft-pmohapat-sidr-pfx-validate-01.txt
>    draft-ymbk-rpki-rtr-protocol-04.txt
>    Presenter: Randy Bush & Dave Ward.
>
> The WG was requested to consider whether to adopt
> draft-pmohapat-sidr-pfx-validate as a WG document.
>
> Discussion:
>
>   The question was raised as to how this document related to the
>   draft-ietf-sidr-roa-validation draft, which will be taken to the
>   WG mailing list, together with the question of WG adoption of the
>   pfx-validate draft.
>
>   The question was also raised as to the relationship between the
>   pfx-validate draft and the rtr-protocol draft. Matt Lepinski
>   voiced the view that both drafts were helpful contributions should
>   be considered for WG adoption.
>
> 2. New Drafts
>
> 2.1 Use Cases
>
>    Use Cases and interpretation of RPKI objects for issuers and
>    relying parties
>    draft-manderson-sidr-usecases-00.txt
>    Presenter: Terry Manderson
>
> The motivation for this document was to gain a common understanding
> of the problem space by example. The WG was requested to review the
> draft and provide comments.
>
> Discussion:
>
>   Danny McPherson raised the question of the relationship of this
>   document to the SIDR WG charter. The WG discussed the issue
>   relating to the study of validation of AS Path in relation to the
>   current WG charter.
>
>   Ross Callon, speaking as Routing AD noted that this had already
>   been considered at length in RPSEC, and if there was a prospect of
>   reaching some consensus as to requirements relating to Path
>   validation then this should be proposed as an addition to the WG
>   charter. As a first step, however, origination was the area where
>   clear requirements have been provided to SIDR from RPSEC.  This
>   topic should be taken to the WG mailing list for further
>   consideration.
>
>   Randy Bush noted that the work on origination validation was a
>   major achievement and this work should be completed before
>   embarking on another major effort.
>
>   Russ Housley, speaking as IETF Chair, noted that the SIDR charter
>   is clear on this, and requirements need to come from the RPSEC
>   WG. The WG needs to ask the AD where are the requirements going to
>   come from, and it is appropiate for the WG to seek AD guidance on
>   this topic.
>
>   Danny McPherson voiced the opinion that what the WG may decide on
>   origination may restrict the options in addressing path
>   validation. The WG discussed the topic of origination and path
>   validation and there was no clear agreement that the SIDR WG
>   approach to origination necessarily restricted the scope of
>   mechanisms that could be used for path validation.
>
> The WG Chairs will consult the AD for guidance on the topic of the
> WG charter and the program of future activity for this WG.
>
> 2.2 Interpretation of ROA in Origination Validation
>    presented K. Sriram
>
> A particular case of issuing ROAs was presented by K. Sriram and
> discussed by the WG, as an extension of the use-case study and ROA
> validation.
>
> 3. New Topics
>
> 3.1 Local Trust Anchor Management
>    Presenter: Steve Kent
>
> Presentation outlining an approach where Relying Parties could
> generate a TA locally from existing RPKI information.
>
> Discussion:
>
> Randy Bush commented that this has all the problem of unique DNS
> root, where different views of the routing table may result. He
> noted that this approach may have use for private address space. In
> response it was noted that this approach created potential
> differences if there was an inconsistency in the RPKI space and the
> relying party believed it had sufficient information to resolve this
> in favour of one party of the other.
>
> It was also noted that this approach was always viable for RPs, and
> could not be prevented. Rob Austein commented that a RP can know
> more but can also know less that the public universe. The problem
> with multiple roots is that the RP may not have enough information
> on what to do when there is a conflict, nor have the ability to
> resolve these conflicts in a manner that was consistent with the
> linkage between the RP's local TA and the RPKI.
>
>
>