doc: Add RFC documents

1 files changed, 1963 insertions, 0 deletions

diff --git a/doc/rfc/rfc8210.txt b/doc/rfc/rfc8210.txt
new file mode 100644
index 0000000..6659aaa
--- /dev/null
+++ b/doc/rfc/rfc8210.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           R. Bush
+Request for Comments: 8210                     Internet Initiative Japan
+Updates: 6810                                                 R. Austein
+Category: Standards Track                           Dragon Research Labs
+ISSN: 2070-1721                                           September 2017
+
+
+   The Resource Public Key Infrastructure (RPKI) to Router Protocol,
+                               Version 1
+
+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-Router protocol.  RFC
+   6810 describes version 0.  This document updates RFC 6810.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8210.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                    [Page 1]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+Copyright Notice
+
+   Copyright (c) 2017 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                    [Page 2]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
+     1.2.  Changes from RFC 6810 . . . . . . . . . . . . . . . . . .   4
+   2.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   3.  Deployment Structure  . . . . . . . . . . . . . . . . . . . .   5
+   4.  Operational Overview  . . . . . . . . . . . . . . . . . . . .   6
+   5.  Protocol Data Units (PDUs)  . . . . . . . . . . . . . . . . .   7
+     5.1.  Fields of a PDU . . . . . . . . . . . . . . . . . . . . .   7
+     5.2.  Serial Notify . . . . . . . . . . . . . . . . . . . . . .  10
+     5.3.  Serial Query  . . . . . . . . . . . . . . . . . . . . . .  10
+     5.4.  Reset Query . . . . . . . . . . . . . . . . . . . . . . .  12
+     5.5.  Cache Response  . . . . . . . . . . . . . . . . . . . . .  12
+     5.6.  IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . .  13
+     5.7.  IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . .  14
+     5.8.  End of Data . . . . . . . . . . . . . . . . . . . . . . .  15
+     5.9.  Cache Reset . . . . . . . . . . . . . . . . . . . . . . .  16
+     5.10. Router Key  . . . . . . . . . . . . . . . . . . . . . . .  16
+     5.11. Error Report  . . . . . . . . . . . . . . . . . . . . . .  17
+   6.  Protocol Timing Parameters  . . . . . . . . . . . . . . . . .  18
+   7.  Protocol Version Negotiation  . . . . . . . . . . . . . . . .  20
+   8.  Protocol Sequences  . . . . . . . . . . . . . . . . . . . . .  21
+     8.1.  Start or Restart  . . . . . . . . . . . . . . . . . . . .  21
+     8.2.  Typical Exchange  . . . . . . . . . . . . . . . . . . . .  22
+     8.3.  No Incremental Update Available . . . . . . . . . . . . .  23
+     8.4.  Cache Has No Data Available . . . . . . . . . . . . . . .  23
+   9.  Transport . . . . . . . . . . . . . . . . . . . . . . . . . .  24
+     9.1.  SSH Transport . . . . . . . . . . . . . . . . . . . . . .  25
+     9.2.  TLS Transport . . . . . . . . . . . . . . . . . . . . . .  26
+     9.3.  TCP MD5 Transport . . . . . . . . . . . . . . . . . . . .  26
+     9.4.  TCP-AO Transport  . . . . . . . . . . . . . . . . . . . .  27
+   10. Router-Cache Setup  . . . . . . . . . . . . . . . . . . . . .  27
+   11. Deployment Scenarios  . . . . . . . . . . . . . . . . . . . .  28
+   12. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . .  29
+   13. Security Considerations . . . . . . . . . . . . . . . . . . .  30
+   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  31
+   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  32
+     15.1.  Normative References . . . . . . . . . . . . . . . . . .  32
+     15.2.  Informative References . . . . . . . . . . . . . . . . .  34
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  35
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                    [Page 3]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+1.  Introduction
+
+   In order to verifiably validate the origin Autonomous Systems (ASes)
+   and AS paths of BGP announcements, routers need a simple but reliable
+   mechanism to receive cryptographically validated Resource Public Key
+   Infrastructure (RPKI) [RFC6480] prefix origin data and router keys
+   from a trusted cache.  This document describes a protocol to deliver
+   them.  The design is intentionally constrained to be usable on much
+   of the current generation of ISP router platforms.
+
+   This document updates [RFC6810].
+
+   Section 3 describes the deployment structure, and Section 4 then
+   presents an operational overview.  The binary payloads of the
+   protocol are formally described in Section 5, and the expected
+   Protocol Data Unit (PDU) sequences are described in Section 8.  The
+   transport protocol options are described in Section 9.  Section 10
+   details how routers and caches are configured to connect and
+   authenticate.  Section 11 describes likely deployment scenarios.  The
+   traditional security and IANA considerations end the document.
+
+   The protocol is extensible in order to support new PDUs with new
+   semantics, if deployment experience indicates that they are needed.
+   PDUs are versioned should deployment experience call for change.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+1.2.  Changes from RFC 6810
+
+   This section summarizes the significant changes between [RFC6810] and
+   the protocol described in this document.
+
+   o  New Router Key PDU type (Section 5.10) added.
+
+   o  Explicit timing parameters (Section 5.8, Section 6) added.
+
+   o  Protocol version number incremented from 0 (zero) to 1 (one).
+
+   o  Protocol version number negotiation (Section 7) added.
+
+
+
+
+
+
+Bush & Austein               Standards Track                    [Page 4]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+2.  Glossary
+
+   The following terms are used with special meaning.
+
+   Global RPKI:  The authoritative data of the RPKI are published in a
+      distributed set of servers at the IANA, Regional Internet
+      Registries (RIRs), National Internet Registries (NIRs), and ISPs;
+      see [RFC6481].
+
+   Cache:  A cache is a coalesced copy of the published Global RPKI
+      data, periodically fetched or refreshed, directly or indirectly,
+      using the rsync protocol [RFC5781] or some successor.  Relying
+      Party software is used to gather and validate the distributed data
+      of the RPKI into a cache.  Trusting this cache further is a matter
+      between the provider of the cache and a Relying Party.
+
+   Serial Number:  "Serial Number" is a 32-bit strictly increasing
+      unsigned integer which wraps from 2^32-1 to 0.  It denotes the
+      logical version of a cache.  A cache increments the value when it
+      successfully updates its data from a parent cache or from primary
+      RPKI data.  While a cache is receiving updates, new incoming data
+      and implicit deletes are associated with the new serial but MUST
+      NOT be sent until the fetch is complete.  A Serial Number is not
+      commensurate between different caches or different protocol
+      versions, nor need it be maintained across resets of the cache
+      server.  See [RFC1982] on DNS Serial Number Arithmetic for too
+      much detail on the topic.
+
+   Session ID:  When a cache server is started, it generates a
+      Session ID to uniquely identify the instance of the cache and to
+      bind it to the sequence of Serial Numbers that cache instance will
+      generate.  This allows the router to restart a failed session
+      knowing that the Serial Number it is using is commensurate with
+      that of the cache.
+
+   Payload PDU:  A payload PDU is a protocol message which contains data
+      for use by the router, as opposed to a PDU which conveys the
+      control mechanisms of this protocol.  Prefixes and Router Keys are
+      examples of payload PDUs.
+
+3.  Deployment Structure
+
+   Deployment of the RPKI to reach routers has a three-level structure
+   as follows:
+
+   Global RPKI:  The authoritative data of the RPKI are published in a
+      distributed set of servers at the IANA, RIRs, NIRs, and ISPs (see
+      [RFC6481]).
+
+
+
+Bush & Austein               Standards Track                    [Page 5]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   Local Caches:  Local caches are a local set of one or more collected
+      and verified caches of RPKI data.  A Relying Party, e.g., router
+      or other client, MUST have a trust relationship with, and a
+      trusted transport channel to, any cache(s) it uses.
+
+   Routers:  A router fetches data from a local cache using the protocol
+      described in this document.  It is said to be a client of the
+      cache.  There MAY be mechanisms for the router to assure itself of
+      the authenticity of the cache and to authenticate itself to the
+      cache (see Section 9).
+
+4.  Operational Overview
+
+   A router establishes and keeps open a connection to one or more
+   caches with which it has client/server relationships.  It is
+   configured with a semi-ordered list of caches and establishes a
+   connection to the most preferred cache, or set of caches, which
+   accept the connections.
+
+   The router MUST choose the most preferred, by configuration, cache or
+   set of caches so that the operator may control load on their caches
+   and the Global RPKI.
+
+   Periodically, the router sends to the cache the most recent Serial
+   Number for which it has received data from that cache, i.e., the
+   router's current Serial Number, in the form of a Serial Query.  When
+   a router establishes a new session with a cache or wishes to reset a
+   current relationship, it sends a Reset Query.
+
+   The cache responds to the Serial Query with all data changes which
+   took place since the given Serial Number.  This may be the null set,
+   in which case the End of Data PDU (Section 5.8) is still sent.  Note
+   that the Serial Number comparison used to determine "since the given
+   Serial Number" MUST take wrap-around into account; see [RFC1982].
+
+   When the router has received all data records from the cache, it sets
+   its current Serial Number to that of the Serial Number in the
+   received End of Data PDU.
+
+   When the cache updates its database, it sends a Notify PDU to every
+   currently connected router.  This is a hint that now would be a good
+   time for the router to poll for an update, but it is only a hint.
+   The protocol requires the router to poll for updates periodically in
+   any case.
+
+   Strictly speaking, a router could track a cache simply by asking for
+   a complete data set every time it updates, but this would be very
+   inefficient.  The Serial-Number-based incremental update mechanism
+
+
+
+Bush & Austein               Standards Track                    [Page 6]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   allows an efficient transfer of just the data records which have
+   changed since the last update.  As with any update protocol based on
+   incremental transfers, the router must be prepared to fall back to a
+   full transfer if for any reason the cache is unable to provide the
+   necessary incremental data.  Unlike some incremental transfer
+   protocols, this protocol requires the router to make an explicit
+   request to start the fallback process; this is deliberate, as the
+   cache has no way of knowing whether the router has also established
+   sessions with other caches that may be able to provide better
+   service.
+
+   As a cache server must evaluate certificates and ROAs (Route Origin
+   Authorizations; see [RFC6480]), which are time dependent, servers'
+   clocks MUST be correct to a tolerance of approximately an hour.
+
+5.  Protocol Data Units (PDUs)
+
+   The exchanges between the cache and the router are sequences of
+   exchanges of the following PDUs according to the rules described in
+   Section 8.
+
+   Reserved fields (marked "zero" in PDU diagrams) MUST be zero on
+   transmission and MUST be ignored on receipt.
+
+5.1.  Fields of a PDU
+
+   PDUs contain the following data elements:
+
+   Protocol Version:  An 8-bit unsigned integer, currently 1, denoting
+      the version of this protocol.
+
+   PDU Type:  An 8-bit unsigned integer, denoting the type of the PDU,
+      e.g., IPv4 Prefix.
+
+   Serial Number:  The Serial Number of the RPKI cache when this set of
+      PDUs was received from an upstream cache server or gathered from
+      the Global RPKI.  A cache increments its Serial Number when
+      completing a rigorously validated update from a parent cache or
+      the Global RPKI.
+
+   Session ID:  A 16-bit unsigned integer.  When a cache server is
+      started, it generates a Session ID to identify the instance of the
+      cache and to bind it to the sequence of Serial Numbers that cache
+      instance will generate.  This allows the router to restart a
+      failed session knowing that the Serial Number it is using is
+      commensurate with that of the cache.  If, at any time after the
+      protocol version has been negotiated (Section 7), either the
+      router or the cache finds that the value of the Session ID is not
+
+
+
+Bush & Austein               Standards Track                    [Page 7]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+      the same as the other's, the party which detects the mismatch MUST
+      immediately terminate the session with an Error Report PDU with
+      code 0 ("Corrupt Data"), and the router MUST flush all data
+      learned from that cache.
+
+      Note that sessions are specific to a particular protocol version.
+      That is, if a cache server supports multiple versions of this
+      protocol, happens to use the same Session ID value for multiple
+      protocol versions, and further happens to use the same Serial
+      Number values for two or more sessions using the same Session ID
+      but different Protocol Version values, the Serial Numbers are not
+      commensurate.  The full test for whether Serial Numbers are
+      commensurate requires comparing Protocol Version, Session ID, and
+      Serial Number.  To reduce the risk of confusion, cache servers
+      SHOULD NOT use the same Session ID across multiple protocol
+      versions, but even if they do, routers MUST treat sessions with
+      different Protocol Version fields as separate sessions even if
+      they do happen to have the same Session ID.
+
+      Should a cache erroneously reuse a Session ID so that a router
+      does not realize that the session has changed (old Session ID and
+      new Session ID have the same numeric value), the router may become
+      confused as to the content of the cache.  The time it takes the
+      router to discover that it is confused will depend on whether the
+      Serial Numbers are also reused.  If the Serial Numbers in the old
+      and new sessions are different enough, the cache will respond to
+      the router's Serial Query with a Cache Reset, which will solve the
+      problem.  If, however, the Serial Numbers are close, the cache may
+      respond with a Cache Response, which may not be enough to bring
+      the router into sync.  In such cases, it's likely but not certain
+      that the router will detect some discrepancy between the state
+      that the cache expects and its own state.  For example, the Cache
+      Response may tell the router to drop a record which the router
+      does not hold or may tell the router to add a record which the
+      router already has.  In such cases, a router will detect the error
+      and reset the session.  The one case in which the router may stay
+      out of sync is when nothing in the Cache Response contradicts any
+      data currently held by the router.
+
+      Using persistent storage for the Session ID or a clock-based
+      scheme for generating Session IDs should avoid the risk of
+      Session ID collisions.
+
+      The Session ID might be a pseudorandom value, a strictly
+      increasing value if the cache has reliable storage, et cetera.  A
+      seconds-since-epoch timestamp value such as the POSIX time()
+      function makes a good Session ID value.
+
+
+
+
+Bush & Austein               Standards Track                    [Page 8]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   Length:  A 32-bit unsigned integer which has as its value the count
+      of the bytes in the entire PDU, including the 8 bytes of header
+      which includes the length field.
+
+   Flags:  The lowest-order bit of the Flags field is 1 for an
+      announcement and 0 for a withdrawal.  For a Prefix PDU (IPv4 or
+      IPv6), the flag indicates whether this PDU announces a new right
+      to announce the prefix or withdraws a previously announced right;
+      a withdraw effectively deletes one previously announced Prefix PDU
+      with the exact same Prefix, Length, Max-Len, and Autonomous System
+      Number (ASN).  Similarly, for a Router Key PDU, the flag indicates
+      whether this PDU announces a new Router Key or deletes one
+      previously announced Router Key PDU with the exact same AS Number,
+      subjectKeyIdentifier, and subjectPublicKeyInfo.
+
+      The remaining bits in the Flags field are reserved for future use.
+      In protocol version 1, they MUST be zero on transmission and MUST
+      be ignored on receipt.
+
+   Prefix Length:  An 8-bit unsigned integer denoting the shortest
+      prefix allowed by the Prefix element.
+
+   Max Length:  An 8-bit unsigned integer denoting the longest prefix
+      allowed by the Prefix element.  This MUST NOT be less than the
+      Prefix Length element.
+
+   Prefix:  The IPv4 or IPv6 prefix of the ROA.
+
+   Autonomous System Number:  A 32-bit unsigned integer representing an
+      ASN allowed to announce a prefix or associated with a router key.
+
+   Subject Key Identifier:  20-octet Subject Key Identifier (SKI) value
+      of a router key, as described in [RFC6487].
+
+   Subject Public Key Info:  A router key's subjectPublicKeyInfo value,
+      as described in [RFC8208].  This is the full ASN.1 DER encoding of
+      the subjectPublicKeyInfo, including the ASN.1 tag and length
+      values of the subjectPublicKeyInfo SEQUENCE.
+
+   Refresh Interval:  Interval between normal cache polls.  See
+      Section 6.
+
+   Retry Interval:  Interval between cache poll retries after a failed
+      cache poll.  See Section 6.
+
+   Expire Interval:  Interval during which data fetched from a cache
+      remains valid in the absence of a successful subsequent cache
+      poll.  See Section 6.
+
+
+
+Bush & Austein               Standards Track                    [Page 9]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+5.2.  Serial Notify
+
+   The cache notifies the router that the cache has new data.
+
+   The Session ID reassures the router that the Serial Numbers are
+   commensurate, i.e., the cache session has not been changed.
+
+   Upon receipt of a Serial Notify PDU, the router MAY issue an
+   immediate Serial Query (Section 5.3) or Reset Query (Section 5.4)
+   without waiting for the Refresh Interval timer (see Section 6) to
+   expire.
+
+   Serial Notify is the only message that the cache can send that is not
+   in response to a message from the router.
+
+   If the router receives a Serial Notify PDU during the initial startup
+   period where the router and cache are still negotiating to agree on a
+   protocol version, the router MUST simply ignore the Serial Notify
+   PDU, even if the Serial Notify PDU is for an unexpected protocol
+   version.  See Section 7 for details.
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |                     |
+   | Version  |   Type   |     Session ID      |
+   |    1     |    0     |                     |
+   +-------------------------------------------+
+   |                                           |
+   |                Length=12                  |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |               Serial Number               |
+   |                                           |
+   `-------------------------------------------'
+
+5.3.  Serial Query
+
+   The router sends a Serial Query to ask the cache for all
+   announcements and withdrawals which have occurred since the Serial
+   Number specified in the Serial Query.
+
+   The cache replies to this query with a Cache Response PDU
+   (Section 5.5) if the cache has a (possibly null) record of the
+   changes since the Serial Number specified by the router, followed by
+   zero or more payload PDUs and an End Of Data PDU (Section 5.8).
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 10]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   When replying to a Serial Query, the cache MUST return the minimum
+   set of changes needed to bring the router into sync with the cache.
+   That is, if a particular prefix or router key underwent multiple
+   changes between the Serial Number specified by the router and the
+   cache's current Serial Number, the cache MUST merge those changes to
+   present the simplest possible view of those changes to the router.
+   In general, this means that, for any particular prefix or router key,
+   the data stream will include at most one withdrawal followed by at
+   most one announcement, and if all of the changes cancel out, the data
+   stream will not mention the prefix or router key at all.
+
+   The rationale for this approach is that the entire purpose of the
+   RPKI-Router protocol is to offload work from the router to the cache,
+   and it should therefore be the cache's job to simplify the change
+   set, thus reducing work for the router.
+
+   If the cache does not have the data needed to update the router,
+   perhaps because its records do not go back to the Serial Number in
+   the Serial Query, then it responds with a Cache Reset PDU
+   (Section 5.9).
+
+   The Session ID tells the cache what instance the router expects to
+   ensure that the Serial Numbers are commensurate, i.e., the cache
+   session has not been changed.
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |                     |
+   | Version  |   Type   |     Session ID      |
+   |    1     |    1     |                     |
+   +-------------------------------------------+
+   |                                           |
+   |                 Length=12                 |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |               Serial Number               |
+   |                                           |
+   `-------------------------------------------'
+
+
+
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 11]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+5.4.  Reset Query
+
+   The router tells the cache that it wants to receive the total active,
+   current, non-withdrawn database.  The cache responds with a Cache
+   Response PDU (Section 5.5), followed by zero or more payload PDUs and
+   an End of Data PDU (Section 5.8).
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |                     |
+   | Version  |   Type   |         zero        |
+   |    1     |    2     |                     |
+   +-------------------------------------------+
+   |                                           |
+   |                 Length=8                  |
+   |                                           |
+   `-------------------------------------------'
+
+5.5.  Cache Response
+
+   The cache responds to queries with zero or more payload PDUs.  When
+   replying to a Serial Query (Section 5.3), the cache sends the set of
+   announcements and withdrawals that have occurred since the Serial
+   Number sent by the client router.  When replying to a Reset Query
+   (Section 5.4), the cache sends the set of all data records it has; in
+   this case, the withdraw/announce field in the payload PDUs MUST have
+   the value 1 (announce).
+
+   In response to a Reset Query, the new value of the Session ID tells
+   the router the instance of the cache session for future confirmation.
+   In response to a Serial Query, the Session ID being the same
+   reassures the router that the Serial Numbers are commensurate, i.e.,
+   the cache session has not been changed.
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |                     |
+   | Version  |   Type   |     Session ID      |
+   |    1     |    3     |                     |
+   +-------------------------------------------+
+   |                                           |
+   |                 Length=8                  |
+   |                                           |
+   `-------------------------------------------'
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 12]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+5.6.  IPv4 Prefix
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |                     |
+   | Version  |   Type   |         zero        |
+   |    1     |    4     |                     |
+   +-------------------------------------------+
+   |                                           |
+   |                 Length=20                 |
+   |                                           |
+   +-------------------------------------------+
+   |          |  Prefix  |   Max    |          |
+   |  Flags   |  Length  |  Length  |   zero   |
+   |          |   0..32  |   0..32  |          |
+   +-------------------------------------------+
+   |                                           |
+   |                IPv4 Prefix                |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |         Autonomous System Number          |
+   |                                           |
+   `-------------------------------------------'
+
+   The lowest-order bit of the Flags field is 1 for an announcement and
+   0 for a withdrawal.
+
+   In the RPKI, nothing prevents a signing certificate from issuing two
+   identical ROAs.  In this case, there would be no semantic difference
+   between the objects, merely a process redundancy.
+
+   In the RPKI, there is also an actual need for what might appear to a
+   router as identical IPvX PDUs.  This can occur when an upstream
+   certificate is being reissued or there is an address ownership
+   transfer up the validation chain.  The ROA would be identical in the
+   router sense, i.e., have the same {Prefix, Len, Max-Len, ASN}, but it
+   would have a different validation path in the RPKI.  This is
+   important to the RPKI but not to the router.
+
+   The cache server MUST ensure that it has told the router client to
+   have one and only one IPvX PDU for a unique {Prefix, Len, Max-Len,
+   ASN} at any one point in time.  Should the router client receive an
+   IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it
+   already has active, it SHOULD raise a Duplicate Announcement Received
+   error.
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 13]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+5.7.  IPv6 Prefix
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |                     |
+   | Version  |   Type   |         zero        |
+   |    1     |    6     |                     |
+   +-------------------------------------------+
+   |                                           |
+   |                 Length=32                 |
+   |                                           |
+   +-------------------------------------------+
+   |          |  Prefix  |   Max    |          |
+   |  Flags   |  Length  |  Length  |   zero   |
+   |          |  0..128  |  0..128  |          |
+   +-------------------------------------------+
+   |                                           |
+   +---                                     ---+
+   |                                           |
+   +---            IPv6 Prefix              ---+
+   |                                           |
+   +---                                     ---+
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |         Autonomous System Number          |
+   |                                           |
+   `-------------------------------------------'
+
+   Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 14]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+5.8.  End of Data
+
+   The cache tells the router it has no more data for the request.
+
+   The Session ID and Protocol Version MUST be the same as that of the
+   corresponding Cache Response which began the (possibly null) sequence
+   of payload PDUs.
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |                     |
+   | Version  |   Type   |     Session ID      |
+   |    1     |    7     |                     |
+   +-------------------------------------------+
+   |                                           |
+   |                 Length=24                 |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |               Serial Number               |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |              Refresh Interval             |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |               Retry Interval              |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |              Expire Interval              |
+   |                                           |
+   `-------------------------------------------'
+
+   The Refresh Interval, Retry Interval, and Expire Interval are all
+   32-bit elapsed times measured in seconds.  They express the timing
+   parameters which the cache expects the router to use in deciding when
+   to send subsequent Serial Query or Reset Query PDUs to the cache.
+   See Section 6 for an explanation of the use and the range of allowed
+   values for these parameters.
+
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 15]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+5.9.  Cache Reset
+
+   The cache may respond to a Serial Query informing the router that the
+   cache cannot provide an incremental update starting from the Serial
+   Number specified by the router.  The router must decide whether to
+   issue a Reset Query or switch to a different cache.
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |                     |
+   | Version  |   Type   |         zero        |
+   |    1     |    8     |                     |
+   +-------------------------------------------+
+   |                                           |
+   |                 Length=8                  |
+   |                                           |
+   `-------------------------------------------'
+
+5.10.  Router Key
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |          |          |
+   | Version  |   Type   |   Flags  |   zero   |
+   |    1     |    9     |          |          |
+   +-------------------------------------------+
+   |                                           |
+   |                  Length                   |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   +---                                     ---+
+   |          Subject Key Identifier           |
+   +---                                     ---+
+   |                                           |
+   +---                                     ---+
+   |                (20 octets)                |
+   +---                                     ---+
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |                 AS Number                 |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |          Subject Public Key Info          |
+   |                                           |
+   `-------------------------------------------'
+
+
+
+Bush & Austein               Standards Track                   [Page 16]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   The lowest-order bit of the Flags field is 1 for an announcement and
+   0 for a withdrawal.
+
+   The cache server MUST ensure that it has told the router client to
+   have one and only one Router Key PDU for a unique {SKI, ASN, Subject
+   Public Key} at any one point in time.  Should the router client
+   receive a Router Key PDU with a {SKI, ASN, Subject Public Key}
+   identical to one it already has active, it SHOULD raise a Duplicate
+   Announcement Received error.
+
+   Note that a particular ASN may appear in multiple Router Key PDUs
+   with different Subject Public Key values, while a particular Subject
+   Public Key value may appear in multiple Router Key PDUs with
+   different ASNs.  In the interest of keeping the announcement and
+   withdrawal semantics as simple as possible for the router, this
+   protocol makes no attempt to compress either of these cases.
+
+   Also note that it is possible, albeit very unlikely, for multiple
+   distinct Subject Public Key values to hash to the same SKI.  For this
+   reason, implementations MUST compare Subject Public Key values as
+   well as SKIs when detecting duplicate PDUs.
+
+5.11.  Error Report
+
+   This PDU is used by either party to report an error to the other.
+
+   Error reports are only sent as responses to other PDUs, not to report
+   errors in Error Report PDUs.
+
+   Error codes are described in Section 12.
+
+   If the error is generic (e.g., "Internal Error") and not associated
+   with the PDU to which it is responding, the Erroneous PDU field MUST
+   be empty and the Length of Encapsulated PDU field MUST be zero.
+
+   An Error Report PDU MUST NOT be sent for an Error Report PDU.  If an
+   erroneous Error Report PDU is received, the session SHOULD be
+   dropped.
+
+   If the error is associated with a PDU of excessive length, i.e., too
+   long to be any legal PDU other than another Error Report, or a
+   possibly corrupt length, the Erroneous PDU field MAY be truncated.
+
+   The diagnostic text is optional; if not present, the Length of Error
+   Text field MUST be zero.  If error text is present, it MUST be a
+   string in UTF-8 encoding (see [RFC3629]).
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 17]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   0          8          16         24        31
+   .-------------------------------------------.
+   | Protocol |   PDU    |                     |
+   | Version  |   Type   |     Error Code      |
+   |    1     |    10    |                     |
+   +-------------------------------------------+
+   |                                           |
+   |                  Length                   |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |       Length of Encapsulated PDU          |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   ~               Erroneous PDU               ~
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |           Length of Error Text            |
+   |                                           |
+   +-------------------------------------------+
+   |                                           |
+   |              Arbitrary Text               |
+   |                    of                     |
+   ~          Error Diagnostic Message         ~
+   |                                           |
+   `-------------------------------------------'
+
+6.  Protocol Timing Parameters
+
+   Since the data the cache distributes via the RPKI-Router protocol are
+   retrieved from the Global RPKI system at intervals which are only
+   known to the cache, only the cache can really know how frequently it
+   makes sense for the router to poll the cache, or how long the data
+   are likely to remain valid (or, at least, unchanged).  For this
+   reason, as well as to allow the cache some control over the load
+   placed on it by its client routers, the End Of Data PDU includes
+   three values that allow the cache to communicate timing parameters to
+   the router:
+
+   Refresh Interval:  This parameter tells the router how long to wait
+      before next attempting to poll the cache and between subsequent
+      attempts, using a Serial Query or Reset Query PDU.  The router
+      SHOULD NOT poll the cache sooner than indicated by this parameter.
+      Note that receipt of a Serial Notify PDU overrides this interval
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 18]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+      and suggests that the router issue an immediate query without
+      waiting for the Refresh Interval to expire.  Countdown for this
+      timer starts upon receipt of the containing End Of Data PDU.
+
+      Minimum allowed value:  1 second.
+
+      Maximum allowed value:  86400 seconds (1 day).
+
+      Recommended default:  3600 seconds (1 hour).
+
+   Retry Interval:  This parameter tells the router how long to wait
+      before retrying a failed Serial Query or Reset Query.  The router
+      SHOULD NOT retry sooner than indicated by this parameter.  Note
+      that a protocol version mismatch overrides this interval: if the
+      router needs to downgrade to a lower protocol version number, it
+      MAY send the first Serial Query or Reset Query immediately.
+      Countdown for this timer starts upon failure of the query and
+      restarts after each subsequent failure until a query succeeds.
+
+      Minimum allowed value:  1 second.
+
+      Maximum allowed value:  7200 seconds (2 hours).
+
+      Recommended default:  600 seconds (10 minutes).
+
+   Expire Interval:  This parameter tells the router how long it can
+      continue to use the current version of the data while unable to
+      perform a successful subsequent query.  The router MUST NOT retain
+      the data past the time indicated by this parameter.  Countdown for
+      this timer starts upon receipt of the containing End Of Data PDU.
+
+      Minimum allowed value:  600 seconds (10 minutes).
+
+      Maximum allowed value:  172800 seconds (2 days).
+
+      Recommended default:  7200 seconds (2 hours).
+
+   If the router has never issued a successful query against a
+   particular cache, it SHOULD retry periodically using the default
+   Retry Interval, above.
+
+   Caches MUST set Expire Interval to a value larger than either Refresh
+   Interval or Retry Interval.
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 19]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+7.  Protocol Version Negotiation
+
+   A router MUST start each transport connection by issuing either a
+   Reset Query or a Serial Query.  This query will tell the cache which
+   version of this protocol the router implements.
+
+   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.
+
+   If a router which supports version 1 sends a query to a cache which
+   only supports version 0, one of two things will happen:
+
+   1.  The cache may terminate the connection, perhaps with a version 0
+       Error Report PDU.  In this case, the router MAY retry the
+       connection using protocol version 0.
+
+   2.  The cache may reply with a version 0 response.  In this case, the
+       router MUST either downgrade to version 0 or terminate the
+       connection.
+
+   In any of the downgraded combinations above, the new features of
+   version 1 will not be available, and all PDUs will have 0 in their
+   version fields.
+
+   If either party receives a PDU containing an unrecognized Protocol
+   Version (neither 0 nor 1) during this negotiation, it MUST either
+   downgrade to a known version or terminate the connection, with an
+   Error Report PDU unless the received PDU is itself an Error
+   Report PDU.
+
+   The router MUST ignore any Serial Notify PDUs it might receive from
+   the cache during this initial startup period, regardless of the
+   Protocol Version field in the Serial Notify PDU.  Since Session ID
+   and Serial Number values are specific to a particular protocol
+   version, the values in the notification are not useful to the router.
+   Even if these values were meaningful, the only effect that processing
+   the notification would have would be to trigger exactly the same
+   Reset Query or Serial Query that the router has already sent as part
+   of the not-yet-complete version negotiation process, so there is
+   nothing to be gained by processing notifications until version
+   negotiation completes.
+
+   Caches SHOULD NOT send Serial Notify PDUs before version negotiation
+   completes.  Routers, however, MUST handle such notifications (by
+   ignoring them) for backwards compatibility with caches serving
+   protocol version 0.
+
+
+
+Bush & Austein               Standards Track                   [Page 20]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   Once the cache and router have agreed upon a Protocol Version via the
+   negotiation process above, that version is stable for the life of the
+   session.  See Section 5.1 for a discussion of the interaction between
+   Protocol Version and Session ID.
+
+   If either party receives a PDU for a different Protocol Version once
+   the above negotiation completes, that party MUST drop the session;
+   unless the PDU containing the unexpected Protocol Version was itself
+   an Error Report PDU, the party dropping the session SHOULD send an
+   Error Report with an error code of 8 ("Unexpected Protocol Version").
+
+8.  Protocol Sequences
+
+   The sequences of PDU transmissions fall into four conversations as
+   follows:
+
+8.1.  Start or Restart
+
+   Cache                         Router
+     ~                             ~
+     | <----- Reset Query -------- | R requests data (or Serial Query)
+     |                             |
+     | ----- Cache Response -----> | C confirms request
+     | ------- Payload PDU ------> | C sends zero or more
+     | ------- Payload PDU ------> |   IPv4 Prefix, IPv6 Prefix,
+     | ------- Payload PDU ------> |   or Router Key PDUs
+     | ------- End of Data ------> | C sends End of Data
+     |                             |   and sends new serial
+     ~                             ~
+
+   When a transport connection is first established, the router MUST
+   send either a Reset Query or a Serial Query.  A Serial Query would be
+   appropriate if the router has significant unexpired data from a
+   broken session with the same cache and remembers the Session ID of
+   that session, in which case a Serial Query containing the Session ID
+   from the previous session will allow the router to bring itself up to
+   date while ensuring that the Serial Numbers are commensurate and that
+   the router and cache are speaking compatible versions of the
+   protocol.  In all other cases, the router lacks the necessary data
+   for fast resynchronization and therefore MUST fall back to a Reset
+   Query.
+
+   The Reset Query sequence is also used when the router receives a
+   Cache Reset, chooses a new cache, or fears that it has otherwise lost
+   its way.
+
+   See Section 7 for details on version negotiation.
+
+
+
+
+Bush & Austein               Standards Track                   [Page 21]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   To limit the length of time a cache must keep the data necessary to
+   generate incremental updates, a router MUST send either a Serial
+   Query or a Reset Query periodically.  This also acts as a keep-alive
+   at the application layer.  See Section 6 for details on the required
+   polling frequency.
+
+8.2.  Typical Exchange
+
+   Cache                         Router
+     ~                             ~
+     | -------- Notify ----------> |  (optional)
+     |                             |
+     | <----- Serial Query ------- | R requests data
+     |                             |
+     | ----- Cache Response -----> | C confirms request
+     | ------- Payload PDU ------> | C sends zero or more
+     | ------- Payload PDU ------> |   IPv4 Prefix, IPv6 Prefix,
+     | ------- Payload PDU ------> |   or Router Key PDUs
+     | ------- End of Data ------> | C sends End of Data
+     |                             |   and sends new serial
+     ~                             ~
+
+   The cache server SHOULD send a Notify PDU with its current Serial
+   Number when the cache's serial changes, with the expectation that the
+   router MAY then issue a Serial Query earlier than it otherwise might.
+   This is analogous to DNS NOTIFY in [RFC1996].  The cache MUST
+   rate-limit Serial Notifies to no more frequently than one per minute.
+
+   When the transport layer is up and either a timer has gone off in the
+   router or the cache has sent a Notify PDU, the router queries for new
+   data by sending a Serial Query, and the cache sends all data newer
+   than the serial in the Serial Query.
+
+   To limit the length of time a cache must keep old withdraws, a router
+   MUST send either a Serial Query or a Reset Query periodically.  See
+   Section 6 for details on the required polling frequency.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 22]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+8.3.  No Incremental Update Available
+
+   Cache                         Router
+     ~                             ~
+     | <------ Serial Query ------ | R requests data
+     | ------- Cache Reset ------> | C cannot supply update
+     |                             |   from specified serial
+     | <------ Reset Query ------- | R requests new data
+     | ----- Cache Response -----> | C confirms request
+     | ------- Payload PDU ------> | C sends zero or more
+     | ------- Payload PDU ------> |   IPv4 Prefix, IPv6 Prefix,
+     | ------- Payload PDU ------> |   or Router Key PDUs
+     | ------- End of Data ------> | C sends End of Data
+     |                             |   and sends new serial
+     ~                             ~
+
+   The cache may respond to a Serial Query with a Cache Reset, informing
+   the router that the cache cannot supply an incremental update from
+   the Serial Number specified by the router.  This might be because the
+   cache has lost state, or because the router has waited too long
+   between polls and the cache has cleaned up old data that it no longer
+   believes it needs, or because the cache has run out of storage space
+   and had to expire some old data early.  Regardless of how this state
+   arose, the cache replies with a Cache Reset to tell the router that
+   it cannot honor the request.  When a router receives this, the router
+   SHOULD attempt to connect to any more-preferred caches in its cache
+   list.  If there are no more-preferred caches, it MUST issue a Reset
+   Query and get an entire new load from the cache.
+
+8.4.  Cache Has No Data Available
+
+   Cache                         Router
+     ~                             ~
+     | <------ Serial Query ------ | R requests data
+     | ---- Error Report PDU ----> | C No Data Available
+     ~                             ~
+
+   Cache                         Router
+     ~                             ~
+     | <------ Reset Query ------- | R requests data
+     | ---- Error Report PDU ----> | C No Data Available
+     ~                             ~
+
+   The cache may respond to either a Serial Query or a Reset Query
+   informing the router that the cache cannot supply any update at all.
+   The most likely cause is that the cache has lost state, perhaps due
+   to a restart, and has not yet recovered.  While it is possible that a
+   cache might go into such a state without dropping any of its active
+
+
+
+Bush & Austein               Standards Track                   [Page 23]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   sessions, a router is more likely to see this behavior when it
+   initially connects and issues a Reset Query while the cache is still
+   rebuilding its database.
+
+   When a router receives this kind of error, the router SHOULD attempt
+   to connect to any other caches in its cache list, in preference
+   order.  If no other caches are available, the router MUST issue
+   periodic Reset Queries until it gets a new usable load from the
+   cache.
+
+9.  Transport
+
+   The transport-layer session between a router and a cache carries the
+   binary PDUs in a persistent session.
+
+   To prevent cache spoofing and DoS attacks by illegitimate routers, it
+   is highly desirable that the router and the cache be authenticated to
+   each other.  Integrity protection for payloads is also desirable to
+   protect against monkey-in-the-middle (MITM) attacks.  Unfortunately,
+   there is no protocol to do so on all currently used platforms.
+   Therefore, as of the writing of this document, there is no mandatory-
+   to-implement transport which provides authentication and integrity
+   protection.
+
+   To reduce exposure to dropped but non-terminated sessions, both
+   caches and routers SHOULD enable keep-alives when available in the
+   chosen transport protocol.
+
+   It is expected that, when the TCP Authentication Option (TCP-AO)
+   [RFC5925] is available on all platforms deployed by operators, it
+   will become the mandatory-to-implement transport.
+
+   Caches and routers MUST implement unprotected transport over TCP
+   using a port, rpki-rtr (323); see Section 14.  Operators SHOULD use
+   procedural means, e.g., access control lists (ACLs), to reduce the
+   exposure to authentication issues.
+
+   If unprotected TCP is the transport, the cache and routers MUST be on
+   the same trusted and controlled network.
+
+   If available to the operator, caches and routers MUST use one of the
+   following more protected protocols:
+
+   o  Caches and routers SHOULD use TCP-AO transport [RFC5925] over the
+      rpki-rtr port.
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 24]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   o  Caches and routers MAY use Secure Shell version 2 (SSHv2)
+      transport [RFC4252] using the normal SSH port.  For an example,
+      see Section 9.1.
+
+   o  Caches and routers MAY use TCP MD5 transport [RFC2385] using the
+      rpki-rtr port.  Note that TCP MD5 has been obsoleted by TCP-AO
+      [RFC5925].
+
+   o  Caches and routers MAY use TCP over IPsec transport [RFC4301]
+      using the rpki-rtr port.
+
+   o  Caches and routers MAY use Transport Layer Security (TLS)
+      transport [RFC5246] using port rpki-rtr-tls (324); see Section 14.
+
+9.1.  SSH Transport
+
+   To run over SSH, the client router first establishes an SSH transport
+   connection using the SSHv2 transport protocol, and the client and
+   server exchange keys for message integrity and encryption.  The
+   client then invokes the "ssh-userauth" service to authenticate the
+   application, as described in the SSH authentication protocol
+   [RFC4252].  Once the application has been successfully authenticated,
+   the client invokes the "ssh-connection" service, also known as the
+   SSH connection protocol.
+
+   After the ssh-connection service is established, the client opens a
+   channel of type "session", which results in an SSH session.
+
+   Once the SSH session has been established, the application invokes
+   the application transport as an SSH subsystem called "rpki-rtr".
+   Subsystem support is a feature of SSHv2 and is not included in SSHv1.
+   Running this protocol as an SSH subsystem avoids the need for the
+   application to recognize shell prompts or skip over extraneous
+   information, such as a system message that is sent at shell startup.
+
+   It is assumed that the router and cache have exchanged keys out of
+   band by some reasonably secured means.
+
+   Cache servers supporting SSH transport MUST accept RSA authentication
+   and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA)
+   authentication.  User authentication MUST be supported; host
+   authentication MAY be supported.  Implementations MAY support
+   password authentication.  Client routers SHOULD verify the public key
+   of the cache to avoid MITM attacks.
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 25]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+9.2.  TLS Transport
+
+   Client routers using TLS transport MUST present client-side
+   certificates to authenticate themselves to the cache in order to
+   allow the cache to manage the load by rejecting connections from
+   unauthorized routers.  In principle, any type of certificate and
+   Certification Authority (CA) may be used; however, in general, cache
+   operators will wish to create their own small-scale CA and issue
+   certificates to each authorized router.  This simplifies credential
+   rollover; any unrevoked, unexpired certificate from the proper CA may
+   be used.
+
+   Certificates used to authenticate client routers in this protocol
+   MUST include a subjectAltName extension [RFC5280] containing one or
+   more iPAddress identities; when authenticating the router's
+   certificate, the cache MUST check the IP address of the TLS
+   connection against these iPAddress identities and SHOULD reject the
+   connection if none of the iPAddress identities match the connection.
+
+   Routers MUST also verify the cache's TLS server certificate, using
+   subjectAltName dNSName identities as described in [RFC6125], to avoid
+   MITM attacks.  The rules and guidelines defined in [RFC6125] apply
+   here, with the following considerations:
+
+   o  Support for the DNS-ID identifier type (that is, the dNSName
+      identity in the subjectAltName extension) is REQUIRED in rpki-rtr
+      server and client implementations which use TLS.  Certification
+      authorities which issue rpki-rtr server certificates MUST support
+      the DNS-ID identifier type, and the DNS-ID identifier type MUST be
+      present in rpki-rtr server certificates.
+
+   o  DNS names in rpki-rtr server certificates SHOULD NOT contain the
+      wildcard character "*".
+
+   o  rpki-rtr implementations which use TLS MUST NOT use Common Name
+      (CN-ID) identifiers; a CN field may be present in the server
+      certificate's subject name but MUST NOT be used for authentication
+      within the rules described in [RFC6125].
+
+   o  The client router MUST set its "reference identifier" to the DNS
+      name of the rpki-rtr cache.
+
+9.3.  TCP MD5 Transport
+
+   If TCP MD5 is used, implementations MUST support key lengths of at
+   least 80 printable ASCII bytes, per Section 4.5 of [RFC2385].
+   Implementations MUST also support hexadecimal sequences of at least
+   32 characters, i.e., 128 bits.
+
+
+
+Bush & Austein               Standards Track                   [Page 26]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   Key rollover with TCP MD5 is problematic.  Cache servers SHOULD
+   support [RFC4808].
+
+9.4.  TCP-AO Transport
+
+   Implementations MUST support key lengths of at least 80 printable
+   ASCII bytes.  Implementations MUST also support hexadecimal sequences
+   of at least 32 characters, i.e., 128 bits.  Message Authentication
+   Code (MAC) lengths of at least 96 bits MUST be supported, per
+   Section 5.1 of [RFC5925].
+
+   The cryptographic algorithms and associated parameters described in
+   [RFC5926] MUST be supported.
+
+10.  Router-Cache Setup
+
+   A cache has the public authentication data for each router it is
+   configured to support.
+
+   A router may be configured to peer with a selection of caches, and a
+   cache may be configured to support a selection of routers.  Each must
+   have the name of, and authentication data for, each peer.  In
+   addition, in a router, this list has a non-unique preference value
+   for each server.  This preference merely denotes proximity, not
+   trust, preferred belief, et cetera.  The client router attempts to
+   establish a session with each potential serving cache in preference
+   order and then starts to load data from the most preferred cache to
+   which it can connect and authenticate.  The router's list of caches
+   has the following elements:
+
+   Preference:  An unsigned integer denoting the router's preference to
+      connect to that cache; the lower the value, the more preferred.
+
+   Name:  The IP address or fully qualified domain name of the cache.
+
+   Cache Credential(s):  Any credential (such as a public key) needed to
+      authenticate the cache's identity to the router.
+
+   Router Credential(s):  Any credential (such as a private key or
+      certificate) needed to authenticate the router's identity to the
+      cache.
+
+   Due to the distributed nature of the RPKI, caches simply cannot be
+   rigorously synchronous.  A client may hold data from multiple caches
+   but MUST keep the data marked as to source, as later updates MUST
+   affect the correct data.
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 27]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   Just as there may be more than one covering ROA from a single cache,
+   there may be multiple covering ROAs from multiple caches.  The
+   results are as described in [RFC6811].
+
+   If data from multiple caches are held, implementations MUST NOT
+   distinguish between data sources when performing validation of BGP
+   announcements.
+
+   When a more-preferred cache becomes available, if resources allow, it
+   would be prudent for the client to start fetching from that cache.
+
+   The client SHOULD attempt to maintain at least one set of data,
+   regardless of whether it has chosen a different cache or established
+   a new connection to the previous cache.
+
+   A client MAY drop the data from a particular cache when it is fully
+   in sync with one or more other caches.
+
+   See Section 6 for details on what to do when the client is not able
+   to refresh from a particular cache.
+
+   If a client loses connectivity to a cache it is using or otherwise
+   decides to switch to a new cache, it SHOULD retain the data from the
+   previous cache until it has a full set of data from one or more other
+   caches.  Note that this may already be true at the point of
+   connection loss if the client has connections to more than one cache.
+
+11.  Deployment Scenarios
+
+   For illustration, we present three likely deployment scenarios:
+
+   Small End Site:  The small multihomed end site may wish to outsource
+      the RPKI cache to one or more of their upstream ISPs.  They would
+      exchange authentication material with the ISP using some out-of-
+      band mechanism, and their router(s) would connect to the cache(s)
+      of one or more upstream ISPs.  The ISPs would likely deploy caches
+      intended for customer use separately from the caches with which
+      their own BGP speakers peer.
+
+   Large End Site:  A larger multihomed end site might run one or more
+      caches, arranging them in a hierarchy of client caches, each
+      fetching from a serving cache which is closer to the Global RPKI.
+      They might configure fallback peerings to upstream ISP caches.
+
+   ISP Backbone:  A large ISP would likely have one or more redundant
+      caches in each major point of presence (PoP), and these caches
+      would fetch from each other in an ISP-dependent topology so as not
+      to place undue load on the Global RPKI.
+
+
+
+Bush & Austein               Standards Track                   [Page 28]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   Experience with large DNS cache deployments has shown that complex
+   topologies are ill-advised, as it is easy to make errors in the
+   graph, e.g., not maintain a loop-free condition.
+
+   Of course, these are illustrations, and there are other possible
+   deployment strategies.  It is expected that minimizing load on the
+   Global RPKI servers will be a major consideration.
+
+   To keep load on Global RPKI services from unnecessary peaks, it is
+   recommended that primary caches which load from the distributed
+   Global RPKI not do so all at the same times, e.g., on the hour.
+   Choose a random time, perhaps the ISP's AS number modulo 60, and
+   jitter the inter-fetch timing.
+
+12.  Error Codes
+
+   This section contains a preliminary list of error codes.  The authors
+   expect additions to the list during development of the initial
+   implementations.  There is an IANA registry where valid error codes
+   are listed; see Section 14.  Errors which are considered fatal MUST
+   cause the session to be dropped.
+
+   0: Corrupt Data (fatal):  The receiver believes the received PDU to
+      be corrupt in a manner not specified by another error code.
+
+   1: Internal Error (fatal):  The party reporting the error experienced
+      some kind of internal error unrelated to protocol operation (ran
+      out of memory, a coding assertion failed, et cetera).
+
+   2: No Data Available:  The cache believes itself to be in good
+      working order but is unable to answer either a Serial Query or a
+      Reset Query because it has no useful data available at this time.
+      This is likely to be a temporary error and most likely indicates
+      that the cache has not yet completed pulling down an initial
+      current data set from the Global RPKI system after some kind of
+      event that invalidated whatever data it might have previously held
+      (reboot, network partition, et cetera).
+
+   3: Invalid Request (fatal):  The cache server believes the client's
+      request to be invalid.
+
+   4: Unsupported Protocol Version (fatal):  The Protocol Version is not
+      known by the receiver of the PDU.
+
+   5: Unsupported PDU Type (fatal):  The PDU Type is not known by the
+      receiver of the PDU.
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 29]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   6: Withdrawal of Unknown Record (fatal):  The received PDU has
+      Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple
+      for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a
+      Router Key PDU) does not exist in the receiver's database.
+
+   7: Duplicate Announcement Received (fatal):  The received PDU has
+      Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple
+      for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a
+      Router Key PDU) is already active in the router.
+
+   8: Unexpected Protocol Version (fatal):  The received PDU has a
+      Protocol Version field that differs from the protocol version
+      negotiated in Section 7.
+
+13.  Security Considerations
+
+   As this document describes a security protocol, many aspects of
+   security interest are described in the relevant sections.  This
+   section points out issues which may not be obvious in other sections.
+
+   Cache Validation:  In order for a collection of caches as described
+      in Section 11 to guarantee a consistent view, they need to be
+      given consistent trust anchors to use in their internal validation
+      process.  Distribution of a consistent trust anchor is assumed to
+      be out of band.
+
+   Cache Peer Identification:  The router initiates a transport
+      connection to a cache, which it identifies by either IP address or
+      fully qualified domain name.  Be aware that a DNS or address
+      spoofing attack could make the correct cache unreachable.  No
+      session would be established, as the authorization keys would not
+      match.
+
+   Transport Security:  The RPKI relies on object, not server or
+      transport, trust.  That is, the IANA root trust anchor is
+      distributed to all caches through some out-of-band means and can
+      then be used by each cache to validate certificates and ROAs all
+      the way down the tree.  The inter-cache relationships are based on
+      this object security model; hence, the inter-cache transport can
+      be lightly protected.
+
+      However, this protocol document assumes that the routers cannot do
+      the validation cryptography.  Hence, the last link, from cache to
+      router, is secured by server authentication and transport-level
+      security.  This is dangerous, as server authentication and
+      transport have very different threat models than object security.
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 30]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+      So the strength of the trust relationship and the transport
+      between the router(s) and the cache(s) are critical.  You're
+      betting your routing on this.
+
+      While we cannot say the cache must be on the same LAN, if only due
+      to the issue of an enterprise wanting to offload the cache task to
+      their upstream ISP(s), locality, trust, and control are very
+      critical issues here.  The cache(s) really SHOULD be as close, in
+      the sense of controlled and protected (against DDoS, MITM)
+      transport, to the router(s) as possible.  It also SHOULD be
+      topologically close so that a minimum of validated routing data
+      are needed to bootstrap a router's access to a cache.
+
+      The identity of the cache server SHOULD be verified and
+      authenticated by the router client, and vice versa, before any
+      data are exchanged.
+
+      Transports which cannot provide the necessary authentication and
+      integrity (see Section 9) must rely on network design and
+      operational controls to provide protection against spoofing/
+      corruption attacks.  As pointed out in Section 9, TCP-AO is the
+      long-term plan.  Protocols which provide integrity and
+      authenticity SHOULD be used, and if they cannot, i.e., TCP is used
+      as the transport, the router and cache MUST be on the same
+      trusted, controlled network.
+
+14.  IANA Considerations
+
+   This section only discusses updates required in the existing IANA
+   protocol registries to accommodate version 1 of this protocol.  See
+   [RFC6810] for IANA considerations from the original (version 0)
+   protocol.
+
+   All existing entries in the IANA "rpki-rtr-pdu" registry remain valid
+   for protocol version 0.  All of the PDU types allowed in protocol
+   version 0 are also allowed in protocol version 1, with the addition
+   of the new Router Key PDU.  To reduce the likelihood of confusion,
+   the PDU number used by the Router Key PDU in protocol version 1 is
+   hereby registered as reserved (and unused) in protocol version 0.
+
+   The policy for adding to the registry is RFC Required per [RFC8126];
+   the document must be either Standards Track or Experimental.
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 31]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   The "rpki-rtr-pdu" registry has been updated as follows:
+
+              Protocol   PDU
+              Version    Type  Description
+              --------   ----  ---------------
+                 0-1       0   Serial Notify
+                 0-1       1   Serial Query
+                 0-1       2   Reset Query
+                 0-1       3   Cache Response
+                 0-1       4   IPv4 Prefix
+                 0-1       6   IPv6 Prefix
+                 0-1       7   End of Data
+                 0-1       8   Cache Reset
+                  0        9   Reserved
+                  1        9   Router Key
+                 0-1      10   Error Report
+                 0-1     255   Reserved
+
+   All existing entries in the IANA "rpki-rtr-error" registry remain
+   valid for all protocol versions.  Protocol version 1 adds one new
+   error code:
+
+              Error
+              Code    Description
+              -----   ---------------------------
+                  8   Unexpected Protocol Version
+
+15.  References
+
+15.1.  Normative References
+
+   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              DOI 10.17487/RFC1982, August 1996,
+              <https://www.rfc-editor.org/info/rfc1982>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
+              Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
+              1998, <https://www.rfc-editor.org/info/rfc2385>.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+              2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+
+
+
+Bush & Austein               Standards Track                   [Page 32]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   [RFC4252]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+              Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
+              January 2006, <https://www.rfc-editor.org/info/rfc4252>.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
+              December 2005, <https://www.rfc-editor.org/info/rfc4301>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246,
+              DOI 10.17487/RFC5246, August 2008,
+              <https://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
+              June 2010, <https://www.rfc-editor.org/info/rfc5925>.
+
+   [RFC5926]  Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
+              for the TCP Authentication Option (TCP-AO)", RFC 5926,
+              DOI 10.17487/RFC5926, June 2010,
+              <https://www.rfc-editor.org/info/rfc5926>.
+
+   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
+              Verification of Domain-Based Application Service Identity
+              within Internet Public Key Infrastructure Using X.509
+              (PKIX) Certificates in the Context of Transport Layer
+              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
+              2011, <https://www.rfc-editor.org/info/rfc6125>.
+
+   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
+              X.509 PKIX Resource Certificates", RFC 6487,
+              DOI 10.17487/RFC6487, February 2012,
+              <https://www.rfc-editor.org/info/rfc6487>.
+
+   [RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
+              Infrastructure (RPKI) to Router Protocol", RFC 6810,
+              DOI 10.17487/RFC6810, January 2013,
+              <https://www.rfc-editor.org/info/rfc6810>.
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 33]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
+              Austein, "BGP Prefix Origin Validation", RFC 6811,
+              DOI 10.17487/RFC6811, January 2013,
+              <https://www.rfc-editor.org/info/rfc6811>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8208]  Turner, S. and O. Borchert, "BGPsec Algorithms, Key
+              Formats, and Signature Formats", RFC 8208,
+              DOI 10.17487/RFC8208, September 2017,
+              <http://www.rfc-editor.org/info/rfc8208>.
+
+15.2.  Informative References
+
+   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
+              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
+              August 1996, <https://www.rfc-editor.org/info/rfc1996>.
+
+   [RFC4808]  Bellovin, S., "Key Change Strategies for TCP-MD5",
+              RFC 4808, DOI 10.17487/RFC4808, March 2007,
+              <https://www.rfc-editor.org/info/rfc4808>.
+
+   [RFC5781]  Weiler, S., Ward, D., and R. Housley, "The rsync URI
+              Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
+              <https://www.rfc-editor.org/info/rfc5781>.
+
+   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
+              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
+              February 2012, <https://www.rfc-editor.org/info/rfc6480>.
+
+   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
+              Resource Certificate Repository Structure", RFC 6481,
+              DOI 10.17487/RFC6481, February 2012,
+              <https://www.rfc-editor.org/info/rfc6481>.
+
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 34]
+
+RFC 8210                  RPKI-Router Protocol            September 2017
+
+
+Acknowledgements
+
+   The authors wish to thank Nils Bars, Steve Bellovin, Tim Bruijnzeels,
+   Rex Fernando, Richard Hansen, Paul Hoffman, Fabian Holler, Russ
+   Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg, Sandy
+   Murphy, Robert Raszuk, Andreas Reuter, Thomas C. Schmidt, John
+   Scudder, Ruediger Volk, Matthias Waehlisch, and David Ward.
+   Particular thanks go to Hannes Gredler for showing us the dangers of
+   unnecessary fields.
+
+   No doubt this list is incomplete.  We apologize to any contributor
+   whose name we missed.
+
+Authors' Addresses
+
+   Randy Bush
+   Internet Initiative Japan
+   5147 Crystal Springs
+   Bainbridge Island, Washington  98110
+   United States of America
+
+   Email: randy@psg.com
+
+
+   Rob Austein
+   Dragon Research Labs
+
+   Email: sra@hactrn.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush & Austein               Standards Track                   [Page 35]
+