draft-ietf-sidr-rpki-rtr-05.txt   draft-ietf-sidr-rpki-rtr-06.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ Internet-Draft IIJ
Intended status: Standards Track R. Austein Intended status: Standards Track R. Austein
Expires: June 19, 2011 ISC Expires: July 10, 2011 ISC
December 16, 2010 January 6, 2011
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-05 draft-ietf-sidr-rpki-rtr-06
Abstract Abstract
In order to formally validate the origin ASes of BGP announcements, In order to formally validate the origin ASes of BGP announcements,
routers need a simple but reliable mechanism to receive RPKI routers need a simple but reliable mechanism to receive RPKI
[I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted
cache. This document describes a protocol to deliver validated cache. This document describes a protocol to deliver validated
prefix origin data to routers over ssh. prefix origin data to routers over ssh.
Requirements Language Requirements Language
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 19, 2011. This Internet-Draft will expire on July 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 3 2. Deployment Structure . . . . . . . . . . . . . . . . . . . . . 3
3. Operational Overview . . . . . . . . . . . . . . . . . . . . . 3 3. Operational Overview . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 4 4. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 4
4.1. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Cache Response . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Cache Response . . . . . . . . . . . . . . . . . . . . . . 6
4.5. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 8 4.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 8 4.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 9
4.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 9
4.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 9 4.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 9
4.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 10 4.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 10
5. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 11 5.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 12
5.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 12 5.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 13
5.3. No Incremental Update Available . . . . . . . . . . . . . 13 5.3. No Incremental Update Available . . . . . . . . . . . . . 13
5.4. Cache has No Data Available . . . . . . . . . . . . . . . 13 5.4. Cache has No Data Available . . . . . . . . . . . . . . . 14
6. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 6. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 14 7. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 15
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
14.1. Normative References . . . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
In order to formally validate the origin ASes of BGP announcements, In order to formally validate the origin ASes of BGP announcements,
routers need a simple but reliable mechanism to receive RPKI routers need a simple but reliable mechanism to receive RPKI
[I-D.ietf-sidr-arch] or analogous formally validated prefix origin [I-D.ietf-sidr-arch] or analogous formally validated prefix origin
data from a trusted cache. This document describes a protocol to data from a trusted cache. This document describes a protocol to
deliver validated prefix origin data to routers over ssh. deliver validated prefix origin data to routers over ssh.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
cache(s) it uses. cache(s) it uses.
Routers: A router fetches data from a local cache using the protocol Routers: A router fetches data from a local cache using the protocol
described in this document. It is said to be a client of the described in this document. It is said to be a client of the
cache. There are mechanisms for the router to assure itself of cache. There are mechanisms for the router to assure itself of
the authenticity of the cache and to authenticate itself to the the authenticity of the cache and to authenticate itself to the
cache. cache.
3. Operational Overview 3. Operational Overview
A router establishes and keeps open an authenticated connection to a A router establishes and keeps open an authenticated connection to
cache with which it has a client/server relationship. It is one or more caches with which it has client/server relationships. It
configured with a semi-ordered list of caches, and establishes a is configured with a semi-ordered list of caches, and establishes a
connection to the most preferred cache, or set of caches, which connection to the most preferred cache, or set of caches, which
accepts one. accept the connections.
The router MUST choose the most preferred, by configuration, cache or
set of caches so that the operator may control load on their caches
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 record it has received from that cache, i.e.
the router's current serial number. When a router establishes a new the 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'
skipping to change at page 9, line 5 skipping to change at page 9, line 9
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Autonomous System Number | | Autonomous System Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.7. End of Data 4.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
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 | reserved = zero | | Version | Type | Cache Nonce |
| 0 | 7 | | | 0 | 7 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Serial Number | | Serial Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
skipping to change at page 11, line 8 skipping to change at page 11, line 16
Cache Nonce: When a cache server is started, it generates a nonce to Cache Nonce: When a cache server is started, it generates a nonce to
identify the instance of the cache and to bind it to the sequence identify the instance of the cache and to bind it to the sequence
of Serial Numbers that cache instance will generate. This allows of Serial Numbers that cache instance will generate. This allows
the router to restart a failed session knowing that the Serial the router to restart a failed session knowing that the Serial
Number it is using is comensurate with that of the cache. If, at Number it is using is comensurate with that of the cache. If, at
any time, either the router or the cache finds the value of the any time, either the router or the cache finds the value of the
nonces they hold disagree, they MUST completely drop the session nonces they hold disagree, they MUST completely drop the session
and the router MUST flush all data learned from that cache. and the router MUST flush all data learned from that cache.
The nonce might be a pseudo-random, a monotonically increasing
value if the cache has reliable storage, etc. An implementation
which uses a fine granularity of time for the Serial Number might
never change the Cache Nonce.
Length: A 32 bit ordinal which has as its value the count of the Length: A 32 bit ordinal which has as its value the count of the
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-
Len, and ASN. Len, and ASN.
 End of changes. 15 change blocks. 
21 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/