draft-ietf-sidr-rpki-rtr-12.txt   draft-ietf-sidr-rpki-rtr-13.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: October 28, 2011 ISC Expires: December 31, 2011 ISC
April 26, 2011 June 29, 2011
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-12 draft-ietf-sidr-rpki-rtr-13
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] or analogous prefix origin data from a trusted [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This
cache. This document describes a protocol to deliver validated document describes a protocol to deliver validated prefix origin data
prefix origin data to routers over ssh. to routers.
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 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 October 28, 2011. This Internet-Draft will expire on December 31, 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
5.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 9 5.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 9
5.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 9 5.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 9
5.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 10 5.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 10
5.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 10 5.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 10
5.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 11 5.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 12 6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 13 6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 13
6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 14 6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 14
6.3. No Incremental Update Available . . . . . . . . . . . . . 14 6.3. No Incremental Update Available . . . . . . . . . . . . . 14
6.4. Cache has No Data Available . . . . . . . . . . . . . . . 15 6.4. Cache has No Data Available . . . . . . . . . . . . . . . 15
7. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 16 7.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 16
9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17 7.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 17
10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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] or analogous formally validated prefix origin [I-D.ietf-sidr-arch] formally validated prefix origin data from a
data from a trusted cache. This document describes a protocol to trusted cache. This document describes a protocol to deliver
deliver validated prefix origin data to routers over ssh. validated prefix origin data to routers.
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 is sequences are described in Section 6. The transport protocol options
described in Section 7. Section 8 details how routers and caches are are described in Section 7. Section 8 details how routers and caches
configured to connect and authenticate. Section 9 describes likely are configured to connect and authenticate. Section 9 describes
deployment scenarios. The traditional security and IANA likely 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. Glossary 2. Glossary
The following terms are used with special meaning: The following terms are used with special meaning:
Global RPKI: The authoritative data of the RPKI are published in a Global RPKI: The authoritative data of the RPKI are published in a
distributed set of servers at the IANA, 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].
Non-authoritative Cache: A coalesced copy of the RPKI which is Cache: A coalesced copy of the RPKI which is periodically fetched/
periodically fetched/refreshed directly or indirectly from the refreshed directly or indirectly from the global RPKI using the
global RPKI using the [RFC5781] protocol/tools [RFC5781] protocol/tools. Relying party update software such as
rcynic is used to gather and validate the distributed data of the
Cache: Relying party update software such as rcynic is used to RPKI into a cache. Trusting this cache further is a matter
gather and validate the distributed data of the RPKI into a cache. between the provider of the cache and a relying party.
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 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 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 receiving, new incoming data and implicit deletes are marked with
with the new serial but MUST NOT be sent until the fetch is the new serial but MUST NOT be sent until the fetch is complete.
complete. A serial number is not commensurate between caches, nor A serial number is not commensurate between caches, nor need it be
need it be maintained across resets of the cache server. See maintained across resets of the cache server. See [RFC1982] on
[RFC1982] on DNS Serial Number Arithmetic for too much detail on DNS Serial Number Arithmetic for too much detail on serial number
serial number arithmetic. arithmetic.
Nonce: When a cache server is started, it generates a nonce to 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 commensurate with that of the cache. 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].
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
authoritative caches. A relying party, e.g. router or other caches. A relying party, e.g. router or other client, MUST have a
client, MUST have a formally authenticated trust relationship trust relationship with, and a trusted transport channel to, any
with, and a secure transport channel to, any non-authoritative 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 MAY be mechanisms for the router to assure itself of
the authenticity of the cache and to authenticate itself to the the authenticity of the cache and to authenticate itself to the
cache. cache.
4. Operational Overview 4. Operational Overview
A router establishes and keeps open an authenticated connection to A router establishes and keeps open a connection to one or more
one or more caches with which it has client/server relationships. It caches with which it has client/server relationships. It is
is configured with a semi-ordered list of caches, and establishes a configured with a semi-ordered list of caches, and establishes a
connection to the most preferred cache, or set of caches, which connection to the most preferred cache, or set of caches, 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.
Periodically, the router sends to the cache the serial number of the Periodically, the router sends to the cache the serial number of the
highest numbered data record it has received from that cache, i.e. highest numbered data it has received from that cache, i.e. the
the router's current serial number. When a router establishes a new router's current serial number. When a router establishes a new
connection to a cache, or wishes to reset a current relationship, it connection to a cache, or wishes to reset a current relationship, it
sends a Reset Query. sends a Reset Query.
The Cache responds with all data records which have serial numbers The Cache responds with all data records which have serial numbers
greater than that in the router's query. This may be the null set, greater than that in the router's query. This may be the null set,
in which case the End of Data PDU is still sent. Note that 'greater' in which case the End of Data PDU is still sent. Note that 'greater'
must take wrap-around into account, see [RFC1982]. must take wrap-around into account, see [RFC1982].
When the router has received all data records from the cache, it sets When the router has received all data records from the cache, it sets
its current serial number to that of the serial number in the End of its current serial number to that of the serial number in the End of
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 Cache Nonce tells the router the In response to a Reset Query, the new value of Cache Nonce tells the
instance of the cache session for future confirmation. In response router the instance of the cache session for future confirmation. In
to a Serial Query, the Cache Nonce reassures the router that the response to a Serial Query, the Cache Nonce being the same reassures
serial numbers are commensurate, i.e. the cache session has not been the router that the serial numbers are commensurate, i.e. the cache
changed. session has not 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 |
| | | |
skipping to change at page 9, line 29 skipping to change at page 9, line 29
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | reserved = zero | | Version | Type | reserved = zero |
| 0 | 6 | | | 0 | 6 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=32 | | Length=32 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | Prefix | Max | | | | Prefix | Max | |
| Flags | Length | Length | zero | | Flags | Length | Length | zero |
| | 0..32 | 0..128 | | | | 0..128 | 0..128 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
+--- ---+ +--- ---+
| | | |
+--- IPv6 Prefix ---+ +--- IPv6 Prefix ---+
| | | |
+--- ---+ +--- ---+
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
skipping to change at page 10, line 48 skipping to change at page 10, line 48
5.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 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 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
skipping to change at page 13, line 37 skipping to change at page 13, line 37
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 little more than one hour, the
MUST have a polling interval of no greater than half an hour router MUST have a polling interval of no greater than once an hour.
6.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
| ------- 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
~ ~ ~ ~
The cache server SHOULD send a notify PDU with its current serial The cache server SHOULD send a notify PDU with its current serial
number when the cache's serial changes, with the expectation that the number when the cache's serial changes, with the expectation that the
router MAY then issue a serial query earlier than it otherwise might. router MAY then issue a serial query earlier than it otherwise might.
This is analogous to DNS NOTIFY in [RFC1996]. The cache SHOULD rate This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate
limit Serial Notifies to no more frequently than one per minute. limit Serial Notifies to no more frequently than one per minute.
When the transport layer is up and either a timer has gone off in the When the transport layer is up and either a timer has gone off in the
router, or the cache has sent a Notify, the router queries for new router, or the cache has sent a Notify, the router queries for new
data by sending a Serial Query, and the cache sends all data newer data by sending a Serial Query, and the cache sends all data newer
than the serial in the Serial Query. than the serial in the Serial Query.
To limit the length of time a cache must keep old withdraws, a router To limit the length of time a cache must keep old withdraws, a router
MUST send either a Serial Query or a Reset Query no less frequently MUST send either a Serial Query or a Reset Query no less frequently
than once an hour. than once an hour.
skipping to change at page 15, 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.
7. SSH 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 SSH session. binary Protocol Data Units (PDUs) in a persistent session.
To prevent cache spoofing and DoS attacks by illegitimate routers, it
is highly desirable that the router and the cache are authenticated
to each other. Integrity protection for payloads is also desirable
to protect against monkey in the middle attacks. Unfortunately,
there is no protocol to do so on all currently used platforms.
Therefore, as of this document, there is no mandatory to implement
transport which provides authentication and integrity protection.
It is expected that, when TCP-AO [RFC5925]is available on all
platforms deployed by operators, it will become the mandatory to
implement transport.
Caches and routers MUST implement unprotected transport over TCP
using a port, RPKI-Rtr, to be assigned, see Section 12. Operators
SHOULD use procedural means, ACLs, ... to reduce the exposure to
authentication issues.
If available to the operator, caches and routers SHOULD use one of
the following more protected protocols.
Caches and routers SHOULD use TCP AO transport [RFC5925] over the
RPKI-Rtr port.
Caches and routers MAY use SSH transport [RFC4252] using using a the
normal SSH port. For an example, see Section 7.1.
Caches and routers MAY use TCP MD5 transport [RFC2385] using the
RPKI-Rtr port.
Caches and routers MAY use IPsec transport [RFC4301] using the RPKI-
Rtr port.
Caches and routers MAY use TLS transport [RFC5246] using using a
port, RPKI-Rtr TLS, to be assigned, see Section 12.
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
SSH connection protocol. SSH connection protocol.
skipping to change at page 16, line 26 skipping to change at page 17, line 16
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.
Cache servers supporting SSH transport MUST accept RSA and DSA
authentication, and SHOULD accept ECDSA authentication. User
authentication MUST be supported; host authentication MAY be
supported. Implementations MAY support password authentication.
Client routers SHOULD verify the public key of the cache, to avoid
monkey-in-the-middle attacks.
7.2. TLS Transport
Client routers using TLS transport MUST use client-side certificates
for authentication. While in principle any type of certificate and
certificate authority may be used, in general cache operators will
generally wish to create their own small-scale CA and issue
certificates to each authorized router. This simplifies credential
roll-over; any unrevoked, unexpired certificate from the proper CA
may be used. If such certificates are used, the CN field [RFC5280]
MUST be used to denote the router's identity.
Clients SHOULD verify the cache's certificate as well, to avoid
monkey-in-the-middle attacks.
7.3. TCP MD5 Transport
If TCP-MD5 is used, implementations MUST support key lengths of at
least 80 printable ASCII bytes, per section 4.5 of [RFC2385].
Implementations MUST also support hexadecimal sequences of at least
32 characters, i.e., 128 bits.
Key rollover with TCP-MD5 is problematic. Cache servers SHOULD
support [RFC4808].
7.4. TCP-AO Transport
Implementations MUST support key lengths of at least 80 printable
ASCII bytes. Implementations MUST also support hexadecimal sequences
of at least 32 characters, i.e., 128 bits. MAC lengths of at least
96 bits MUST be supported, per section 5.3 of [RFC5925].
The cryptographic algorithms and associcated parameters described in
[RFC5926] MUST be supported.
8. 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
skipping to change at page 20, line 30 skipping to change at page 22, line 7
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.
12. IANA Considerations 12. IANA Considerations
This document requests the IANA to create a registry for PDU types. This document requests the IANA to assign TCP Port Numbers to the
The name of the registry should be rpki-rtr-pdu. The policy for RPKI-Router Protocol for the following, see Section 7:
adding to the registry is RFC Required per [RFC5226]. The initial
entries should be as follows: RPKI-Rtr
RPKI-Rtr TLS
This document requests the IANA to create a registry for PDU types 0
to 255. The name of the registry should be rpki-rtr-pdu. The policy
for adding to the registry is RFC Required per [RFC5226], either
standards track or experimental. The initial 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
10 - Error Report 10 - Error Report
255 - Reserved
This document requests the IANA to create a registry for Error Codes. This document requests the IANA to create a registry for Error Codes
The name of the registry should be rpki-rtr-error. The policy for 0 to 255. The name of the registry should be rpki-rtr-error. The
adding to the registry is Expert Review per [RFC5226], where the policy for adding to the registry is Expert Review per [RFC5226],
responsible IESG area director should appoint the Expert Reviewer. where the responsible IESG area director should appoint the Expert
The initial entries should be as follows: Reviewer. The initial entries should be as follows:
0 - Corrupt Data 0 - Corrupt Data
1 - Internal Error 1 - Internal Error
2 - No Data Available 2 - No Data Available
3 - Invalid Request 3 - Invalid Request
4 - Unsupported Protocol Version 4 - Unsupported Protocol Version
5 - Unsupported PDU Type 5 - Unsupported PDU Type
6 - Withdrawal of Unknown Record 6 - Withdrawal of Unknown Record
7 - Duplicate Announcement Received 7 - Duplicate Announcement Received
255 - Reserved
This document requests the IANA to add an SSH Subsystem Name, as This document requests the IANA to add an SSH Connection Protocol
defined in [RFC4250], of 'rpki-rtr'. Subsystem Name, as defined in [RFC4250], of 'rpki-rtr'.
Note to RFC Editor: this section may be replaced on publication as an
RFC.
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Steve Bellovin, Rex Fernando, Russ Housley, The authors wish to thank Steve Bellovin, Rex Fernando, Russ Housley,
Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John
Scudder, Ruediger Volk, and David Ward. Particular thanks go to Scudder, Ruediger Volk, and David Ward. Particular thanks go to
Hannes Gredler for showing us the dangers of unnecessary fields. Hannes Gredler for showing us the dangers of unnecessary fields.
14. References 14. References
skipping to change at page 21, line 43 skipping to change at page 23, line 24
Austein, "BGP Prefix Origin Validation", Austein, "BGP Prefix Origin Validation",
draft-ietf-sidr-pfx-validate-01 (work in progress), draft-ietf-sidr-pfx-validate-01 (work in progress),
February 2011. February 2011.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH)
Protocol Assigned Numbers", RFC 4250, January 2006. Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5",
RFC 4808, March 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926,
June 2010.
14.2. Informative References 14.2. Informative References
[I-D.ietf-sidr-arch] [I-D.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-12 (work in Secure Internet Routing", draft-ietf-sidr-arch-13 (work in
progress), February 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-07 (work in progress), draft-ietf-sidr-repos-struct-08 (work in progress),
February 2011. June 2011.
[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
 End of changes. 32 change blocks. 
80 lines changed or deleted 191 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/