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.