The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
RFC 8210

Received changes through RFC Editor sync (changed abstract to 'In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them.

This document describes version 1 of the RPKI-Router protocol. RFC 6810 describes version 0. This document updates RFC 6810.')

Received changes through RFC Editor sync (created alias RFC 8210, changed abstract to 'In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver them.', changed pages to 35, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2017-09-27, changed IESG state to RFC Published, created updates relation between draft-ietf-sidr-rpki-rtr-rfc6810-bis and RFC 6810)

[Ballot comment]
This document should update rfc6810 as discussed with responsible AD.

Here is my old discuss for the record:

This is a general discuss on the principle of using extension mechanisms (like versioning) and how and when to use it.

This document increases the version number to add one new PDU type as well as to clarify some questions on timing parameters. However, versioning is just one extensibility mechanism out-of a whole set of option. In this case the protocol also has an (8 bit) type field to define new PDU types. Only 8 types are used so far (in version 0 of the protocol) out of 2^8 which leaves another option for extending the protocol. The usually specification here is that the receiver will ignore unknown types which is exactly what you want. There in this case I don't see that a new version necessary.

Further there is an issue on how the versioning is done. This document looks like a bis document and used to obsolete the old spec till the last version (-07) but now neither updates nor obsolete it. If you actually decide to have a new version, that might be right (also updating might be an option which I would actually recommend in this case because I believe the expectation is that new implementation should always implement this version) but I don't really see in this case that duplicating all the text is the best option.

I would actually not recommend to increase the version because I really don't see a need for this, given the (much easier) extensibility mechanism you have with the type. If you'd only would like add the new type, then actually a short draft that defines the type and updates rfc6810 would be sufficient. Regarding the other clarification, I think this could also be done in a short (potentially the same) updating draft. If you still think it better to copy all the text and have one clean draft than obsoleting is the right choice.

[Ballot comment]
Thank you for a well written document.

I share Mirja's concern about versioning, her concern is related to my comment below.

Regarding obsoleting the original RFC: I am Ok with not doing that if both are going to be used at the same time, but I would like to hear from the WG whether this is the case.

I have one small issue I would like to discuss:

In section 7: what are the conditions for bumping the version number to 2? I think the document is missing some criteria for what would require a version change.

[Ballot comment]
I share Mirja's questions about versioning, and whether this updates or obsoletes 6810.

- 5, 2nd paragraph: Why is the SHOULD not a MUST? When might it make sense not to ignore the contents of a reserved field?

- 5.1, 6th paragraph: I'm not sure I understand the use of the word "commensurate" in this context.

- 9.2: Seems like a reference to RFC 7525 would be useful here.

[Ballot comment]

Review based on diff. [1]

[1] https://tools.ietf.org/rfcdiff?url1=rfc6810&url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt

- 5.1: To get around the hard-coded-sha1 thing could we do the
same with the 20 byte SKI value as we did on some other recent
RPKI spec? (IIRC, that was to say that if actual SKI is longer
truncate left, and if shorter pad left with zero, but please
check.)

- section 9: What's the background to removing the statement
that one of TCP-AO ssh etc SHOULD be used? What is the reality
of deployments here? I assume it is not TCP-AO anyway but does
TLS or SSH get used?

- various places: I think 6810 was correct in using "that" and
not "which" in many places. I realise that's a fairly frequent
style thing that gets toggled though, but I bet the RFC editor
sets a load of those back to "that" :-)

[Ballot discuss]
This is a general discuss on the principle of using extension mechanisms (like versioning) and how and when to use it.

This document increases the version number to add one new PDU type as well as to clarify some questions on timing parameters. However, versioning is just one extensibility mechanism out-of a whole set of option. In this case the protocol also has an (8 bit) type field to define new PDU types. Only 8 types are used so far (in version 0 of the protocol) out of 2^8 which leaves another option for extending the protocol. The usually specification here is that the receiver will ignor unknown types which is exactl what you want. There in this case I don't see that a new version necessary.

Further there is an issue on how the versioning is done. This document looks like a bis document and used to obsolete the old spec till the last version (-07) but now neither updates nor obsolete it. If you actually decide to have a new version, that might be right (also updating might be an option which I would actually recommend in this case because I believe the expectation is that new implementation should always implement this version) but I don't really see in this case that doublicating all the text is the best option.

I would actually not recommend to increase the version because I really don't see a need for this, given the (much easier) extensibily mechanism you have with the type. If you'd only would like add the new type, then actually a short draft that defines the type and updates rfc6810 would be sufficient. Regarding the other calrification, I think this could also be done in a short (potentially the same) updating draft. If you still think it better to copy all the text and have one clean draft than obsoleting is the right choice.

[Ballot comment]
I have read through the document and I still was unable to figure out what the Max Len field for the IPvX PDUs is being used for. It is defined as

Max Length:  An 8-bit unsigned integer denoting the longest prefix allowed by the Prefix element.

but I was not able to find any processing rules for this. i.e. what it is actually used for. An example would greatly help.

[Ballot comment]
Thanks for your work on this draft.  The first question is more of a nit, the second is more important.

Section 9.1
I suggest saying man-in-the-middle instead of monkey-in-the-middle as we use the latter typically in documents and I don't think there's anything particularly unique to a monkey-in-the-middle attack, but correct me if I am wrong.  I think it's just an alternate name for man-in-the-middle as result of Dug Song's tool sniff on monkey.org.  If monkey-in-the-middle is important for some reason, could you include a reference?

Section 9.3
Why isn't MD5 deprecated or discouraged more in this section?

[Ballot comment]
Thank you for a well written document.

I have one small issue I would like to discuss:

In section 7: what are the conditions for bumping the version number to 2? I think the document is missing some criteria for what would require a version change.

[Ballot comment]
On top of the OPS DIR feedback from Stefan at https://datatracker.ietf.org/doc/review-ietf-sidr-rpki-rtr-rfc6810-bis-08-opsdir-lc-winter-2017-02-07/, one editorial remark.

Periodically, the router sends to the cache the most recent Serial
  Number for which it has has received data from that cache

s/has has/has

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-08.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the rpki-rtr-pdu subregistry of the Resource Public Key Infrastructure (RPKI) registry located at:

https://www.iana.org/assignments/rpki/

the entire registry is to be modified with a new field (protocol version). The newly updated registry will be:

Protocol PDU
Version Type Description Reference
---------+------+----------------+--------------------------
0-1 0 Serial Notify [ RFC6810, [ RFC-to-be ] ]
0-1 1 Serial Query [ RFC6810, [ RFC-to-be ] ]
0-1 2 Reset Query [ RFC6810, [ RFC-to-be ] ]
0-1 3 Cache Response [ RFC6810, [ RFC-to-be ] ]
0-1 4 IPv4 Prefix [ RFC6810, [ RFC-to-be ] ]
0-1 6 IPv6 Prefix [ RFC6810, [ RFC-to-be ] ]
0-1 7 End of Data [ RFC6810, [ RFC-to-be ] ]
0-1 8 Cache Reset [ RFC6810, [ RFC-to-be ] ]
0 9 Reserved [ RFC-to-be ]
1 9 Router Key [ RFC-to-be ]
0-1 10 Error Report [ RFC6810, [ RFC-to-be ] ]
0-1 255 Reserved [ RFC6810, [ RFC-to-be ] ]

The registration rule for this registry remains RFC Required as defined by RFC 5226.

Second, in the rpki-rtr-error subregistry also in the Resource Public Key Infrastructure (RPKI) registry located at:

https://www.iana.org/assignments/rpki/

a single new registration is to be made as follows:

Error Code: [ TBD-at-Registration ]
Description: Unexpected Protocol Version
Reference: [ RFC-to-be ]

We note that the authors have suggested a value of 8 for the above registration.

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, morrowc@ops-netman.net, sidr-chairs@ietf.org, "Chris Morrow" , sidr@ietf.org, aretana@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Resource Public Key Infrastructure (RPKI) to 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 Resource Public Key Infrastructure (RPKI) to Router Protocol'
  as 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 2017-01-30. 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 verifiably validate the origin Autonomous Systems and
  Autonomous System Paths of BGP announcements, routers need a simple
  but reliable mechanism to receive Resource Public Key Infrastructure
  (RFC 6480) prefix origin data and router keys from a trusted cache.
  This document describes a protocol to deliver them.

  This document describes version 1 of the rpki-rtr protocol.  RFC 6810
  describes version 0.


Downref:
Normative reference is made to an Obsolete document: RFC2385 (Protection of BGP Sessions via the TCP MD5 Signature Option).
The text is clear about the Status, but the reference is used due to the lack of general availability of a preferred option.

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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ballot/


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

=== AD Review -07 ===
Hi!

I have a couple of Major comments related to the existence/co-existence of two versions of the protocol.  I would like to see the comments discussed/addressed before starting the IETF Last Call.

Thanks!!

Alvaro.


Major:

1.RFC6810.

* Section 1.2. (Changes from RFC 6810):  "The protocol described in this document is largely compatible with [RFC6810]."  What does "largely compatible" mean?  It either is compatible or it isn't.  From Section 7. (Protocol Version Negotiation), it looks like there's no way for a router that only supports version 0 to talk a cache that only supports version 1, and viceversa.  Even though the PDUs are mostly the same, that doesn't seem to matter…in the end it looks like the versions
are not compatible and in reality version 1 is simply an update to version 0.

* This document is marked as obsoleting rfc6810, but it mandates its use in section 7 ("…the cache MUST downgrade to protocol version 0 [RFC6810]…").  There are a couple of paths forward:
1. It seems to me that this document should simply be called "RPKI to Router Protocol version 1" and not change the status of rfc6810 — we can always declare version 0 historic later.
2. If you really want to obsolete version 0, then an alternative is to eliminate the normative language when it refers to it...  For example,

    * OLD> "If a cache which supports version 1 receives a query from a router which specifies version 0, the cache MUST downgrade to protocol version 0 [RFC6810] or send a version 1 Error Report PDU with Error Code 4 ("Unsupported Protocol Version") and terminate the connection."
    * NEW> "If a cache which supports version 1 receives a query from a router which specifies version 0, the cache SHOULD send a version 1 Error Report PDU with Error Code 4 ("Unsupported Protocol Version") and terminate the connection."


2. Section 7. (Protocol Version Negotiation)  Related to the points above…  Are other versions of this protocol expected?  I know the answer may come from a crystal ball at this point…but can the process defined here be generalized?


Minor:

1. Implementation

* In Section 1. (Introduction) you reference rfc7128 for an implementation report, but that RFC reports on the implementation of rfc6810, and not this new version. 
* It would be nice to include a section according to rfc6982 about implementations of this version.


2. Section 9. (Transport)  I think this sentence is superfluous: "Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPSec transport.", because a couple of paragraphs later the text also says "…caches and routers MUST use one of the following more protected protocols" (and the same protocols are revisited).

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The RFC is to be Standards Track

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

  In order to verifiably validate the origin Autonomous Systems and
  Autonomous System Paths of BGP announcements, routers need a simple
  but reliable mechanism to receive Resource Public Key Infrastructure
  (RFC 6480) prefix origin data and router keys from a trusted cache.
  This document describes a protocol to deliver validated prefix origin
  data and router keys to routers.

Working Group Summary

  This document is an update to RFC6810.  It adds support for
  a new PDU to carry router key information, new timing
  values, and a version negotiation.  As it is an update to
  a protocol currently in use, the working group discussion
  was focused on the additional features.

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?

  There are three different implementations of the server side
  of this protocol.  Three router vendors have implemented the
  client side.  Four other implementations of the client side
  are also known.

  Richard Hansen did a particularly meticulous review.

  There was no need for an expert review.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Document Shepherd: Chris Morrow
  Responsible Area Director: Alvaro Retana

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd has read the document and believes the document
  is ready for a publication request.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No.  Several reviews were detailed and in depth.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No need for a review from a broader perspective.

(6) Describe any specific concerns or issues that the Document Shepherd
has 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.

  The document shepherd has no concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Each author has confirmed that they know of no needed IPR
  disclosures.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No, no IPR disclosures have been filed.

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

  This document has been discussed in the wg since Apr 2014.
  This is an update to rfc64810 with a limited number of changes
  to discuss, and there was solid agreement on the changes.

(10) 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 publicly available.)

  No appeal has been threatened or filed.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The nits tool finds the following errors:

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

  This is true of RFC6810 as well.  Both RFC2385 and RFC6925 were/are
  mentioned in the draft as alternatives, RFC2385 is a "MAY".


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  There is no nothing in the document that requires a formal review.

(13) Have all references within this document been identified as
either normative or informative?

  Yes, the list of references is separated into normative and informative.

(14) 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 plan for their completion?

  The reference draft-ietf-sidr-bgpsec-algs  has passed wglc but
  is waiting on a referenced document.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  The nits tools reports no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

    This document obsoletes RFC6810.  That is listed in the header
    on the first page.  The changes are listed in the Introduction
    section, in section 1.2.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document extends the IANA registries established in RFC6810.
  This document defines a new protocol version, and retains the
  original registered values for the rpki-rtr-pdu and rpki-rtr-error
  registries, duplicating the registered values for the new protocol
  version.  A new value is added to the rpki-rtr-pdu registry and
  a new value is added to the rpki-rtr-error registry.  This is
  consistent with the text.

  The registries are clearly identified, the values are consistent
  with the text, all extensions are noted for registration in the
  proper registries.  No new IANA registries are created.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No new IANA registries are created by this document.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  There are no formal languages used in this document.