draft-ietf-sidr-rpki-rtr-rfc6810-bis-04.txt   draft-ietf-sidr-rpki-rtr-rfc6810-bis-05.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Updates: 6810 (if approved) R. Austein Updates: 6810 (if approved) R. Austein
Intended status: Standards Track Dragon Research Labs Intended status: Standards Track Dragon Research Labs
Expires: December 17, 2015 June 15, 2015 Expires: February 1, 2016 July 31, 2015
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-04 draft-ietf-sidr-rpki-rtr-rfc6810-bis-05
Abstract Abstract
In order to verifiably validate the origin Autonomous Systems and In order to verifiably validate the origin Autonomous Systems and
Autonomous System Paths of BGP announcements, routers need a simple Autonomous System Paths of BGP announcements, routers need a simple
but reliable mechanism to receive Resource Public Key Infrastructure but reliable mechanism to receive Resource Public Key Infrastructure
(RFC 6480) prefix origin data and router keys from a trusted cache. (RFC 6480) prefix origin data and router keys from a trusted cache.
This document describes a protocol to deliver validated prefix origin This document describes a protocol to deliver validated prefix origin
data and router keys to routers. data and router keys to routers.
This document describes version 1 of the rpki-rtr protocol.
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 December 17, 2015. This Internet-Draft will expire on February 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 22 skipping to change at page 2, line 24
3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 4 3. Deployment Structure . . . . . . . . . . . . . . . . . . . . 4
4. Operational Overview . . . . . . . . . . . . . . . . . . . . 5 4. Operational Overview . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 6 5. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . 6
5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6 5.1. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 6
5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Serial Query . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 10 5.5. Cache Response . . . . . . . . . . . . . . . . . . . . . 10
5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11 5.6. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 11
5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 12 5.7. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 12
5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 12 5.8. End of Data . . . . . . . . . . . . . . . . . . . . . . . 13
5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 13 5.9. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 14
5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 14 5.10. Router Key . . . . . . . . . . . . . . . . . . . . . . . 14
5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 15 5.11. Error Report . . . . . . . . . . . . . . . . . . . . . . 15
6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 16 6. Protocol Timing Parameters . . . . . . . . . . . . . . . . . 16
7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 17 7. Protocol Version Negotiation . . . . . . . . . . . . . . . . 17
8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 19 8. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . 19
8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 19 8.1. Start or Restart . . . . . . . . . . . . . . . . . . . . 19
8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 20 8.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . 20
8.3. No Incremental Update Available . . . . . . . . . . . . . 20 8.3. No Incremental Update Available . . . . . . . . . . . . . 20
8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 21 8.4. Cache Has No Data Available . . . . . . . . . . . . . . . 21
9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 21
skipping to change at page 3, line 18 skipping to change at page 3, line 18
and AS paths of BGP announcements, routers need a simple but reliable and AS paths of BGP announcements, routers need a simple but reliable
mechanism to receive cryptographically validated Resource Public Key mechanism to receive cryptographically validated Resource Public Key
Infrastructure (RPKI) [RFC6480] prefix origin data and router keys Infrastructure (RPKI) [RFC6480] prefix origin data and router keys
from a trusted cache. This document describes a protocol to deliver from a trusted cache. This document describes a protocol to deliver
validated prefix origin data and router keys to routers. The design validated prefix origin data and router keys to routers. The design
is intentionally constrained to be usable on much of the current is intentionally constrained to be usable on much of the current
generation of ISP router platforms. 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
sequences are described in Section 8. The transport protocol options Protocol Data Unit (PDU) sequences are described in Section 8. The
are described in Section 9. Section 10 details how routers and transport protocol options are described in Section 9. Section 10
caches are configured to connect and authenticate. Section 11 details how routers and caches are configured to connect and
describes likely deployment scenarios. The traditional security and authenticate. Section 11 describes likely deployment scenarios. The
IANA considerations end the document. traditional security and 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 on the use of For an implementation (not interoperability) report on the use of
this protocol with prefix origin data, see [RFC7128]. this protocol with prefix origin data, see [RFC7128].
1.1. Requirements Language 1.1. Requirements Language
skipping to change at page 4, line 18 skipping to change at page 4, line 18
wraps from 2^32-1 to 0. It denotes the logical version of a wraps from 2^32-1 to 0. It denotes the logical version of a
cache. A cache increments the value when it successfully updates cache. A cache increments the value when it successfully updates
its data from a parent cache or from primary RPKI data. While a its data from a parent cache or from primary RPKI data. While a
cache is receiving updates, new incoming data and implicit deletes cache is receiving updates, new incoming data and implicit deletes
are associated with the new serial but MUST NOT be sent until the are associated with the new serial but MUST NOT be sent until the
fetch is complete. A Serial Number is not commensurate between fetch is complete. A Serial Number is not commensurate between
different caches or different protocol versions, nor need it be different caches or different protocol versions, 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 the topic. DNS Serial Number Arithmetic for too much detail on the topic.
Session ID: When a cache server is started, it generates a session Session ID: When a cache server is started, it generates a Session
identifier to uniquely identify the instance of the cache and to ID to uniquely identify the instance of the cache and to bind it
bind it to the sequence of Serial Numbers that cache instance will to the sequence of Serial Numbers that cache instance will
generate. This allows the router to restart a failed session generate. This allows the router to restart a failed session
knowing that the Serial Number it is using is commensurate with knowing that the Serial Number it is using is commensurate with
that of the cache. that of the cache.
Payload PDU: A protocol message which contains data for use by the Payload PDU: A protocol message which contains data for use by the
router, as opposed to a PDU which just conveys the semantics of router, as opposed to a PDU which just conveys the semantics of
this protocol. Prefixes and Router Keys are examples of payload this protocol. Prefixes and Router Keys are examples of payload
PDUs. PDUs.
3. Deployment Structure 3. Deployment Structure
skipping to change at page 5, line 17 skipping to change at page 5, line 17
A router establishes and keeps open a connection to one or more A router establishes and keeps open a connection to one or more
caches with which it has client/server relationships. It is caches with which it has client/server relationships. It 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 most recent Serial
highest numbered data it has received from that cache, i.e., the Number for which it has has received data from that cache, i.e., the
router's current Serial Number, in the form of a Serial Query. When router's current Serial Number, in the form of a Serial Query. When
a router establishes a new connection to a cache, or wishes to reset a router establishes a new session with a cache, or wishes to reset a
a current relationship, it sends a Reset Query. current relationship, it sends a Reset Query.
The cache responds to the Serial Query with all data records which The cache responds to the Serial Query with all data changes which
have Serial Numbers greater than that in the router's query. This took place since the given Serial Number. This may be the null set,
may be the null set, in which case the End of Data PDU is still sent. in which case the End of Data PDU is still sent. Note that the
Note that "greater" MUST take wrap-around into account, see Serial Number comparison used to determine "since the given Serial
[RFC1982]. Number" 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
Data PDU. Data PDU.
When the cache updates its database, it sends a Notify message to When the cache updates its database, it sends a Notify message to
every currently connected router. This is a hint that now would be a every currently connected router. This is a hint that now would be a
good time for the router to poll for an update, but is only a hint. good time for the router to poll for an update, but is only a hint.
The protocol requires the router to poll for updates periodically in The protocol requires the router to poll for updates periodically in
any case. any case.
skipping to change at page 6, line 39 skipping to change at page 6, line 39
PDUs was received from an upstream cache server or gathered from PDUs was received from an upstream 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 a rigorously validated update from a parent cache or completing a rigorously validated update from a parent cache or
the Global RPKI. the Global RPKI.
Session ID: A 16-bit unsigned integer. When a cache server is Session ID: A 16-bit unsigned integer. When a cache server is
started, it generates a Session ID to identify the instance of the started, it generates a Session ID to identify the instance of the
cache and to bind it to the sequence of Serial Numbers that cache cache and to bind it to the sequence of Serial Numbers that cache
instance will generate. This allows the router to restart a instance will generate. This allows the router to restart a
failed session knowing that the Serial Number it is using is failed session knowing that the Serial Number it is using is
commensurate with that of the cache. If, at any time, either the commensurate with that of the cache. If, at any time after the
router or the cache finds the value of the session identifier is protocol version has been negotiated (Section 7), either the
not the same as the other's, they MUST completely drop the session router or the cache finds the value of the Session ID is not the
and the router MUST flush all data learned from that cache. same as the other's, the party which detects the mismatch MUST
immediately terminate the session with an Error Report PDU with
code 0 ("Corrupt Data"), and the router MUST flush all data
learned from that cache.
Note that sessions are specific to a particular protocol version. Note that sessions are specific to a particular protocol version.
That is: if a cache server supports multiple versions of this That is: if a cache server supports multiple versions of this
protocol, happens to use the same Session ID value for multiple protocol, happens to use the same Session ID value for multiple
protocol versions, and further happens to use the same Serial protocol versions, and further happens to use the same Serial
Number values for two or more sessions using the same Session ID Number values for two or more sessions using the same Session ID
but different Protocol Version values, the serial numbers are not but different Protocol Version values, the serial numbers are not
commensurate. The full test for whether serial numbers are commensurate. The full test for whether serial numbers are
commensurate requires comparing Protocol Version, Session ID, and commensurate requires comparing Protocol Version, Session ID, and
Serial Number. To reduce the risk of confusion, cache servers Serial Number. To reduce the risk of confusion, cache servers
skipping to change at page 7, line 29 skipping to change at page 7, line 32
the router into sync. In such cases, it's likely but not certain the router into sync. In such cases, it's likely but not certain
that the router will detect some discrepancy between the state that the router will detect some discrepancy between the state
that the cache expects and its own state. For example, the Cache that the cache expects and its own state. For example, the Cache
Response may tell the router to drop a record which the router Response may tell the router to drop a record which the router
does not hold, or may tell the router to add a record which the does not hold, or may tell the router to add a record which the
router already has. In such cases, a router will detect the error router already has. In such cases, a router will detect the error
and reset the session. The one case in which the router may stay and reset the session. The one case in which the router may stay
out of sync is when nothing in the Cache Response contradicts any out of sync is when nothing in the Cache Response contradicts any
data currently held by the router. data currently held by the router.
Using persistent storage for the session identifier or a clock- Using persistent storage for the Session ID or a clock-based
based scheme for generating session identifiers should avoid the scheme for generating Session IDs should avoid the risk of Session
risk of session identifier collisions. ID collisions.
The Session ID might be a pseudo-random value, a strictly The Session ID might be a pseudo-random value, a strictly
increasing value if the cache has reliable storage, etc. increasing value if the cache has reliable storage, etc.
Length: A 32-bit unsigned integer which has as its value the count Length: A 32-bit unsigned integer which has as its value the count
of the bytes in the entire PDU, including the eight bytes of of the bytes in the entire PDU, including the eight bytes of
header which end with the length field. header which end with the length field.
Flags: The lowest order bit of the Flags field is 1 for an Flags: The lowest order bit of the Flags field is 1 for an
announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or announcement and 0 for a withdrawal. For a Prefix PDU (IPv4 or
skipping to change at page 8, line 40 skipping to change at page 8, line 42
of such a field SHOULD be ignored on receipt. of such a field SHOULD 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.
Upon receipt of a Serial Notify PDU, the router MAY issue an Upon receipt of a Serial Notify PDU, the router MAY issue an
immediate Serial Query or Reset Query without waiting for the Refresh immediate Serial Query (Section 5.3) or Reset Query (Section 5.4)
Interval timer (see Section 6) to expire. without waiting for the Refresh Interval timer (see Section 6) to
expire.
Serial Notify is the only message that the cache can send that is not Serial Notify is the only message that the cache can send that is not
in response to a message from the router. in response to a message from the router.
If the router receives a Serial Notify PDU during the initial start- If the router receives a Serial Notify PDU during the initial start-
up period where the router and cache are still negotiating to agree up period where the router and cache are still negotiating to agree
on a protocol version, the router SHOULD simply ignore the Serial on a protocol version, the router SHOULD simply ignore the Serial
Notify PDU, even if the Serial Notify PDU is for an unexpected Notify PDU, even if the Serial Notify PDU is for an unexpected
protocol version. See Section 7 for details. protocol version. See Section 7 for details.
skipping to change at page 9, line 22 skipping to change at page 9, line 24
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Serial Number | | Serial Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
5.3. Serial Query 5.3. Serial Query
Serial Query: The router sends Serial Query to ask the cache for all The router sends Serial Query to ask the cache for all announcements
all announcements and withdrawals which have occurred since the and withdrawals which have occurred since the Serial Number specified
Serial Number specified in the Serial Query. in the Serial Query.
The cache replies to this query with a Cache Response PDU The cache replies to this query with a Cache Response PDU
(Section 5.5) if the cache has a, possibly null, record of the (Section 5.5) if the cache has a, possibly null, record of the
changes since the Serial Number specified by the router, followed by changes since the Serial Number specified by the router, followed by
zero or more payload PDUs and an End Of Data PDU. zero or more payload PDUs and an End Of Data PDU (Section 5.8).
When replying to a Serial Query, the cache MUST return the minimum
set of changes needed to bring the router into sync with the cache.
That is, if a particular prefix or router key underwent multiple
changes between the Serial Number specified by the router and the
cache's current Serial Number, the cache MUST merge those changes to
present the simplest possible view of those changes to the router.
In general, this means that, for any particular prefix or router key,
the data stream will include at most one withdrawal followed by at
most one announcement, and if all of the changes cancel out, the data
stream will not mention the prefix or router key at all.
The rationale for this approach is that the entire purpose of the
rpki-rtr protocol is to offload work from the router to the cache,
and it should therefore be the cache's job to simplify the change
set, thus reducing work for the router.
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.9). (Section 5.9).
The Session ID 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.
skipping to change at page 10, line 22 skipping to change at page 10, line 28
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Serial Number | | Serial Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
5.4. Reset Query 5.4. Reset Query
Reset Query: The router tells the cache that it wants to receive the The router tells the cache that it wants to receive the total active,
total active, current, non-withdrawn database. The cache responds current, non-withdrawn database. The cache responds with a Cache
with a Cache Response PDU (Section 5.5). Response PDU (Section 5.5), followed by zero or more payload PDUs and
an End of Data PDU (Section 5.8).
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | zero | | Version | Type | zero |
| 1 | 2 | | | 1 | 2 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=8 | | Length=8 |
| | | |
`-------------------------------------------' `-------------------------------------------'
5.5. Cache Response 5.5. Cache Response
The cache responds with zero or more payload PDUs. When replying to The cache responds to queries with zero or more payload PDUs. When
a Serial Query request (Section 5.3), the cache sends the set of replying to a Serial Query (Section 5.3), the cache sends the set of
announcements and withdrawals that have occurred since the Serial announcements and withdrawals that have occurred since the Serial
Number sent by the client router. When replying to a Reset Query, Number 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 (Section 5.4), the cache sends the set of all data records it has; in
withdraw/announce field in the payload PDUs MUST have the value 1 this case, the withdraw/announce field in the payload PDUs MUST have
(announce). the value 1 (announce).
In response to a Reset Query, the new value of the Session ID tells In response to a Reset Query, the new value of the Session ID tells
the router the instance of the cache session for future confirmation. the router the instance of the cache session for future confirmation.
In response to a Serial Query, the Session ID being the same In response to a Serial Query, the Session ID being the same
reassures the router that the Serial Numbers are commensurate, i.e., reassures the router that the Serial Numbers are commensurate, i.e.,
the cache session has not changed. the cache session has not changed.
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
skipping to change at page 12, line 42 skipping to change at page 13, line 4
| | | |
+--- IPv6 Prefix ---+ +--- IPv6 Prefix ---+
| | | |
+--- ---+ +--- ---+
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Autonomous System Number | | Autonomous System Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic. Analogous to the IPv4 Prefix PDU, it has 96 more bits and no magic.
5.8. End of Data 5.8. End of Data
End of Data: The cache tells the router it has no more data for the The cache tells the router it has no more data for the request.
request.
The Session ID and Protocol Version MUST be the same as that of the The Session ID and Protocol Version MUST be the same as that of the
corresponding Cache Response which began the, possibly null, sequence corresponding Cache Response which began the, possibly null, sequence
of data PDUs. of payload PDUs.
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | Session ID | | Version | Type | Session ID |
| 1 | 7 | | | 1 | 7 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=24 | | Length=24 |
| | | |
skipping to change at page 17, line 46 skipping to change at page 17, line 46
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 successful query against a If the router has never issued a successful query against a
particular cache, it SHOULD retry periodically using the default particular cache, it SHOULD retry periodically using the default
Retry Interval, above. 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 connection by issuing either a
Query or a Serial Query. This query will tell the cache which Reset 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 receives 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 send a version 1 Error Report PDU with Error
Code 4 ("Unsupported Protocol Version") and terminate the connection.
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.
2. The cache may reply with a version 0 response. In this case the 2. The cache may reply with a version 0 response. In this case the
router MUST either downgrade to version 0 or terminate the router MUST either downgrade to version 0 or terminate the
skipping to change at page 18, line 42 skipping to change at page 18, line 40
and Serial Number values are specific to a particular protocol and Serial Number values are specific to a particular protocol
version, the values in the notification are not useful to the router. version, the values in the notification are not useful to the router.
Even if these values were meaningful, the only effect that processing Even if these values were meaningful, the only effect that processing
the notification would have would be to trigger exactly the same the notification would have would be to trigger exactly the same
Reset Query or Serial Query that the router has already sent as part Reset Query or Serial Query that the router has already sent as part
of the not-yet-complete version negotiation process, so there is of the not-yet-complete version negotiation process, so there is
nothing to be gained by processing notifications until version nothing to be gained by processing notifications until version
negotiation completes. negotiation completes.
Caches SHOULD NOT send Serial Notify PDUs before version negotiation Caches SHOULD NOT send Serial Notify PDUs before version negotiation
completes. Note, however, that routers must handle such completes. Note, however, that routers MUST handle such
notifications (by ignoring them) for backwards compatibility with notifications (by ignoring them) for backwards compatibility with
caches serving protocol version 0. caches serving protocol version 0.
Once the cache and router have agreed upon a Protocol Version via the Once the cache and router have agreed upon a Protocol Version via the
negotiation process above, that version is stable for the life of the negotiation process above, that version is stable for the life of the
session. See Section 5.1 for a discussion of the interaction between session. See Section 5.1 for a discussion of the interaction between
Protocol Version and Session ID. Protocol Version and Session ID.
If either party receives a PDU for a different Protocol Version once If either party receives a PDU for a different Protocol Version once
the above negotiation completes, that party MUST drop the session; the above negotiation completes, that party MUST drop the session;
skipping to change at page 19, line 23 skipping to change at page 19, line 22
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
| ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key 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 connection is first established, the router MAY send
Reset Query and the cache responds with a data sequence of all data a 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 Session ID 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.
The router MUST send either a Reset Query or a Serial Query when The router MUST send either a Reset Query or a Serial Query when
starting a transport session, in order to confirm that router and starting a transport connection, in order to confirm that router and
cache are speaking compatible versions of the protocol. See cache are speaking compatible versions of the protocol. See
Section 7 for details on version negotiation. Section 7 for details on version negotiation.
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 periodically. This also acts as a keep-alive Query or a Reset Query periodically. This also acts as a keep-alive
at the application layer. See Section 6 for details on the required at the application layer. See Section 6 for details on the required
polling frequency. polling frequency.
8.2. Typical Exchange 8.2. Typical Exchange
skipping to change at page 20, line 17 skipping to change at page 20, line 17
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
| ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key 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
skipping to change at page 20, line 48 skipping to change at page 20, line 48
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
| ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | C sends zero or more
| ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix,
| ------- Payload PDU ------> | or Router Key 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
and had to expire some old data early. Regardless of how this state and had to expire some old data early. Regardless of how this state
skipping to change at page 28, line 17 skipping to change at page 28, line 17
As this document describes a security protocol, many aspects of As this document describes a security protocol, many aspects of
security interest are described in the relevant sections. This security interest are described in the relevant sections. This
section points out issues which may not be obvious in other sections. section points out issues which may not be obvious in other sections.
Cache Validation: In order for a collection of caches as described Cache Validation: In order for a collection of caches as described
in Section 11 to guarantee a consistent view, they need to be in Section 11 to guarantee a consistent view, they need to be
given consistent trust anchors to use in their internal validation given consistent trust anchors to use in their internal validation
process. Distribution of a consistent trust anchor is assumed to process. Distribution of a consistent trust anchor is assumed to
be out of band. be out of band.
Cache Peer Identification: The router initiates a transport session Cache Peer Identification: The router initiates a transport
to a cache, which it identifies by either IP address or fully connection to a cache, which it identifies by either IP address or
qualified domain name. Be aware that a DNS or address spoofing fully qualified domain name. Be aware that a DNS or address
attack could make the correct cache unreachable. No session would spoofing attack could make the correct cache unreachable. No
be established, as the authorization keys would not match. session would be established, as the authorization keys would not
match.
Transport Security: The RPKI relies on object, not server or Transport Security: The RPKI relies on object, not server or
transport, trust. That is, the IANA root trust anchor is transport, trust. That is, the IANA root trust anchor is
distributed to all caches through some out-of-band means, and can distributed to all caches through some out-of-band means, and can
then be used by each cache to validate certificates and ROAs all then be used by each cache to validate certificates and ROAs all
the way down the tree. The inter-cache relationships are based on the way down the tree. The inter-cache relationships are based on
this object security model; hence, the inter-cache transport can this object security model; hence, the inter-cache transport can
be lightly protected. be lightly protected.
However, this protocol document assumes that the routers cannot do However, this protocol document assumes that the routers cannot do
skipping to change at page 29, line 50 skipping to change at page 30, line 5
0-1 3 Cache Response 0-1 3 Cache Response
0-1 4 IPv4 Prefix 0-1 4 IPv4 Prefix
0-1 6 IPv6 Prefix 0-1 6 IPv6 Prefix
0-1 7 End of Data 0-1 7 End of Data
0-1 8 Cache Reset 0-1 8 Cache Reset
0 9 Reserved 0 9 Reserved
1 9 Router Key 1 9 Router Key
0-1 10 Error Report 0-1 10 Error Report
0-1 255 Reserved 0-1 255 Reserved
All exiting entries in the IANA "rpki-rtr-error" registry remain All existing entries in the IANA "rpki-rtr-error" registry remain
valid for all protocol versions. Protocol version 1 adds one new valid for all protocol versions. Protocol version 1 adds one new
error code: error code:
Error Error
Code Description Code Description
----- ---------------- ----- ----------------
8 Unexpected Protocol Version 8 Unexpected Protocol Version
15. Acknowledgments 15. Acknowledgments
skipping to change at page 30, line 28 skipping to change at page 30, line 32
unnecessary fields. unnecessary fields.
No doubt this list is incomplete. We apologize to any contributor No doubt this list is incomplete. We apologize to any contributor
whose name we missed. whose name we missed.
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., "BGPsec Algorithms, Key Formats, & Signature
Formats", draft-ietf-sidr-bgpsec-algs-09 (work in Formats", draft-ietf-sidr-bgpsec-algs-10 (work in
progress), January 2015. progress), July 2015.
[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 31, line 12 skipping to change at page 31, line 15
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[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", RFC 5226, BCP 26, IANA Considerations Section in RFCs", RFC 5226, BCP 26,
May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (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 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
[RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
for the TCP Authentication Option (TCP-AO)", RFC 5926, for the TCP Authentication Option (TCP-AO)", RFC 5926,
June 2010. June 2010.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
 End of changes. 33 change blocks. 
68 lines changed or deleted 96 lines changed or added

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