draft-ietf-sidr-rpki-rtr-13.txt   draft-ietf-sidr-rpki-rtr-14.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: December 31, 2011 ISC Expires: January 11, 2012 ISC
June 29, 2011 July 10, 2011
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-13 draft-ietf-sidr-rpki-rtr-14
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 December 31, 2011. This Internet-Draft will expire on January 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 29 skipping to change at page 2, line 29
5.1. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. Cache Response . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Cache Response . . . . . . . . . . . . . . . . . . . . . . 7
5.5. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 8 5.5. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 8
5.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 9 5.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 9
5.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 9 5.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 9
5.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 10 5.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 10
5.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 10 5.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 10
5.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 11 5.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . 20
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 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,
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] formally validated prefix origin data from a [I-D.ietf-sidr-arch] formally validated prefix origin data from a
skipping to change at page 9, line 8 skipping to change at page 9, line 8
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 might appear to a In the RPKI, there is also an actual need for what might appear to a
router as identical IPvX PDUs. This can occur when an upstream router as identical IPvX PDUs. This can occur when an upstream
certificate is being reissued or there is an address ownership certificate is being reissued or there is an address ownership
transfer up the validation chain. The ROA would be identical in the transfer up the validation chain. The ROA would be identical in the
router sense, i.e. have the same {prefix, len, max-len, asn}, but 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 cache server is responsible for assuring that it has told the The cache server MUST ensure that it has told the router client to
router client to have one and only one IPvX PDU for a unique {prefix, have one and only one IPvX PDU for a unique {prefix, len, max-len,
len, max-len, asn} at any one point in time. Should the router asn} at any one point in time. Should the router client receive an
client receive an IPvX PDU with a {prefix, len, max-len, asn} IPvX PDU with a {prefix, len, max-len, asn} identical to one it
identical to one it already has active, it SHOULD raise a Duplicate already has active, it SHOULD raise a Duplicate Announcement Received
Announcement Received error. 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 11, line 47 skipping to change at page 11, line 47
| | | |
`-------------------------------------------' `-------------------------------------------'
5.10. Fields of a PDU 5.10. Fields of a PDU
PDUs contain the following data elements: PDUs contain the following data elements:
Protocol Version: An ordinal, currently 0, denoting the version of Protocol Version: An ordinal, currently 0, denoting the version of
this protocol. this protocol.
PDU Type: An ordinal, denoting the type of the PDU, e.g. IPv4
Prefix, etc.
Serial Number: The serial number of the RPKI Cache when this ROA was Serial Number: The serial number of the RPKI Cache when this ROA was
received from the cache's up-stream cache server or gathered from received from the cache's up-stream 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 an rigorously validated update from a parent cache, for completing an rigorously validated update from a parent cache, for
example via rcynic. See [RFC1982] on DNS Serial Number Arithmetic example via rcynic. See [RFC1982] on DNS Serial Number Arithmetic
for too much detail on serial number arithmetic. for too much detail on serial number arithmetic.
Cache Nonce: When a cache server is started, it generates a nonce to Cache Nonce: When a cache server is started, it generates a nonce to
identify the instance of the cache and to bind it to the sequence identify the instance of the cache and to bind it to the sequence
of Serial Numbers that cache instance will generate. This allows of Serial Numbers that cache instance will generate. This allows
skipping to change at page 18, line 29 skipping to change at page 18, line 29
router attempts to establish a session with each potential serving router attempts to establish a session with each potential serving
cache in preference order, and then starts to load data from the most cache in preference order, and then starts to load data from the most
preferred cache to which it can connect and authenticate. The preferred cache to which it can connect and authenticate. The
router's list of caches has the following elements: router's list of caches has the following elements:
Preference: An ordinal denoting the router's preference to connect Preference: An ordinal denoting the router's preference to connect
to that cache, the lower the value the more preferred. to that cache, the lower the value the more preferred.
Name: The IP Address or fully qualified domain name of the cache. Name: The IP Address or fully qualified domain name of the cache.
Key: The public ssh key of the cache. Key: Any needed public key of the cache.
MyKey: The private ssh key of this client. MyKey: Any needed private key or certificate of this client.
Due to the distributed nature of the RPKI, caches simply can not be Due to the distributed nature of the RPKI, caches simply can not be
rigorously synchronous. A client may hold data from multiple caches, rigorously synchronous. A client may hold data from multiple caches,
but MUST keep the data marked as to source, as later updates MUST but MUST keep the data marked as to source, as later updates MUST
affect the correct data. affect the correct data.
Just as there may be more than one covering ROA from a single cache, Just as there may be more than one covering ROA from a single cache,
there may be multiple covering ROAs from multiple caches. The there may be multiple covering ROAs from multiple caches. The
results are as described in [I-D.ietf-sidr-pfx-validate]. results are as described in [I-D.ietf-sidr-pfx-validate].
skipping to change at page 21, line 12 skipping to change at page 21, line 12
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
be out of band. be out of band.
Cache Peer Identification: The router initiates an ssh transport Cache Peer Identification: The router initiates a transport session
session to a cache, which it identifies by either IP address or to a cache, which it identifies by either IP address or fully
fully qualified domain name. Be aware that a DNS or address qualified domain name. Be aware that a DNS or address spoofing
spoofing attack could make the correct cache unreachable. No attack could make the correct cache unreachable. No session would
session would be established, as the authorization keys would not be established, as the authorization keys would not match.
match.
Transport Security: The RPKI relies on object, not server or Transport Security: The RPKI relies on object, not server or
transport, trust. I.e. the IANA root trust anchor is distributed transport, trust. I.e. the IANA root trust anchor is distributed
to all caches through some out of band means, and can then be used to all caches through some out of band means, and can then be used
by each cache to validate certificates and ROAs all the way down by each cache to validate certificates and ROAs all the way down
the tree. The inter-cache relationships are based on this object the tree. The inter-cache relationships are based on this object
security model, hence the inter-cache transport can be lightly security model, hence the inter-cache transport can be lightly
protected. protected.
But this protocol document assumes that the routers can not do the But this protocol document assumes that the routers can not do the
skipping to change at page 21, line 46 skipping to change at page 21, line 45
While we can not say the cache must be on the same LAN, if only While we can not say the cache must be on the same LAN, if only
due to the issue of an enterprise wanting to off-load the cache due to the issue of an enterprise wanting to off-load the cache
task to their upstream ISP(s), locality, trust, and control are task to their upstream ISP(s), locality, trust, and control are
very critical issues here. The cache(s) really SHOULD be as very critical issues here. The cache(s) really SHOULD be as
close, in the sense of controlled and protected (against DDoS, close, in the sense of controlled and protected (against DDoS,
MITM) transport, to the router(s) as possible. It also SHOULD be MITM) transport, to the router(s) as possible. It also SHOULD be
topologically close so that a minimum of validated routing data topologically close so that a minimum of validated routing data
are needed to bootstrap a router's access to a cache. are needed to bootstrap a router's access to a cache.
The ssh identity of the cache server MUST be verified and The identity of the cache server MUST be verified and
authenticated by the router client, and vice versa, before any authenticated by the router client, and vice versa, before any
data are exchanged. data are exchanged.
12. IANA Considerations 12. IANA Considerations
This document requests the IANA to assign TCP Port Numbers to the This document requests the IANA to assign TCP Port Numbers to the
RPKI-Router Protocol for the following, see Section 7: RPKI-Router Protocol for the following, see Section 7:
RPKI-Rtr RPKI-Rtr
RPKI-Rtr TLS RPKI-Rtr TLS
This document requests the IANA to create a registry for PDU types 0 This document requests the IANA to create a registry for tuples of
to 255. The name of the registry should be rpki-rtr-pdu. The policy Protocol Version / PDU Type, each of which may range from 0 to 255.
for adding to the registry is RFC Required per [RFC5226], either The name of the registry should be rpki-rtr-pdu. The policy for
adding to the registry is RFC Required per [RFC5226], either
standards track or experimental. The initial entries should be as standards track or experimental. The initial entries should be as
follows: follows:
0 - Serial Notify Protocol
1 - Serial Query Version PDU Type
2 - Reset Query -------- -------------------
3 - Cache Response 0 0 - Serial Notify
4 - IPv4 Prefix 0 1 - Serial Query
6 - IPv6 Prefix 0 2 - Reset Query
7 - End of Data 0 3 - Cache Response
8 - Cache Reset 0 4 - IPv4 Prefix
10 - Error Report 0 6 - IPv6 Prefix
255 - Reserved 0 7 - End of Data
0 8 - Cache Reset
0 10 - Error Report
0 255 - Reserved
This document requests the IANA to create a registry for Error Codes This document requests the IANA to create a registry for Error Codes
0 to 255. The name of the registry should be rpki-rtr-error. The 0 to 255. The name of the registry should be rpki-rtr-error. The
policy for adding to the registry is Expert Review per [RFC5226], policy for adding to the registry is Expert Review per [RFC5226],
where the responsible IESG area director should appoint the Expert where the responsible IESG area director should appoint the Expert
Reviewer. The initial entries should be as follows: Reviewer. 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 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, Russ Housley,
Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John
Scudder, Ruediger Volk, and David Ward. Particular thanks go to Scudder, Ruediger Volk, 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.
 End of changes. 14 change blocks. 
43 lines changed or deleted 49 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/