draft-ietf-sidr-rpki-rtr-14.txt   draft-ietf-sidr-rpki-rtr-15.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: January 11, 2012 ISC Expires: February 11, 2012 Dragon Research Labs
July 10, 2011 August 10, 2011
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-14 draft-ietf-sidr-rpki-rtr-15
Abstract Abstract
In order to formally validate the origin ASs of BGP announcements, In order to formally validate the origin ASs of BGP announcements,
routers need a simple but reliable mechanism to receive RPKI routers need a simple but reliable mechanism to receive RPKI
[I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This [I-D.ietf-sidr-arch] prefix origin data from a trusted cache. This
document describes a protocol to deliver validated prefix origin data document describes a protocol to deliver validated prefix origin data
to routers. to routers.
Requirements Language Requirements Language
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 11, 2012. This Internet-Draft will expire on February 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
5.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 11 5.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 13 6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 13 6.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 13
6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 14 6.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 14
6.3. No Incremental Update Available . . . . . . . . . . . . . 14 6.3. No Incremental Update Available . . . . . . . . . . . . . 14
6.4. Cache has No Data Available . . . . . . . . . . . . . . . 15 6.4. Cache has No Data Available . . . . . . . . . . . . . . . 15
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 16 7.1. SSH Transport . . . . . . . . . . . . . . . . . . . . . . 16
7.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 17 7.2. TLS Transport . . . . . . . . . . . . . . . . . . . . . . 17
7.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 17 7.3. TCP MD5 Transport . . . . . . . . . . . . . . . . . . . . 17
7.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . . 17 7.4. TCP-AO Transport . . . . . . . . . . . . . . . . . . . . . 18
8. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 18 8. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 18
9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 19 9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 19
10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
14.1. Normative References . . . . . . . . . . . . . . . . . . . 23 14.1. Normative References . . . . . . . . . . . . . . . . . . . 23
14.2. Informative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
In order to formally validate the origin ASs of BGP announcements, In order to formally validate the origin ASs of BGP announcements,
skipping to change at page 6, line 12 skipping to change at page 6, line 12
exchanges of the following PDUs according to the rules described in exchanges of the following PDUs according to the rules described in
Section 6. Section 6.
5.1. Serial Notify 5.1. Serial Notify
The cache notifies the router that the cache has new data. The cache notifies the router that the cache has new data.
The Cache Nonce reassures the router that the serial numbers are The Cache Nonce reassures the router that the serial numbers are
commensurate, i.e. the cache session has not been changed. commensurate, i.e. the cache session has not been changed.
Serial Notify is only message that the cache can send that is not in
response to a message from the router.
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | Cache Nonce | | Version | Type | Cache Nonce |
| 0 | 0 | | | 0 | 0 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=12 | | Length=12 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
skipping to change at page 10, line 42 skipping to change at page 10, line 42
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=8 | | Length=8 |
| | | |
`-------------------------------------------' `-------------------------------------------'
5.9. Error Report 5.9. Error Report
This PDU is used by either party to report an error to the other. This PDU is used by either party to report an error to the other.
Error reports are only sent as responses to other PDUs.
The Error Code is described in Section 10. The Error Code is described in Section 10.
If the error is not associated with any particular PDU, the Erroneous If the error is not associated with any particular PDU, the Erroneous
PDU field MUST be empty and the Length of Encapsulated PDU field MUST PDU field MUST be empty and the Length of Encapsulated PDU field MUST
be zero. be zero.
An Error Report PDU MUST NOT be sent for an Error Report PDU. An Error Report PDU MUST NOT be sent for an Error Report PDU.
If the error is associated with a PDU of excessive, or possibly If the error is associated with a PDU of excessive, or possibly
corrupt, length, the Erroneous PDU field MAY be truncated. corrupt, length, the Erroneous PDU field MAY be truncated.
skipping to change at page 15, line 21 skipping to change at page 15, line 21
it cannot honor the request. When a router receives this, the router it cannot honor the request. When a router receives this, the router
SHOULD attempt to connect to any more preferred caches in its cache SHOULD attempt to connect to any more preferred caches in its cache
list. If there are no more preferred caches it MUST issue a Reset list. If there are no more preferred caches it MUST issue a Reset
Query and get an entire new load from the cache. Query and get an entire new load from the cache.
6.4. Cache has No Data Available 6.4. Cache has No Data Available
Cache Router Cache Router
~ ~ ~ ~
| <----- Serial Query ------ | R requests data | <----- Serial Query ------ | R requests data
| ---- Error Report PDU ----> | C cannot supply update | ---- Error Report PDU ----> | C No Data Available
~ ~ ~ ~
Cache Router Cache Router
~ ~ ~ ~
| <----- Reset Query ------- | R requests data | <----- Reset Query ------- | R requests data
| ---- Error Report PDU ----> | C cannot supply update | ---- Error Report PDU ----> | C No Data Available
~ ~ ~ ~
The cache may respond to either a Serial Query or a Reset Query The cache may respond to either a Serial Query or a Reset Query
informing the router that the cache cannot supply any update at all. informing the router that the cache cannot supply any update at all.
The most likely cause is that the cache has lost state, perhaps due The most likely cause is that the cache has lost state, perhaps due
to a restart, and has not yet recovered. While it is possible that a to a restart, and has not yet recovered. While it is possible that a
cache might go into such a state without dropping any of its active cache might go into such a state without dropping any of its active
sessions, a router is more likely to see this behavior when it sessions, a router is more likely to see this behavior when it
initially connects and issues a Reset Query while the cache is still initially connects and issues a Reset Query while the cache is still
rebuilding its database. rebuilding its database.
skipping to change at page 16, line 11 skipping to change at page 16, line 11
binary Protocol Data Units (PDUs) in a persistent session. binary Protocol Data Units (PDUs) in a persistent session.
To prevent cache spoofing and DoS attacks by illegitimate routers, it To prevent cache spoofing and DoS attacks by illegitimate routers, it
is highly desirable that the router and the cache are authenticated is highly desirable that the router and the cache are authenticated
to each other. Integrity protection for payloads is also desirable to each other. Integrity protection for payloads is also desirable
to protect against monkey in the middle attacks. Unfortunately, to protect against monkey in the middle attacks. Unfortunately,
there is no protocol to do so on all currently used platforms. there is no protocol to do so on all currently used platforms.
Therefore, as of this document, there is no mandatory to implement Therefore, as of this document, there is no mandatory to implement
transport which provides authentication and integrity protection. transport which provides authentication and integrity protection.
To reduce exposure to dropped but non-terminated sessions, both
caches and routers SHOULD enable keep alives when available in the
chosen transport protocol.
It is expected that, when TCP-AO [RFC5925]is available on all It is expected that, when TCP-AO [RFC5925]is available on all
platforms deployed by operators, it will become the mandatory to platforms deployed by operators, it will become the mandatory to
implement transport. implement transport.
Caches and routers MUST implement unprotected transport over TCP Caches and routers MUST implement unprotected transport over TCP
using a port, RPKI-Rtr, to be assigned, see Section 12. Operators using a port, RPKI-Rtr, to be assigned, see Section 12. Operators
SHOULD use procedural means, ACLs, ... to reduce the exposure to SHOULD use procedural means, ACLs, ... to reduce the exposure to
authentication issues. authentication issues.
If available to the operator, caches and routers SHOULD use one of If available to the operator, caches and routers SHOULD use one of
skipping to change at page 23, line 7 skipping to change at page 23, line 20
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
This document requests the IANA to add an SSH Connection Protocol This document requests the IANA to add an SSH Connection Protocol
Subsystem Name, as defined in [RFC4250], of 'rpki-rtr'. Subsystem Name, as defined in [RFC4250], of 'rpki-rtr'.
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Steve Bellovin, Rex Fernando, Russ Housley, The authors wish to thank Steve Bellovin, Rex Fernando, Paul Hoffman,
Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John Russ Housley, Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert
Scudder, Ruediger Volk, and David Ward. Particular thanks go to Raszuk, John Scudder, Ruediger Volk, and David Ward. Particular
Hannes Gredler for showing us the dangers of unnecessary fields. thanks go to Hannes Gredler for showing us the dangers of unnecessary
fields.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-sidr-pfx-validate] [I-D.ietf-sidr-pfx-validate]
Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", Austein, "BGP Prefix Origin Validation",
draft-ietf-sidr-pfx-validate-01 (work in progress), draft-ietf-sidr-pfx-validate-01 (work in progress),
February 2011. February 2011.
skipping to change at page 25, line 4 skipping to change at page 25, line 15
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
Rob Austein Rob Austein
Internet Systems Consortium Dragon Research Labs
950 Charter Street
Redwood City, CA 94063
USA
Email: sra@isc.org Email: sra@hactrn.net
 End of changes. 14 change blocks. 
16 lines changed or deleted 24 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/