draft-ietf-sidr-rpki-rtr-10.txt   draft-ietf-sidr-rpki-rtr-11.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ Internet-Draft Internet Initiative Japan
Intended status: Standards Track R. Austein Intended status: Standards Track R. Austein
Expires: September 4, 2011 ISC Expires: September 16, 2011 ISC
March 3, 2011 March 15, 2011
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-10 draft-ietf-sidr-rpki-rtr-11
Abstract Abstract
In order to formally validate the origin ASes of BGP announcements, In order to formally validate the origin ASs of BGP announcements,
routers need a simple but reliable mechanism to receive RPKI routers need a simple but reliable mechanism to receive RPKI
[I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted
cache. This document describes a protocol to deliver validated cache. This document describes a protocol to deliver validated
prefix origin data to routers over ssh. prefix origin data to routers over ssh.
Requirements Language 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].
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2011. This Internet-Draft will expire on September 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
2. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Operational Overview . . . . . . . . . . . . . . . . . . . . . 3 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 4 4. Operational Overview . . . . . . . . . . . . . . . . . . . . . 4
4.1. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 5
4.2. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Cache Response . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Cache Response . . . . . . . . . . . . . . . . . . . . . . 7
4.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 9 5.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 9
4.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 9 5.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 9
4.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 9 5.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 10
4.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 10 5.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 10
5. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 12 5.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 11
5.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 12 6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 12
5.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 13 6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 13
5.3. No Incremental Update Available . . . . . . . . . . . . . 13 6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 14
5.4. Cache has No Data Available . . . . . . . . . . . . . . . 14 6.3. No Incremental Update Available . . . . . . . . . . . . . 14
6. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 6.4. Cache has No Data Available . . . . . . . . . . . . . . . 15
7. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 15 7. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16 8. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 16
9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
In order to formally validate the origin ASes of BGP announcements, In order to formally validate the origin ASs of BGP announcements,
routers need a simple but reliable mechanism to receive RPKI routers need a simple but reliable mechanism to receive RPKI
[I-D.ietf-sidr-arch] or analogous formally validated prefix origin [I-D.ietf-sidr-arch] or analogous formally validated prefix origin
data from a trusted cache. This document describes a protocol to data from a trusted cache. This document describes a protocol to
deliver validated prefix origin data to routers over ssh. deliver validated prefix origin data to routers over ssh.
Section 2 describes the deployment structure and Section 3 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 4, and the expected PDU protocol are formally described in Section 5, and the expected PDU
sequences are described in Section 5. The transport protocol is sequences are described in Section 6. The transport protocol is
described in Section 6. Section 7 details how routers and caches are described in Section 7. Section 8 details how routers and caches are
configured to connect and authenticate. Section 8 describes likely configured to connect and authenticate. Section 9 describes likely
deployment scenarios. The traditional security and IANA deployment scenarios. The traditional security and IANA
considerations end the document. considerations end the document.
The protocol is extensible to support new PDUs with new semantics The protocol is extensible to support new PDUs with new semantics
when and as needed, as indicated by deployment experience. PDUs are when and as needed, as indicated by deployment experience. PDUs are
versioned should deployment experience call for change. versioned should deployment experience call for change.
2. Deployment Structure 2. Glossary
The following terms are used with special meaning:
Global RPKI: The authoritative data of the RPKI are published in a
distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see
[I-D.ietf-sidr-repos-struct].
Non-authorative Cache: A coalesced copy of the RPKI which is
periodically fetched/refreshed directly or indirectly from the
global RPKI using the [RFC5781] protocol/tools
Cache: Relying party update software such as rcynic is used to
gather and validate the distributed data of the RPKI into a cache.
Trusting this cache further is a matter between the provider of
the cache and a relying party.
Serial Number: A 32-bit monotonically increasing ordinal which wraps
from 2^32-1 to 0. It denotes the logical version of a cache. A
cache increments the value by one when it successfully updates its
data from a parent cache or from primary RPKI data. As a cache is
receiving, new incoming data, and implicit deletes, are marked
with the new serial but MUST NOT be sent until the fetch is
complete. A serial number is not commensurate between caches, nor
need it be maintained across resets of the cache server. See
[RFC1982] on DNS Serial Number Arithmetic for too much detail on
serial number arithmetic.
Nonce: When a cache server is started, it generates a nonce to
identify the instance of the cache and to bind it to the sequence
of Serial Numbers that cache instance will generate. This allows
the router to restart a failed session knowing that the Serial
Number it is using is commensurate with that of the cache.
3. Deployment Structure
Deployment of the RPKI to reach routers has a three level structure Deployment of the RPKI to reach routers has a three level structure
as follows: as follows:
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, RPKI publication repositories, e.g. distributed set of servers, RPKI publication repositories, e.g.
the IANA, RIRs, NIRs, and ISPs, see [I-D.ietf-sidr-repos-struct]. the IANA, RIRs, NIRs, and ISPs, see [I-D.ietf-sidr-repos-struct].
Local Caches: A local set of one or more collected and verified non- Local Caches: A local set of one or more collected and verified non-
authoritative caches. A relying party, e.g. router or other authoritative caches. A relying party, e.g. router or other
client, MUST have a formally authenticated trust relationship client, MUST have a formally authenticated trust relationship
with, and a secure transport channel to, any non-authoritative with, and a secure transport channel to, any non-authoritative
cache(s) it uses. cache(s) it uses.
Routers: A router fetches data from a local cache using the protocol Routers: A router fetches data from a local cache using the protocol
described in this document. It is said to be a client of the described in this document. It is said to be a client of the
cache. There are mechanisms for the router to assure itself of cache. There are mechanisms for the router to assure itself of
the authenticity of the cache and to authenticate itself to the the authenticity of the cache and to authenticate itself to the
cache. cache.
3. Operational Overview 4. Operational Overview
A router establishes and keeps open an authenticated connection to A router establishes and keeps open an authenticated connection to
one or more caches with which it has client/server relationships. It one or more caches with which it has client/server relationships. It
is configured with a semi-ordered list of caches, and establishes a is configured with a semi-ordered list of caches, and establishes a
connection to the most preferred cache, or set of caches, which connection to the most preferred cache, or set of caches, which
accept the connections. accept the connections.
The router MUST choose the most preferred, by configuration, cache or The router MUST choose the most preferred, by configuration, cache or
set of caches so that the operator may control load on their caches set of caches so that the operator may control load on their caches
and the Global RPKI. and the Global RPKI.
skipping to change at page 4, line 47 skipping to change at page 5, line 34
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.
4. 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 5. Section 6.
4.1. Serial Notify 5.1. 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 Cache Nonce reassures the router that the serial numbers are The Cache Nonce reassures the router that the serial numbers are
comensurate, i.e. the cache session has not been changed. commensurate, i.e. the cache session has not been changed.
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | Cache Nonce | | Version | Type | Cache Nonce |
| 0 | 0 | | | 0 | 0 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Serial Number | | Serial Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.2. Serial Query 5.2. 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 which 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 4.4) if the cache has a record of the changes since the (Section 5.4) if the cache has a record of the changes since the
serial number specified by the router. If there have been no changes serial number specified by the router. If there have been no changes
since the router last queried, the cache responds with an End Of Data since the router last queried, the cache responds with an End Of Data
PDU. If the cache does not have the data needed to update the PDU. If the cache does not have the data needed to update the
router, perhaps because its records do not go back to the Serial router, perhaps because its records do not go back to the Serial
Number in the Serial Query, then it responds with a Cache Reset PDU Number in the Serial Query, then it responds with a Cache Reset PDU
(Section 4.8). (Section 5.8).
The Cache Nonce tells the cache what instance the router expects to The Cache Nonce tells the cache what instance the router expects to
ensure that the serial numbers are comensurate, 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 | Cache Nonce | | Version | Type | Cache Nonce |
| 0 | 1 | | | 0 | 1 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Serial Number | | Serial Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.3. Reset Query 5.3. 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 4.4). with a Cache Response PDU (Section 5.4).
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | reserved = zero | | Version | Type | reserved = zero |
| 0 | 2 | | | 0 | 2 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=8 | | Length=8 |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.4. Cache Response 5.4. 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 4.2), the cache When replying to a Serial Query request (Section 5.2), 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 Cache Nonce tells the router the In response to a Reset Query, the Cache Nonce tells the router the
instance of the cache session for future confirmation. In response instance of the cache session for future confirmation. In response
to a Serial Query, the Cache Nonce reassures the router that the to a Serial Query, the Cache Nonce reassures the router that the
serial numbers are comensurate, i.e. the cache session has not been serial numbers are commensurate, i.e. the cache session has not been
changed. changed.
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | Cache Nonce | | Version | Type | Cache Nonce |
| 0 | 3 | | | 0 | 3 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=8 | | Length=8 |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.5. IPv4 Prefix 5.5. 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 | | | 0 | 4 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=20 | | Length=20 |
| | | |
skipping to change at page 8, line 5 skipping to change at page 8, line 45
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Autonomous System Number | | Autonomous System Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
Due to the nature of the RPKI and the IRR, there can be multiple Due to the nature of the RPKI and the IRR, there can be multiple
identical IPvX PDUs. A router MUST be prepared to receive multiple identical IPvX PDUs. A router MUST be prepared to receive multiple
identical record announcements and MUST NOT consider a record to have identical record announcements and MUST NOT consider a record to have
been deleted until it has received a corresponding number of been deleted until it has received a corresponding number of
withdrawals or a reset is performed Hence the router will likely keep withdrawals or a reset is performed. Hence the router will likely
an internal reference count on each IPvX PDU. keep an internal reference count on each IPvX PDU.
In the RPKI, nothing prevents a signing certificate from issuing two In the RPKI, nothing prevents a signing certificate from issuing two
identical ROAs, and nothing prohibits the existence of two identical identical ROAs, and nothing prohibits the existence of two identical
route: or route6: objects in the IRR. In this case there would be no route: or route6: objects in the IRR. In this case there would be no
semantic difference between the objects, merely a process redundancy. semantic difference between the objects, merely a process redundancy.
In the RPKI, there is also an actual need for what will appear to the In the RPKI, there is also an actual need for what will appear to the
router as identical IPvX PDUs. This occurs when an upstream router as identical IPvX PDUs. This occurs when an upstream
certificate is being reissued or a site is changing providers, often certificate is being reissued or a site is changing providers, often
a 'make and break' situation. The ROA is identical in the router a 'make and break' situation. The ROA is identical in the router
sense, i.e. has the same {prefix, len, max-len, asn}, but has a sense, i.e. has the same {prefix, len, max-len, asn}, but has a
different validation path in the RPKI. This is important to the different validation path in the RPKI. This is important to the
RPKI, but not to the router. RPKI, but not to the router.
The lowest order bit of the Flags field is 1 for an announcement and The lowest order bit of the Flags field is 1 for an announcement and
0 for a withdrawal. 0 for a withdrawal.
4.6. IPv6 Prefix 5.6. 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 | | | 0 | 6 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=32 | | Length=32 |
| | | |
skipping to change at page 9, line 5 skipping to change at page 9, line 45
+--- IPv6 Prefix ---+ +--- IPv6 Prefix ---+
| | | |
+--- ---+ +--- ---+
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Autonomous System Number | | Autonomous System Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.7. End of Data 5.7. End of Data
End of Data: Cache tells router it has no more data for the request. End of Data: Cache tells router it has no more data for the request.
The Cache Nonce MUST be the same as that of the corresponding Cache The Cache Nonce MUST be the same as that of the corresponding Cache
Response which 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 | Cache Nonce | | Version | Type | Cache Nonce |
skipping to change at page 9, line 27 skipping to change at page 10, line 20
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Serial Number | | Serial Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.8. Cache Reset 5.8. 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 | | | 0 | 8 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=8 | | Length=8 |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.9. Error Report 5.9. 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.
The Error Number is described in Section 9. The Error Code is described in Section 10.
If the error is not associated with any particular PDU, the Erroneous If the error is not associated with any particular PDU, the Erroneous
PDU field MUST be empty and the Length of Encapsulated PDU field MUST PDU field MUST be empty and the Length of Encapsulated PDU field MUST
be zero. be zero.
If the error is associated with a PDU of excessive, or possibly If the error is associated with a PDU of excessive, or possibly
corrupt, length, the Erroneous PDU field MAY be truncated. 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 SHOULD be zero. If error text is present, it SHOULD be a Text field SHOULD be zero. If error text is present, it SHOULD be a
string in US-ASCII, for maximum portability; if non-US-ASCII string in US-ASCII, for maximum portability; if non-US-ASCII
characters are absolutely required, the error text MUST use UTF-8 characters are absolutely required, the error text MUST use UTF-8
encoding. encoding.
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | Error Number | | Version | Type | Error Code |
| 0 | 10 | | | 0 | 10 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length | | Length |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length of Encapsulated PDU | | Length of Encapsulated PDU |
| | | |
+-------------------------------------------+ +-------------------------------------------+
skipping to change at page 10, line 44 skipping to change at page 11, line 37
| Length of Error Text | | Length of Error Text |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Arbitrary Text | | Arbitrary Text |
| of | | of |
~ Error Diagnostic Message ~ ~ Error Diagnostic Message ~
| | | |
`-------------------------------------------' `-------------------------------------------'
4.10. Fields of a PDU 5.10. Fields of a PDU
PDUs contain the following data elements: PDUs contain the following data elements:
Protocol Version: An ordinal, currently 0, denoting the version of Protocol Version: An ordinal, currently 0, denoting the version of
this protocol. this protocol.
Serial Number: The serial number of the RPKI Cache when this ROA was Serial Number: The serial number of the RPKI Cache when this ROA was
received from the cache's up-stream cache server or gathered from received from the cache's up-stream 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 an rigorously validated update from a parent cache, for completing an rigorously validated update from a parent cache, for
example via rcynic. See [RFC1982] on DNS Serial Number Arithmetic example via rcynic. See [RFC1982] on DNS Serial Number Arithmetic
for too much detail on serial number arithmetic. for too much detail on serial number arithmetic.
Cache Nonce: When a cache server is started, it generates a nonce to Cache Nonce: When a cache server is started, it generates a nonce to
identify the instance of the cache and to bind it to the sequence identify the instance of the cache and to bind it to the sequence
of Serial Numbers that cache instance will generate. This allows of Serial Numbers that cache instance will generate. This allows
the router to restart a failed session knowing that the Serial the router to restart a failed session knowing that the Serial
Number it is using is comensurate with that of the cache. If, at Number it is using is commensurate with that of the cache. If, at
any time, either the router or the cache finds the value of the any time, either the router or the cache finds the value of the
nonces they hold disagree, they MUST completely drop the session nonces they hold disagree, they MUST completely drop the session
and the router MUST flush all data learned from that cache. and the router MUST flush all data learned from that cache.
The nonce might be a pseudo-random, a monotonically increasing The nonce might be a pseudo-random, a monotonically increasing
value if the cache has reliable storage, etc. An implementation value if the cache has reliable storage, etc. An implementation
which uses a fine granularity of time for the Serial Number might which uses a fine granularity of time for the Serial Number might
never change the Cache Nonce. never change the Cache Nonce.
Length: A 32 bit ordinal which has as its value the count of the Length: A 32 bit ordinal which has as its value the count of the
skipping to change at page 12, line 5 skipping to change at page 12, line 44
prefix. This MUST NOT be less than the Prefix Length element. prefix. This MUST NOT be less than the Prefix 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 32 Autonomous System Number: ASN allowed to announce this prefix, a 32
bit ordinal. bit ordinal.
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. Protocol Sequences 6. Protocol Sequences
The sequences of PDU transmissions fall into three conversations as The sequences of PDU transmissions fall into three conversations as
follows: follows:
5.1. Start or Restart 6.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 | ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix | ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
| ------- IPvX Prefix ------> | Payload PDUs | ------- IPvX Prefix ------> | Payload 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 Cache Nonce from the previous session to ensure the containing the Cache Nonce from the previous session to ensure the
serial numbers are comensurate. 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.
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 no less frequently than once an hour. This
also acts as a keep alive at the application layer. also acts as a keep alive at the application layer.
As the cache MAY not keep updates for more than one hour, the router As the cache MAY not keep updates for more than one hour, the router
MUST have a polling interval of no greater than half an hour MUST have a polling interval of no greater than half an hour
5.2. Typical Exchange 6.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 | ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix | ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
skipping to change at page 13, line 36 skipping to change at page 14, line 36
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 no less frequently
than once an hour. than once an hour.
5.3. No Incremental Update Available 6.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 | ------- IPvX Prefix ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix | ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix
skipping to change at page 14, line 16 skipping to change at page 15, line 16
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.
5.4. Cache has No Data Available 6.4. Cache has No Data Available
Cache Router Cache Router
~ ~ ~ ~
| <----- Serial Query ------ | R requests data | <----- Serial Query ------ | R requests data
| ---- Error Report PDU ----> | C cannot supply update | ---- Error Report PDU ----> | C cannot supply update
~ ~ ~ ~
Cache Router Cache Router
~ ~ ~ ~
| <----- Reset Query ------- | R requests data | <----- Reset Query ------- | R requests data
skipping to change at page 14, line 45 skipping to change at page 15, line 45
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.
6. SSH Transport 7. SSH 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 Protocol Data Units (PDUs) in a persistent SSH session. binary Protocol Data Units (PDUs) in a persistent SSH session.
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 SSH transport protocol, and the client and connection using the SSH 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 RFC 4252 application, as described in the SSH authentication protocol RFC 4252
[RFC4252]. Once the application has been successfully authenticated, [RFC4252]. Once the application has been successfully authenticated,
skipping to change at page 15, line 26 skipping to change at page 16, line 26
the application transport as an SSH subsystem called "rpki-rtr". the application transport as an SSH subsystem called "rpki-rtr".
Subsystem support is a feature of SSH version 2 (SSHv2) and is not Subsystem support is a feature of SSH version 2 (SSHv2) and is not
included in SSHv1. Running this protocol as an SSH subsystem avoids included in SSHv1. Running this protocol as an SSH subsystem avoids
the need for the application to recognize shell prompts or skip over the need for the application to recognize shell prompts or skip over
extraneous information, such as a system message that is sent at extraneous information, such as a system message that is sent at
shell start-up. shell start-up.
It is assumed that the router and cache have exchanged keys out of It is assumed that the router and cache have exchanged keys out of
band by some reasonably secured means. band by some reasonably secured means.
7. Router-Cache Set-Up 8. Router-Cache Set-Up
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 in order of preference. This preference merely for each server in order of preference. This preference merely
denotes proximity, not trust, preferred belief, etc. The client denotes proximity, not trust, preferred belief, etc. The client
skipping to change at page 16, line 39 skipping to change at page 17, line 39
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.
8. Deployment Scenarios 9. Deployment Scenarios
For illustration, we present three likely deployment scenarios. For illustration, we present three likely deployment scenarios.
Small End Site: The small multi-homed end site may wish to outsource Small End Site: The small multi-homed 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 one or more band mechanism, and their router(s) would connect to one or more
up-streams' caches. The ISPs would likely deploy caches intended up-streams' caches. The ISPs would likely deploy caches intended
for customer use separately from the caches with which their own for customer use separately from the caches with which their own
BGP speakers peer. BGP speakers peer.
skipping to change at page 17, line 29 skipping to change at page 18, line 29
Of course, these are illustrations and there are other possible Of course, these are illustrations and there are other possible
deployment strategies. It is expected that minimizing load on the deployment strategies. It is expected that minimizing load on the
global RPKI servers will be a major consideration. global RPKI servers will be a major consideration.
To keep load on global RPKI services from unnecessary peaks, it is To keep load on global RPKI services from unnecessary peaks, it is
recommended that primary caches which load from the distributed recommended that primary caches which load from the distributed
global RPKI not do so all at the same times, e.g. on the hour. global RPKI not do so all at the same times, e.g. on the hour.
Choose a random time, perhaps the ISP's AS number modulo 60 and Choose a random time, perhaps the ISP's AS number modulo 60 and
jitter the inter-fetch timing. jitter the inter-fetch timing.
9. Error Codes 10. 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 this section during development of the initial expect additions to this section during development of the initial
implementations. Errors which are considered fatal SHOULD cause the implementations. Errors which are considered fatal SHOULD cause the
session to be dropped. 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
Reset Query because it has no useful data available at this time. Reset Query because it has no useful data available at this time.
This is likely to be a temporary error, and most likely indicates This is likely to be a temporary error, and most likely indicates
that the cache has not yet completed pulling down an initial that the cache has not yet completed pulling down an initial
current data set from the global RPKI system after some kind of current data set from the global RPKI system after some kind of
event that invalidated whatever data it might have previously held event that invalidated whatever data it might have previously held
(reboot, network partition, etcetera). (reboot, network partition, et cetera).
3: Invalid Request (fatal): The cache server believes the client's 3: Invalid Request (fatal): The cache server believes the client's
request to be invalid. request to be invalid.
4: Unsupported Protocol Version (fatal): The Protocol Version is not 4: Unsupported Protocol Version (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/PrefixLength/MaxLength triple does not but a record for the Prefix/PrefixLength/MaxLength triple does not
exist in the receiver's database. exist in the receiver's database.
10. Security Considerations 11. Security Considerations
As this document describes a security protocol, many aspects of As this document describes a security protocol, many aspects of
security interest are described in the relevant sections. This security interest are described in the relevant sections. This
section points out issues which may not be obvious in other sections. section points out issues which may not be obvious in other sections.
Cache Validation: In order for a collection of caches as described Cache Validation: In order for a collection of caches as described
in Section 8 to guarantee a consistent view, they need to be given in Section 9 to guarantee a consistent view, they need to be given
consistent trust anchors to use in their internal validation 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 an ssh transport Cache Peer Identification: The router initiates an ssh transport
session to a cache, which it identifies by either IP address or session to a cache, which it identifies by either IP address or
fully qualified domain name. Be aware that a DNS or address fully qualified domain name. Be aware that a DNS or address
spoofing attack could make the correct cache unreachable. No spoofing attack could make the correct cache unreachable. No
session would be established, as the authorization keys would not session would be established, as the authorization keys would not
match. match.
skipping to change at page 19, line 22 skipping to change at page 20, line 22
very critical issues here. The cache(s) really SHOULD be as very critical issues here. The cache(s) really SHOULD be as
close, in the sense of controlled and protected (against DDoS, close, in the sense of controlled and protected (against DDoS,
MITM) transport, to the router(s) as possible. It also SHOULD be MITM) 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 ssh identity of the cache server MUST be verified and The ssh identity of the cache server MUST 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.
11. Glossary
The following terms are used with special meaning:
Global RPKI: The authoritative data of the RPKI are published in a
distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see
[I-D.ietf-sidr-repos-struct].
Non-authorative Cache: A coalesced copy of the RPKI which is
periodically fetched/refreshed directly or indirectly from the
global RPKI using the [RFC5781] protocol/tools
Cache: Relying party update sofcware such as rcynic is used to
gather and validate the distributed data of the RPKI into a cache.
Trusting this cache further is a matter between the provider of
the cache and a relying party.
Serial Number: A 32-bit monotonically increasing ordinal which wraps
from 2^32-1 to 0. It denotes the logical version of a cache. A
cache increments the value by one when it successfully updates its
data from a parent cache or from primary RPKI data. As a cache is
receiving, new incoming data, and implicit deletes, are marked
with the new serial but MUST NOT be sent until the fetch is
complete. A serial number is not commensurate between caches, nor
need it be maintained across resets of the cache server. See
[RFC1982] on DNS Serial Number Arithmetic for too much detail on
serial number arithmetic.
12. IANA Considerations 12. IANA Considerations
This document requests the IANA to create a registry for PDU types. This document requests the IANA to create a registry for PDU types.
The name of the registry should be rpki-rtr-pdu. The policy for The name of the registry should be rpki-rtr-pdu. The policy for
adding to the registry is RFC Required per [RFC5226]. The intitial adding to the registry is RFC Required per [RFC5226]. The initial
entries should be as follows: entries should be as follows:
0 - Serial Notify 0 - Serial Notify
1 - Serial Query 1 - Serial Query
2 - Reset Query 2 - Reset Query
3 - Cache Response 3 - Cache Response
4 - IPv4 Prefix 4 - IPv4 Prefix
6 - IPv6 Prefix 6 - IPv6 Prefix
7 - End of Data 7 - End of Data
8 - Cache Reset 8 - Cache Reset
skipping to change at page 22, line 8 skipping to change at page 22, line 20
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996. Changes (DNS NOTIFY)", RFC 1996, August 1996.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, February 2010. Scheme", RFC 5781, February 2010.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
Internet Initiative Japan, Inc. Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
US US
Phone: +1 206 780 0431 x1 Phone: +1 206 780 0431 x1
Email: randy@psg.com Email: randy@psg.com
Rob Austein Rob Austein
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
 End of changes. 52 change blocks. 
107 lines changed or deleted 113 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/