summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8210.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8210.txt')
-rw-r--r--doc/rfc/rfc8210.txt1963
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]
+