The Resource Public Key Infrastructure (RPKI) to Router Protocol
draft-ietf-sidr-rpki-rtr-26

[Ballot comment]
Thank you for addressing my comments and those from the AppsDir reviewer. The new text about TLS is well formulated, and I'll be pointing future authors to it as a model for how to use RFC 6125.

[Ballot comment]
This is a well written and much needed document, thank you for writing it.

(The only worry that I had was that there was a long list of different security mechanisms, perhaps too many for interoperability.)

[Ballot comment]
I second Pete's query about ASCII-only error text.

The AppsDir review by Lisa Dusseault asks some questions that deserve a response:

http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04230.html

Section 2 states:

  Serial Number:  A 32-bit monotonically increasing unsigned integer
      which wraps from 2^32-1 to 0.

Do you mean "strictly increasing" instead of "monotonically increasing"?

Section 10 states:

  This section contains a preliminary list of error codes.  The authors
  expect additions to this section during development of the initial
  implementations.

A forward reference to the IANA considerations would be friendly here.

IDnits reports:

  ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925)

[Ballot discuss]
There are two interrelated issues I'd like to chat about with respect to TLS transport.

Section 7.2 states:

  If such certificates are used, the CN field [RFC5280]
  MUST be used to denote the router's identity.

What is meant by "identity" here? Is there a specific identifier that ought to be included in the CN (e.g., IP address or FQDN)? The term "identity" is nearly void for vagueness.

Then: "Clients SHOULD verify the cache's certificate". It would be good to specify more clearly what is meant by certificate verification (e.g., using the rules from RFC 2818 or RFC 6125).

[Ballot comment]
1. It would be useful for the readability of the document to have acronyms expanded at the first occurence (starting with RPKI)

2. In Section 5.9: 

> The diagnostic text is optional, if not present the Length of Error
  Text field SHOULD be zero.

Why is this a SHOULD?

3. Same:

> If error text is present, it SHOULD be a
  string in US-ASCII, for maximum portability; if non-US-ASCII
  characters are absolutely required, the error text MUST use UTF-8
  encoding.

Pete already refered to this. RFC 2277 mandates implementing UTF-8, so what is the reason for recommending US-ASCII?

[Ballot comment]
Minor editorial suggestion - section 5.10 seems out of order
and would have been more useful to me if it had appeared
before the definitions of the PDU fields in section 5.

[Ballot comment]
- "Formally" and "simple but reliable" in the abstract and intro
seem to be marketing text.

- I (still) don't like where it says you SHOULD do ACLs or
something. (The text in the document uses "..." rather than "or
something" but that's the meaning.)  Just delete the elipsis or
actually give a non-ACL example of what one might sensibly do.

- I agree with the comments about the expansion of MITM but,
like everyone else probably, don't care that much.

[Ballot comment]
In 5.9:

  If error text is present, it SHOULD be a
  string in US-ASCII, for maximum portability; if non-US-ASCII
  characters are absolutely required, the error text MUST use UTF-8
  encoding.

I'm trying to suss out what "maximum portability" means. Is UTF-8 known to screw up some implementations (in which case the SHOULD is justified), or is it just that you're being super-conservative, or worse, that you're afraid some non-English might end up in the error log? :-) Unless there's a real worry for interoperability here, just define the thing as UTF-8 (which means that US-ASCII still looks like US-ASCII) and be done with it.

A reference to RFC 3629 might be extra friendly.

IANA has questions about the port registrations requested by
draft-ietf-sidr-rpki-rtr-19.txt:

QUESTIONS: "RPKI-Rtr" and "RPKI-Rtr TLS" aren't valid service names, per
RFC 6335; we can't use capital letters or spaces. Should we use these in
the description field? If not, how should we fill in the description
field for the two new port numbers?

Should we use "rpki-rtr" and "rpki-rtr-tls" for the service names?

ACTION 1:

IANA will register the following ports in the 0-1023 range:

Port Number: TBD
Service Name: rpki-rtr
Transport Protocol: TCP
Description: RPKI-Rtr (?)
Assignee: IESG
Contact: IETF Chair
Reference: [RFCXXXX]

Port Number: TBD
Service Name: rpki-rtr-tls
Transport Protocol: TCP
Description: RPKI-Rtr TLS (?)
Assignee: IESG
Contact: IETF Chair
Reference: [RFCXXXX]


ACTION 2:

IANA will create the following registry at
http://www.iana.org/assignments/rpki

Registry Name: rpki-rtr-pdu
Registration Procedure: RFC Required (Standards Track or Experimental)

Protocol
Version PDU Type Description Reference
-------- -------- ----------- ---------
0 0 Serial Notify [RFCXXXX]
0 1 Serial Query [RFCXXXX]
0 2 Reset Query [RFCXXXX]
0 3 Cache Response [RFCXXXX]
0 4 IPv4 Prefix [RFCXXXX]
5 Unassigned
0 6 IPv6 Prefix [RFCXXXX]
0 7 End of Data [RFCXXXX]
0 8 Cache Reset [RFCXXXX]
9 Unassigned
0 10 Error Report [RFCXXXX]
11-254 Unassigned
0 255 Reserved [RFCXXXX]


ACTION 3:

IANA will create the following registry at
http://www.iana.org/assignments/rpki

Registry Name: rpki-rtr-error
Registration Procedure: Expert Review

Value Description Reference
----- ------------------------------- ---------
0 Corrupt Data [RFCXXXX]
1 Internal Error [RFCXXXX]
2 No Data Available [RFCXXXX]
3 Invalid Request [RFCXXXX]
4 Unsupported Protocol Version [RFCXXXX]
5 Unsupported PDU Type [RFCXXXX]
6 Withdrawal of Unknown Record [RFCXXXX]
7 Duplicate Announcement Received [RFCXXXX]
8-254 Unassigned
255 Reserved [RFCXXXX]


ACTION 4:

IANA will register the following SSH Connection Protocol Subsystem Name
at http://www.iana.org/assignments/ssh-parameters

rpki-rtr [RFCXXXX]

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:  (The RPKI/Router Protocol) to Proposed Standard


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'The RPKI/Router Protocol'
  as a Proposed Standard

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-12-13. 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.

Abstract


  In order to formally validate the origin ASs of BGP announcements,
  routers need a simple but reliable mechanism to receive RPKI
  [I-D.ietf-sidr-arch] prefix origin data from a trusted cache.  This
  document describes a protocol to deliver validated prefix origin data
  to routers.





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

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


No IPR declarations have been submitted directly on this I-D.

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

Shepard: Chris Morrow
Has been read: True
Is Document Ready: True


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

Adequate Review: True
Existing Concerns: False

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

Need Further Review: False

(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.

Specific Concerns: False
IPR issues: False

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

Consensus Reached: True
Solidity: Solid

(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.)

Appeals Threats: False

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

ID-Nits has 2 outstanding issues,
Authors to fix in IESG Review (down ref + obsolete ref,
non-critcal)

(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].

Split Refs: True

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


Consistent/IANA Section: True

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

Format Language Checks: True

(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.

"In order to formally validate the origin ASs of BGP announcements,
routers need a simple but reliable mechanism to receive RPKI
[I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This
document describes a protocol to deliver validated prefix origin data
to routers."


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?

WG Summary: Significant discussion on-list about authentication
protocols to be used between the 2 parties in play
(router/cache), this did wind down to a conclusion though, which
is a positive result.

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?

Quality: Fine