draft-ietf-sidr-rpki-rtr-24.txt   draft-ietf-sidr-rpki-rtr-25.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: Standards Track R. Austein Intended status: Standards Track R. Austein
Expires: July 15, 2012 Dragon Research Labs Expires: July 31, 2012 Dragon Research Labs
January 12, 2012 January 28, 2012
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-24 draft-ietf-sidr-rpki-rtr-25
Abstract Abstract
In order to formally validate the origin ASs 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] prefix origin data from a trusted cache. This [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This
document describes a protocol to deliver validated prefix origin data document describes a protocol to deliver validated prefix origin data
to routers. to routers.
Requirements Language Requirements Language
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 July 15, 2012. This Internet-Draft will expire on July 31, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24
14.2. Informative References . . . . . . . . . . . . . . . . . . 25 14.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In order to formally validate the origin ASs 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] formally validated prefix origin data from a [I-D.ietf-sidr-arch] formally validated prefix origin data from a
trusted cache. This document describes a protocol to deliver trusted cache. This document describes a protocol to deliver
validated prefix origin data to routers. validated prefix origin data to routers. The design 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 6. The transport protocol options
are described in Section 7. Section 8 details how routers and caches are described in Section 7. Section 8 details how routers and caches
are configured to connect and authenticate. Section 9 describes are configured to connect and authenticate. Section 9 describes
likely deployment scenarios. The traditional security and IANA likely deployment scenarios. The traditional security and IANA
considerations end the document. considerations end the document.
skipping to change at page 3, line 44 skipping to change at page 3, line 46
distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see
[I-D.ietf-sidr-repos-struct]. [I-D.ietf-sidr-repos-struct].
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 monotonically increasing ordinal which wraps Serial Number: A 32-bit monotonically increasing unsigned integer
from 2^32-1 to 0. It denotes the logical version of a cache. A which wraps from 2^32-1 to 0. It denotes the logical version of a
cache increments the value by one when it successfully updates its cache. A cache increments the value by one when it successfully
data from a parent cache or from primary RPKI data. As a cache is updates its data from a parent cache or from primary RPKI data.
receiving, new incoming data and implicit deletes are marked with As a cache is receiving, new incoming data and implicit deletes
the new serial but MUST NOT be sent until the fetch is complete. are marked with the new serial but MUST NOT be sent until the
A serial number is not commensurate between caches, nor need it be fetch is complete. A serial number is not commensurate between
maintained across resets of the cache server. See [RFC1982] on caches, nor need it be maintained across resets of the cache
DNS Serial Number Arithmetic for too much detail on serial number server. See [RFC1982] on DNS Serial Number Arithmetic for too
arithmetic. much detail on serial number arithmetic.
Session ID: When a cache server is started, it generates a session Session ID: When a cache server is started, it generates a session
identifier to uniquely identify the instance of the cache and to identifier to uniquely identify the instance of the cache and to
bind it to the sequence of Serial Numbers that cache instance will bind it to the sequence of Serial Numbers that cache instance will
generate. This allows the router to restart a failed session generate. This allows the router to restart a failed session
knowing that the Serial Number it is using is commensurate with knowing that the Serial Number it is using is commensurate with
that of the cache. that of the cache.
3. Deployment Structure 3. Deployment Structure
skipping to change at page 5, line 35 skipping to change at page 5, line 37
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 which are time As a cache server must evaluate certificates and ROAs (Route Origin
dependent, servers' clocks MUST be correct to a tolerance of Attestations, see [I-D.ietf-sidr-arch]) which are time dependent,
approximately an hour. servers' 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 6.
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.
skipping to change at page 8, line 45 skipping to change at page 8, line 45
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Autonomous System Number | | Autonomous System Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
The lowest order bit of the Flags field is 1 for an announcement and The lowest order bit of the Flags field is 1 for an announcement and
0 for a withdrawal. 0 for a withdrawal.
In the RPKI, nothing prevents a signing certificate from issuing two In the RPKI, nothing prevents a signing certificate from issuing two
identical ROAs, and nothing prohibits the existence of two identical identical ROAs. In this case there would be no semantic difference
route: or route6: objects in the IRR. In this case there would be no 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 might appear to a In the RPKI, there is also an actual need for what might appear to a
router as identical IPvX PDUs. This can occur when an upstream router as identical IPvX (IPv4 or IPv6) PDUs. This can occur when an
certificate is being reissued or there is an address ownership upstream certificate is being reissued or there is an address
transfer up the validation chain. The ROA would be identical in the ownership transfer up the validation chain. The ROA would be
router sense, i.e. have the same {prefix, len, max-len, asn}, but a identical in the router sense, i.e. have the same {prefix, len, max-
different validation path in the RPKI. This is important to the len, asn}, but a different validation path in the RPKI. This is
RPKI, but not to the router. important to the RPKI, but not to the router.
The cache server MUST ensure that it has told the router client to The cache server MUST ensure that it has told the router client to
have one and only one IPvX PDU for a unique {prefix, len, max-len, have one and only one IPvX PDU for a unique {prefix, len, max-len,
asn} at any one point in time. Should the router client receive an asn} at any one point in time. Should the router client receive an
IPvX PDU with a {prefix, len, max-len, asn} identical to one it 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.6. IPv6 Prefix 5.6. IPv6 Prefix
skipping to change at page 9, line 44 skipping to change at page 9, line 43
+--- IPv6 Prefix ---+ +--- IPv6 Prefix ---+
| | | |
+--- ---+ +--- ---+
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Autonomous System Number | | Autonomous System Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
Analogous to the IPv4 Prefix PDU, 96 more bits no magic.
5.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 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 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 | |
skipping to change at page 11, line 5 skipping to change at page 11, line 5
The Error Code is described in Section 10. 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.
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, or possibly If the error is associated with a PDU of excessive (too long to be
corrupt, length, the Erroneous PDU field MAY be truncated. any legal PDU other than another Error Report), or 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 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 | |
skipping to change at page 11, line 47 skipping to change at page 11, line 48
| Arbitrary Text | | Arbitrary Text |
| of | | of |
~ Error Diagnostic Message ~ ~ Error Diagnostic Message ~
| | | |
`-------------------------------------------' `-------------------------------------------'
5.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 eight-bit unsigned integer, currently 0,
this protocol. denoting the version of this protocol.
PDU Type: An ordinal, denoting the type of the PDU, e.g. IPv4 PDU Type: An eight-bit unsigned integer, denoting the type of the
Prefix, etc. PDU, e.g. IPv4 Prefix, etc.
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.
Session ID: When a cache server is started, it generates a Session Session ID: When a cache server is started, it generates a Session
ID to identify the instance of the cache and to bind it to the ID to identify the instance of the cache and to bind it to the
skipping to change at page 13, line 5 skipping to change at page 13, line 5
out of sync is when nothing in the Cache Response contradicts any out of sync is when nothing in the Cache Response contradicts any
data currently held by the router. data currently held by the router.
Using persistent storage for the session 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, a monotonically The Session ID might be a pseudo-random, a monotonically
increasing value if the cache has reliable storage, etc. increasing value if the cache has reliable storage, etc.
Length: A 32 bit ordinal which has as its value the count of the Length: A 32-bit unsigned integer which has as its value the count
bytes in the entire PDU, including the eight bytes of header which of the bytes in the entire PDU, including the eight bytes of
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, whether this PDU announces a
new right to announce the prefix or withdraws a previously new right to announce the prefix or withdraws a previously
announced right. A withdraw effectively deletes one previously announced right. A withdraw effectively deletes one previously
announced IPvX Prefix PDU with the exact same Prefix, Length, Max- announced IPvX Prefix PDU with the exact same Prefix, Length, Max-
Len, and ASN. Len, and ASN.
Prefix Length: An ordinal denoting the shortest prefix allowed for Prefix Length: An eight-bit unsigned integer denoting the shortest
the prefix. prefix allowed for the prefix.
Max Length: An ordinal denoting the longest prefix allowed by the Max Length: An eight-bit unsigned integer denoting the longest
prefix. This MUST NOT be less than the Prefix Length element. prefix allowed by the 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 unsigned integer.
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.
6. 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:
6.1. Start or Restart 6.1. Start or Restart
skipping to change at page 16, line 41 skipping to change at page 16, line 43
It is expected that, when TCP-AO [RFC5925] is available on all It is expected that, when TCP-AO [RFC5925] is available on all
platforms deployed by operators, it will become the mandatory to platforms deployed by operators, it will become the mandatory to
implement transport. 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, to be assigned, see Section 12. Operators using a port, rpki-rtr, to be assigned, see Section 12. Operators
SHOULD use procedural means, e.g. access control lists (ACLs), ... to SHOULD use procedural means, e.g. access control lists (ACLs), ... to
reduce the exposure to authentication issues. reduce the exposure to authentication issues.
Caches and routers SHOULD use TCP-AO, SSH, 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 SSH transport [RFC4252] using a the normal Caches and routers MAY use SSHv2 transport [RFC4252] using a the
SSH port. For an example, see Section 7.1. normal SSH port. For an example, see Section 7.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 using a Caches and routers MAY use TLS transport [RFC5246] using using a
port, rpki-rtr-tls, to be assigned, see Section 12. port, rpki-rtr-tls, to be assigned, see Section 12.
7.1. SSH Transport 7.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 SSH 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 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,
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.
After the ssh-connection service is established, the client opens a After the ssh-connection service is established, the client opens a
channel of type "session", which results in an SSH session. channel of type "session", which results in an SSH session.
skipping to change at page 19, line 7 skipping to change at page 19, line 7
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
router attempts to establish a session with each potential serving router attempts to establish a session with each potential serving
cache in preference order, and then starts to load data from the most cache in preference order, and then starts to load data from the most
preferred cache to which it can connect and authenticate. The preferred cache to which it can connect and authenticate. The
router's list of caches has the following elements: router's list of caches has the following elements:
Preference: An ordinal denoting the router's preference to connect Preference: An unsigned integer denoting the router's preference to
to that cache, the lower the value the more preferred. connect to that cache, the lower the value the more preferred.
Name: The IP Address or fully qualified domain name of the cache. Name: The IP Address or fully qualified domain name of the cache.
Key: Any needed public key of the cache. Key: Any needed public key of the cache.
MyKey: Any needed private key or certificate of this client. MyKey: Any needed private key or certificate of this client.
Due to the distributed nature of the RPKI, caches simply can not be Due to the distributed nature of the RPKI, caches simply can not be
rigorously synchronous. A client may hold data from multiple caches, rigorously synchronous. A client may hold data from multiple caches,
but MUST keep the data marked as to source, as later updates MUST but MUST keep the data marked as to source, as later updates MUST
skipping to change at page 25, line 19 skipping to change at page 25, line 19
Secure Internet Routing", draft-ietf-sidr-arch-13 (work in Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), May 2011. progress), May 2011.
[I-D.ietf-sidr-repos-struct] [I-D.ietf-sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaelson, "A Profile for Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", Resource Certificate Repository Structure",
draft-ietf-sidr-repos-struct-09 (work in progress), draft-ietf-sidr-repos-struct-09 (work in progress),
July 2011. July 2011.
[I-D.ymbk-rpki-rtr-impl] [I-D.ymbk-rpki-rtr-impl]
Bush, R., Austein, R., Patel, K., and H. Gredler, "RPKI Bush, R., Austein, R., Patel, K., Gredler, H., and M.
Router Implementation Report", draft-ymbk-rpki-rtr-impl-00 Waehlisch, "RPKI Router Implementation Report",
(work in progress), January 2012. draft-ymbk-rpki-rtr-impl-01 (work in progress),
January 2012.
[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.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
RFC 4808, March 2007. RFC 4808, March 2007.
[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.
 End of changes. 21 change blocks. 
51 lines changed or deleted 58 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/