Re: [sidr] draft IETF 75 meeting minutes uploaded
Geoff Huston <gih@apnic.net> Tue, 25 August 2009 03:36 UTC
Return-Path: <gih@apnic.net>
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB5B3A6837 for <sidr@core3.amsl.com>; Mon, 24 Aug 2009 20:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.181
X-Spam-Level:
X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwv8Fj5w63yv for <sidr@core3.amsl.com>; Mon, 24 Aug 2009 20:36:56 -0700 (PDT)
Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id D1C083A68EA for <sidr@ietf.org>; Mon, 24 Aug 2009 20:36:54 -0700 (PDT)
Received: from [218.189.94.92] (unknown [218.189.94.92]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 9A5B5110066; Tue, 25 Aug 2009 13:36:53 +1000 (EST)
Message-Id: <0D3F2A5C-5900-4D11-A34D-AD2D6E732944@apnic.net>
From: Geoff Huston <gih@apnic.net>
To: Sandra Murphy <sandy@sparta.com>
In-Reply-To: <Pine.WNT.4.64.0908241745220.3780@SANDYM-LT.columbia.ads.sparta.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 25 Aug 2009 13:36:48 +1000
References: <Pine.WNT.4.64.0908241745220.3780@SANDYM-LT.columbia.ads.sparta.com>
X-Mailer: Apple Mail (2.936)
Cc: sidr@ietf.org
Subject: Re: [sidr] draft IETF 75 meeting minutes uploaded
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2009 03:36:58 -0000
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. So I've taken the liberty of reviewing Roque's notes and editing them a little - I hope this is useful 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.
- Re: [sidr] draft IETF 75 meeting minutes uploaded Stephen Kent
- [sidr] draft IETF 75 meeting minutes uploaded Sandra Murphy
- Re: [sidr] draft IETF 75 meeting minutes uploaded Geoff Huston
- Re: [sidr] draft IETF 75 meeting minutes uploaded Randy Bush
- Re: [sidr] draft IETF 75 meeting minutes uploaded Sandra Murphy
- Re: [sidr] draft IETF 75 meeting minutes uploaded Roque Gagliano
- Re: [sidr] draft IETF 75 meeting minutes uploaded Samuel Weiler