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