draft-ietf-sidr-rpki-rtr-11.txt   draft-ietf-sidr-rpki-rtr-12.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: September 16, 2011 ISC Expires: October 28, 2011 ISC
March 15, 2011 April 26, 2011
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-11 draft-ietf-sidr-rpki-rtr-12
Abstract Abstract
In order to formally validate the origin ASs of BGP announcements, In order to formally validate the origin ASs of BGP announcements,
routers need a simple but reliable mechanism to receive RPKI routers need a simple but reliable mechanism to receive RPKI
[I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted [I-D.ietf-sidr-arch] or analogous prefix origin data from a trusted
cache. This document describes a protocol to deliver validated cache. This document describes a protocol to deliver validated
prefix origin data to routers over ssh. prefix origin data to routers over ssh.
Requirements Language Requirements Language
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 16, 2011. This Internet-Draft will expire on October 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
6.4. Cache has No Data Available . . . . . . . . . . . . . . . 15 6.4. Cache has No Data Available . . . . . . . . . . . . . . . 15
7. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 15 7. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 16 8. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 16
9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17 9. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 17
10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
14.1. Normative References . . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . . 21
14.2. Informative References . . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
In order to formally validate the origin ASs of BGP announcements, In order to formally validate the origin ASs of BGP announcements,
routers need a simple but reliable mechanism to receive RPKI routers need a simple but reliable mechanism to receive RPKI
[I-D.ietf-sidr-arch] or analogous formally validated prefix origin [I-D.ietf-sidr-arch] or analogous formally validated prefix origin
data from a trusted cache. This document describes a protocol to data from a trusted cache. This document describes a protocol to
deliver validated prefix origin data to routers over ssh. deliver validated prefix origin data to routers over ssh.
skipping to change at page 3, line 34 skipping to change at page 3, line 34
versioned should deployment experience call for change. versioned should deployment experience call for change.
2. Glossary 2. Glossary
The following terms are used with special meaning: The following terms are used with special meaning:
Global RPKI: The authoritative data of the RPKI are published in a Global RPKI: The authoritative data of the RPKI are published in a
distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see distributed set of servers at the IANA, RIRs, NIRs, and ISPs, see
[I-D.ietf-sidr-repos-struct]. [I-D.ietf-sidr-repos-struct].
Non-authorative Cache: A coalesced copy of the RPKI which is Non-authoritative Cache: A coalesced copy of the RPKI which is
periodically fetched/refreshed directly or indirectly from the periodically fetched/refreshed directly or indirectly from the
global RPKI using the [RFC5781] protocol/tools global RPKI using the [RFC5781] protocol/tools
Cache: Relying party update software such as rcynic is used to Cache: Relying party update software such as rcynic is used to
gather and validate the distributed data of the RPKI into a cache. gather and validate the distributed data of the RPKI into a cache.
Trusting this cache further is a matter between the provider of Trusting this cache further is a matter between the provider of
the cache and a relying party. the cache and a relying party.
Serial Number: A 32-bit monotonically increasing ordinal which wraps Serial Number: A 32-bit monotonically increasing ordinal which wraps
from 2^32-1 to 0. It denotes the logical version of a cache. A from 2^32-1 to 0. It denotes the logical version of a cache. A
skipping to change at page 5, line 34 skipping to change at page 5, line 34
changed since last update. As with any update protocol based on changed since last update. As with any update protocol based on
incremental transfers, the router must be prepared to fall back to a incremental transfers, the router must be prepared to fall back to a
full transfer if for any reason the cache is unable to provide the full transfer if for any reason the cache is unable to provide the
necessary incremental data. Unlike some incremental transfer necessary incremental data. Unlike some incremental transfer
protocols, this protocol requires the router to make an explicit protocols, this protocol requires the router to make an explicit
request to start the fallback process; this is deliberate, as the request to start the fallback process; this is deliberate, as the
cache has no way of knowing whether the router has also established cache has no way of knowing whether the router has also established
sessions with other caches that may be able to provide better sessions with other caches that may be able to provide better
service. service.
As a cache server must evaluate certificates and ROAs which are time
dependent, servers' clocks MUST be correct to a tolerance of
approximately an hour.
5. Protocol Data Units (PDUs) 5. Protocol Data Units (PDUs)
The exchanges between the cache and the router are sequences of The exchanges between the cache and the router are sequences of
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.
skipping to change at page 8, line 41 skipping to change at page 8, line 41
+-------------------------------------------+ +-------------------------------------------+
| | | |
| IPv4 Prefix | | IPv4 Prefix |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Autonomous System Number | | Autonomous System Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
Due to the nature of the RPKI and the IRR, there can be multiple The lowest order bit of the Flags field is 1 for an announcement and
identical IPvX PDUs. A router MUST be prepared to receive multiple 0 for a withdrawal.
identical record announcements and MUST NOT consider a record to have
been deleted until it has received a corresponding number of
withdrawals or a reset is performed. Hence the router will likely
keep an internal reference count on each IPvX PDU.
In the RPKI, nothing prevents a signing certificate from issuing two In the RPKI, nothing prevents a signing certificate from issuing two
identical ROAs, and nothing prohibits the existence of two identical identical ROAs, and nothing prohibits the existence of two identical
route: or route6: objects in the IRR. In this case there would be no route: or route6: objects in the IRR. In this case there would be no
semantic difference between the objects, merely a process redundancy. semantic difference between the objects, merely a process redundancy.
In the RPKI, there is also an actual need for what will appear to the In the RPKI, there is also an actual need for what might appear to a
router as identical IPvX PDUs. This occurs when an upstream router as identical IPvX PDUs. This can occur when an upstream
certificate is being reissued or a site is changing providers, often certificate is being reissued or there is an address ownership
a 'make and break' situation. The ROA is identical in the router transfer up the validation chain. The ROA would be identical in the
sense, i.e. has the same {prefix, len, max-len, asn}, but has a router sense, i.e. have the same {prefix, len, max-len, asn}, but a
different validation path in the RPKI. This is important to the different validation path in the RPKI. This is important to the
RPKI, but not to the router. RPKI, but not to the router.
The lowest order bit of the Flags field is 1 for an announcement and The cache server is responsible for assuring that it has told the
0 for a withdrawal. router client to have one and only one IPvX PDU for a unique {prefix,
len, max-len, asn} at any one point in time. Should the router
client receive an IPvX PDU with a {prefix, len, max-len, asn}
identical to one it already has active, it SHOULD raise a Duplicate
Announcement Received error.
5.6. IPv6 Prefix 5.6. IPv6 Prefix
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | reserved = zero | | Version | Type | reserved = zero |
| 0 | 6 | | | 0 | 6 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
skipping to change at page 19, line 18 skipping to change at page 19, line 18
4: Unsupported Protocol Version (fatal): The Protocol Version is not 4: Unsupported Protocol Version (fatal): The Protocol Version is not
known by the receiver of the PDU. known by the receiver of the PDU.
5: Unsupported PDU Type (fatal): The PDU Type is not known by the 5: Unsupported PDU Type (fatal): The PDU Type is not known by the
receiver of the PDU. receiver of the PDU.
6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0 6: Withdrawal of Unknown Record (fatal): The received PDU has Flag=0
but a record for the Prefix/PrefixLength/MaxLength triple does not but a record for the Prefix/PrefixLength/MaxLength triple does not
exist in the receiver's database. exist in the receiver's database.
7: Duplicate Announcement Received (fatal): The received PDU has an
identical {prefix, len, max-len, asn} tuple as a PDU which is
still active in the router.
11. Security Considerations 11. Security Considerations
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 9 to guarantee a consistent view, they need to be given in Section 9 to guarantee a consistent view, they need to be given
consistent trust anchors to use in their internal validation 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
skipping to change at page 21, line 4 skipping to change at page 21, line 12
responsible IESG area director should appoint the Expert Reviewer. responsible IESG area director should appoint the Expert Reviewer.
The initial entries should be as follows: The initial entries should be as follows:
0 - Corrupt Data 0 - Corrupt Data
1 - Internal Error 1 - Internal Error
2 - No Data Available 2 - No Data Available
3 - Invalid Request 3 - Invalid Request
4 - Unsupported Protocol Version 4 - Unsupported Protocol Version
5 - Unsupported PDU Type 5 - Unsupported PDU Type
6 - Withdrawal of Unknown Record 6 - Withdrawal of Unknown Record
7 - Duplicate Announcement Received
This document requests the IANA to add an SSH Subsystem Name, as This document requests the IANA to add an SSH Subsystem Name, as
defined in [RFC4250], of 'rpki-rtr'. defined in [RFC4250], of 'rpki-rtr'.
Note to RFC Editor: this section may be replaced on publication as an Note to RFC Editor: this section may be replaced on publication as an
RFC. RFC.
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Steve Bellovin, Rex Fernando, Russ Housley, The authors wish to thank Steve Bellovin, Rex Fernando, Russ Housley,
 End of changes. 11 change blocks. 
19 lines changed or deleted 28 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/