rfc6810.txt | draft-ietf-sidr-rpki-rtr-rfc6810-bis-03.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) R. Bush | Network Working Group R. Bush | |||
Request for Comments: 6810 Internet Initiative Japan | Internet-Draft Internet Initiative Japan | |||
Category: Standards Track R. Austein | Intended status: Standards Track R. Austein | |||
ISSN: 2070-1721 Dragon Research Labs | Expires: September 6, 2015 Dragon Research Labs | |||
January 2013 | March 5, 2015 | |||
The Resource Public Key Infrastructure (RPKI) to Router Protocol | The Resource Public Key Infrastructure (RPKI) to Router Protocol | |||
draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 | ||||
Abstract | Abstract | |||
In order to verifiably validate the origin Autonomous Systems of BGP | In order to verifiably validate the origin Autonomous Systems and | |||
announcements, routers need a simple but reliable mechanism to | Autonomous System Paths of BGP announcements, routers need a simple | |||
receive Resource Public Key Infrastructure (RFC 6480) prefix origin | but reliable mechanism to receive Resource Public Key Infrastructure | |||
data from a trusted cache. This document describes a protocol to | (RFC 6480) prefix origin data and router keys from a trusted cache. | |||
deliver validated prefix origin data to routers. | This document describes a protocol to deliver validated prefix origin | |||
data and router keys to routers. | ||||
Status of This Memo | Status of This Memo | |||
This is an Internet Standards Track document. | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | ||||
This document is a product of the Internet Engineering Task Force | Internet-Drafts are working documents of the Internet Engineering | |||
(IETF). It represents the consensus of the IETF community. It has | Task Force (IETF). Note that other groups may also distribute | |||
received public review and has been approved for publication by the | working documents as Internet-Drafts. The list of current Internet- | |||
Internet Engineering Steering Group (IESG). Further information on | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet Standards is available in Section 2 of RFC 5741. | ||||
Information about the current status of this document, any errata, | Internet-Drafts are draft documents valid for a maximum of six months | |||
and how to provide feedback on it may be obtained at | and may be updated, replaced, or obsoleted by other documents at any | |||
http://www.rfc-editor.org/info/rfc6810. | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | ||||
This Internet-Draft will expire on September 6, 2015. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2015 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 | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 4 | 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Operational Overview . . . . . . . . . . . . . . . . . . . . . 4 | 4. Operational Overview . . . . . . . . . . . . . . . . . . . . 4 | |||
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 6 | 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 5 | |||
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6 | 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6 | |||
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 8 | 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 8 | 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 8 | |||
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 9 | 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . . 9 | 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 9 | |||
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 10 | 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11 | 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
5.10. Error Report . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 14 | 5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 14 | 6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 15 | |||
6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 15 | 7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 16 | |||
6.3. No Incremental Update Available . . . . . . . . . . . . . 15 | 8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 17 | |||
6.4. Cache Has No Data Available . . . . . . . . . . . . . . . 16 | 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 17 | |||
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 18 | |||
7.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 18 | 8.3. No Incremental Update Available . . . . . . . . . . . . . 18 | |||
7.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 18 | 8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 19 | |||
7.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 19 | 9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
7.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . . 19 | 9.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 21 | |||
8. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . . 20 | 9.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 22 | |||
9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 21 | 9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 22 | |||
10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 23 | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 | 10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 23 | |||
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 | 11. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 24 | |||
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 | 12. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 | 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . . 25 | 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 | |||
14.2. Informative References . . . . . . . . . . . . . . . . . . 26 | 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 | |||
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 | ||||
16.1. Normative References . . . . . . . . . . . . . . . . . . 28 | ||||
16.2. Informative References . . . . . . . . . . . . . . . . . 30 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 | ||||
1. Introduction | 1. Introduction | |||
In order to verifiably validate the origin Autonomous Systems (ASes) | In order to verifiably validate the origin Autonomous Systems (ASes) | |||
of BGP announcements, routers need a simple but reliable mechanism to | and AS paths of BGP announcements, routers need a simple but reliable | |||
receive Resource Public Key Infrastructure (RPKI) [RFC6480] | mechanism to receive cryptographically validated Resource Public Key | |||
cryptographically validated prefix origin data from a trusted cache. | Infrastructure (RPKI) [RFC6480] prefix origin data and router keys | |||
This document describes a protocol to deliver validated prefix origin | from a trusted cache. This document describes a protocol to deliver | |||
data to routers. The design is intentionally constrained to be | validated prefix origin data and router keys to routers. The design | |||
usable on much of the current generation of ISP router platforms. | is intentionally constrained to be usable on much of the current | |||
generation of ISP router platforms. | ||||
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 PDU | protocol are formally described in Section 5, and the expected PDU | |||
sequences are described in Section 6. The transport protocol options | sequences are described in Section 8. The transport protocol options | |||
are described in Section 7. Section 8 details how routers and caches | are described in Section 9. Section 10 details how routers and | |||
are configured to connect and authenticate. Section 9 describes | caches are configured to connect and authenticate. Section 11 | |||
likely deployment scenarios. The traditional security and IANA | describes likely deployment scenarios. The traditional security and | |||
considerations end the document. | IANA considerations end the document. | |||
The protocol is extensible in order to support new PDUs with new | The protocol is extensible in order to support new PDUs with new | |||
semantics, if deployment experience indicates they are needed. PDUs | semantics, if deployment experience indicates they are needed. PDUs | |||
are versioned should deployment experience call for change. | are versioned should deployment experience call for change. | |||
For an implementation (not interoperability) report, see [RTR-IMPL] | For an implementation (not interoperability) report on use of this | |||
protocol with prefix origin data, see [RFC7128]. | ||||
1.1. Requirements Language | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [RFC2119] | document are to be interpreted as described in RFC 2119 [RFC2119] | |||
only when they appear in all upper case. They may also appear in | only when they appear in all upper case. They may also appear in | |||
lower or mixed case as English words, without special meaning. | lower or mixed case as English words, without special meaning. | |||
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 | |||
Registries (RIRs), National Internet Registry (NIRs), and ISPs; | Registries (RIRs), National Internet Registries (NIRs), and ISPs; | |||
see [RFC6481]. | see [RFC6481]. | |||
Cache: A coalesced copy of the RPKI, which is periodically fetched/ | Cache: A coalesced copy of the RPKI, which is periodically fetched/ | |||
refreshed directly or indirectly from the Global RPKI using the | refreshed directly or indirectly from the Global RPKI using the | |||
[RFC5781] protocol/tools. Relying party software is used to | [RFC5781] protocol/tools. Relying party software is used to | |||
gather and validate the distributed data of the RPKI into a cache. | gather and validate the distributed data of the RPKI into a cache. | |||
Trusting this cache further is a matter between the provider of | Trusting this cache further is a matter between the provider of | |||
the cache and a relying party. | the cache and a relying party. | |||
Serial Number: A 32-bit strictly increasing unsigned integer that | Serial Number: A 32-bit strictly increasing unsigned integer which | |||
wraps from 2^32-1 to 0. It denotes the logical version of a | wraps from 2^32-1 to 0. It denotes the logical version of a | |||
cache. A cache increments the value when it successfully updates | cache. A cache increments the value when it successfully updates | |||
its data from a parent cache or from primary RPKI data. As a | its data from a parent cache or from primary RPKI data. As a | |||
cache is receiving, new incoming data and implicit deletes are | cache is receiving, new incoming data and implicit deletes are | |||
associated with the new serial but MUST NOT be sent until the | associated with the new serial but MUST NOT be sent until the | |||
fetch is complete. A Serial Number is not commensurate between | fetch is complete. A Serial Number is not commensurate between | |||
caches, nor need it be maintained across resets of the cache | caches, 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. | |||
skipping to change at page 5, line 15 | skipping to change at page 5, line 15 | |||
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 Serial Number of the | Periodically, the router sends to the cache the Serial Number of the | |||
highest numbered data it has received from that cache, i.e., the | highest numbered data it has received from that cache, i.e., the | |||
router's current Serial Number. When a router establishes a new | router's current Serial Number. When a router establishes a new | |||
connection to a cache, or wishes to reset a current relationship, it | connection to a cache, or wishes to reset a current relationship, it | |||
sends a Reset Query. | sends a Reset Query. | |||
The Cache responds with all data records that have Serial Numbers | The Cache responds with all data records which have Serial Numbers | |||
greater than that in the router's query. This may be the null set, | greater than that in the router's query. This may be the null set, | |||
in which case the End of Data PDU is still sent. Note that 'greater' | in which case the End of Data PDU is still sent. Note that 'greater' | |||
must take wrap-around into account, see [RFC1982]. | 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 End of | its current Serial Number to that of the Serial Number in the End of | |||
Data PDU. | Data PDU. | |||
When the cache updates its database, it sends a Notify message to | When the cache updates its database, it sends a Notify message to | |||
every currently connected router. This is a hint that now would be a | every currently connected router. This is a hint that now would be a | |||
good time for the router to poll for an update, but is only a hint. | good time for the router to poll for an update, but is only a hint. | |||
The protocol requires the router to poll for updates periodically in | The protocol requires the router to poll for updates periodically in | |||
any case. | any case. | |||
Strictly speaking, a router could track a cache simply by asking for | Strictly speaking, a router could track a cache simply by asking for | |||
a complete data set every time it updates, but this would be very | a complete data set every time it updates, but this would be very | |||
inefficient. The Serial Number based incremental update mechanism | inefficient. The Serial Number based incremental update mechanism | |||
allows an efficient transfer of just the data records that have | allows an efficient transfer of just the data records which have | |||
changed since last update. As with any update protocol based on | changed since last update. As with any update protocol based on | |||
incremental transfers, the router must be prepared to fall back to a | incremental transfers, the router must be prepared to fall back to a | |||
full transfer if for any reason the cache is unable to provide the | 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 | |||
Attestations; see [RFC6480]), which are time dependent, servers' | Attestations; 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 approximately an hour. | |||
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 6. | Section 8. | |||
Fields with unspecified content MUST be zero on transmission and MAY | Fields with unspecified content MUST be zero on transmission and MAY | |||
be ignored on receipt. | 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 eight-bit unsigned integer, currently 0, | Protocol Version: An eight-bit unsigned integer, currently 1, | |||
denoting the version of this protocol. | denoting the version of this protocol. | |||
PDU Type: An eight-bit unsigned integer, denoting the type of the | PDU Type: An eight-bit unsigned integer, denoting the type of the | |||
PDU, e.g., IPv4 Prefix, etc. | PDU, e.g., IPv4 Prefix, etc. | |||
Serial Number: The Serial Number of the RPKI Cache when this set of | Serial Number: The Serial Number of the RPKI Cache when this set of | |||
PDUs was received from an upstream cache server or gathered from | PDUs was received from an upstream cache server or gathered from | |||
the Global RPKI. A cache increments its Serial Number when | the Global RPKI. A cache increments its Serial Number when | |||
completing a rigorously validated update from a parent cache or | completing a rigorously validated update from a parent cache or | |||
the Global RPKI. | the Global RPKI. | |||
skipping to change at page 7, line 4 | skipping to change at page 6, line 47 | |||
confused as to the content of the cache. The time it takes the | confused as to the content of the cache. The time it takes the | |||
router to discover it is confused will depend on whether the | router to discover it is confused will depend on whether the | |||
Serial Numbers are also reused. If the Serial Numbers in the old | Serial Numbers are also reused. If the Serial Numbers in the old | |||
and new sessions are different enough, the cache will respond to | and new sessions are different enough, the cache will respond to | |||
the router's Serial Query with a Cache Reset, which will solve the | the router's Serial Query with a Cache Reset, which will solve the | |||
problem. If, however, the Serial Numbers are close, the cache may | problem. If, however, the Serial Numbers are close, the cache may | |||
respond with a Cache Response, which may not be enough to bring | respond with a Cache Response, which may not be enough to bring | |||
the router into sync. In such cases, it's likely but not certain | the router into sync. In such cases, it's likely but not certain | |||
that the router will detect some discrepancy between the state | that the router will detect some discrepancy between the state | |||
that the cache expects and its own state. For example, the Cache | that the cache expects and its own state. For example, the Cache | |||
Response may tell the router to drop a record that the router does | Response may tell the router to drop a record which the router | |||
not hold, or may tell the router to add a record that the router | does not hold, or may tell the router to add a record which the | |||
already has. In such cases, a router will detect the error and | router already has. In such cases, a router will detect the error | |||
reset the session. The one case in which the router may stay out | and reset the session. The one case in which the router may stay | |||
of sync is when nothing in the Cache Response contradicts any data | out of sync is when nothing in the Cache Response contradicts any | |||
currently held by the router. | data currently held by the router. | |||
Using persistent storage for the session identifier or a clock- | Using persistent storage for the session identifier or a clock- | |||
based scheme for generating session identifiers should avoid the | based scheme for generating session identifiers should avoid the | |||
risk of session identifier collisions. | risk of session identifier collisions. | |||
The Session ID might be a pseudo-random value, a strictly | The Session ID might be a pseudo-random value, a strictly | |||
increasing value if the cache has reliable storage, etc. | increasing value if the cache has reliable storage, etc. | |||
Length: A 32-bit unsigned integer that has as its value the count of | Length: A 32-bit unsigned integer which has as its value the count | |||
the bytes in the entire PDU, including the eight bytes of header | of the bytes in the entire PDU, including the eight bytes of | |||
that end with the length field. | header which end with the length field. | |||
Flags: The lowest order bit of the Flags field is 1 for an | Flags: The lowest order bit of the Flags field is 1 for an | |||
announcement and 0 for a withdrawal, whether this PDU announces a | announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or | |||
new right to announce the prefix or withdraws a previously | IPv6), the flag indicates whether this PDU announces a new right | |||
announced right. A withdraw effectively deletes one previously | to announce the prefix or withdraws a previously announced right; | |||
announced IPvX (IPv4 or IPv6) Prefix PDU with the exact same | a withdraw effectively deletes one previously announced Prefix PDU | |||
Prefix, Length, Max-Len, and Autonomous System Number (ASN). | with the exact same Prefix, Length, Max-Len, and Autonomous System | |||
Number (ASN). Similarly, for a Router Key PDU, the flag indicates | ||||
whether this PDU announces a new Router Key or deletes one | ||||
previously announced Router Key PDU with the exact same AS Number, | ||||
subjectKeyIdentifier, and subjectPublicKeyInfo. | ||||
Prefix Length: An 8-bit unsigned integer denoting the shortest | Prefix Length: An 8-bit unsigned integer denoting the shortest | |||
prefix allowed for the prefix. | prefix allowed for the prefix. | |||
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. This MUST NOT be less than the Prefix | allowed by the prefix. This MUST NOT be less than the Prefix | |||
Length element. | Length element. | |||
Prefix: The IPv4 or IPv6 prefix of the ROA. | Prefix: The IPv4 or IPv6 prefix of the ROA. | |||
Autonomous System Number: ASN allowed to announce this prefix, a | Autonomous System Number: A 32-bit unsigned integer representing an | |||
32-bit unsigned integer. | ASN allowed to announce a prefix or associated with a router key. | |||
Subject Key Identifier: 20-octet Subject Key Identifier (SKI) value | ||||
of a router key, as described in [RFC6487]. | ||||
Subject Public Key Info: a router key's subjectPublicKeyInfo value, | ||||
as described in [I-D.ietf-sidr-bgpsec-algs]. This is the full | ||||
ASN.1 DER encoding of the subjectPublicKeyInfo, including the | ||||
ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE. | ||||
Zero: Fields shown as zero or reserved MUST be zero. The value of | Zero: Fields shown as zero or reserved MUST be zero. The value of | |||
such a field MUST be ignored on receipt. | such a field MUST be ignored on receipt. | |||
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 | ||||
immediate Serial Query or Reset Query without waiting for the Refresh | ||||
Interval timer to expire. | ||||
Serial Notify is the only message that the cache can send that is not | Serial Notify is the only message that the cache can send that is not | |||
in response to a message from the router. | in response to a message from the router. | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | Session ID | | | Version | Type | Session ID | | |||
| 0 | 0 | | | | 1 | 0 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length=12 | | | Length=12 | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Serial Number | | | Serial Number | | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
5.3. Serial Query | 5.3. Serial Query | |||
Serial Query: The router sends Serial Query to ask the cache for all | Serial Query: The router sends Serial Query to ask the cache for all | |||
payload PDUs that have Serial Numbers higher than the Serial Number | payload PDUs which have Serial Numbers higher than the Serial Number | |||
in the Serial Query. | in the Serial Query. | |||
The cache replies to this query with a Cache Response PDU | The cache replies to this query with a Cache Response PDU | |||
(Section 5.5) if the cache has a, possibly null, record of the | (Section 5.5) if the cache has a, possibly null, record of the | |||
changes since the Serial Number specified by the router. If there | changes since the Serial Number specified by the router. If there | |||
have been no changes since the router last queried, the cache sends | have been no changes since the router last queried, the cache sends | |||
an End Of Data PDU. | an End Of Data PDU. | |||
If the cache does not have the data needed to update the router, | If the cache does not have the data needed to update the router, | |||
perhaps because its records do not go back to the Serial Number in | perhaps because its records do not go back to the Serial Number in | |||
skipping to change at page 9, line 9 | skipping to change at page 9, line 13 | |||
(Section 5.9). | (Section 5.9). | |||
The Session ID tells the cache what instance the router expects to | The Session ID tells the cache what instance the router expects to | |||
ensure that the Serial Numbers are commensurate, i.e., the cache | ensure that the Serial Numbers are commensurate, i.e., the cache | |||
session has not been changed. | session has not been changed. | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | Session ID | | | Version | Type | Session ID | | |||
| 0 | 1 | | | | 1 | 1 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length=12 | | | Length=12 | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Serial Number | | | Serial Number | | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
5.4. Reset Query | 5.4. Reset Query | |||
Reset Query: The router tells the cache that it wants to receive the | Reset Query: The router tells the cache that it wants to receive the | |||
total active, current, non-withdrawn database. The cache responds | total active, current, non-withdrawn database. The cache responds | |||
with a Cache Response PDU (Section 5.5). | with a Cache Response PDU (Section 5.5). | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | reserved = zero | | | Version | Type | reserved = zero | | |||
| 0 | 2 | | | | 1 | 2 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length=8 | | | Length=8 | | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
5.5. Cache Response | 5.5. Cache Response | |||
Cache Response: The cache responds with zero or more payload PDUs. | Cache Response: The cache responds with zero or more payload PDUs. | |||
When replying to a Serial Query request (Section 5.3), the cache | When replying to a Serial Query request (Section 5.3), the cache | |||
skipping to change at page 9, line 49 | skipping to change at page 10, line 4 | |||
Cache Response: The cache responds with zero or more payload PDUs. | Cache Response: The cache responds with zero or more payload PDUs. | |||
When replying to a Serial Query request (Section 5.3), the cache | When replying to a Serial Query request (Section 5.3), the cache | |||
sends the set of all data records it has with Serial Numbers greater | sends the set of all data records it has with Serial Numbers greater | |||
than that sent by the client router. When replying to a Reset Query, | than that sent by the client router. When replying to a Reset Query, | |||
the cache sends the set of all data records it has; in this case, the | the cache sends the set of all data records it has; in this case, the | |||
withdraw/announce field in the payload PDUs MUST have the value 1 | withdraw/announce field in the payload PDUs MUST have the value 1 | |||
(announce). | (announce). | |||
In response to a Reset Query, the new value of the Session ID tells | In response to a Reset Query, the new value of the Session ID tells | |||
the router the instance of the cache session for future confirmation. | the router the instance of the cache session for future confirmation. | |||
In response to a Serial Query, the Session ID being the same | In response to a Serial Query, the Session ID being the same | |||
reassures the router that the Serial Numbers are commensurate, i.e., | reassures the router that the Serial Numbers are commensurate, i.e., | |||
the cache session has not changed. | the cache session has not changed. | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | Session ID | | | Version | Type | Session ID | | |||
| 0 | 3 | | | | 1 | 3 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length=8 | | | Length=8 | | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
5.6. IPv4 Prefix | 5.6. IPv4 Prefix | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | reserved = zero | | | Version | Type | reserved = zero | | |||
| 0 | 4 | | | | 1 | 4 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length=20 | | | Length=20 | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | Prefix | Max | | | | | Prefix | Max | | | |||
| Flags | Length | Length | zero | | | Flags | Length | Length | zero | | |||
| | 0..32 | 0..32 | | | | | 0..32 | 0..32 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
skipping to change at page 11, line 21 | skipping to change at page 11, line 26 | |||
IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it | IPvX PDU with a {Prefix, Len, Max-Len, ASN} identical to one it | |||
already has active, it SHOULD raise a Duplicate Announcement Received | already has active, it SHOULD raise a Duplicate Announcement Received | |||
error. | error. | |||
5.7. IPv6 Prefix | 5.7. IPv6 Prefix | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | reserved = zero | | | Version | Type | reserved = zero | | |||
| 0 | 6 | | | | 1 | 6 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length=32 | | | Length=32 | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | Prefix | Max | | | | | Prefix | Max | | | |||
| Flags | Length | Length | zero | | | Flags | Length | Length | zero | | |||
| | 0..128 | 0..128 | | | | | 0..128 | 0..128 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
skipping to change at page 12, line 11 | skipping to change at page 12, line 11 | |||
`-------------------------------------------' | `-------------------------------------------' | |||
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 | |||
End of Data: The cache tells the router it has no more data for the | End of Data: The cache tells the router it has no more data for the | |||
request. | request. | |||
The Session ID MUST be the same as that of the corresponding Cache | The Session ID MUST be the same as that of the corresponding Cache | |||
Response that began the, possibly null, sequence of data PDUs. | Response which began the, possibly null, sequence of data PDUs. | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | Session ID | | | Version | Type | Session ID | | |||
| 0 | 7 | | | | 1 | 7 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length=12 | | | Length=24 | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Serial Number | | | Serial Number | | |||
| | | | | | |||
+-------------------------------------------+ | ||||
| | | ||||
| Refresh Interval | | ||||
| | | ||||
+-------------------------------------------+ | ||||
| | | ||||
| Retry Interval | | ||||
| | | ||||
+-------------------------------------------+ | ||||
| | | ||||
| Expire Interval | | ||||
| | | ||||
`-------------------------------------------' | `-------------------------------------------' | |||
The Refresh Interval, Retry Interval, and Expire Interval are all | ||||
32-bit elapsed times measured in seconds, and express the timing | ||||
parameters that the cache expects the router to use to decide when | ||||
next to send the cache another Serial Query or Reset Query PDU. See | ||||
Section 6 for an explanation of the use and the range of allowed | ||||
values for these parameters. | ||||
5.9. Cache Reset | 5.9. Cache Reset | |||
The cache may respond to a Serial Query informing the router that the | The cache may respond to a Serial Query informing the router that the | |||
cache cannot provide an incremental update starting from the Serial | cache cannot provide an incremental update starting from the Serial | |||
Number specified by the router. The router must decide whether to | Number specified by the router. The router must decide whether to | |||
issue a Reset Query or switch to a different cache. | issue a Reset Query or switch to a different cache. | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | reserved = zero | | | Version | Type | reserved = zero | | |||
| 0 | 8 | | | | 1 | 8 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length=8 | | | Length=8 | | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
5.10. Error Report | 5.10. Router Key | |||
0 8 16 24 31 | ||||
.-------------------------------------------. | ||||
| Protocol | PDU | | | | ||||
| Version | Type | Flags | zero | | ||||
| 1 | 9 | | | | ||||
+-------------------------------------------+ | ||||
| | | ||||
| Length | | ||||
| | | ||||
+-------------------------------------------+ | ||||
| | | ||||
| Subject Key Identifier | | ||||
| 20 octets | | ||||
| | | ||||
+-------------------------------------------+ | ||||
| | | ||||
| AS Number | | ||||
| | | ||||
+-------------------------------------------+ | ||||
| | | ||||
| Subject Public Key Info | | ||||
| | | ||||
`-------------------------------------------' | ||||
The cache server MUST ensure that it has told the router client to | ||||
have one and only one Router Key PDU for a unique {SKI, ASN, Subject | ||||
Public Key} at any one point in time. Should the router client | ||||
receive a Router Key PDU with a {SKI, ASN, Subject Public Key} | ||||
identical to one it already has active, it SHOULD raise a Duplicate | ||||
Announcement Received error. | ||||
Note that a particular ASN may appear in multiple Router Key PDUs | ||||
with different Subject Public Key values, while a particular Subject | ||||
Public Key value may appear in multiple Router Key PDUs with | ||||
different ASNs. In the interest of keeping the announcement and | ||||
withdrawal semantics as simple as possible for the router, this | ||||
protocol makes no attempt to compress either of these cases. | ||||
Also note that it is possible, albeit very unlikely, for multiple | ||||
distinct Subject Public Key values to hash to the same SKI. For this | ||||
reason, implementations MUST compare Subject Public Key values as | ||||
well as SKIs when detecting duplicate PDUs. | ||||
5.11. Error Report | ||||
This PDU is used by either party to report an error to the other. | This PDU is used by either party to report an error to the other. | |||
Error reports are only sent as responses to other PDUs. | Error reports are only sent as responses to other PDUs. | |||
The Error Code is described in Section 10. | The Error Code is described in Section 12. | |||
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 | |||
skipping to change at page 13, line 25 | skipping to change at page 15, line 9 | |||
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 diagnostic text is optional; if not present, the Length of Error | |||
Text field MUST be zero. If error text is present, it MUST be a | Text field MUST be zero. If error text is present, it MUST be a | |||
string in UTF-8 encoding (see [RFC3269]). | string in UTF-8 encoding (see [RFC3269]). | |||
0 8 16 24 31 | 0 8 16 24 31 | |||
.-------------------------------------------. | .-------------------------------------------. | |||
| Protocol | PDU | | | | Protocol | PDU | | | |||
| Version | Type | Error Code | | | Version | Type | Error Code | | |||
| 0 | 10 | | | | 1 | 10 | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length | | | Length | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Length of Encapsulated PDU | | | Length of Encapsulated PDU | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
skipping to change at page 14, line 5 | skipping to change at page 15, line 34 | |||
| Length of Error Text | | | Length of Error Text | | |||
| | | | | | |||
+-------------------------------------------+ | +-------------------------------------------+ | |||
| | | | | | |||
| Arbitrary Text | | | Arbitrary Text | | |||
| of | | | of | | |||
~ Error Diagnostic Message ~ | ~ Error Diagnostic Message ~ | |||
| | | | | | |||
`-------------------------------------------' | `-------------------------------------------' | |||
6. Protocol Sequences | 6. Protocol Timing Parameters | |||
Since the data the cache distributes via the rpki-rtr protocol are | ||||
retrieved from the Global RPKI system at intervals which are only | ||||
known to the cache, only the cache can really know how frequently it | ||||
makes sense for the router to poll the cache, or how long the data | ||||
are likely to remain valid (or, at least, unchanged). For this | ||||
reason, as well as to allow the cache some control over the load | ||||
placed on it by its client routers, the End Of Data PDU includes | ||||
three values that allow the cache to communicate timing parameters to | ||||
the router. | ||||
Refresh Interval: This parameter tells the router how long to wait | ||||
before next attempting to poll the cache, using a Serial Query or | ||||
Reset Query PDU. The router SHOULD NOT poll the cache sooner than | ||||
indicated by this parameter. Note that receipt of a Serial Notify | ||||
PDU overrides this interval and allows the router to issue an | ||||
immediate query without waiting for the Refresh Interval to | ||||
expire. Countdown for this timer starts upon receipt of the | ||||
containing End Of Data PDU. | ||||
Minimum allowed value: 1 second. | ||||
Maximum allowed value: 86400 seconds (one day). | ||||
Recommended default: 3600 seconds (one hour). | ||||
Retry Interval: This parameter tells the router how long to wait | ||||
before retrying a failed Serial Query or Reset Query. The router | ||||
SHOULD NOT retry sooner than indicated by this parameter. | ||||
Countdown for this timer starts upon failure of the query, and | ||||
restarts after each subsequent failure until a query succeeds. | ||||
Minimum allowed value: 1 second. | ||||
Maximum allowed value: 7200 seconds (two hours). | ||||
Recommended default: 600 seconds (ten minutes). | ||||
Expire Interval: This parameter tells the router how long it can | ||||
continue to use the current version of the data while unable to | ||||
perform a successful query. The router MUST NOT retain the data | ||||
past the time indicated by this parameter. Countdown for this | ||||
timer starts upon receipt of the containing End Of Data PDU. | ||||
Minimum allowed value: 600 seconds (ten minutes). | ||||
Maximum allowed value: 172800 seconds (two days). | ||||
Recommended default: 7200 seconds (two hours). | ||||
If the router has never issued a successful query against a | ||||
particular cache, it SHOULD retry periodically using the default | ||||
Retry Interval, above. | ||||
7. Protocol Version Negotiation | ||||
A router MUST start each transport session by issuing either a Reset | ||||
Query or a Serial Query. This query will tell the cache which | ||||
version of this protocol the router implements. | ||||
If a cache which supports version 1 receives a query from a router | ||||
which specifies version 0, the cache MUST downgrade to protocol | ||||
version 0 [RFC6810] or terminate the session. | ||||
If a router which supports version 1 sends a query to a cache which | ||||
only supports version 0, one of two things will happen. | ||||
1. The cache may terminate the connection, perhaps with a version 0 | ||||
Error Report PDU. In this case the router MAY retry the | ||||
connection using protocol version 0. | ||||
2. The cache may reply with a version 0 response. In this case the | ||||
router MUST either downgrade to version 0 or terminate the | ||||
connection. | ||||
In any of the downgraded combinations above, the new features of | ||||
version 1 will not be available. | ||||
8. Protocol Sequences | ||||
The sequences of PDU transmissions fall into three conversations as | The sequences of PDU transmissions fall into three conversations as | |||
follows: | follows: | |||
6.1. Start or Restart | 8.1. Start or Restart | |||
Cache Router | Cache Router | |||
~ ~ | ~ ~ | |||
| <----- Reset Query -------- | R requests data (or Serial Query) | | <----- Reset Query -------- | R requests data (or Serial Query) | |||
| | | | | | |||
| ----- Cache Response -----> | C confirms request | | ----- Cache Response -----> | C confirms request | |||
| ------- IPvX Prefix ------> | C sends zero or more | | ------- Payload PDU ------> | C sends zero or more | |||
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix | | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | |||
| ------- IPvX Prefix ------> | Payload PDUs | | ------- Payload PDU ------> | 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 session is first established, the router MAY send a | When a transport session is first established, the router MAY send a | |||
Reset Query and the cache responds with a data sequence of all data | Reset Query and the cache responds with a data sequence of all data | |||
it contains. | it contains. | |||
Alternatively, if the router has significant unexpired data from a | Alternatively, if the router has significant unexpired data from a | |||
broken session with the same cache, it MAY start with a Serial Query | broken session with the same cache, it MAY start with a Serial Query | |||
containing the Session ID from the previous session to ensure the | containing the Session ID from the previous session to ensure the | |||
Serial Numbers are commensurate. | Serial Numbers are commensurate. | |||
This Reset Query sequence is also used when the router receives a | This 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. | |||
The router MUST send either a Reset Query or a Serial Query when | ||||
starting a transport session, in order to confirm that router and | ||||
cache are speaking compatible versions of the protocol. 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 no less frequently than once an hour. This | Query or a Reset Query periodically. This also acts as a keep-alive | |||
also acts as a keep-alive at the application layer. | at the application layer. See Section 6 for details on the required | |||
polling frequency. | ||||
As the cache MAY not keep updates for little more than one hour, the | ||||
router MUST have a polling interval of no greater than once an hour. | ||||
6.2. Typical Exchange | 8.2. Typical Exchange | |||
Cache Router | Cache Router | |||
~ ~ | ~ ~ | |||
| -------- Notify ----------> | (optional) | | -------- Notify ----------> | (optional) | |||
| | | | | | |||
| <----- Serial Query ------- | R requests data | | <----- Serial Query ------- | R requests data | |||
| | | | | | |||
| ----- Cache Response -----> | C confirms request | | ----- Cache Response -----> | C confirms request | |||
| ------- IPvX Prefix ------> | C sends zero or more | | ------- Payload PDU ------> | C sends zero or more | |||
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix | | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | |||
| ------- IPvX Prefix ------> | Payload PDUs | | ------- Payload PDU ------> | 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 | |||
~ ~ | ~ ~ | |||
The cache server SHOULD send a notify PDU with its current Serial | The cache server SHOULD send a notify PDU with its current Serial | |||
Number when the cache's serial changes, with the expectation that the | Number when the cache's serial changes, with the expectation that the | |||
router MAY then issue a Serial Query earlier than it otherwise might. | router MAY then issue a Serial Query earlier than it otherwise might. | |||
This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate | This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate | |||
limit Serial Notifies to no more frequently than one per minute. | limit Serial Notifies to no more frequently than one per minute. | |||
When the transport layer is up and either a timer has gone off in the | When the transport layer is up and either a timer has gone off in the | |||
router, or the cache has sent a Notify, the router queries for new | router, or the cache has sent a Notify, the router queries for new | |||
data by sending a Serial Query, and the cache sends all data newer | data by sending a Serial Query, and the cache sends all data newer | |||
than the serial in the Serial Query. | than the serial in the Serial Query. | |||
To limit the length of time a cache must keep old withdraws, a router | To limit the length of time a cache must keep old withdraws, a router | |||
MUST send either a Serial Query or a Reset Query no less frequently | MUST send either a Serial Query or a Reset Query periodically. See | |||
than once an hour. | Section 6 for details on the required polling frequency. | |||
6.3. No Incremental Update Available | ||||
8.3. No Incremental Update Available | ||||
Cache Router | Cache Router | |||
~ ~ | ~ ~ | |||
| <----- Serial Query ------ | R requests data | | <----- Serial Query ------ | R requests data | |||
| ------- Cache Reset ------> | C cannot supply update | | ------- Cache Reset ------> | C cannot supply update | |||
| | from specified serial | | | from specified serial | |||
| <------ Reset Query ------- | R requests new data | | <------ Reset Query ------- | R requests new data | |||
| ----- Cache Response -----> | C confirms request | | ----- Cache Response -----> | C confirms request | |||
| ------- IPvX Prefix ------> | C sends zero or more | | ------- Payload PDU ------> | C sends zero or more | |||
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix | | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | |||
| ------- IPvX Prefix ------> | Payload PDUs | | ------- Payload PDU ------> | 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 | |||
~ ~ | ~ ~ | |||
The cache may respond to a Serial Query with a Cache Reset, informing | The cache may respond to a Serial Query with a Cache Reset, informing | |||
the router that the cache cannot supply an incremental update from | the router that the cache cannot supply an incremental update from | |||
the Serial Number specified by the router. This might be because the | the Serial Number specified by the router. This might be because the | |||
cache has lost state, or because the router has waited too long | cache has lost state, or because the router has waited too long | |||
between polls and the cache has cleaned up old data that it no longer | between polls and the cache has cleaned up old data that it no longer | |||
believes it needs, or because the cache has run out of storage space | believes it needs, or because the cache has run out of storage space | |||
and had to expire some old data early. Regardless of how this state | and had to expire some old data early. Regardless of how this state | |||
arose, the cache replies with a Cache Reset to tell the router that | arose, the cache replies with a Cache Reset to tell the router that | |||
it cannot honor the request. When a router receives this, the router | it cannot honor the request. When a router receives this, the router | |||
SHOULD attempt to connect to any more preferred caches in its cache | SHOULD attempt to connect to any more preferred caches in its cache | |||
list. If there are no more preferred caches, it MUST issue a Reset | list. If there are no more preferred caches, it MUST issue a Reset | |||
Query and get an entire new load from the cache. | Query and get an entire new load from the cache. | |||
6.4. Cache Has No Data Available | 8.4. Cache Has No Data Available | |||
Cache Router | Cache Router | |||
~ ~ | ~ ~ | |||
| <----- Serial Query ------ | R requests data | | <----- Serial Query ------ | R requests data | |||
| ---- Error Report PDU ----> | C No Data Available | | ---- Error Report PDU ----> | C No Data Available | |||
~ ~ | ~ ~ | |||
Cache Router | Cache Router | |||
~ ~ | ~ ~ | |||
| <----- Reset Query ------- | R requests data | | <----- Reset Query ------- | R requests data | |||
skipping to change at page 17, line 5 | skipping to change at page 20, line 13 | |||
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. | |||
7. 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, | |||
there is no protocol to do so on all currently used platforms. | there is no protocol to do so on all currently used platforms. | |||
Therefore, as of the writing of this document, there is no mandatory- | Therefore, as of the writing of this document, there is no mandatory- | |||
to-implement transport that provides authentication and integrity | to-implement transport which provides authentication and integrity | |||
protection. | protection. | |||
To reduce exposure to dropped but non-terminated sessions, both | To reduce exposure to dropped but non-terminated sessions, both | |||
caches and routers SHOULD enable keep-alives when available in the | caches and routers SHOULD enable keep-alives when available in the | |||
chosen transport protocol. | chosen transport protocol. | |||
It is expected that, when the TCP Authentication Option (TCP-AO) | It is expected that, when the TCP Authentication Option (TCP-AO) | |||
[RFC5925] is available on all platforms deployed by operators, it | [RFC5925] is available on all platforms deployed by operators, it | |||
will become the mandatory-to-implement transport. | will become the mandatory-to-implement transport. | |||
Caches and routers MUST implement unprotected transport over TCP | Caches and routers MUST implement unprotected transport over TCP | |||
using a port, rpki-rtr (323); see Section 12. Operators SHOULD use | using a port, rpki-rtr (323); see Section 14. Operators SHOULD use | |||
procedural means, e.g., access control lists (ACLs), to reduce the | procedural means, e.g., access control lists (ACLs), to reduce the | |||
exposure to authentication issues. | exposure to authentication issues. | |||
Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPsec | Caches and routers SHOULD use TCP-AO, SSHv2, TCP MD5, or IPsec | |||
transport. | transport. | |||
If unprotected TCP is the transport, the cache and routers MUST be on | If unprotected TCP is the transport, the cache and routers MUST be on | |||
the same trusted and controlled network. | the same trusted and controlled network. | |||
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 SSHv2 transport [RFC4252] using a the | Caches and routers MAY use SSHv2 transport [RFC4252] using a the | |||
normal SSH port. For an example, see Section 7.1. | normal SSH port. For an example, see Section 9.1. | |||
Caches and routers MAY use TCP MD5 transport [RFC2385] 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. Note that TCP MD5 has been obsoleted by TCP-AO | |||
[RFC5925]. | [RFC5925]. | |||
Caches and routers MAY use IPsec transport [RFC4301] using the rpki- | Caches and routers MAY use IPsec transport [RFC4301] using the rpki- | |||
rtr port. | rtr port. | |||
Caches and routers MAY use TLS transport [RFC5246] using a port, | Caches and routers MAY use TLS transport [RFC5246] using a port, | |||
rpki-rtr-tls (324); see Section 12. | rpki-rtr-tls (324); see Section 14. | |||
7.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 | |||
SSH connection protocol. | SSH connection protocol. | |||
skipping to change at page 18, line 41 | skipping to change at page 22, line 5 | |||
band by some reasonably secured means. | band by some reasonably secured means. | |||
Cache servers supporting SSH transport MUST accept RSA and Digital | Cache servers supporting SSH transport MUST accept RSA and Digital | |||
Signature Algorithm (DSA) authentication and SHOULD accept Elliptic | Signature Algorithm (DSA) authentication and SHOULD accept Elliptic | |||
Curve Digital Signature Algorithm (ECDSA) authentication. User | Curve Digital Signature Algorithm (ECDSA) authentication. User | |||
authentication MUST be supported; host authentication MAY be | authentication MUST be supported; host authentication MAY be | |||
supported. Implementations MAY support password authentication. | supported. Implementations MAY support password authentication. | |||
Client routers SHOULD verify the public key of the cache to avoid | Client routers SHOULD verify the public key of the cache to avoid | |||
monkey-in-the-middle attacks. | monkey-in-the-middle attacks. | |||
7.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 | |||
certificate authority (CA) may be used; however, in general, cache | certificate 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 | |||
rollover; any unrevoked, unexpired certificate from the proper CA may | rollover; any unrevoked, unexpired certificate from the proper CA may | |||
be used. | be used. | |||
skipping to change at page 19, line 19 | skipping to change at page 22, line 31 | |||
connection against these iPAddress identities and SHOULD reject the | connection against these iPAddress identities and SHOULD reject the | |||
connection if none of the iPAddress identities match the connection. | connection if none of the iPAddress identities match the connection. | |||
Routers MUST also verify the cache's TLS server certificate, using | Routers MUST also verify the cache's TLS server certificate, using | |||
subjectAltName dNSName identities as described in [RFC6125], to avoid | subjectAltName dNSName identities as described in [RFC6125], to avoid | |||
monkey-in-the-middle attacks. The rules and guidelines defined in | monkey-in-the-middle attacks. The rules and guidelines defined in | |||
[RFC6125] apply here, with the following considerations: | [RFC6125] apply here, with the following considerations: | |||
Support for DNS-ID identifier type (that is, the dNSName identity | Support for DNS-ID identifier type (that is, the dNSName identity | |||
in the subjectAltName extension) is REQUIRED in rpki-rtr server | in the subjectAltName extension) is REQUIRED in rpki-rtr server | |||
and client implementations that use TLS. Certification | and client implementations which use TLS. Certification | |||
authorities that issue rpki-rtr server certificates MUST support | authorities which issue rpki-rtr server certificates MUST support | |||
the DNS-ID identifier type, and the DNS-ID identifier type MUST be | the DNS-ID identifier type, and the DNS-ID identifier type MUST be | |||
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 that use TLS MUST NOT use CN-ID | rpki-rtr implementations which use TLS MUST NOT use CN-ID | |||
identifiers; a CN field may be present in the server certificate's | identifiers; a CN field may be present in the server certificate's | |||
subject name, but MUST NOT be used for authentication within the | subject name, but MUST NOT be used for authentication within the | |||
rules described in [RFC6125]. | rules described in [RFC6125]. | |||
The client router MUST set its "reference identifier" to the DNS | The client router MUST set its "reference identifier" to the DNS | |||
name of the rpki-rtr cache. | name of the rpki-rtr cache. | |||
7.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 [RFC2385]. | 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]. | |||
7.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 | |||
of at least 32 characters, i.e., 128 bits. MAC (Message | of at least 32 characters, i.e., 128 bits. Message Authentication | |||
Authentication Code) lengths of at least 96 bits MUST be supported, | Code (MAC) lengths of at least 96 bits MUST be supported, per | |||
per Section 5.1 of [RFC5925]. | Section 5.1 of [RFC5925]. | |||
The cryptographic algorithms and associated parameters described in | The cryptographic algorithms and associated parameters described in | |||
[RFC5926] MUST be supported. | [RFC5926] MUST be supported. | |||
8. 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 server. This preference merely denotes proximity, not | |||
trust, preferred belief, etc. The client router attempts to | trust, preferred belief, etc. The client router attempts to | |||
skipping to change at page 21, line 18 | skipping to change at page 24, line 28 | |||
A client SHOULD delete the data from a cache when it has been unable | A client SHOULD delete the data from a cache when it has been unable | |||
to refresh from that cache for a configurable timer value. The | to refresh from that cache for a configurable timer value. The | |||
default for that value is twice the polling period for that cache. | default for that value is twice the polling period for that 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. | |||
9. Deployment Scenarios | 11. Deployment Scenarios | |||
For illustration, we present three likely deployment scenarios. | For illustration, we present three likely deployment scenarios. | |||
Small End Site: The small multihomed end site may wish to outsource | Small End Site: The small multihomed end site may wish to outsource | |||
the RPKI cache to one or more of their upstream ISPs. They would | the RPKI cache to one or more of their upstream ISPs. They would | |||
exchange authentication material with the ISP using some out-of- | exchange authentication material with the ISP using some out-of- | |||
band mechanism, and their router(s) would connect to the cache(s) | band mechanism, and their router(s) would connect to the cache(s) | |||
of one or more upstream ISPs. The ISPs would likely deploy caches | of one or more upstream ISPs. The ISPs would likely deploy caches | |||
intended for customer use separately from the caches with which | intended for customer use separately from the caches with which | |||
their own BGP speakers peer. | their own BGP speakers peer. | |||
Large End Site: A larger multihomed end site might run one or more | Large End Site: A larger multihomed end site might run one or more | |||
caches, arranging them in a hierarchy of client caches, each | caches, arranging them in a hierarchy of client caches, each | |||
fetching from a serving cache that is closer to the Global RPKI. | fetching from a serving cache which is closer to the Global RPKI. | |||
They might configure fall-back peerings to upstream ISP caches. | They might configure fall-back peerings to upstream ISP caches. | |||
ISP Backbone: A large ISP would likely have one or more redundant | ISP Backbone: A large ISP would likely have one or more redundant | |||
caches in each major point of presence (PoP), and these caches | caches in each major point of presence (PoP), and these caches | |||
would fetch from each other in an ISP-dependent topology so as not | would fetch from each other in an ISP-dependent topology so as not | |||
to place undue load on the Global RPKI. | to place undue load on the Global RPKI. | |||
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 graph, | topologies are ill-advised as it is easy to make errors in the graph, | |||
e.g., not maintain a loop-free condition. | 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 that load from the distributed Global | recommended that primary caches which load from the distributed | |||
RPKI not do so all at the same times, e.g., on the hour. Choose a | Global RPKI not do so all at the same times, e.g., on the hour. | |||
random time, perhaps the ISP's AS number modulo 60 and jitter the | Choose a random time, perhaps the ISP's AS number modulo 60 and | |||
inter-fetch timing. | jitter the inter-fetch timing. | |||
10. Error Codes | 12. Error Codes | |||
This section contains a preliminary list of error codes. The authors | This section contains a preliminary list of error codes. The authors | |||
expect additions to the list this section during development of the | expect additions to the list during development of the initial | |||
initial implementations. There is an IANA registry where valid error | implementations. There is an IANA registry where valid error codes | |||
codes are listed; see Section 12. Errors that are considered fatal | are listed; see Section 14. Errors which are considered fatal SHOULD | |||
SHOULD cause the session to be dropped. | cause the session to be dropped. | |||
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 other error codes. | be corrupt in a manner not specified by other error codes. | |||
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 | |||
skipping to change at page 22, line 39 | skipping to change at page 25, line 49 | |||
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 (fatal): The Protocol Version is not | |||
known by the receiver of the PDU. | known by the receiver of the PDU. | |||
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 Flag=0 | 6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0 | |||
but a record for the {Prefix, Len, Max-Len, ASN} tuple does not | but a matching record ({Prefix, Len, Max-Len, ASN} tuple for an | |||
exist in the receiver's database. | IPvX PDU, {SKI, ASN, Subject Public Key} tuple for a Router Key | |||
PDU) does not exist in the receiver's database. | ||||
7: Duplicate Announcement Received (fatal): The received PDU has an | 7: Duplicate Announcement Received (fatal): The received PDU has | |||
identical {Prefix, Len, Max-Len, ASN} tuple as a PDU that is still | Flag=1 but a matching record ({Prefix, Len, Max-Len, ASN} tuple | |||
active in the router. | for an IPvX PDU, {SKI, ASN, Subject Public Key} tuple for a Router | |||
Key PDU) is already active in the router. | ||||
11. Security Considerations | 13. 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 that 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 9 to guarantee a consistent view, they need to be given | in Section 11 to guarantee a consistent view, they need to be | |||
consistent trust anchors to use in their internal validation | given consistent trust anchors to use in their internal validation | |||
process. Distribution of a consistent trust anchor is assumed to | process. Distribution of a consistent trust anchor is assumed to | |||
be out of band. | be out of band. | |||
Cache Peer Identification: The router initiates a transport session | Cache Peer Identification: The router initiates a transport session | |||
to a cache, which it identifies by either IP address or fully | to a cache, which it identifies by either IP address or fully | |||
qualified domain name. Be aware that a DNS or address spoofing | qualified domain name. Be aware that a DNS or address spoofing | |||
attack could make the correct cache unreachable. No session would | attack could make the correct cache unreachable. No session would | |||
be established, as the authorization keys would not match. | be established, as the authorization keys would not match. | |||
Transport Security: The RPKI relies on object, not server or | Transport Security: The RPKI relies on object, not server or | |||
skipping to change at page 24, line 5 | skipping to change at page 27, line 11 | |||
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 | The identity of the cache server SHOULD be verified and | |||
authenticated by the router client, and vice versa, before any | authenticated by the router client, and vice versa, before any | |||
data are exchanged. | data are exchanged. | |||
Transports that cannot provide the necessary authentication and | Transports which cannot provide the necessary authentication and | |||
integrity (see Section 7) 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 7, TCP-AO is the | corruption attacks. As pointed out in Section 9, TCP-AO is the | |||
long-term plan. Protocols that provide integrity and authenticity | long-term plan. Protocols which provide integrity and | |||
SHOULD be used, and if they cannot, i.e., TCP is used as the | authenticity SHOULD be used, and if they cannot, i.e., TCP is used | |||
transport, the router and cache MUST be on the same trusted, | as the transport, the router and cache MUST be on the same | |||
controlled network. | trusted, controlled network. | |||
12. IANA Considerations | 14. IANA Considerations | |||
IANA has assigned 'well-known' TCP Port Numbers to the RPKI-Router | IANA has assigned "well-known" TCP Port Numbers to the RPKI-Router | |||
Protocol for the following, see Section 7: | Protocol for the following, see Section 9: | |||
rpki-rtr | rpki-rtr | |||
rpki-rtr-tls | rpki-rtr-tls | |||
IANA has created a registry for tuples of Protocol Version / PDU | IANA has created a registry for tuples of Protocol Version / PDU | |||
Type, each of which may range from 0 to 255. The name of the | Type, each of which may range from 0 to 255. The name of the | |||
registry is "rpki-rtr-pdu". The policy for adding to the registry is | registry is "rpki-rtr-pdu". The policy for adding to the registry is | |||
RFC Required per [RFC5226], either Standards Track or Experimental. | RFC Required per [RFC5226], either Standards Track or Experimental. | |||
The initial entries are as follows: | The initial entries are as follows: | |||
Protocol PDU | Protocol PDU | |||
Version Type Description | Version Type Description | |||
-------- ---- --------------- | -------- ---- --------------- | |||
0 0 Serial Notify | 0 0 Serial Notify | |||
0 1 Serial Query | 0 1 Serial Query | |||
0 2 Reset Query | 0 2 Reset Query | |||
0 3 Cache Response | 0 3 Cache Response | |||
0 4 IPv4 Prefix | 0 4 IPv4 Prefix | |||
0 6 IPv6 Prefix | 0 6 IPv6 Prefix | |||
0 7 End of Data | 0 7 End of Data | |||
0 8 Cache Reset | 0 8 Cache Reset | |||
0 10 Error Report | 0 10 Error Report | |||
0 255 Reserved | 0 255 Reserved | |||
IANA has created a registry for Error Codes 0 to 255. The name of | IANA has created a registry for Error Codes 0 to 255. The name of | |||
the registry is "rpki-rtr-error". The policy for adding to the | the registry is "rpki-rtr-error". The policy for adding to the | |||
registry is Expert Review per [RFC5226], where the responsible IESG | registry is Expert Review per [RFC5226], where the responsible IESG | |||
Area Director should appoint the Expert Reviewer. The initial | Area Director should appoint the Expert Reviewer. The initial | |||
entries should be as follows: | entries are as follows: | |||
Error | Error | |||
Code Description | Code Description | |||
----- ---------------- | ----- ---------------- | |||
0 Corrupt Data | 0 Corrupt Data | |||
1 Internal Error | 1 Internal Error | |||
2 No Data Available | 2 No Data Available | |||
3 Invalid Request | 3 Invalid Request | |||
4 Unsupported Protocol Version | 4 Unsupported Protocol Version | |||
5 Unsupported PDU Type | 5 Unsupported PDU Type | |||
6 Withdrawal of Unknown Record | 6 Withdrawal of Unknown Record | |||
7 Duplicate Announcement Received | 7 Duplicate Announcement Received | |||
255 Reserved | 255 Reserved | |||
IANA has added an SSH Connection Protocol Subsystem Name, as defined | IANA has added an SSH Connection Protocol Subsystem Name, as defined | |||
in [RFC4250], of 'rpki-rtr'. | in [RFC4250], of "rpki-rtr". | |||
13. Acknowledgments | 15. Acknowledgments | |||
The authors wish to thank Steve Bellovin, Rex Fernando, Paul Hoffman, | The authors wish to thank Nils Bars, Steve Bellovin, Tim Bruijnzeels, | |||
Russ Housley, Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert | Rex Fernando, Paul Hoffman, Fabian Holler, Russ Housley, Pradosh | |||
Raszuk, John Scudder, Ruediger Volk, and David Ward. Particular | Mohapatra, Keyur Patel, David Mandelberg, Sandy Murphy, Robert | |||
thanks go to Hannes Gredler for showing us the dangers of unnecessary | Raszuk, Andreas Reuter, Thomas C. Schmidt, John Scudder, Ruediger | |||
fields. | Volk, Matthias Waehlisch, and David Ward. Particular thanks go to | |||
Hannes Gredler for showing us the dangers of unnecessary fields. | ||||
14. References | 16. References | |||
14.1. Normative References | 16.1. Normative References | |||
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", | [I-D.ietf-sidr-bgpsec-algs] | |||
RFC 1982, August 1996. | Turner, S., "BGP Algorithms, Key Formats, & Signature | |||
Formats", draft-ietf-sidr-bgpsec-algs-09 (work in | ||||
progress), January 2015. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | August 1996. | |||
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
MD5 Signature Option", RFC 2385, August 1998. | Requirement Levels", RFC 2119, BCP 14, March 1997. | |||
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for | [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 | |||
Reliable Multicast Transport (RMT) Building Blocks and | Signature Option", RFC 2385, August 1998. | |||
Protocol Instantiation documents", RFC 3269, April 2002. | ||||
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) | [RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for | |||
Protocol Assigned Numbers", RFC 4250, January 2006. | Reliable Multicast Transport (RMT) Building Blocks and | |||
Protocol Instantiation documents", RFC 3269, April 2002. | ||||
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) | |||
Authentication Protocol", RFC 4252, January 2006. | Protocol Assigned Numbers", RFC 4250, January 2006. | |||
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the | [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) | |||
Internet Protocol", RFC 4301, December 2005. | Authentication Protocol", RFC 4252, January 2006. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | Internet Protocol", RFC 4301, December 2005. | |||
May 2008. | ||||
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
(TLS) Protocol Version 1.2", RFC 5246, August 2008. | IANA Considerations Section in RFCs", RFC 5226, BCP 26, | |||
May 2008. | ||||
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security | |||
Housley, R., and W. Polk, "Internet X.509 Public Key | (TLS) Protocol Version 1.2", RFC 5246, August 2008. | |||
Infrastructure Certificate and Certificate Revocation | ||||
List (CRL) Profile", RFC 5280, May 2008. | ||||
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | |||
Authentication Option", RFC 5925, June 2010. | Authentication Option", RFC 5925, June 2010. | |||
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms | [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms | |||
for the TCP Authentication Option (TCP-AO)", RFC 5926, | for the TCP Authentication Option (TCP-AO)", RFC 5926, | |||
June 2010. | June 2010. | |||
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | |||
Verification of Domain-Based Application Service Identity | Verification of Domain-Based Application Service Identity | |||
within Internet Public Key Infrastructure Using X.509 | within Internet Public Key Infrastructure Using X.509 | |||
(PKIX) Certificates in the Context of Transport Layer | (PKIX) Certificates in the Context of Transport Layer | |||
Security (TLS)", RFC 6125, March 2011. | Security (TLS)", RFC 6125, March 2011. | |||
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. | [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for | |||
Austein, "BGP Prefix Origin Validation", RFC 6811, | X.509 PKIX Resource Certificates", RFC 6487, February | |||
January 2013. | 2012. | |||
14.2. Informative References | [RFC6810] Bush, R. and R. Austein, "The Resource Public Key | |||
Infrastructure (RPKI) to Router Protocol", RFC 6810, | ||||
January 2013. | ||||
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone | [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. | |||
Changes (DNS NOTIFY)", RFC 1996, August 1996. | Austein, "BGP Prefix Origin Validation", RFC 6811, January | |||
2013. | ||||
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", | 16.2. Informative References | |||
RFC 4808, March 2007. | ||||
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI | [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone | |||
Scheme", RFC 5781, February 2010. | Changes (DNS NOTIFY)", RFC 1996, August 1996. | |||
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support | [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC | |||
Secure Internet Routing", RFC 6480, February 2012. | 4808, March 2007. | |||
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile | [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI | |||
for Resource Certificate Repository Structure", RFC 6481, | Scheme", RFC 5781, February 2010. | |||
February 2012. | ||||
[RTR-IMPL] Bush, R., Austein, R., Patel, K., Gredler, H., and M. | [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support | |||
Waehlisch, "RPKI Router Implementation Report", Work | Secure Internet Routing", RFC 6480, February 2012. | |||
in Progress, January 2012. | ||||
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for | ||||
Resource Certificate Repository Structure", RFC 6481, | ||||
February 2012. | ||||
[RFC7128] Bush, R., Austein, R., Patel, K., Gredler, H., and M. | ||||
Waehlisch, "Resource Public Key Infrastructure (RPKI) | ||||
Router Implementation Report", RFC 7128, February 2014. | ||||
Authors' Addresses | Authors' Addresses | |||
Randy Bush | Randy Bush | |||
Internet Initiative Japan | Internet Initiative Japan | |||
5147 Crystal Springs | 5147 Crystal Springs | |||
Bainbridge Island, WA 98110 | Bainbridge Island, Washington 98110 | |||
US | US | |||
EMail: randy@psg.com | Phone: +1 206 780 0431 x1 | |||
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. 111 change blocks. | ||||
262 lines changed or deleted | 448 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |