An Infrastructure to Support Secure Internet Routing
draft-ietf-sidr-arch-13

[Ballot discuss]
I am taking over Aexey Melnikov's discuss for administrative reasons

Discuss (2011-03-15)

This is a well written document and I support its publication. However I have a
small pedantic DISCUSS which should be easy to address:

1).
9. IANA Considerations

  This document requests that the IANA issue RPKI Certificates for the
  resources for which it is authoritative, i.e., reserved IPv4
  addresses, IPv6 Unique Local Addresses (ULAs), and address space not
  yet allocated by IANA to the RIRs. IANA SHOULD make available trust
  anchor material in the format defined in [SIDR-TA] in support of
  these functions.

Is this the right document? I thought that was already specified in draft-ietf-
sidr-iana-objects.

2).
11.2. Informative References

  [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI
              Scheme", RFC 5781, February 2010.

This reference is Normative, because of the use of a MUST.

Comment (2011-03-15)

4.2. Contents and structure

  For every certificate in the PKI, there will be a corresponding file
  system directory in the repository that is the authoritative
  publication point for all objects (certificates, CRLs, ROAs and
  manifests) verifiable via this certificate. A certificate's Subject
  Information Authority (SIA) extension provides a URI that references
  this directory.

An Informative reference to the URI RFC is needed here.

[Ballot discuss]
I am taking over Aexey Melnikov's discuss for administrative reasons

Discuss (2011-03-15)

This is a well written document and I support its publication. However I have a
small pedantic DISCUSS which should be easy to address:

1).
9. IANA Considerations

  This document requests that the IANA issue RPKI Certificates for the
  resources for which it is authoritative, i.e., reserved IPv4
  addresses, IPv6 Unique Local Addresses (ULAs), and address space not
  yet allocated by IANA to the RIRs. IANA SHOULD make available trust
  anchor material in the format defined in [SIDR-TA] in support of
  these functions.

Is this the right document? I thought that was already specified in draft-ietf-
sidr-iana-objects.

2).
11.2. Informative References

  [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI
              Scheme", RFC 5781, February 2010.

This reference is Normative, because of the use of a MUST.

Comment (2011-03-15)

4.2. Contents and structure

  For every certificate in the PKI, there will be a corresponding file
  system directory in the repository that is the authoritative
  publication point for all objects (certificates, CRLs, ROAs and
  manifests) verifiable via this certificate. A certificate's Subject
  Information Authority (SIA) extension provides a URI that references
  this directory.

An Informative reference to the URI RFC is needed here.

[Ballot comment]
From Ari Keränen's review:

9. IANA Considerations

  This document requests that the IANA issue RPKI Certificates for the
  resources for which it is authoritative, i.e., reserved IPv4
  addresses, IPv6 Unique Local Addresses (ULAs), and address space not
  yet allocated by IANA to the RIRs.

It would be good to have explicit references to the documents where each of these "resources" are defined.

draft-ietf-sidr-iana-objects-01 lists also AS numbers as such a resource; should that be listed here too?

[Ballot comment]
I am balloting "Yes" for this document, but there are a few minor nits
that I hope the authors will attend to before publication.

---

The Introduction uses "CRL" without explanation. This does show up in
the Terminology section that follows immediately, but it would be nice
to clarify in the Introduction.

---

CRLDP shows up in Figure 3 and nowhere else in the document.
Please add a note to the text.

---

Figure 1 seems to be mysteriously missing.

---

Section 4.3 has a slight disconnect between the specification of access
protocols and the deployment of access protocols. Thus, when you say...

  each function must be implemented by at least one access protocol.

...I think you mean...

  each function must be implemented by at least one access protocol
  deployed by a repository operator.

Similarly, when you say things like...

  Download: Access protocols MUST support the bulk download of 

...it is ambiguous whether you mean "all access protocols" or "at least
one access protocol in the suite of access protocols" or "at least one
access protocol deployed by the repository operator"

---

Section 4.3

  To ensure all relying parties are able to acquire all RPKI signed
  objects, all publication points MUST be accessible via RSYNC (see
  [RFC 5781] and [RSYNC]), although other download protocols also be
  supported.

s/also/may also/

---

Section 5

Since according to this text a manifest is a signed object, and since
the manifest is presumable issued by the authority, I would assume that
a manifest includes itself in its listing. But perhaps you should
clarify this one way or the other.

[Ballot comment]
4.2. Contents and structure

  For every certificate in the PKI, there will be a corresponding file
  system directory in the repository that is the authoritative
  publication point for all objects (certificates, CRLs, ROAs and
  manifests) verifiable via this certificate. A certificate's Subject
  Information Authority (SIA) extension provides a URI that references
  this directory.

An Informative reference to the URI RFC is needed here.

[Ballot discuss]
This is a well written document and I support its publication. However I have a small pedantic DISCUSS which should be easy to address:

1).
9. IANA Considerations

  This document requests that the IANA issue RPKI Certificates for the
  resources for which it is authoritative, i.e., reserved IPv4
  addresses, IPv6 Unique Local Addresses (ULAs), and address space not
  yet allocated by IANA to the RIRs. IANA SHOULD make available trust
  anchor material in the format defined in [SIDR-TA] in support of
  these functions.

Is this the right document? I thought that was already specified in draft-ietf-sidr-iana-objects.

2).
11.2. Informative References

  [RFC 5781] Weiler, S., Ward, D., and Housley, R., "The rsync URI
              Scheme", RFC 5781, February 2010.

This reference is Normative, because of the use of a MUST.

IANA notes that the IANA Actions related to this document are detailed
in another companion draft: draft-ietf-sidr-iana-objects-01.txt. IANA
understands that, upon approval of this document, the instructions
contained in the companion draft represent all of the IANA Actions
required for both the current document and the companion draft.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (An Infrastructure to Support Secure Internet Routing) to Informational RFC


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'An Infrastructure to Support Secure Internet Routing'
  as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sidr-arch/

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd is Sandra Murphy, sidr co-chair.  The document
shepherd has personally reviewed the document.  No issues were
discovered that would prevent advancement.  This document is ready
for forwarding to the IESG.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document has had adequate review.  It was presented at working
group meetings at the IETF70, IETF71, IETF73, IETF74, IETF75, IETF76,
and IETF77 meetings and went through last call in Nov 2010 in the
working group.  Comments received were addressed on the list.
There was adequate support from the working group to indicate broad
interest.


  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No, the document shepherd has no concerns about this document.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The document shepherd has no concerns with advancing this document. No
IPR claims have been filed against this document.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

There has been strong participation from the working group in producing
this document.  As the architecture for the work done in the working
group, it is the touchstone for most other drafts in the working
group.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No appeals have been issued or threatened for this document.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts
Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The tools site reports the following for this draft:

Summary: 1 error (**), 7 warnings (==), 3 comments (--).

The error is the existence of lines that are longer than 72 characters.
I believe that this error will be simple to correct when addressing
any comments received in IETF Last Call.

Most of the warnings have to do with missing or unused references.  The
missing references are caused by typos in the citations.

One warning may need to be addressed.  It reminds the authors that the
first version of the document was created before Nov 2008 and so the
document may need a pre-rfc5378 disclaimer.  This is an issue that has
been discussed with the authors and the routing ADs.

There are no formal reviews required for this document.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes, the document has split its references into normative and
informative sections.  This document relies normatively on several other
working group documents that are either advancing at the same time or
have been through last call and are awaiting final versions addressing
minor comments in order to advance.  This document is intended for
Informational status; none of the references are downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section exists and does not create a new
registry or entries in an existing registry.  However, the section
does point out that IANA may have a role to play in the defined
architecture and that role would create new obligations for IANA.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

There are no sections in this document written in a formal language.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

Technical Summary

This document describes an architecture for an infrastructure to
support improved security of Internet routing. The foundation of this
architecture is a public key infrastructure (PKI) that represents the
allocation hierarchy of IP address space and Autonomous System (AS)
Numbers; and a distributed repository system for storing and
disseminating the data objects that comprise the PKI, as well as
other signed objects necessary for improved routing security. As an
initial application of this architecture, the document describes how
a legitimate holder of IP address space can explicitly and verifiably
authorize one or more ASes to originate routes to that address space.
Such verifiable authorizations could be used, for example, to more
securely construct BGP route filters.

Working Group Summary

This draft's first version came early in the working group history.
It has been presented many times and has gone through many versions
but the outline remains essentially the same, indicating consistency
in the working group thinking. 

Document Quality

The document is well written and clear. It does not describe a protocol,
so there are no "implementations" per se. However, it serves as the
reference point for the other working group drafts, so the authors of
this draft and the authors of the other drafts have worked to ensure
that they remain mutually consistent.

There is no MIB and there is no Media Type. 

Several implementations exist of the PKI expressed in this architecture.
Implementation experience has been reflected in changes in the
architecture.