Re: [sidr] draft IETF 75 meeting minutes uploaded

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sandy,

>
> 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?
>

I  believe that Geoff-s effort should not be lost and its content does  
not contradict my notes. I have no objection to append it to the  
minutes.

Roque.

> --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.
>>
>>
>>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkqUbnIACgkQnk+WSgHpbO6SqACgxDA9ilDUZB2fo3PRXlclnJjv
LTwAoMswb/IX+MSbDFhNq7Da6n++Nq8v
=n2mc
-----END PGP SIGNATURE-----