draft-ietf-sidr-rpki-rtr-rfc6810-bis-01.txt   draft-ietf-sidr-rpki-rtr-rfc6810-bis-02.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 6, 2014 Dragon Research Labs Expires: March 2, 2015 Dragon Research Labs
April 4, 2014 August 29, 2014
The Resource Public Key Infrastructure (RPKI) to Router Protocol The Resource Public Key Infrastructure (RPKI) to Router Protocol
draft-ietf-sidr-rpki-rtr-rfc6810-bis-01 draft-ietf-sidr-rpki-rtr-rfc6810-bis-02
Abstract Abstract
In order to verifiably validate the origin Autonomous Systems of BGP In order to verifiably validate the origin Autonomous Systems and
announcements, routers need a simple but reliable mechanism to Autonomous System Paths of BGP announcements, routers need a simple
receive Resource Public Key Infrastructure (RFC 6480) prefix origin but reliable mechanism to receive Resource Public Key Infrastructure
data from a trusted cache. This document describes a protocol to (RFC 6480) prefix origin data and router keys from a trusted cache.
deliver validated prefix origin data to routers. This document describes a protocol to deliver validated prefix origin
data and router keys to routers.
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 6, 2014. This Internet-Draft will expire on March 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 4 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 4
4. Operational Overview . . . . . . . . . . . . . . . . . . . . 4 4. Operational Overview . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 5 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 5
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 9 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 9
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 9 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 9
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 10 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 11 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 12
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 12 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 12
5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 13 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 13
5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 14 5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 14
6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 15 6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 15
7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 16 7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 16
8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 17 8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 17
8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 17 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 17
8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 18 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 18
8.3. No Incremental Update Available . . . . . . . . . . . . . 18 8.3. No Incremental Update Available . . . . . . . . . . . . . 18
8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 19 8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 19
skipping to change at page 2, line 46 skipping to change at page 2, line 46
9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 22 9.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 22
9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 23 9.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . 23
10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 23 10. Router-Cache Setup . . . . . . . . . . . . . . . . . . . . . 23
11. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 24 11. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 24
12. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
16.1. Normative References . . . . . . . . . . . . . . . . . . 28 16.1. Normative References . . . . . . . . . . . . . . . . . . 28
16.2. Informative References . . . . . . . . . . . . . . . . . 29 16.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
In order to verifiably validate the origin Autonomous Systems (ASes) In order to verifiably validate the origin Autonomous Systems (ASes)
of BGP announcements, routers need a simple but reliable mechanism to and AS paths of BGP announcements, routers need a simple but reliable
receive Resource Public Key Infrastructure (RPKI) [RFC6480] mechanism to receive cryptographically validated Resource Public Key
cryptographically validated prefix origin data from a trusted cache. Infrastructure (RPKI) [RFC6480] prefix origin data and router keys
This document describes a protocol to deliver validated prefix origin from a trusted cache. This document describes a protocol to deliver
data to routers. The design is intentionally constrained to be validated prefix origin data and router keys to routers. The design
usable on much of the current generation of ISP router platforms. 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 8. The transport protocol options sequences are described in Section 8. The transport protocol options
are described in Section 9. Section 10 details how routers and are described in Section 9. Section 10 details how routers and
caches are configured to connect and authenticate. Section 11 caches are configured to connect and authenticate. Section 11
describes likely deployment scenarios. The traditional security and describes likely deployment scenarios. The traditional security and
IANA considerations end the document. IANA considerations end the document.
The protocol is extensible in order to support new PDUs with new The protocol is extensible in order to support new PDUs with new
semantics, if deployment experience indicates they are needed. PDUs semantics, if deployment experience indicates they are needed. PDUs
are versioned should deployment experience call for change. are versioned should deployment experience call for change.
For an implementation (not interoperability) report, see For an implementation (not interoperability) report on use of this
[I-D.ietf-sidr-rpki-rtr-impl] protocol with prefix origin data, see [RFC7128].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] document are to be interpreted as described in RFC 2119 [RFC2119]
only when they appear in all upper case. They may also appear in only when they appear in all upper case. They may also appear in
lower or mixed case as English words, without special meaning. lower or mixed case as English words, without special meaning.
2. Glossary 2. Glossary
skipping to change at page 7, line 36 skipping to change at page 7, line 36
Prefix Length: An 8-bit unsigned integer denoting the shortest Prefix Length: An 8-bit unsigned integer denoting the shortest
prefix allowed for the prefix. prefix allowed for the prefix.
Max Length: An 8-bit unsigned integer denoting the longest prefix Max Length: An 8-bit unsigned integer denoting the longest prefix
allowed by the prefix. This MUST NOT be less than the Prefix allowed by the prefix. This MUST NOT be less than the Prefix
Length element. 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 Autonomous System Number: A 32-bit unsigned integer representing an
32-bit unsigned integer. ASN allowed to announce a prefix or associated with a router key.
Subject Key Identifier: 20-octet Subject Key Identifier (SKI) value
of a router key, as described in [RFC6487].
Subject Public Key Info: a router key's subjectPublicKeyInfo value,
as described in [I-D.ietf-sidr-bgpsec-algs]. This is the full
ASN.1 DER encoding of the subjectPublicKeyInfo, including the
ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE.
Zero: Fields shown as zero or reserved MUST be zero. The value of Zero: Fields shown as zero or reserved MUST be zero. The value of
such a field MUST be ignored on receipt. such a field MUST be ignored on receipt.
5.2. Serial Notify 5.2. 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 Session ID 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.
skipping to change at page 13, line 42 skipping to change at page 13, line 42
+-------------------------------------------+ +-------------------------------------------+
| | | |
| AS Number | | AS Number |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Subject Public Key Info | | Subject Public Key Info |
| | | |
`-------------------------------------------' `-------------------------------------------'
In addition to the normal boilerplate fields of an RPKI-Router PDU,
the Router Key PDU has the following fields.
Subject Key Identifier is the 20-octet subjectKeyIdentifier (SKI)
value for the Router Key, as described in [RFC6487].
AS Number one Autonomous System Number.
Subject Public Key Info is the Router Key's subjectPublicKeyInfo as
described in [I-D.ietf-sidr-bgpsec-algs]. This is the full ASN.1
DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag
and length values of the subjectPublicKeyInfo SEQUENCE.
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 Router Key PDU for a unique {SKI, ASN, Subject have one and only one Router Key PDU for a unique {SKI, ASN, Subject
Public Key} at any one point in time. Should the router client Public Key} at any one point in time. Should the router client
receive a Router Key PDU with a {SKI, ASN, Subject Public Key} receive a Router Key PDU with a {SKI, ASN, Subject Public Key}
identical to one it already has active, it SHOULD raise a Duplicate identical to one it already has active, it SHOULD raise a Duplicate
Announcement Received error. Announcement Received error.
Note that a particular ASN may appear in multiple Router Key PDUs Note that a particular ASN may appear in multiple Router Key PDUs
with different Subject Public Key values, while a particular Subject with different Subject Public Key values, while a particular Subject
Public Key value may appear in multiple Router Key PDUs with Public Key value may appear in multiple Router Key PDUs with
skipping to change at page 15, line 43 skipping to change at page 15, line 43
6. Protocol Timing Parameters 6. Protocol Timing Parameters
Since the data the cache distributes via the rpki-rtr protocol are Since the data the cache distributes via the rpki-rtr protocol are
retrieved from the Global RPKI system at intervals which are only retrieved from the Global RPKI system at intervals which are only
known to the cache, only the cache can really know how frequently it known to the cache, only the cache can really know how frequently it
makes sense for the router to poll the cache, or how long the data makes sense for the router to poll the cache, or how long the data
are likely to remain valid (or, at least, unchanged). For this are likely to remain valid (or, at least, unchanged). For this
reason, as well as to allow the cache some control over the load reason, as well as to allow the cache some control over the load
placed on it by its client routers, the End Of Data PDU includes placed on it by its client routers, the End Of Data PDU includes
three values that allow the router to communicate timing parameters three values that allow the cache to communicate timing parameters to
to the router. the router.
Refresh Interval: This parameter tells the router how long to wait Refresh Interval: This parameter tells the router how long to wait
before next attempting to poll the cache, using a Serial Query or before next attempting to poll the cache, using a Serial Query or
Reset Query PDU. Note that receipt of a Serial Notify PDU Reset Query PDU. The router SHOULD NOT poll the cache sooner than
overrides this interval and allows the router to issue an indicated by this parameter. Note that receipt of a Serial Notify
PDU overrides this interval and allows the router to issue an
immediate query without waiting for the Refresh Interval to immediate query without waiting for the Refresh Interval to
expire. Countdown for this timer starts upon receipt of the expire. Countdown for this timer starts upon receipt of the
containing End Of Data PDU. containing End Of Data PDU.
Minimum allowed value: 120 seconds (two minutes). Minimum allowed value: 1 second.
Maximum allowed value: 86400 seconds (one day). Maximum allowed value: 86400 seconds (one day).
Recommended default: 3600 seconds (one hour). Recommended default: 3600 seconds (one hour).
Retry Interval: This parameter tells the router how long to wait Retry Interval: This parameter tells the router how long to wait
before retrying a failed Serial Query or Reset Query. Countdown before retrying a failed Serial Query or Reset Query. The router
for this timer starts upon failure of the query, and restarts SHOULD NOT retry sooner than indicated by this parameter.
after each subsequent failure until a query succeeds. Countdown for this timer starts upon failure of the query, and
restarts after each subsequent failure until a query succeeds.
Minimum allowed value: 120 seconds (two minutes). Minimum allowed value: 1 second.
Maximum allowed value: 7200 seconds (two hours). Maximum allowed value: 7200 seconds (two hours).
Recommended default: 600 seconds (ten minutes). Recommended default: 600 seconds (ten minutes).
Expire Interval: This parameter tells the router how long it can Expire Interval: This parameter tells the router how long it can
continue to use the current version of the data while unable to continue to use the current version of the data while unable to
perform a sucessful query. Countdown for this timer starts upon perform a successful query. The router MUST NOT retain the data
receipt of the containing End Of Data PDU. past the time indicated by this parameter. Countdown for this
timer starts upon receipt of the containing End Of Data PDU.
Minimum allowed value: 600 seconds (ten minutes). Minimum allowed value: 600 seconds (ten minutes).
Maximum allowed value: 172800 seconds (two days). Maximum allowed value: 172800 seconds (two days).
Recommended default: 7200 seconds (two hours). Recommended default: 7200 seconds (two hours).
If the router has never issued a succesful query against a particular If the router has never issued a successful query against a
cache, it retry periodically using the default Retry Interval, above. particular cache, it SHOULD retry periodically using the default
Retry Interval, above.
7. Protocol Version Negotiation 7. Protocol Version Negotiation
A router MUST start each transport session by issuing either a Reset A router MUST start each transport session by issuing either a Reset
Query or a Serial Query. This query will tell the cache which Query or a Serial Query. This query will tell the cache which
version of this protocol the router implements. version of this protocol the router implements.
If a cache which supports version 1 receieves a query from a router If a cache which supports version 1 receives a query from a router
which specifies version 0, the cache MUST downgrade to protocol which specifies version 0, the cache MUST downgrade to protocol
version 0 [RFC6810] or terminate the session. version 0 [RFC6810] or terminate the session.
If a router which supports version 1 sends a query to a cache which If a router which supports version 1 sends a query to a cache which
only supports version 0, one of two things will happen. only supports version 0, one of two things will happen.
1. The cache may terminate the connection, perhaps with a version 0 1. The cache may terminate the connection, perhaps with a version 0
Error Report PDU. In this case the router MAY retry the Error Report PDU. In this case the router MAY retry the
connection using protocol version 0. connection using protocol version 0.
skipping to change at page 17, line 24 skipping to change at page 17, line 31
The sequences of PDU transmissions fall into three conversations as The sequences of PDU transmissions fall into three conversations as
follows: follows:
8.1. Start or Restart 8.1. Start or Restart
Cache Router Cache Router
~ ~ ~ ~
| <----- Reset Query -------- | R requests data (or Serial Query) | <----- Reset Query -------- | R requests data (or Serial Query)
| | | |
| ----- Cache Response -----> | C confirms request | ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more | ------- Payload PDU ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- IPvX Prefix ------> | Payload PDUs | ------- Payload PDU ------> | or Router Key PDUs
| ------ End of Data ------> | C sends End of Data | ------ End of Data ------> | C sends End of Data
| | and sends new serial | | and sends new serial
~ ~ ~ ~
When a transport session is first established, the router MAY send a When a transport session is first established, the router MAY send a
Reset Query and the cache responds with a data sequence of all data Reset Query and the cache responds with a data sequence of all data
it contains. it contains.
Alternatively, if the router has significant unexpired data from a Alternatively, if the router has significant unexpired data from a
broken session with the same cache, it MAY start with a Serial Query broken session with the same cache, it MAY start with a Serial Query
skipping to change at page 18, line 16 skipping to change at page 18, line 22
8.2. Typical Exchange 8.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 | ------- Payload PDU ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- IPvX Prefix ------> | Payload PDUs | ------- Payload PDU ------> | or Router Key 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 MUST 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 periodially. See MUST send either a Serial Query or a Reset Query periodically. See
Section 6 for details on the required polling frequency. Section 6 for details on the required polling frequency.
8.3. No Incremental Update Available 8.3. No Incremental Update Available
Cache Router Cache Router
~ ~ ~ ~
| <----- Serial Query ------ | R requests data | <----- Serial Query ------ | R requests data
| ------- Cache Reset ------> | C cannot supply update | ------- Cache Reset ------> | C cannot supply update
| | from specified serial | | from specified serial
| <------ Reset Query ------- | R requests new data | <------ Reset Query ------- | R requests new data
| ----- Cache Response -----> | C confirms request | ----- Cache Response -----> | C confirms request
| ------- IPvX Prefix ------> | C sends zero or more | ------- Payload PDU ------> | C sends zero or more
| ------- IPvX Prefix ------> | IPv4 and IPv6 Prefix | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- IPvX Prefix ------> | Payload PDUs | ------- Payload PDU ------> | or Router Key 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 may respond to a Serial Query with a Cache Reset, informing The cache may respond to a Serial Query with a Cache Reset, informing
the router that the cache cannot supply an incremental update from the router that the cache cannot supply an incremental update from
the Serial Number specified by the router. This might be because the the Serial Number specified by the router. This might be because the
cache has lost state, or because the router has waited too long cache has lost state, or because the router has waited too long
between polls and the cache has cleaned up old data that it no longer between polls and the cache has cleaned up old data that it no longer
believes it needs, or because the cache has run out of storage space believes it needs, or because the cache has run out of storage space
skipping to change at page 23, line 16 skipping to change at page 23, line 16
support [RFC4808]. support [RFC4808].
9.4. TCP-AO Transport 9.4. TCP-AO Transport
Implementations MUST support key lengths of at least 80 printable Implementations MUST support key lengths of at least 80 printable
ASCII bytes. Implementations MUST also support hexadecimal sequences ASCII bytes. Implementations MUST also support hexadecimal sequences
of at least 32 characters, i.e., 128 bits. Message Authentication of at least 32 characters, i.e., 128 bits. Message Authentication
Code (MAC) lengths of at least 96 bits MUST be supported, per Code (MAC) lengths of at least 96 bits MUST be supported, per
Section 5.1 of [RFC5925]. Section 5.1 of [RFC5925].
The cryptographic algorithms and associcated parameters described in The cryptographic algorithms and associated parameters described in
[RFC5926] MUST be supported. [RFC5926] MUST be supported.
10. Router-Cache Setup 10. Router-Cache Setup
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
skipping to change at page 28, line 25 skipping to change at page 28, line 25
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 255 Reserved
IANA has added an SSH Connection Protocol Subsystem Name, as defined IANA has added an SSH Connection Protocol Subsystem Name, as defined
in [RFC4250], of "rpki-rtr". in [RFC4250], of "rpki-rtr".
15. Acknowledgments 15. Acknowledgments
The authors wish to thank Steve Bellovin, Tim Bruijnzeels, Rex The authors wish to thank Nils Bars, Steve Bellovin, Tim Bruijnzeels,
Fernando, Paul Hoffman, Russ Housley, Pradosh Mohapatra, Keyur Patel, Rex Fernando, Paul Hoffman, Fabian Holler, Russ Housley, Pradosh
David Mandelberg, Sandy Murphy, Robert Raszuk, John Scudder, Ruediger Mohapatra, Keyur Patel, David Mandelberg, Sandy Murphy, Robert
Raszuk, Andreas Reuter, Thomas C. Schmidt, John Scudder, Ruediger
Volk, Matthias Waehlisch, and David Ward. Particular thanks go to Volk, Matthias Waehlisch, 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.
16. References 16. References
16.1. Normative References 16.1. Normative References
[I-D.ietf-sidr-bgpsec-algs] [I-D.ietf-sidr-bgpsec-algs]
Turner, S., "BGP Algorithms, Key Formats, & Signature Turner, S., "BGP Algorithms, Key Formats, & Signature
Formats", draft-ietf-sidr-bgpsec-algs-06 (work in Formats", draft-ietf-sidr-bgpsec-algs-08 (work in
progress), March 2014. progress), July 2014.
[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", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
skipping to change at page 29, line 48 skipping to change at page 30, line 7
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key [RFC6810] Bush, R. and R. Austein, "The Resource Public Key
Infrastructure (RPKI) to Router Protocol", RFC 6810, Infrastructure (RPKI) to Router Protocol", RFC 6810,
January 2013. January 2013.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, January Austein, "BGP Prefix Origin Validation", RFC 6811, January
2013. 2013.
16.2. Informative References 16.2. Informative References
[I-D.ietf-sidr-rpki-rtr-impl]
Bush, R., Austein, R., Patel, K., Gredler, H., and M.
Waehlisch, "RPKI Router Implementation Report", draft-
ietf-sidr-rpki-rtr-impl-05 (work in progress), December
2013.
[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", RFC [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC
4808, March 2007. 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.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
February 2012. February 2012.
[RFC7128] Bush, R., Austein, R., Patel, K., Gredler, H., and M.
Waehlisch, "Resource Public Key Infrastructure (RPKI)
Router Implementation Report", RFC 7128, February 2014.
Authors' Addresses Authors' Addresses
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
US US
Phone: +1 206 780 0431 x1 Phone: +1 206 780 0431 x1
Email: randy@psg.com Email: randy@psg.com
 End of changes. 28 change blocks. 
71 lines changed or deleted 71 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/