draft-ietf-sidr-rpki-rtr-20.txt   draft-ietf-sidr-rpki-rtr-21.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: June 2, 2012 Dragon Research Labs Expires: June 19, 2012 Dragon Research Labs
November 30, 2011 December 17, 2011
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-20 draft-ietf-sidr-rpki-rtr-21
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 June 2, 2012. This Internet-Draft will expire on June 19, 2012.
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
skipping to change at page 4, line 5 skipping to change at page 4, line 5
from 2^32-1 to 0. It denotes the logical version of a cache. A 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 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 data from a parent cache or from primary RPKI data. As a cache is
receiving, new incoming data and implicit deletes are marked with receiving, new incoming data and implicit deletes are marked with
the new serial but MUST NOT be sent until the fetch is complete. 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 A serial number is not commensurate between caches, nor need it be
maintained across resets of the cache server. See [RFC1982] on maintained across resets of the cache server. See [RFC1982] on
DNS Serial Number Arithmetic for too much detail on serial number DNS Serial Number Arithmetic for too much detail on serial number
arithmetic. arithmetic.
Nonce: When a cache server is started, it generates a nonce to Session ID: When a cache server is started, it generates a session
identify the instance of the cache and to bind it to the sequence identifier to uniquely identify the instance of the cache and to
of Serial Numbers that cache instance will generate. This allows bind it to the sequence of Serial Numbers that cache instance will
the router to restart a failed session knowing that the Serial generate. This allows the router to restart a failed session
Number it is using is commensurate with that of the cache. knowing that the Serial Number it is using is commensurate with
that of the cache.
3. Deployment Structure 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].
skipping to change at page 5, line 48 skipping to change at page 5, line 49
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.
5.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 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.
Serial Notify is only message that the cache can send that is not in Serial Notify is only message that the cache can send that is not in
response to a message from the router. response to a message from the router.
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | Cache Nonce | | Version | Type | Session ID |
| 0 | 0 | | | 0 | 0 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Serial Number | | Serial Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
skipping to change at page 6, line 40 skipping to change at page 6, line 40
(Section 5.4) if the cache has a, possibly null, record of the (Section 5.4) 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 then have been no changes since the router last queried, the cache then
sends an End Of Data PDU. sends 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
the Serial Query, then it responds with a Cache Reset PDU the Serial Query, then it responds with a Cache Reset PDU
(Section 5.8). (Section 5.8).
The Cache Nonce 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 | Cache Nonce | | Version | Type | Session ID |
| 0 | 1 | | | 0 | 1 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Serial Number | | Serial Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
skipping to change at page 7, line 47 skipping to change at page 7, line 47
5.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 5.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 new value of Cache Nonce tells the In response to a Reset Query, the new value of the Session ID tells
router the instance of the cache session for future confirmation. In the router the instance of the cache session for future confirmation.
response to a Serial Query, the Cache Nonce being the same reassures In response to a Serial Query, the Session ID being the same
the router that the serial numbers are commensurate, i.e. the cache reassures the router that the serial numbers are commensurate, i.e.
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 | Cache Nonce | | Version | Type | Session ID |
| 0 | 3 | | | 0 | 3 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=8 | | Length=8 |
| | | |
`-------------------------------------------' `-------------------------------------------'
5.5. IPv4 Prefix 5.5. IPv4 Prefix
0 8 16 24 31 0 8 16 24 31
skipping to change at page 9, line 48 skipping to change at page 9, line 48
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Autonomous System Number | | Autonomous System Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
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 Cache Nonce 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 | |
| Version | Type | Cache Nonce | | Version | Type | Session ID |
| 0 | 7 | | | 0 | 7 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Serial Number | | Serial Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
skipping to change at page 12, line 15 skipping to change at page 12, line 15
PDU Type: An ordinal, denoting the type of the PDU, e.g. IPv4 PDU Type: An ordinal, denoting the type of the PDU, e.g. IPv4
Prefix, etc. 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.
Cache Nonce: When a cache server is started, it generates a nonce to Session ID: When a cache server is started, it generates a session
identify the instance of the cache and to bind it to the sequence identifier to identify the instance of the cache and to bind it to
of Serial Numbers that cache instance will generate. This allows the sequence of Serial Numbers that cache instance will generate.
the router to restart a failed session knowing that the Serial This allows the router to restart a failed session knowing that
Number it is using is commensurate with that of the cache. If, at the Serial Number it is using is commensurate with that of the
any time, either the router or the cache finds the value of the cache. If, at any time, either the router or the cache finds the
nonces they hold disagree, they MUST completely drop the session value of the session identifiers they hold disagree, they MUST
and the router MUST flush all data learned from that cache. completely drop the session and the router MUST flush all data
learned from that cache.
The nonce might be a pseudo-random, a monotonically increasing The Session ID might be a pseudo-random, a monotonically
value if the cache has reliable storage, etc. An implementation increasing value if the cache has reliable storage, etc. An
which uses a fine granularity of time for the Serial Number might implementation which uses a fine granularity of time for the
never change the Cache Nonce. Serial Number might never change the Session ID.
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
bytes in the entire PDU, including the eight bytes of header which bytes in the entire PDU, including the eight bytes of header which
end with the length field. 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-
skipping to change at page 13, line 33 skipping to change at page 13, line 33
| ------ 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 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.
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.
skipping to change at page 16, line 6 skipping to change at page 16, line 6
cache. cache.
7. Transport 7. 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 session. binary Protocol Data Units (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 are authenticated is highly desirable that the router and the cache are 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 attacks. Unfortunately, to protect against monkey in the middle (MITM) attacks.
there is no protocol to do so on all currently used platforms. Unfortunately, there is no protocol to do so on all currently used
Therefore, as of this document, there is no mandatory to implement platforms. Therefore, as of this document, there is no mandatory to
transport which provides authentication and integrity protection. implement transport which provides authentication and integrity
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 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, ACLs, ... to reduce the exposure to SHOULD use procedural means, ACLs, ... to reduce the exposure to
authentication issues. authentication issues.
If available to the operator, caches and routers SHOULD use one of If available to the operator, caches and routers SHOULD use one of
the following more protected protocols. the following more protected protocols.
Caches and routers SHOULD use TCP AO transport [RFC2385] over the Caches and routers SHOULD use TCP AO transport [RFC2385] over the
RPKI-Rtr port. rpki-rtr port.
Caches and routers MAY use SSH transport [RFC4252] using using a the Caches and routers MAY use SSH transport [RFC4252] using using a the
normal 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. rpki-rtr port.
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 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,
the client invokes the "ssh-connection" service, also known as the the client invokes the "ssh-connection" service, also known as the
skipping to change at page 17, line 24 skipping to change at page 17, line 25
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.
Cache servers supporting SSH transport MUST accept RSA and DSA Cache servers supporting SSH transport MUST accept RSA and DSA
authentication, and SHOULD accept ECDSA authentication. User authentication, and SHOULD accept 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 7.2. TLS Transport
Client routers using TLS transport MUST use client-side certificates Client routers using TLS transport MUST use client-side certificates
for authentication. While in principle any type of certificate and for authentication. While in principle any type of certificate and
certificate authority may be used, in general cache operators will certificate authority may be used, in general cache operators will
generally wish to create their own small-scale CA and issue generally 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
roll-over; any unrevoked, unexpired certificate from the proper CA roll-over; any unrevoked, unexpired certificate from the proper CA
may be used. If such certificates are used, the CN field [RFC5280] may be used. If such certificates are used, the CN field [RFC5280]
MUST be used to denote the router's identity. MUST be used to denote the router's identity.
Clients SHOULD verify the cache's certificate as well, to avoid Clients SHOULD verify the cache's certificate as well, to avoid
monkey-in-the-middle attacks. monkey in the middle attacks.
7.3. TCP MD5 Transport 7.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].
skipping to change at page 22, line 6 skipping to change at page 22, line 6
While we can not say the cache must be on the same LAN, if only While we can not say the cache must be on the same LAN, if only
due to the issue of an enterprise wanting to off-load the cache due to the issue of an enterprise wanting to off-load the cache
task to their upstream ISP(s), locality, trust, and control are task to their upstream ISP(s), locality, trust, and control are
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 identity of the cache server MUST 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 which can not provide the necessary authentication and
integrity (see Section 7) must rely on network design and
operational controls to provide protection against spoofing/
corruption attacks.
12. IANA Considerations 12. IANA Considerations
This document requests the IANA to assign 'well known' TCP Port This document requests the IANA to assign 'well known' TCP Port
Numbers to the RPKI-Router Protocol for the following, see Section 7: Numbers to the RPKI-Router Protocol for the following, see Section 7:
RPKI-Rtr rpki-rtr
RPKI-Rtr TLS rpki-rtr-tls
This document requests the IANA to create a registry for tuples of This document requests the IANA to create a registry for tuples of
Protocol Version / PDU Type, each of which may range from 0 to 255. Protocol Version / PDU Type, each of which may range from 0 to 255.
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], either adding to the registry is RFC Required per [RFC5226], either
standards track or experimental. The initial entries should be as standards track or experimental. The initial entries should be as
follows: follows:
Protocol Protocol
Version PDU Type Version PDU Type
 End of changes. 26 change blocks. 
49 lines changed or deleted 57 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/