draft-ietf-sidrops-8210bis-08.txt | draft-ietf-sidrops-8210bis-13.txt | |||
---|---|---|---|---|
Network Working Group R. Bush | Network Working Group R. Bush | |||
Internet-Draft IIJ, Arrcus, & DRL | Internet-Draft IIJ Research, Arrcus, & DRL | |||
Updates: 8210 (if approved) R. Austein | Intended status: Standards Track R. Austein | |||
Intended status: Standards Track Dragon Research Labs | Expires: 2 January 2025 Dragon Research Labs | |||
Expires: 3 December 2022 1 June 2022 | 1 July 2024 | |||
The Resource Public Key Infrastructure (RPKI) to Router Protocol, | The Resource Public Key Infrastructure (RPKI) to Router Protocol, | |||
Version 2 | Version 2 | |||
draft-ietf-sidrops-8210bis-08 | draft-ietf-sidrops-8210bis-13 | |||
Abstract | Abstract | |||
In order to verifiably validate the origin Autonomous Systems and | In order to verifiably validate the origin Autonomous Systems and | |||
Autonomous System Paths of BGP announcements, routers need a simple | Autonomous System Paths of BGP announcements, routers need a simple | |||
but reliable mechanism to receive Resource Public Key Infrastructure | but reliable mechanism to receive Resource Public Key Infrastructure | |||
(RFC 6480) prefix origin data and router keys from a trusted cache. | (RFC 6480) prefix origin data and router keys from a trusted cache. | |||
This document describes a protocol to deliver them. | This document describes a protocol to deliver them. | |||
This document describes version 2 of the RPKI-Router protocol. RFC | This document describes version 2 of the RPKI-Router protocol. RFC | |||
6810 describes version 0, and RFC 8210 describes version 1. This | 6810 describes version 0, and RFC 8210 describes version 1. This | |||
document updates and replaces RFC 8210. | document is compatible with both. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 3 December 2022. | This Internet-Draft will expire on 2 January 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Revised BSD License text as | extracted from this document must include Revised BSD License text as | |||
described in Section 4.e of the Trust Legal Provisions and are | described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Revised BSD License. | provided without warranty as described in the Revised BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
1.2. Changes from RFC 8210 . . . . . . . . . . . . . . . . . . 3 | 1.2. Changes from RFC 8210 . . . . . . . . . . . . . . . . . . 3 | |||
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 5 | 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Operational Overview . . . . . . . . . . . . . . . . . . . . 5 | 4. Operational Overview . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 6 | 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 7 | |||
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6 | 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 9 | 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 10 | |||
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 10 | 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 11 | 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 12 | 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 13 | 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 14 | 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 15 | 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 16 | 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 17 | 5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 17 | |||
5.12. ASPA PDU . . . . . . . . . . . . . . . . . . . . . . . . 18 | 5.12. ASPA PDU . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 20 | 6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 20 | |||
7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 22 | 7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 21 | |||
8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 23 | 8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 23 | |||
8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 23 | 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 23 | |||
8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 24 | 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 24 | |||
8.3. No Incremental Update Available . . . . . . . . . . . . . 25 | 8.3. No Incremental Update Available . . . . . . . . . . . . . 24 | |||
8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 25 | 8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 25 | |||
9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | 9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||
9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 27 | 9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 27 | |||
9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 28 | 9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 28 | |||
9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 29 | 9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 29 | |||
9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 29 | 9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 29 | |||
10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 29 | 10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 29 | |||
11. ROA PDU Race Minimization . . . . . . . . . . . . . . . . . . 30 | 11. ROA PDU Race Minimization . . . . . . . . . . . . . . . . . . 30 | |||
12. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 31 | 12. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 31 | |||
13. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 32 | 13. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
skipping to change at page 3, line 10 ¶ | skipping to change at page 3, line 10 ¶ | |||
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 | 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 | |||
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 | |||
16.1. Normative References . . . . . . . . . . . . . . . . . . 35 | 16.1. Normative References . . . . . . . . . . . . . . . . . . 35 | |||
16.2. Informative References . . . . . . . . . . . . . . . . . 37 | 16.2. Informative References . . . . . . . . . . . . . . . . . 37 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 38 | Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
1. Introduction | 1. Introduction | |||
In order to verifiably validate the origin Autonomous Systems (ASs) | In order to verifiably validate the origin Autonomous Systems (ASes) | |||
and AS paths of BGP announcements, routers need a simple but reliable | and AS paths of BGP announcements, routers need a simple but reliable | |||
mechanism to receive cryptographically validated Resource Public Key | mechanism to receive cryptographically validated Resource Public Key | |||
Infrastructure (RPKI) [RFC6480] prefix origin data and router keys | Infrastructure (RPKI) [RFC6480] prefix origin data and router keys | |||
from a trusted cache. This document describes a protocol to deliver | from a trusted cache. This document describes a protocol to deliver | |||
them. The design is intentionally constrained to be usable on much | them. The design is intentionally constrained to be usable on much | |||
of the current generation of ISP router platforms. | of the current generation of ISP router platforms. | |||
This document updates [RFC8210]. | This specification documents version 2 of the RPKI-RTR protocol. | |||
Earlier versions are documented in [RFC6810] and [RFC8210]. Though | ||||
this version is, of course, preferred, the earlier versions are | ||||
expected to continue to be productively deployed indefinitely, and | ||||
Section 7 details how to downgrade from this version to earlier | ||||
versions as needed in order to interoperate. | ||||
Section 3 describes the deployment structure, and Section 4 then | Section 3 describes the deployment structure, and Section 4 then | |||
presents an operational overview. The binary payloads of the | presents an operational overview. The binary payloads of the | |||
protocol are formally described in Section 5, and the expected | protocol are formally described in Section 5, and the expected | |||
Protocol Data Unit (PDU) sequences are described in Section 8. The | Protocol Data Unit (PDU) sequences are described in Section 8. The | |||
transport protocol options are described in Section 9. Section 10 | transport protocol options are described in Section 9. Section 10 | |||
details how routers and caches are configured to connect and | details how routers and caches are configured to connect and | |||
authenticate. Section 12 describes likely deployment scenarios. The | authenticate. Section 12 describes likely deployment scenarios. The | |||
traditional security and IANA considerations end the document. | traditional security and IANA considerations end the document. | |||
skipping to change at page 3, line 50 ¶ | skipping to change at page 4, line 9 ¶ | |||
1.2. Changes from RFC 8210 | 1.2. Changes from RFC 8210 | |||
This section summarizes the significant changes between [RFC8210] and | This section summarizes the significant changes between [RFC8210] and | |||
the protocol described in this document. | the protocol described in this document. | |||
* A new ASPA (Autonomous System Provider Authorization) PDU type | * A new ASPA (Autonomous System Provider Authorization) PDU type | |||
(Section 5.12) has been added to support | (Section 5.12) has been added to support | |||
[I-D.ietf-sidrops-aspa-profile]. | [I-D.ietf-sidrops-aspa-profile]. | |||
* A small Section 11 has been added to handle two ROA (Route | * A small Section 11 has been added to handle two possible ROA | |||
Origination Authorization) PDU race conditions, Break Before Make | (Route Origination Authorization) PDU race conditions, Break | |||
and Shorter Prefix First. | Before Make and Shorter Prefix First. | |||
* Language was clarified when multiple caches are configured, and an | ||||
interesting affect is noted. | ||||
* The protocol version number incremented from 1 (one) to 2 (two) | * The protocol version number incremented from 1 (one) to 2 (two) | |||
and Section 7 has been updated accordingly. | and Section 7 has been updated accordingly. | |||
2. Glossary | 2. Glossary | |||
The following terms are used with special meaning. | The following terms are used with special meaning. | |||
Global RPKI: The authoritative data of the RPKI are published in a | Global RPKI: The authoritative data of the RPKI are published in a | |||
distributed set of servers at the IANA, Regional Internet | distributed set of servers at the IANA, Regional Internet | |||
skipping to change at page 4, line 34 ¶ | skipping to change at page 4, line 45 ¶ | |||
successor. Relying Party software is used to gather and validate | successor. Relying Party software is used to gather and validate | |||
the distributed data of the RPKI into a cache. Trusting this | the distributed data of the RPKI into a cache. Trusting this | |||
cache further is a matter between the provider of the cache and a | cache further is a matter between the provider of the cache and a | |||
Relying Party. | Relying Party. | |||
Serial Number: "Serial Number" is a 32-bit strictly increasing | Serial Number: "Serial Number" is a 32-bit strictly increasing | |||
unsigned integer which wraps from 2^32-1 to 0. It denotes the | 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 | logical version of a cache. A cache increments the value when it | |||
successfully updates its data from a parent cache or from primary | successfully updates its data from a parent cache or from primary | |||
RPKI data. While a cache is receiving updates, new incoming data | RPKI data. While a cache is receiving updates, new incoming data | |||
and implicit deletes are associated with the new serial but MUST | and implicit deletes are associated with the new Serial Number but | |||
NOT be sent until the fetch is complete. A Serial Number is not | MUST NOT be sent until the fetch is complete. A Serial Number is | |||
commensurate between different caches or different protocol | not commensurate between different caches or different protocol | |||
versions, nor need it be maintained across resets of the cache | versions, nor need it be maintained across resets of the cache | |||
server. See [RFC1982] on DNS Serial Number Arithmetic for too | server. See [RFC1982] on DNS Serial Number Arithmetic for too | |||
much detail on the topic. | much detail on the topic. | |||
Session ID: When a cache server is started, it generates a Session | 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 | ID to uniquely identify the instance of the cache and to bind it | |||
to the sequence of Serial Numbers that cache instance will | to the sequence of Serial Numbers that cache instance will | |||
generate. This allows the router to restart a failed session | generate. This allows the router to restart a failed session | |||
knowing that the Serial Number it is using is commensurate with | knowing that the Serial Number it is using is commensurate with | |||
that of the cache. | that of the cache. | |||
skipping to change at page 5, line 30 ¶ | skipping to change at page 5, line 40 ¶ | |||
described in this document. It is said to be a client of the | 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 | cache. There MAY be mechanisms for the router to assure itself of | |||
the authenticity of the cache and to authenticate itself to the | the authenticity of the cache and to authenticate itself to the | |||
cache (see Section 9). | cache (see Section 9). | |||
4. Operational Overview | 4. Operational Overview | |||
A router establishes and keeps open a transport connection to one or | A router establishes and keeps open a transport connection to one or | |||
more caches with which it has client/server relationships. It is | more caches with which it has client/server relationships. It is | |||
configured with a semi-ordered list of caches and establishes a | configured with a semi-ordered list of caches and establishes a | |||
connection to the most preferred cache, or set of caches, which | connection to the most preferred cache, or set of caches with that | |||
accept the connections. | same priority, which accept the connections. | |||
The router MUST choose the most preferred, by configuration, cache or | The router MUST choose the most preferred, by configuration, cache or | |||
set of caches so that the operator may control load on their caches | set of caches so that the operator may control load on their caches | |||
and the Global RPKI. | and the Global RPKI. | |||
Periodically, the router sends to the cache the most recent Serial | A VRP is effective if it is in the fetched set from any of the | |||
Number for which it has received data from that cache, i.e., the | currently preferred caches. Therefore, a VRP takes effect on the | |||
router's current Serial Number, in the form of a Serial Query. When | router when the first cache serves that VRP, and the VRP is in effect | |||
a router establishes a new session with a cache or wishes to reset a | until the last cache withdraws that VRP. Thus, in a global sense, | |||
current relationship, it sends a Reset Query. | the effect of a VRP announcement propagates more quickly than a | |||
withdraw, | ||||
Periodically, the router sends a Serial Query 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 | 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, | 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 | 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 | that the Serial Number comparison used to determine "since the given | |||
Serial Number" MUST take wrap-around into account; see [RFC1982]. | Serial Number" MUST take wrap-around into account; see [RFC1982]. | |||
When the router has received all data records from the cache, it sets | 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 | its current Serial Number to that of the Serial Number in the | |||
received End of Data PDU. | received End of Data PDU. | |||
skipping to change at page 6, line 27 ¶ | skipping to change at page 6, line 50 ¶ | |||
full transfer if for any reason the cache is unable to provide the | full transfer if for any reason the cache is unable to provide the | |||
necessary incremental data. Unlike some incremental transfer | necessary incremental data. Unlike some incremental transfer | |||
protocols, this protocol requires the router to make an explicit | protocols, this protocol requires the router to make an explicit | |||
request to start the fallback process; this is deliberate, as the | request to start the fallback process; this is deliberate, as the | |||
cache has no way of knowing whether the router has also established | cache has no way of knowing whether the router has also established | |||
sessions with other caches that may be able to provide better | sessions with other caches that may be able to provide better | |||
service. | service. | |||
As a cache server must evaluate certificates and ROAs (Route Origin | As a cache server must evaluate certificates and ROAs (Route Origin | |||
Authorizations; see [RFC6480]), which are time dependent, servers' | Authorizations; see [RFC6480]), which are time dependent, servers' | |||
clocks MUST be correct to a tolerance of approximately an hour. | clocks MUST be correct to a tolerance of an hour. | |||
Barring errors, transport connections remain up as long as the cache | Barring errors, transport connections remain up as long as the cache | |||
and router remain up and the router is not reconfigured to no longer | and router remain up and the router is not reconfigured to no longer | |||
use the cache. | use the cache. | |||
Should a transport connection be lost for unknown reasons, the router | Should a transport connection be lost for unknown reasons, the router | |||
SHOULD try to reestablish one; being careful to not abuse the cache | SHOULD try to reestablish one; being careful to not abuse the cache | |||
with twoo many failed requests. | with two many failed requests. | |||
5. Protocol Data Units (PDUs) | 5. Protocol Data Units (PDUs) | |||
The exchanges between the cache and the router are sequences of | The exchanges between the cache and the router are sequences of | |||
exchanges of the following PDUs according to the rules described in | exchanges of the following PDUs according to the rules described in | |||
Section 8. | Section 8. | |||
Reserved fields (marked "zero" in PDU diagrams) MUST be zero on | Reserved fields (marked "zero" in PDU diagrams) MUST be zero on | |||
transmission and MUST be ignored on receipt. | transmission and MUST be ignored on receipt. | |||
5.1. Fields of a PDU | 5.1. Fields of a PDU | |||
PDUs contain the following data elements: | PDUs contain the following data elements: | |||
Protocol Version: An 8-bit unsigned integer, currently 2, denoting | Protocol Version: An 8-bit unsigned integer, currently 2, denoting | |||
the version of this protocol. | the version of this protocol. | |||
PDU Type: An 8-bit unsigned integer, denoting the type of the PDU, | PDU Type: An 8-bit unsigned integer, denoting the type of the PDU, | |||
e.g., IPv4 Prefix. | e.g., IPv4 Prefix. | |||
Serial Number: The Serial Number of the RPKI cache when this set of | Serial Number: A 32-bit unsigned integer serializing the RPKI cache | |||
PDUs was received from an upstream cache server or gathered from | epoch when this set of PDUs was received from an upstream cache | |||
the Global RPKI. A cache increments its Serial Number when | server or gathered from the Global RPKI. A cache increments its | |||
completing a rigorously validated update from a parent cache or | Serial Number when completing a validated update from a parent | |||
the Global RPKI. | cache or the Global RPKI. | |||
Session ID: A 16-bit unsigned integer. When a cache server is | Session ID: A 16-bit unsigned integer. When a cache server is | |||
started, it generates a Session ID to identify the instance of the | 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 | cache and to bind it to the sequence of Serial Numbers that cache | |||
instance will generate. This allows the router to restart a | instance will generate. This allows the router to restart a | |||
failed session knowing that the Serial Number it is using is | failed session knowing that the Serial Number it is using is | |||
commensurate with that of the cache. If, at any time after the | commensurate with that of the cache. If, at any time after the | |||
protocol version has been negotiated (Section 7), either the | protocol version has been negotiated (Section 7), either the | |||
router or the cache finds that the value of the Session ID is not | router or the cache finds that the value of the Session ID is not | |||
the same as the other's, the party which detects the mismatch MUST | the same as the other's, the party which detects the mismatch MUST | |||
skipping to change at page 8, line 18 ¶ | skipping to change at page 8, line 44 ¶ | |||
and reset the session. The one case in which the router may stay | 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 | out of sync is when nothing in the Cache Response contradicts any | |||
data currently held by the router. | data currently held by the router. | |||
Using persistent storage for the Session ID or a clock-based | Using persistent storage for the Session ID or a clock-based | |||
scheme for generating Session IDs should avoid the risk of Session | scheme for generating Session IDs should avoid the risk of Session | |||
ID collisions. | ID collisions. | |||
The Session ID might be a pseudorandom value, a strictly | The Session ID might be a pseudorandom value, a strictly | |||
increasing value if the cache has reliable storage, et cetera. A | increasing value if the cache has reliable storage, et cetera. A | |||
seconds-since-epoch timestamp value such as the POSIX time() | seconds-since-epoch timestamp value such as the low order 16 bits | |||
function makes a good Session ID value. | of unsigned integer seconds since 1970-01-01T00:00:00Z ignoring | |||
leap seconds might make a good Session ID value. | ||||
Length: A 32-bit unsigned integer which has as its value the count | 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 | of the bytes in the entire PDU, including the 8 bytes of header | |||
which includes the length field. | which includes the length field. | |||
Flags: The lowest-order bit of the Flags field is 1 for an | Flags: An 8-bit binary field, with the lowest-order bit being 1 for | |||
announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or | an announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or | |||
IPv6), the announce/withdraw flag indicates whether this PDU | IPv6), the announce/withdraw flag indicates whether this PDU | |||
announces a new right to announce the prefix or withdraws a | announces a new right to announce the prefix or withdraws a | |||
previously announced right; a withdraw effectively deletes one | previously announced right; a withdraw effectively deletes one | |||
previously announced Prefix PDU with the exact same Prefix, | previously announced Prefix PDU with the exact same Prefix, | |||
Length, Max-Len, and Autonomous System Number (ASN). | Length, Max-Len, and Autonomous System Number (ASN). | |||
Similarly, for a Router Key PDU, the flag indicates whether this | Similarly, for a Router Key PDU, the flag indicates whether this | |||
PDU announces a new Router Key or deletes one previously announced | PDU announces a new Router Key or deletes one previously announced | |||
Router Key PDU with the exact same AS Number, | Router Key PDU with the exact same AS Number, | |||
subjectKeyIdentifier, and subjectPublicKeyInfo. | subjectKeyIdentifier, and subjectPublicKeyInfo. | |||
skipping to change at page 9, line 5 ¶ | skipping to change at page 9, line 30 ¶ | |||
Max Length: An 8-bit unsigned integer denoting the longest prefix | Max Length: An 8-bit unsigned integer denoting the longest prefix | |||
allowed by the Prefix element. This MUST NOT be less than the | allowed by the Prefix element. This MUST NOT be less than the | |||
Prefix Length element. | Prefix Length element. | |||
Prefix: The IPv4 or IPv6 prefix of the ROA. | Prefix: The IPv4 or IPv6 prefix of the ROA. | |||
Autonomous System Number: A 32-bit unsigned integer representing an | Autonomous System Number: A 32-bit unsigned integer representing an | |||
ASN allowed to announce a prefix or associated with a router key. | ASN allowed to announce a prefix or associated with a router key. | |||
Subject Key Identifier: 20-octet Subject Key Identifier (SKI) value | Subject Key Identifier: The 20-octet Subject Key Identifier (SKI) | |||
of a router key, as described in [RFC6487]. | value of a router key, as described in [RFC6487]. | |||
Subject Public Key Info: A router key's subjectPublicKeyInfo value, | ||||
as described in [RFC8608]. 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 | Subject Public Key Info: A variable length field holding a router | |||
Section 6. | key's subjectPublicKeyInfo value, as described in [RFC8608]. This | |||
is the full ASN.1 DER encoding of the subjectPublicKeyInfo, | ||||
including the ASN.1 tag and length values of the | ||||
subjectPublicKeyInfo SEQUENCE. | ||||
Retry Interval: Interval between cache poll retries after a failed | Refresh Interval: A 32-bit interval in seconds between normal cache | |||
cache poll. See Section 6. | polls. See Section 6. | |||
Expire Interval: Interval during which data fetched from a cache | Retry Interval: A 32-bit interval in seconds between cache poll | |||
remains valid in the absence of a successful subsequent cache | retries after a failed cache poll. See Section 6. | |||
poll. See Section 6. | ||||
AFI Flags: A field of the ASPA PDU where the low order bit denotes | Expire Interval: A 32-bit interval in seconds during which data | |||
whether the AS relationships are for IPv4 (0) or IPv6 (1) AFI. | fetched from a cache remains valid in the absence of a successful | |||
subsequent cache poll. See Section 6. | ||||
Provider AS Count: The number of Provider Autonomous System Numbers | Provider AS Count: A 16-bit count of Provider Autonomous System | |||
in the PDU. | Numbers in the PDU. | |||
Customer Autonomous System Number: The AS number of the Autonomous | Customer Autonomous System Number: The 32-bit AS number of the | |||
System that authorizes the upstream providers listed in the | Autonomous System that authorizes the upstream providers listed in | |||
Provider Autonomous System list to propagate prefixes of the | the Provider Autonomous System list to propagate prefixes of the | |||
specified address family other ASes. | specified address family to other ASes. | |||
Provider Autonomous System Numbers: The set of AS numbers authorized | Provider Autonomous System Numbers: The set of 32-bit AS numbers | |||
to propagate prefixes of the spacified AFI which were received | authorized to propagate prefixes which were received from the | |||
from the customer AS. | customer AS. | |||
5.2. Serial Notify | 5.2. Serial Notify | |||
The cache notifies the router that the cache has new data. | The cache notifies the router that the cache has new data. | |||
The Session ID reassures the router that the Serial Numbers are | The Session ID reassures the router that the Serial Numbers are | |||
commensurate, i.e., the cache session has not been changed. | commensurate, i.e., the cache session has not been changed. | |||
Upon receipt of a Serial Notify PDU, the router MAY issue an | Upon receipt of a Serial Notify PDU, the router MAY issue an | |||
immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) | immediate Serial Query (Section 5.3) or Reset Query (Section 5.4) | |||
skipping to change at page 13, line 27 ¶ | skipping to change at page 13, line 41 ¶ | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| IPv4 Prefix | | | IPv4 Prefix | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Autonomous System Number | | | Autonomous System Number | | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv4 | ||||
ROA. | ||||
The lowest-order bit of the Flags field is 1 for an announcement and | The lowest-order bit of the Flags field is 1 for an announcement and | |||
0 for a withdrawal. | 0 for a withdrawal. | |||
In the RPKI, nothing prevents a signing certificate from issuing two | In the RPKI, nothing prevents a signing certificate from issuing two | |||
identical ROAs. In this case, there would be no semantic difference | identical ROAs. In this case, there would be no semantic difference | |||
between the objects, merely a process redundancy. | between the objects, merely a process redundancy. | |||
In the RPKI, there is also an actual need for what might appear to a | 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 | router as identical IPvX PDUs. This can occur when an upstream | |||
certificate is being reissued or there is an address ownership | certificate is being reissued or there is an address ownership | |||
skipping to change at page 14, line 31 ¶ | skipping to change at page 14, line 49 ¶ | |||
+--- IPv6 Prefix ---+ | +--- IPv6 Prefix ---+ | |||
| | | | | | |||
+--- ---+ | +--- ---+ | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Autonomous System Number | | | Autonomous System Number | | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
This PDU carries an [RFC6811] Validated ROA Payload (VRP) for an IPv6 | ||||
ROA. | ||||
Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. | Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. | |||
5.8. End of Data | 5.8. End of Data | |||
The cache tells the router it has no more data for the request. | 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 | The Session ID and Protocol Version MUST be the same as that of the | |||
corresponding Cache Response which began the (possibly null) sequence | corresponding Cache Response which began the (possibly null) sequence | |||
of payload PDUs. | of payload PDUs. | |||
skipping to change at page 16, line 46 ¶ | skipping to change at page 17, line 4 ¶ | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| AS Number | | | AS Number | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Subject Public Key Info | | | Subject Public Key Info | | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
The Router Key PDU transports an [RFC8635] Router key. | ||||
The lowest-order bit of the Flags field is 1 for an announcement and | The lowest-order bit of the Flags field is 1 for an announcement and | |||
0 for a withdrawal. | 0 for a withdrawal. | |||
The cache server MUST ensure that it has told the router client to | 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 | 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 | Public Key} at any one point in time. Should the router client | |||
receive a Router Key PDU with a {SKI, ASN, Subject Public Key} | receive a Router Key PDU with a {SKI, ASN, Subject Public Key} | |||
identical to one it already has active, it SHOULD raise a Duplicate | identical to one it already has active, it SHOULD raise a Duplicate | |||
Announcement Received error. | Announcement Received error. | |||
skipping to change at page 17, line 20 ¶ | skipping to change at page 17, line 28 ¶ | |||
Public Key value may appear in multiple Router Key PDUs with | Public Key value may appear in multiple Router Key PDUs with | |||
different ASNs. In the interest of keeping the announcement and | different ASNs. In the interest of keeping the announcement and | |||
withdrawal semantics as simple as possible for the router, this | withdrawal semantics as simple as possible for the router, this | |||
protocol makes no attempt to compress either of these cases. | protocol makes no attempt to compress either of these cases. | |||
Also note that it is possible, albeit very unlikely, for multiple | Also note that it is possible, albeit very unlikely, for multiple | |||
distinct Subject Public Key values to hash to the same SKI. For this | distinct Subject Public Key values to hash to the same SKI. For this | |||
reason, implementations MUST compare Subject Public Key values as | reason, implementations MUST compare Subject Public Key values as | |||
well as SKIs when detecting duplicate PDUs. | well as SKIs when detecting duplicate PDUs. | |||
As the Subject Public Key Info is a variable length field, it must be | ||||
decoded to determine where the PDU terminates. | ||||
5.11. Error Report | 5.11. Error Report | |||
This PDU is used by either party to report an error to the other. | 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 | Error reports are only sent as responses to other PDUs, not to report | |||
errors in Error Report PDUs. | errors in Error Report PDUs. | |||
Error codes are described in Section 13. | Error codes are described in Section 13. | |||
The Erroneous PDU field is a binary copy of the PDU causing the error | ||||
condition, including all fields. | ||||
If the error is generic (e.g., "Internal Error") and not associated | 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 | 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. | 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 | 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 | erroneous Error Report PDU is received, the session SHOULD be | |||
dropped. | dropped. | |||
If the error is associated with a PDU of excessive length, i.e., too | 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 | long to be any legal PDU other than another Error Report, or a | |||
possibly corrupt length, the Erroneous PDU field MAY be truncated. | possibly corrupt length, the Erroneous PDU field MAY be truncated. | |||
The diagnostic text is optional; if not present, the Length of Error | The Arbitrary Text field is optional; if not present, the Length of | |||
Text field MUST be zero. If error text is present, it MUST be a | Arbitrary text field MUST be zero. If Arbitrary Text is present, it | |||
string in UTF-8 encoding (see [RFC3629]). | MUST be a string in UTF-8 encoding (see [RFC3629]) in the Queen's | |||
English. | ||||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | Error Code | | | Version | Type | Error Code | | |||
| 2 | 10 | | | | 2 | 10 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length | | | Length | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length of Encapsulated PDU | | | Length of Encapsulated PDU | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
~ Erroneous PDU ~ | ~ Erroneous PDU ~ | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length of Error Text | | | Length of Arbitrary Text | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Arbitrary Text | | | Arbitrary Text | | |||
| of | | ~ of ~ | |||
~ Error Diagnostic Message ~ | | Error Diagnostic Message | | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
5.12. ASPA PDU | 5.12. ASPA PDU | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | zero | | | Version | Type | zero | | |||
| 2 | 11 | | | | 2 | 11 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length | | | Length | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | | | | | |||
| Flags | AFI Flags| Provider AS Count | | | Flags | zero | Provider AS Count | | |||
| | | | | | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Customer Autonomous System Number | | | Customer Autonomous System Number | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
~ Provider Autonomous System Numbers ~ | ~ Provider Autonomous System Numbers ~ | |||
| | | | | | |||
~-------------------------------------------~ | ~-------------------------------------------~ | |||
The ASPA PDU supports [I-D.ietf-sidrops-aspa-profile]. An ASPA PDU | The ASPA PDU supports [I-D.ietf-sidrops-aspa-profile]. An ASPA PDU | |||
represents one single customer AS and its provider ASs for a | represents one single customer AS and its provider ASes. Receipt of | |||
particular Address Family. Receipt of an ASPA PDU announcement | an ASPA PDU announcement (announce/withdraw flag == 1) when the | |||
(announce/withdraw flag == 1) when the router already has an ASPA PDU | router already has an ASPA PDU with the same Customer Autonomous | |||
with the same Customer Autonomous System Number and the same Address | System Number replaces the previous one. The cache MUST deliver the | |||
Family (see AFI Flags field), replaces the previous one. This is to | complete data of an ASPA record in a single ASPA PDU. | |||
avoid a race condition when a BGP announcement is received between a | ||||
withdrawn ASPA PDU and a newly announced ASPA PDU. Therefore, the | ||||
cache MUST deliver the complete data of an ASPA record in a single | ||||
ASPA PDU. | ||||
The router should see at most one ASPA for a given AFI from a cache | The router MUST see at most one ASPA from a cache for a particular | |||
for a particular Customer Autonomous System Number active at any | Customer Autonomous System Number active at any time. As a number of | |||
time. As a number of conditions in the global RPKI may present | conditions in the global RPKI may present multiple valid ASPA RPKI | |||
multiple valid ASPA RPKI records for a single customer to a | records for a single customer to a particular RP cache, this places a | |||
particular RP cache, this places a burden on the cache to form the | burden on the cache to form the union of multiple ASPA records it has | |||
union of multiple ASPA records it has received from the global RPKI | received from the global RPKI into one ASPA PDU. | |||
into one ASPA PDU. | ||||
The Flags field is as described in Section 5. | The Flags field is as described in Section 5. | |||
For the ASPA PDU, the announce/withdraw Flag is set to 1 to indicate | For the ASPA PDU, the announce/withdraw Flag is set to 1 to indicate | |||
either the announcement of a new ASPA record or a replacement for a | either the announcement of a new ASPA record or a replacement for a | |||
previously announced record with the same Customer Autonomous System | previously announced record with the same Customer Autonomous System | |||
Number and AFI. The announce/withdraw flag set to 0 indicates | Number. | |||
removal of the ASPA record in total. Here, only the AFI and the | ||||
customer AS of the ASPA record MUST be provided, the Provider AS | ||||
Count as well as the Provider AS Numbers list MUST be zero. | ||||
The AFI Flags field is defined as follows: | ||||
Bit Bit Name | If the announce/withdraw flag is set to 0, it indicates removal of | |||
---- ------------------- | the entire ASPA record for that Customer AS. Here, the customer AS | |||
0 AFI (IPv4 == 0, IPv6 == 1) | of the ASPA record MUST be provided, the Provider AS Count must be | |||
1-7 Reserved, MUST be zero | zero, the Provider AS Numbers list MUST be null, and these last two | |||
fields MUST be ignored by the router. | ||||
The Provider AS Count is the number of 32-bit Provider Autonomous | The Provider AS Count is the number of 32-bit Provider Autonomous | |||
System Numbers in the PDU. | System Numbers in the PDU. | |||
The Customer Autonomous System Number is the 32-bit Autonomous System | The Customer Autonomous System Number is the 32-bit Autonomous System | |||
Number of the customer which authenticated the PDU. There MUST be | Number of the customer which authenticated the ASPA RPKI data. There | |||
one and only one ASPA for a Customer Autonomous System Number active | MUST be one and only one ASPA for a Customer Autonomous System Number | |||
in the router at any time. | active in the router at any time. | |||
There are zero or more 32-bit Provider Autonomous System Number | There are zero or more 32-bit Provider Autonomous System Number | |||
fields as indicated in the Provider AS Count; see | fields as indicated in the Provider AS Count; see | |||
[I-D.ietf-sidrops-aspa-profile]. | [I-D.ietf-sidrops-aspa-profile]. | |||
Receipt of an ASPA PDU with the Flags field indicating Delete is an | ||||
explicit withdraw from the router of the entire ASPA data for that | ||||
customer AS. While the Provider AS Count and the Provider AS Numbers | ||||
MUST be ignored by the router when the Flags field indicates a | ||||
Delete, the cache MUST set the Provider AS Count to zero, and have a | ||||
null Provider AS Numbers list. | ||||
6. Protocol Timing Parameters | 6. Protocol Timing Parameters | |||
Since the data the cache distributes via the RPKI-Router protocol are | Since the data the cache distributes via the RPKI-Router protocol are | |||
retrieved from the Global RPKI system at intervals which are only | retrieved from the Global RPKI system at intervals which are only | |||
known to the cache, only the cache can really know how frequently it | 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 | 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 | are likely to remain valid (or, at least, unchanged). For this | |||
reason, as well as to allow the cache some control over the load | 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 | placed on it by its client routers, the End Of Data PDU includes | |||
three values that allow the cache to communicate timing parameters to | three values that allow the cache to communicate timing parameters to | |||
skipping to change at page 21, line 49 ¶ | skipping to change at page 21, line 34 ¶ | |||
Minimum allowed value: 600 seconds (10 minutes). | Minimum allowed value: 600 seconds (10 minutes). | |||
Maximum allowed value: 172800 seconds (2 days). | Maximum allowed value: 172800 seconds (2 days). | |||
Recommended default: 7200 seconds (2 hours). | Recommended default: 7200 seconds (2 hours). | |||
If the router has never issued a successful query against a | If the router has never issued a successful query against a | |||
particular cache, it SHOULD retry periodically using the default | particular cache, it SHOULD retry periodically using the default | |||
Retry Interval, above. | Retry Interval, above. | |||
Caches MUST set Expire Interval to a value larger than either Refresh | Caches MUST set Expire Interval to a value larger than both the | |||
Interval or Retry Interval. | Refresh Interval and the Retry Interval. | |||
7. Protocol Version Negotiation | 7. Protocol Version Negotiation | |||
A router MUST start each transport connection by issuing either a | Once a router has established a transport connection to a cache, it | |||
Reset Query or a Serial Query. This query MUST tell the cache the | MUST attempt to open a RPKI-Router 'session' by issuing either a | |||
highest version of this protocol the router implements. | Reset Query Section 5.4) or a Serial Query (Section 5.3) with the | |||
highest version of this protocol the router implements in the | ||||
Protocol Version field. If the cache supports that version, it | ||||
responds with a Cache Response (Section 5.5) of that version and the | ||||
session is considered open. | ||||
If a cache which supports version N receives a query from a router | If a cache which supports version C receives a query with Protocol | |||
which specifies its highest supported version Q < N, the cache MUST | Version Q < C, and the cache does not support versions <= Q, the | |||
downgrade to protocol version Q [RFC6810] or [RFC8210] or send a | cache MUST send an Error Report (Section 5.11) with Protocol Version | |||
version 2 Error Report PDU with Error Code 4 ("Unsupported Protocol | C and Error Code 4 ("Unsupported Protocol Version") and disconnect | |||
Version") and terminate the connection; in which case the Arbitrary | the transport, as negotiation is hopeless. | |||
Text field of the ERROR Report PDU MUST be a list of one octet binary | ||||
integers indicating the version numbers the cache supports. The | ||||
router MUST choose the highest mutally supported version. If there | ||||
are none, the router MUST abort the session, sending a version 2 | ||||
Error Report PDU with Error Code 4 ("Unsupported Protocol Version"). | ||||
If a router which supports version N sends a query to a cache which | If a cache which supports version C receives a query with Protocol | |||
only supports version C < N, one of two things will happen: | Version Q < C, and the cache can support version Q, the cache MUST | |||
downgrade to protocol version Q, [RFC6810] or [RFC8210], and respond | ||||
with a Cache Response (Section 5.5) of that Protocol Version, Q, and | ||||
the RPKI-Rtr session is considered open. | ||||
1. The cache may terminate the connection, perhaps with a version 2 | If the the cache which supports C as its highest verion receives a | |||
Error Report PDU with Error Code 4 ("Unsupported Protocol | query of version Q > C, the cache MUST send an Error Report with | |||
Version"). In this case, the router MAY retry the connection | Protocol Version C and Error Code 4. The router SHOULD send another | |||
using protocol version C. | query with a Protocol Version Q with Q == the version C in the Error | |||
Report; unless it has already failed at that version, which indicates | ||||
a fatal error in programming of the cache which SHOULD result in | ||||
transport termination. | ||||
2. The cache may reply with a version C response. In this case, the | If the router requests Q == 0 and it still fails with the cache | |||
router MUST either downgrade to version C or terminate the | responding with an Error Report with Error Code 4, then the router | |||
connection. | MUST abort the transport connection, as negotiation is hopeless. | |||
In any of the downgraded combinations above, the new features of the | In any of the downgraded combinations above, the new features of the | |||
higher version will not be available, and all PDUs will have the | higher version will not be available, and all PDUs MUST have the | |||
negotiated lower version number in their version fields. | negotiated lower version number in their version fields. | |||
If either party receives a PDU containing an unrecognized Protocol | If either party receives a PDU containing an unrecognized Protocol | |||
Version (neither 0, 1, nor 2) during this negotiation, it MUST either | Version (neither 0, 1, nor 2) during this negotiation, it MUST either | |||
downgrade to a known version or terminate the connection, with an | downgrade to a known version or terminate the connection, with an | |||
Error Report PDU unless the received PDU is itself an Error Report | Error Report PDU unless the received PDU is itself an Error Report | |||
PDU. | PDU. | |||
The router MUST ignore any Serial Notify PDUs it might receive from | The router MUST ignore any Serial Notify PDUs it might receive from | |||
the cache during this initial startup period, regardless of the | the cache during this initial startup period, regardless of the | |||
skipping to change at page 23, line 23 ¶ | skipping to change at page 23, line 6 ¶ | |||
of the not-yet-complete version negotiation process, so there is | of the not-yet-complete version negotiation process, so there is | |||
nothing to be gained by processing notifications until version | nothing to be gained by processing notifications until version | |||
negotiation completes. | negotiation completes. | |||
Caches SHOULD NOT send Serial Notify PDUs before version negotiation | Caches SHOULD NOT send Serial Notify PDUs before version negotiation | |||
completes. Routers, however, MUST handle such notifications (by | completes. Routers, however, MUST handle such notifications (by | |||
ignoring them) for backwards compatibility with caches serving | ignoring them) for backwards compatibility with caches serving | |||
protocol version 0. | protocol version 0. | |||
Once the cache and router have agreed upon a Protocol Version via the | 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 | negotiation process above, that version is fixed for the life of the | |||
session. See Section 5.1 for a discussion of the interaction between | session. See Section 5.1 for a discussion of the interaction between | |||
Protocol Version and Session ID. | Protocol Version and Session ID. | |||
The configured transport security, the negotiated RPKI-Rtr version, | ||||
etc. MAY NOT be changed once a session has been established. If one | ||||
side or the other wishes to try a different transport, protocol | ||||
version, etc. they MUST terminate the transport and restart the | ||||
entire transport and version negotiation process. | ||||
If either party receives a PDU for a different Protocol Version once | If either party receives a PDU for a different Protocol Version once | |||
the above negotiation completes, that party MUST drop the session; | the above negotiation completes, that party MUST drop the session; | |||
unless the PDU containing the unexpected Protocol Version was itself | unless the PDU containing the unexpected Protocol Version was itself | |||
an Error Report PDU, the party dropping the session SHOULD send an | an Error Report PDU, the party dropping the session SHOULD send an | |||
Error Report with an error code of 8 ("Unexpected Protocol Version"). | Error Report with an error code of 8 ("Unexpected Protocol Version"). | |||
8. Protocol Sequences | 8. Protocol Sequences | |||
The sequences of PDU transmissions fall into four conversations as | The sequences of PDU transmissions fall into four conversations as | |||
follows: | follows: | |||
skipping to change at page 24, line 7 ¶ | skipping to change at page 23, line 43 ¶ | |||
| ----- Cache Response -----> | C confirms request | | ----- Cache Response -----> | C confirms request | |||
| ------- Payload PDU ------> | C sends zero or more | | ------- Payload PDU ------> | C sends zero or more | |||
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | |||
| ------- Payload PDU ------> | ASPA, or Router Key PDUs | | ------- Payload PDU ------> | ASPA, or Router Key PDUs | |||
| ------- End of Data ------> | C sends End of Data | | ------- End of Data ------> | C sends End of Data | |||
| | and sends new serial | | | and sends new serial | |||
~ ~ | ~ ~ | |||
When a transport connection is first established, the router MUST | When a transport connection is first established, the router MUST | |||
send either a Reset Query or a Serial Query. A Serial Query would be | send either a Reset Query or a Serial Query. A Serial Query would be | |||
appropriate if the router has significant unexpired data from a | appropriate if the router has unexpired data from a broken session | |||
broken session with the same cache and remembers the Session ID of | with the same cache and remembers the Session ID of that session, in | |||
that session, in which case a Serial Query containing the Session ID | which case a Serial Query containing the Session ID from the previous | |||
from the previous session will allow the router to bring itself up to | session will allow the router to bring itself up to date while | |||
date while ensuring that the Serial Numbers are commensurate and that | ensuring that the Serial Numbers are commensurate and that the router | |||
the router and cache are speaking compatible versions of the | and cache are speaking compatible versions of the protocol. In all | |||
protocol. In all other cases, the router lacks the necessary data | other cases, the router lacks the necessary data for fast | |||
for fast resynchronization and therefore MUST fall back to a Reset | resynchronization and therefore MUST fall back to a Reset Query. | |||
Query. | ||||
The Reset Query sequence is also used when the router receives a | 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 | Cache Reset, chooses a new cache, or fears that it has otherwise lost | |||
its way. | its way. | |||
See Section 7 for details on version negotiation. | See Section 7 for details on version negotiation. | |||
To limit the length of time a cache must keep the data necessary to | To limit the length of time a cache must keep the data necessary to | |||
generate incremental updates, a router MUST send either a Serial | generate incremental updates, a router MUST send either a Serial | |||
Query or a Reset Query periodically. This also acts as a keep-alive | Query or a Reset Query periodically. This also acts as a keep-alive | |||
skipping to change at page 26, line 29 ¶ | skipping to change at page 26, line 18 ¶ | |||
to a restart, and has not yet recovered. While it is possible that a | 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 | cache might go into such a state without dropping any of its active | |||
sessions, a router is more likely to see this behavior when it | sessions, a router is more likely to see this behavior when it | |||
initially connects and issues a Reset Query while the cache is still | initially connects and issues a Reset Query while the cache is still | |||
rebuilding its database. | rebuilding its database. | |||
When a router receives this kind of error, the router SHOULD attempt | When a router receives this kind of error, the router SHOULD attempt | |||
to connect to any other caches in its cache list, in preference | to connect to any other caches in its cache list, in preference | |||
order. If no other caches are available, the router MUST issue | order. If no other caches are available, the router MUST issue | |||
periodic Reset Queries until it gets a new usable load from the | periodic Reset Queries until it gets a new usable load from the | |||
cache. | cache; maybe once a minute so as not to DoS the cache. | |||
9. Transport | 9. Transport | |||
The transport-layer session between a router and a cache carries the | The transport-layer session between a router and a cache carries the | |||
binary PDUs in a persistent session. | binary PDUs in a persistent session. | |||
To prevent cache spoofing and DoS attacks by illegitimate routers, it | To prevent cache spoofing and DoS attacks by illegitimate routers, it | |||
is highly desirable that the router and the cache be authenticated to | is highly desirable that the router and the cache be authenticated to | |||
each other. Integrity protection for payloads is also desirable to | each other. Integrity protection for payloads is also desirable to | |||
protect against monkey-in-the-middle (MITM) attacks. Unfortunately, | protect against monkey-in-the-middle (MITM) attacks. Unfortunately, | |||
skipping to change at page 27, line 23 ¶ | skipping to change at page 27, line 12 ¶ | |||
If available to the operator, caches and routers MUST use one of the | If available to the operator, caches and routers MUST use one of the | |||
following more protected protocols: | following more protected protocols: | |||
* Caches and routers SHOULD use TCP-AO transport [RFC5925] over the | * Caches and routers SHOULD use TCP-AO transport [RFC5925] over the | |||
rpki-rtr port. | rpki-rtr port. | |||
* Caches and routers MAY use Secure Shell version 2 (SSHv2) | * Caches and routers MAY use Secure Shell version 2 (SSHv2) | |||
transport [RFC4252] using the normal SSH port. For an example, | transport [RFC4252] using the normal SSH port. For an example, | |||
see Section 9.1. | see Section 9.1. | |||
* Caches and routers MAY use TCP MD5 transport [RFC5925] using the | * Caches and routers MAY use TCP MD5 transport [RFC2385] using the | |||
rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO | rpki-rtr port if no other protected transport is available. Note | |||
[RFC5925]. | that TCP MD5 has been obsoleted by TCP-AO [RFC5925]. | |||
* Caches and routers MAY use TCP over IPsec transport [RFC4301] | * Caches and routers MAY use TCP over IPsec transport [RFC4301] | |||
using the rpki-rtr port. | using the rpki-rtr port. | |||
* Caches and routers MAY use Transport Layer Security (TLS) | * Caches and routers MAY use Transport Layer Security (TLS) | |||
transport [RFC8446] using port rpki-rtr-tls (324); see Section 15. | transport [RFC8446] using port rpki-rtr-tls (324); see Section 15. | |||
Conformance to [RFC7525] modern cipher suites is REQUIRED. | ||||
9.1. SSH Transport | 9.1. SSH Transport | |||
To run over SSH, the client router first establishes an SSH transport | To run over SSH, the client router first establishes an SSH transport | |||
connection using the SSHv2 transport protocol, and the client and | connection using the SSHv2 transport protocol, and the client and | |||
server exchange keys for message integrity and encryption. The | server exchange keys for message integrity and encryption. The | |||
client then invokes the "ssh-userauth" service to authenticate the | client then invokes the "ssh-userauth" service to authenticate the | |||
application, as described in the SSH authentication protocol | application, as described in the SSH authentication protocol | |||
[RFC4252]. Once the application has been successfully authenticated, | [RFC4252]. Once the application has been successfully authenticated, | |||
the client invokes the "ssh-connection" service, also known as the | the client invokes the "ssh-connection" service, also known as the | |||
skipping to change at page 28, line 10 ¶ | skipping to change at page 28, line 7 ¶ | |||
Subsystem support is a feature of SSHv2 and is not included in SSHv1. | 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 | Running this protocol as an SSH subsystem avoids the need for the | |||
application to recognize shell prompts or skip over extraneous | application to recognize shell prompts or skip over extraneous | |||
information, such as a system message that is sent at shell startup. | 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 | It is assumed that the router and cache have exchanged keys out of | |||
band by some reasonably secured means. | band by some reasonably secured means. | |||
Cache servers supporting SSH transport MUST accept RSA authentication | Cache servers supporting SSH transport MUST accept RSA authentication | |||
and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) | and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA) | |||
authentication. User authentication MUST be supported; host | authentication. User authentication "publickey") MUST be supported; | |||
authentication MAY be supported. Implementations MAY support | host authentication "hostbased") MAY be supported. Implementations | |||
password authentication. Client routers SHOULD verify the public key | MAY support password authentication "password"). "None" | |||
of the cache to avoid MITM attacks. | authentication MUST NOT be used. Client routers SHOULD verify the | |||
public key of the cache to avoid MITM attacks. | ||||
9.2. TLS Transport | 9.2. TLS Transport | |||
Client routers using TLS transport MUST present client-side | Client routers using TLS transport MUST present client-side | |||
certificates to authenticate themselves to the cache in order to | certificates to authenticate themselves to the cache in order to | |||
allow the cache to manage the load by rejecting connections from | allow the cache to manage the load by rejecting connections from | |||
unauthorized routers. In principle, any type of certificate and | unauthorized routers. In principle, any type of certificate and | |||
Certification Authority (CA) may be used; however, in general, cache | Certification Authority (CA) may be used; however, in general, cache | |||
operators will wish to create their own small-scale CA and issue | operators will wish to create their own small-scale CA and issue | |||
certificates to each authorized router. This simplifies credential | certificates to each authorized router. This simplifies credential | |||
skipping to change at page 29, line 5 ¶ | skipping to change at page 29, line 5 ¶ | |||
present in rpki-rtr server certificates. | present in rpki-rtr server certificates. | |||
* DNS names in rpki-rtr server certificates SHOULD NOT contain the | * DNS names in rpki-rtr server certificates SHOULD NOT contain the | |||
wildcard character "*". | wildcard character "*". | |||
* rpki-rtr implementations which use TLS MUST NOT use Common Name | * rpki-rtr implementations which use TLS MUST NOT use Common Name | |||
(CN-ID) identifiers; a CN field may be present in the server | (CN-ID) identifiers; a CN field may be present in the server | |||
certificate's subject name but MUST NOT be used for authentication | certificate's subject name but MUST NOT be used for authentication | |||
within the rules described in [RFC6125]. | within the rules described in [RFC6125]. | |||
* The client router MUST set its "reference identifier" to the DNS | * The client router MUST set its "reference identifier" (see | |||
name of the rpki-rtr cache. | Section 6.2 of [RFC6125]) to the DNS name of the rpki-rtr cache. | |||
9.3. TCP MD5 Transport | 9.3. TCP MD5 Transport | |||
If TCP MD5 is used, implementations MUST support key lengths of at | If TCP MD5 is used, implementations MUST support key lengths of at | |||
least 80 printable ASCII bytes, per Section 4.5 of [RFC5925]. | least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. | |||
Implementations MUST also support hexadecimal sequences of at least | Implementations MUST also support hexadecimal sequences of at least | |||
32 characters, i.e., 128 bits. | 32 characters, i.e., 128 bits. | |||
Key rollover with TCP MD5 is problematic. Cache servers SHOULD | Key rollover with TCP MD5 is problematic. Cache servers SHOULD | |||
support [RFC4808]. | support [RFC4808]. | |||
9.4. TCP-AO Transport | 9.4. TCP-AO Transport | |||
Implementations MUST support key lengths of at least 80 printable | Implementations MUST support key lengths of at least 80 printable | |||
ASCII bytes. Implementations MUST also support hexadecimal sequences | ASCII bytes. Implementations MUST also support hexadecimal sequences | |||
skipping to change at page 29, line 38 ¶ | skipping to change at page 29, line 38 ¶ | |||
10. Router-Cache Setup | 10. Router-Cache Setup | |||
A cache has the public authentication data for each router it is | A cache has the public authentication data for each router it is | |||
configured to support. | configured to support. | |||
A router may be configured to peer with a selection of caches, and a | 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 | cache may be configured to support a selection of routers. Each must | |||
have the name of, and authentication data for, each peer. In | have the name of, and authentication data for, each peer. In | |||
addition, in a router, this list has a non-unique preference value | addition, in a router, this list has a non-unique preference value | |||
for each server. This preference merely denotes proximity, not | for each cache. This preference is intended to be based on | |||
trust, preferred belief, et cetera. The client router attempts to | proximity, a la RTT, not trust, preferred belief, et cetera. The | |||
establish a session with each potential serving cache in preference | client router attempts to establish a session with each potential | |||
order and then starts to load data from the most preferred cache to | serving cache in preference order and then starts to load data from | |||
which it can connect and authenticate. The router's list of caches | the most preferred cache to which it can connect and authenticate. | |||
has the following elements: | The router's list of caches has the following elements: | |||
Preference: An unsigned integer denoting the router's preference to | Preference: An unsigned integer denoting the router's preference to | |||
connect to that cache; the lower the value, the more preferred. | connect to that cache; the lower the value, the more preferred. | |||
Name: The IP address or fully qualified domain name of the cache. | Name: The IP address or fully qualified domain name of the cache. | |||
Cache Credential(s): Any credential (such as a public key) needed to | Cache Credential(s): Any credential (such as a public key) needed to | |||
authenticate the cache's identity to the router. | authenticate the cache's identity to the router. | |||
Router Credential(s): Any credential (such as a private key or | Router Credential(s): Any credential (such as a private key or | |||
skipping to change at page 30, line 43 ¶ | skipping to change at page 30, line 43 ¶ | |||
to refresh from a particular cache. | to refresh from a particular cache. | |||
If a client loses connectivity to a cache it is using or otherwise | 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 | 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 | 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 | caches. Note that this may already be true at the point of | |||
connection loss if the client has connections to more than one cache. | connection loss if the client has connections to more than one cache. | |||
11. ROA PDU Race Minimization | 11. ROA PDU Race Minimization | |||
When a cache is sending ROA PDUs to a router, especially an initial | When a cache is sending ROA (IPv4 or IPv6) PDUs to a router, | |||
full load in response to a Reset Query PDU, two undesirable race | especially an initial full load in response to a Reset Query PDU, two | |||
conditions are possible: | undesirable race conditions are possible: | |||
Break Before Make: For some prefix P, an AS may announce two (or | Break Before Make: For some prefix P, an AS may announce two (or | |||
more) ROAs because they are in the process of changing what | more) ROAs because they are in the process of changing what | |||
provider AS is announcing P. This is a case of "make before | provider AS is announcing P. This is a case of "make before | |||
break." If a cache is feeding a router and sends the one not yet | break." If a cache is feeding a router and sends the one not yet | |||
in service a significant time before sending the one currently in | in service a significant time before sending the one currently in | |||
service, then BGP data could be marked invalid during the | service, then BGP data could be marked invalid during the | |||
interval. To minimize that interval, the cache SHOULD announce | interval. To minimize that interval, the cache SHOULD announce | |||
all ROAs for the same prefix as close to sequentially as possible. | all ROAs for the same prefix as close to sequentially as possible. | |||
skipping to change at page 32, line 6 ¶ | skipping to change at page 32, line 6 ¶ | |||
Experience with large DNS cache deployments has shown that complex | Experience with large DNS cache deployments has shown that complex | |||
topologies are ill-advised, as it is easy to make errors in the | topologies are ill-advised, as it is easy to make errors in the | |||
graph, e.g., not maintain a loop-free condition. | graph, e.g., not maintain a loop-free condition. | |||
Of course, these are illustrations, and there are other possible | Of course, these are illustrations, and there are other possible | |||
deployment strategies. It is expected that minimizing load on the | deployment strategies. It is expected that minimizing load on the | |||
Global RPKI servers will be a major consideration. | Global RPKI servers will be a major consideration. | |||
To keep load on Global RPKI services from unnecessary peaks, it is | To keep load on Global RPKI services from unnecessary peaks, it is | |||
recommended that primary caches which load from the distributed | recommended that caches which fetch from the Global RPKI not do so | |||
Global RPKI not do so all at the same times, e.g., on the hour. | all at the same times, e.g., on the hour. Choose a random time, | |||
Choose a random time, perhaps the ISP's AS number modulo 60, and | perhaps the ISP's AS number modulo 60, and jitter the inter-fetch | |||
jitter the inter-fetch timing. | timing. | |||
13. Error Codes | 13. Error Codes | |||
This section describes the meaning of the error codes. There is an | This section describes the meaning of the error codes. There is an | |||
IANA registry where valid error codes are listed; see [iana-err]. | IANA registry where valid error codes are listed; see [iana-err]. | |||
Errors which are considered fatal MUST cause the session to be | Errors which are considered fatal MUST cause the session to be | |||
dropped. | dropped, and the router MUST flush all data learned from that cache. | |||
0: Corrupt Data (fatal): The receiver believes the received PDU to | 0: Corrupt Data (fatal): The receiver believes the received PDU to | |||
be corrupt in a manner not specified by another error code. | be corrupt in a manner not specified by another error code. | |||
1: Internal Error (fatal): The party reporting the error experienced | 1: Internal Error (fatal): The party reporting the error experienced | |||
some kind of internal error unrelated to protocol operation (ran | some kind of internal error unrelated to protocol operation (ran | |||
out of memory, a coding assertion failed, et cetera). | out of memory, a coding assertion failed, et cetera). | |||
2: No Data Available: The cache believes itself to be in good | 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 | 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. | Reset Query because it has no useful data available at this time. | |||
This is likely to be a temporary error and most likely indicates | This is likely to be a temporary error and most likely indicates | |||
that the cache has not yet completed pulling down an initial | that the cache has not yet completed pulling down an initial | |||
current data set from the Global RPKI system after some kind of | current data set from the Global RPKI system after some kind of | |||
event that invalidated whatever data it might have previously held | event that invalidated whatever data it might have previously held | |||
(reboot, network partition, et cetera). | (reboot, network partition, et cetera). | |||
3: Invalid Request (fatal): The cache server believes the client's | 3: Invalid Request (fatal): The cache server believes the client's | |||
request to be invalid. | request to be invalid. | |||
4: Unsupported Protocol Version (fatal): The Protocol Version is not | 4: Unsupported Protocol Version (non-fatal): The Protocol Version is | |||
known by the receiver of the PDU. | not known by the receiver of the PDU. A session is not | |||
[re-]established, but data previously learned need not be flushed. | ||||
5: Unsupported PDU Type (fatal): The PDU Type is not known by the | 5: Unsupported PDU Type (fatal): The PDU Type is not known by the | |||
receiver of the PDU. | receiver of the PDU. | |||
6: Withdrawal of Unknown Record (fatal): The received PDU has | 6: Withdrawal of Unknown Record (fatal): The received PDU has | |||
Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple | 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 | for an IPvX PDU, or {SKI, ASN, Subject Public Key} tuple for a | |||
Router Key PDU), or Customer Autonomous System for an ASPA PDU | Router Key PDU), or Customer Autonomous System for an ASPA PDU | |||
does not exist in the receiver's database. | does not exist in the receiver's database. | |||
skipping to change at page 33, line 20 ¶ | skipping to change at page 33, line 20 ¶ | |||
Protocol Version field that differs from the protocol version | Protocol Version field that differs from the protocol version | |||
negotiated in Section 7. | negotiated in Section 7. | |||
14. Security Considerations | 14. Security Considerations | |||
As this document describes a security protocol, many aspects of | As this document describes a security protocol, many aspects of | |||
security interest are described in the relevant sections. This | security interest are described in the relevant sections. This | |||
section points out issues which may not be obvious in other sections. | section points out issues which may not be obvious in other sections. | |||
Cache Validation: In order for a collection of caches as described | Cache Validation: In order for a collection of caches as described | |||
in Section 12 to guarantee a consistent view, they need to be | in Section 12 to provide a consistent view, they need to be given | |||
given consistent trust anchors to use in their internal validation | consistent trust anchors of the Certification Authorities to use | |||
process. Distribution of a consistent trust anchor is assumed to | in their internal validation process. Distribution of a | |||
be out of band. | consistent trust anchor set to validating caches is assumed to be | |||
out of band. | ||||
Cache Peer Identification: The router initiates a transport | Cache Peer Identification: The router initiates a transport | |||
connection to a cache, which it identifies by either IP address or | connection to a cache, which it identifies by either IP address or | |||
fully qualified domain name. Be aware that a DNS or address | fully qualified domain name. Be aware that a DNS or address | |||
spoofing attack could make the correct cache unreachable. No | spoofing attack could make the correct cache unreachable. No | |||
session would be established, as the authorization keys would not | session would be established, as the authorization keys would not | |||
match. | match. | |||
Transport Security: The RPKI relies on object, not server or | Transport Security: The RPKI relies on object, not server or | |||
transport, trust. That is, the IANA root trust anchor is | transport, trust. That is, the IANA root trust anchor is | |||
distributed to all caches through some out-of-band means and can | distributed to all caches through some out-of-band means and can | |||
then be used by each cache to validate certificates and ROAs all | then be used by each cache to validate certificates and ROAs all | |||
the way down the tree. The inter-cache relationships are based on | the way down the tree. The inter-cache relationships are based on | |||
this object security model; hence, the inter-cache transport can | this object security model; hence, the inter-cache transport can | |||
be lightly protected. | be lightly protected. | |||
However, this protocol document assumes that the routers cannot do | However, this protocol document assumes that the routers cannot do | |||
the validation cryptography. Hence, the last link, from cache to | the validation cryptography. Hence, the last link, from cache to | |||
router, is secured by server authentication and transport-level | router, SHOULD be secured by server authentication and transport- | |||
security. This is dangerous, as server authentication and | level security to prevent monkey in the middle attacks; though it | |||
transport have very different threat models than object security. | might not be. Not using transport security is dangerous, as | |||
server authentication and transport have very different threat | ||||
models than object security. | ||||
So the strength of the trust relationship and the transport | So the strength of the trust relationship and the transport | |||
between the router(s) and the cache(s) are critical. You're | between the router(s) and the cache(s) are critical. You're | |||
betting your routing on this. | betting your routing on this. | |||
While we cannot say the cache must be on the same LAN, if only due | 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 | to the issue of an enterprise wanting to offload the cache task to | |||
their upstream ISP(s), locality, trust, and control are very | their upstream ISP(s), locality, trust, and control are very | |||
critical issues here. The cache(s) really SHOULD be as close, in | critical issues here. The cache(s) really SHOULD be as close, in | |||
the sense of controlled and protected (against DDoS, MITM) | the sense of controlled and protected (against DDoS, MITM) | |||
transport, to the router(s) as possible. It also SHOULD be | transport, to the router(s) as possible. It also SHOULD be | |||
topologically close so that a minimum of validated routing data | topologically close so that a minimum of validated routing data | |||
are needed to bootstrap a router's access to a cache. | are needed to bootstrap a router's access to a cache. | |||
The identity of the cache server SHOULD be verified and | Authenticating transport protocols (i.e. not raw TCP) will | |||
authenticated by the router client, and vice versa, before any | authenticate the identity of the cache server to the router | |||
data are exchanged. | client, and vice versa, before any data are exchanged. | |||
Transports which cannot provide the necessary authentication and | Transports which cannot provide the necessary authentication and | |||
integrity (see Section 9) must rely on network design and | integrity (see Section 9) must rely on network design and | |||
operational controls to provide protection against spoofing/ | operational controls to provide protection against spoofing/ | |||
corruption attacks. As pointed out in Section 9, TCP-AO is the | corruption attacks. As pointed out in Section 9, TCP-AO is the | |||
long-term plan. Protocols which provide integrity and | long-term plan. Protocols which provide integrity and | |||
authenticity SHOULD be used, and if they cannot, i.e., TCP is used | 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 | as the transport, the router and cache MUST be on the same | |||
trusted, controlled network. | trusted, controlled network. | |||
skipping to change at page 34, line 36 ¶ | skipping to change at page 34, line 38 ¶ | |||
This section only discusses updates required in the existing IANA | This section only discusses updates required in the existing IANA | |||
protocol registries to accommodate version 2 of this protocol. See | protocol registries to accommodate version 2 of this protocol. See | |||
[RFC8210] for IANA considerations of the previous (version 1) | [RFC8210] for IANA considerations of the previous (version 1) | |||
protocol. | protocol. | |||
All of the PDU types in the IANA "rpki-rtr-pdu" registry [iana-pdu] | All of the PDU types in the IANA "rpki-rtr-pdu" registry [iana-pdu] | |||
in protocol versions 0 and 1 are also allowed in protocol version 2, | in protocol versions 0 and 1 are also allowed in protocol version 2, | |||
with the addition of the new ASPA PDU. | with the addition of the new ASPA PDU. | |||
The policy for adding to the registry is RFC Required per [RFC8126]; | ||||
the document must be either Standards Track or Experimental. | ||||
The "rpki-rtr-pdu" registry [iana-pdu] has been updated as follows: | The "rpki-rtr-pdu" registry [iana-pdu] has been updated as follows: | |||
Protocol PDU | Protocol PDU | |||
Version Type Description | Version Type Description | |||
-------- ---- --------------- | -------- ---- --------------- | |||
0-2 0 Serial Notify | 0-2 0 Serial Notify | |||
0-2 1 Serial Query | 0-2 1 Serial Query | |||
0-2 2 Reset Query | 0-2 2 Reset Query | |||
0-2 3 Cache Response | 0-2 3 Cache Response | |||
0-2 4 IPv4 Prefix | 0-2 4 IPv4 Prefix | |||
0-2 6 IPv6 Prefix | 0-2 6 IPv6 Prefix | |||
0-2 7 End of Data | 0-2 7 End of Data | |||
0-2 8 Cache Reset | 0-2 8 Cache Reset | |||
0 9 Reserved | 0 9 Reserved | |||
1-2 9 Router Key | 1-2 9 Router Key | |||
0-2 10 Error Report | 0-2 10 Error Report | |||
0-1 11 Reserved | 0-1 11 Reserved | |||
2 11 ASPA | 2 11 ASPA | |||
0-2 255 Reserved | 0-2 255 Reserved | |||
All previous entries in the IANA "rpki-rtr-error" registry [iana-err] | ||||
remain valid for all protocol versions. Protocol version 1 added one | ||||
new error code: | ||||
Error | ||||
Code Description | ||||
----- --------------------------- | ||||
8 Unexpected Protocol Version | ||||
16. References | 16. References | |||
16.1. Normative References | 16.1. Normative References | |||
[I-D.ietf-sidrops-aspa-profile] | [I-D.ietf-sidrops-aspa-profile] | |||
Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., | Azimov, A., Uskov, E., Bush, R., Snijders, J., Housley, | |||
and R. Housley, "A Profile for Autonomous System Provider | R., and B. Maddison, "A Profile for Autonomous System | |||
Authorization", Work in Progress, Internet-Draft, draft- | Provider Authorization", Work in Progress, Internet-Draft, | |||
ietf-sidrops-aspa-profile-07, 31 January 2022, | draft-ietf-sidrops-aspa-profile-18, 25 June 2024, | |||
<https://www.ietf.org/archive/id/draft-ietf-sidrops-aspa- | <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops- | |||
profile-07.txt>. | aspa-profile-18>. | |||
[iana-err] IANA, "rpki-rtr-error", | [iana-err] IANA, "rpki-rtr-error", | |||
<https://www.iana.org/assignments/rpki#rpki-rtr-error>. | <https://www.iana.org/assignments/rpki#rpki-rtr-error>. | |||
[iana-pdu] IANA, "rpki-rtr-pdu", | [iana-pdu] IANA, "rpki-rtr-pdu", | |||
<https://www.iana.org/assignments/rpki#rpki-rtr-pdu>. | <https://www.iana.org/assignments/rpki#rpki-rtr-pdu>. | |||
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, | [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, | |||
DOI 10.17487/RFC1982, August 1996, | DOI 10.17487/RFC1982, August 1996, | |||
<https://www.rfc-editor.org/info/rfc1982>. | <https://www.rfc-editor.org/info/rfc1982>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <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 | [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO | |||
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November | 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November | |||
2003, <https://www.rfc-editor.org/info/rfc3629>. | 2003, <https://www.rfc-editor.org/info/rfc3629>. | |||
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) | [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) | |||
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, | Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, | |||
January 2006, <https://www.rfc-editor.org/info/rfc4252>. | January 2006, <https://www.rfc-editor.org/info/rfc4252>. | |||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, | Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, | |||
skipping to change at page 37, line 10 ¶ | skipping to change at page 37, line 5 ¶ | |||
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key | [RFC6810] Bush, R. and R. Austein, "The Resource Public Key | |||
Infrastructure (RPKI) to Router Protocol", RFC 6810, | Infrastructure (RPKI) to Router Protocol", RFC 6810, | |||
DOI 10.17487/RFC6810, January 2013, | DOI 10.17487/RFC6810, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6810>. | <https://www.rfc-editor.org/info/rfc6810>. | |||
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. | [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. | |||
Austein, "BGP Prefix Origin Validation", RFC 6811, | Austein, "BGP Prefix Origin Validation", RFC 6811, | |||
DOI 10.17487/RFC6811, January 2013, | DOI 10.17487/RFC6811, January 2013, | |||
<https://www.rfc-editor.org/info/rfc6811>. | <https://www.rfc-editor.org/info/rfc6811>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | "Recommendations for Secure Use of Transport Layer | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | Security (TLS) and Datagram Transport Layer Security | |||
<https://www.rfc-editor.org/info/rfc8126>. | (DTLS)", RFC 7525, DOI 10.17487/RFC7525, May 2015, | |||
<https://www.rfc-editor.org/info/rfc7525>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key | [RFC8210] Bush, R. and R. Austein, "The Resource Public Key | |||
Infrastructure (RPKI) to Router Protocol, Version 1", | Infrastructure (RPKI) to Router Protocol, Version 1", | |||
RFC 8210, DOI 10.17487/RFC8210, September 2017, | RFC 8210, DOI 10.17487/RFC8210, September 2017, | |||
<https://www.rfc-editor.org/info/rfc8210>. | <https://www.rfc-editor.org/info/rfc8210>. | |||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
[RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key | [RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key | |||
Formats, and Signature Formats", RFC 8608, | Formats, and Signature Formats", RFC 8608, | |||
DOI 10.17487/RFC8608, June 2019, | DOI 10.17487/RFC8608, June 2019, | |||
<https://www.rfc-editor.org/info/rfc8608>. | <https://www.rfc-editor.org/info/rfc8608>. | |||
[RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for | ||||
BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, | ||||
<https://www.rfc-editor.org/info/rfc8635>. | ||||
16.2. Informative References | 16.2. Informative References | |||
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone | [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone | |||
Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, | Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, | |||
August 1996, <https://www.rfc-editor.org/info/rfc1996>. | August 1996, <https://www.rfc-editor.org/info/rfc1996>. | |||
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", | [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", | |||
RFC 4808, DOI 10.17487/RFC4808, March 2007, | RFC 4808, DOI 10.17487/RFC4808, March 2007, | |||
<https://www.rfc-editor.org/info/rfc4808>. | <https://www.rfc-editor.org/info/rfc4808>. | |||
skipping to change at page 38, line 13 ¶ | skipping to change at page 38, line 13 ¶ | |||
February 2012, <https://www.rfc-editor.org/info/rfc6480>. | February 2012, <https://www.rfc-editor.org/info/rfc6480>. | |||
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for | [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for | |||
Resource Certificate Repository Structure", RFC 6481, | Resource Certificate Repository Structure", RFC 6481, | |||
DOI 10.17487/RFC6481, February 2012, | DOI 10.17487/RFC6481, February 2012, | |||
<https://www.rfc-editor.org/info/rfc6481>. | <https://www.rfc-editor.org/info/rfc6481>. | |||
Acknowledgements | Acknowledgements | |||
The authors wish to thank Nils Bars, Steve Bellovin, Oliver Borchert, | The authors wish to thank Nils Bars, Steve Bellovin, Oliver Borchert, | |||
Mohamed Boucadair, Tim Bruijnzeels, Rex Fernando, Richard Hansen, | Mohamed Boucadair, Tim Bruijnzeels, Roman Danyliw, Rex Fernando, | |||
Martin Hoffmann, Paul Hoffman, Fabian Holler, Russ Housley, Pradosh | Richard Hansen, Martin Hoffmann, Paul Hoffman, Fabian Holler, Russ | |||
Mohapatra, Keyur Patel, David Mandelberg, Sandy Murphy, Robert | Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg, Sandy | |||
Raszuk, Andreas Reuter, Thomas Schmidt, John Scudder, Ruediger Volk, | Murphy, Robert Raszuk, Andreas Reuter, Thomas Schmidt, John Scudder, | |||
Matthias Waehlisch, and David Ward. Particular thanks go to Hannes | Ruediger Volk, Matthias Waehlisch, and David Ward. Particular thanks | |||
Gredler for showing us the dangers of unnecessary fields. | go to Hannes Gredler for showing us the dangers of unnecessary | |||
fields. | ||||
No doubt this list is incomplete. We apologize to any contributor | No doubt this list is incomplete. We apologize to any contributor | |||
whose name we missed. | whose name we missed. | |||
Authors' Addresses | Authors' Addresses | |||
Randy Bush | Randy Bush | |||
IIJ, Arrcus, & DRL | IIJ Research, Arrcus, & DRL | |||
5147 Crystal Springs | 5147 Crystal Springs | |||
Bainbridge Island, Washington 98110 | Bainbridge Island, Washington 98110 | |||
United States of America | United States of America | |||
Email: randy@psg.com | Email: randy@psg.com | |||
Rob Austein | Rob Austein | |||
Dragon Research Labs | Dragon Research Labs | |||
Email: sra@hactrn.net | Email: sra@hactrn.net | |||
End of changes. 75 change blocks. | ||||
214 lines changed or deleted | 240 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |