draft-ietf-sidr-rpki-rtr-00.txt   draft-ietf-sidr-rpki-rtr-01.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft IIJ Internet-Draft IIJ
Intended status: Standards Track R. Austein Intended status: Standards Track R. Austein
Expires: February 12, 2011 ISC Expires: February 16, 2011 ISC
August 11, 2010 August 15, 2010
The RPKI/Router Protocol The RPKI/Router Protocol
draft-ietf-sidr-rpki-rtr-00 draft-ietf-sidr-rpki-rtr-01
Abstract Abstract
In order to formally validate the origin ASes of BGP announcements, In order to formally validate the origin ASes 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 February 12, 2011. This Internet-Draft will expire on February 16, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 26 skipping to change at page 2, line 26
3. Operational Overview . . . . . . . . . . . . . . . . . . . . . 3 3. Operational Overview . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 4 4. Protocol Data Units (PDUs) . . . . . . . . . . . . . . . . . . 4
4.1. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Serial Notify . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Serial Query . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Reset Query . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Cache Response . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Cache Response . . . . . . . . . . . . . . . . . . . . . . 6
4.5. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. IPv4 Prefix . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 8 4.6. IPv6 Prefix . . . . . . . . . . . . . . . . . . . . . . . 8
4.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 8 4.7. End of Data . . . . . . . . . . . . . . . . . . . . . . . 8
4.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 9 4.8. Cache Reset . . . . . . . . . . . . . . . . . . . . . . . 9
4.9. Color Map . . . . . . . . . . . . . . . . . . . . . . . . 9 4.9. Error Report . . . . . . . . . . . . . . . . . . . . . . . 9
4.10. Error Report . . . . . . . . . . . . . . . . . . . . . . . 10 4.10. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 10
4.11. Fields of a PDU . . . . . . . . . . . . . . . . . . . . . 11
5. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Sequences . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 12 5.1. Start or Restart . . . . . . . . . . . . . . . . . . . . . 11
5.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 12 5.2. Typical Exchange . . . . . . . . . . . . . . . . . . . . . 12
5.3. No Incremental Update Available . . . . . . . . . . . . . 13 5.3. No Incremental Update Available . . . . . . . . . . . . . 13
5.4. Cache has No Data Available . . . . . . . . . . . . . . . 14 5.4. Cache has No Data Available . . . . . . . . . . . . . . . 13
6. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 6. SSH Transport . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 15 7. Router-Cache Set-Up . . . . . . . . . . . . . . . . . . . . . 14
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 16
9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Normative References . . . . . . . . . . . . . . . . . . . 19 14.1. Normative References . . . . . . . . . . . . . . . . . . . 19
14.2. Informative References . . . . . . . . . . . . . . . . . . 19 14.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 3, line 22 skipping to change at page 3, line 22
Section 2 describes the deployment structure and Section 3 then Section 2 describes the deployment structure and Section 3 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 4, and the expected PDU protocol are formally described in Section 4, and the expected PDU
sequences are described in Section 5. The transport protocol is sequences are described in Section 5. The transport protocol is
described in Section 6. Section 7 details how routers and caches are described in Section 6. Section 7 details how routers and caches are
configured to connect and authenticate. Section 8 describes likely configured to connect and authenticate. Section 8 describes likely
deployment scenarios. The traditional security and IANA deployment scenarios. The traditional security and IANA
considerations end the document. considerations end the document.
The protocol is extensible to support new PDUs with new semantics
when and as needed, as indicated by deployment experience. PDUs are
versioned should deployment experience call for change.
2. Deployment Structure 2. Deployment Structure
Deployment of the RPKI to reach routers has a three level structure Deployment of the RPKI to reach routers has a three level structure
as follows: as follows:
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, RPKI publication repositories, e.g. distributed set of servers, RPKI publication repositories, e.g.
the IANA, RIRs, NIRs, and ISPs, see [I-D.ietf-sidr-repos-struct]. the IANA, RIRs, NIRs, and ISPs, see [I-D.ietf-sidr-repos-struct].
Local Caches: A local set of one or more collected and verified non- Local Caches: A local set of one or more collected and verified non-
skipping to change at page 3, line 48 skipping to change at page 4, line 5
described in this document. It is said to be a client of the described in this document. It is said to be a client of the
cache. There are mechanisms for the router to assure itself of cache. There are mechanisms for the router to assure itself of
the authenticity of the cache and to authenticate itself to the the authenticity of the cache and to authenticate itself to the
cache. cache.
3. Operational Overview 3. Operational Overview
A router establishes and keeps open an authenticated connection to a A router establishes and keeps open an authenticated connection to a
cache with which it has a client/server relationship. It is cache with which it has a client/server relationship. 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 highest preference cache that accepts one. connection to the most preferred cache, or set of caches, which
accepts one.
Periodically, the router sends to the cache the serial number of the Periodically, the router sends to the cache the serial number of the
highest numbered data record it has received from that cache, i.e. highest numbered data record it has received from that cache, i.e.
the router's current serial number. When a router establishes a new the router's current serial number. When a router establishes a new
connection to a cache, or wishes to reset a current relationship, it connection to a cache, or wishes to reset a current relationship, it
sends a Reset Query. sends a Reset Query.
The Cache responds with all data records which have serial numbers The Cache responds with all data records which have serial numbers
greater than that in the router's query. This may be the null set, greater than that in the router's query. This may be the null set,
in which case the End of Data PDU is still sent. Note that 'greater' in which case the End of Data PDU is still sent. Note that 'greater'
skipping to change at page 7, line 10 skipping to change at page 7, line 10
| | | |
| Length=8 | | Length=8 |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.5. IPv4 Prefix 4.5. IPv4 Prefix
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | Color | | Version | Type | reserved = zero |
| 0 | 4 | | | 0 | 4 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=20 | | Length=20 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | Prefix | Max | Data | | | Prefix | Max | |
| Flags | Length | Length | Source | | Flags | Length | Length | zero |
| | 0..32 | 0..32 | RPKI/IRR | | | 0..32 | 0..32 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| IPv4 prefix | | IPv4 prefix |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Autonomous System Number | | Autonomous System Number |
| | | |
`-------------------------------------------' `-------------------------------------------'
skipping to change at page 8, line 10 skipping to change at page 8, line 10
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 lowest order bit of the Flags field is 1 for an announcement and
0 for a withdrawal. 0 for a withdrawal.
4.6. IPv6 Prefix 4.6. IPv6 Prefix
0 8 16 24 31 0 8 16 24 31
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | Color | | Version | Type | reserved = zero |
| 0 | 6 | | | 0 | 6 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=32 | | Length=32 |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | Prefix | Max | Data | | | Prefix | Max | |
| Flags | Length | Length | Source | | Flags | Length | Length | zero |
| | 0..128 | 0..128 | RPKI/IRR | | | 0..32 | 0..128 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
+--- ---+ +--- ---+
| | | |
+--- IPv6 prefix ---+ +--- IPv6 prefix ---+
| | | |
+--- ---+ +--- ---+
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
skipping to change at page 9, line 23 skipping to change at page 9, line 23
.-------------------------------------------. .-------------------------------------------.
| Protocol | PDU | | | Protocol | PDU | |
| Version | Type | reserved = zero | | Version | Type | reserved = zero |
| 0 | 8 | | | 0 | 8 | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Length=8 | | Length=8 |
| | | |
`-------------------------------------------' `-------------------------------------------'
4.9. Color Map 4.9. Error Report
0 8 16 24 31
.-------------------------------------------.
| Protocol | PDU | |
| Version | Type | Color |
| 0 | 9 | |
+-------------------------------------------+
| |
| Length |
| |
+-------------------------------------------+
| |
~ Arbitrary Data ~
| |
`-------------------------------------------'
This PDU allows the cache to send mappings of Color values to the
router. The value of Color is a many to one mapping of the value of
the Arbitrary Data.
The Length field is the total length of the PDU, including the first
eight bytes.
Color Map PDUs may be sent between a Cache Response PDU and the
correspondng End of Data PDU, intermixed among the IPv4 and IPv6
PDUs.
Router implementations are free to ignore this PDU if they have no
need of a mapping on Colors.
4.10. 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.
The Error Number is described in Section 9. The Error Number is described in Section 9.
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 should be empty and the Length of Encapsulated PDU field PDU field should be empty and the Length of Encapsulated PDU field
should be zero. should be zero.
The diagnostic text is optional, if not present the Length of Error The diagnostic text is optional, if not present the Length of Error
skipping to change at page 11, line 5 skipping to change at page 10, line 34
| Length of Error Text | | Length of Error Text |
| | | |
+-------------------------------------------+ +-------------------------------------------+
| | | |
| Arbitrary Text | | Arbitrary Text |
| of | | of |
~ Error Diagnostic Message ~ ~ Error Diagnostic Message ~
| | | |
`-------------------------------------------' `-------------------------------------------'
4.11. Fields of a PDU 4.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.
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 rcynic from a parent cache. See [RFC1982] on DNS completing an rcynic from a parent cache. See [RFC1982] on DNS
Serial Number Arithmetic for too much detail on serial number Serial Number Arithmetic for too much detail on serial number
arithmetic. arithmetic.
Length: A 32 bit ordinal which has as its value the count of the Length: A 32 bit ordinal which has as its value the count of the
bytes in the entire PDU, including the eight bytes of header which bytes in the entire PDU, including the eight bytes of header which
end with the length field. end with the length field.
Color: An arbitrary 16 bit field that might be used in some way.
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, whether this PDU announces a announcement and 0 for a withdrawal, whether this PDU announces a
new right to announce the prefix or withdraws a previously new right to announce the prefix or withdraws a previously
announced right. A withdraw effectively deletes one previously announced right. A withdraw effectively deletes one previously
announced IPvX Prefix PDU with the exact same Prefix, Length, Max- announced IPvX Prefix PDU with the exact same Prefix, Length, Max-
Len, ASN, Data Source, and Color. Len, and ASN.
Prefix Length: An ordinal denoting the shortest prefix allowed for Prefix Length: An ordinal denoting the shortest prefix allowed for
the prefix. the prefix.
Max Length: An ordinal denoting the longest prefix allowed by the Max Length: An ordinal denoting the longest prefix allowed by the
prefix. This MUST NOT be less than the Prefix Length element. prefix. This MUST NOT be less than the Prefix Length element.
Data Source: An ordinal denoting the source of the data, e.g. for
RPKI data, it is 0, for IRR data it is 1.
Prefix: The IPv4 or IPv6 prefix of the ROA. Prefix: The IPv4 or IPv6 prefix of the ROA.
Autonomous System Number: ASN allowed to announce this prefix, a 32 Autonomous System Number: ASN allowed to announce this prefix, a 32
bit ordinal. bit ordinal.
Zero: Fields shown as zero or reserved MUST be zero. The value of
such a field MUST be ignored on receipt.
5. Protocol Sequences 5. Protocol Sequences
The sequences of PDU transmissions fall into three conversations as The sequences of PDU transmissions fall into three conversations as
follows: follows:
5.1. Start or Restart 5.1. Start or Restart
Cache Router Cache Router
~ ~ ~ ~
| <----- Reset Query -------- | R requests data | <----- Reset Query -------- | R requests data
skipping to change at page 15, line 21 skipping to change at page 14, line 49
It is assumed that the router and cache have exchanged keys out of It is assumed that the router and cache have exchanged keys out of
band by some reasonably secured means. band by some reasonably secured means.
7. Router-Cache Set-Up 7. Router-Cache Set-Up
A cache has the public authentication data for each router it is A cache has the public authentication data for each router it is
configured to support. configured to support.
A router may be configured to peer with a selection of caches, and a A router may be configured to peer with a selection of caches, and a
cache may be configured to support a selection of routers. Each must cache may be configured to support a selection of routers. Each must
have the name of, and authentication data for, each each peer. In have the name of, and authentication data for, each peer. In
addition, in a router, this list has a non-unique preference value addition, in a router, this list has a non-unique preference value
for each server in order of preference. The client router attempts for each server in order of preference. This preference merely
to establish a session with each potential serving cache in denotes proximity, not trust, preferred belief, etc. The client
preference order, and then starts to load data from the highest router attempts to establish a session with each potential serving
preference cache to which it can connect and authenticate. The cache in preference order, and then starts to load data from the most
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 use that Preference: An ordinal denoting the router's preference to connect
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: The public ssh key of the cache.
MyKey: The private ssh key of this client. MyKey: The private ssh key of this client.
As caches can not be rigorously synchronous, a client which changes Due to the distributed nature of the RPKI, caches simply can not be
servers can not combine data from different parent caches. rigorously synchronous. A client may hold data from multiple caches,
Therefore, when a lower preference cache becomes available, if but MUST keep the data marked as to source, as later updates MUST
resources allow, it would be prudent for the client to start a new affect the correct data.
buffer for that cache's data, and only switch to those data when that
buffer is fully up to date. Just as there may be more than one covering ROA from a single cache,
there may be multiple covering ROAs from multiple caches. The
results are the same as described in [I-D.ietf-sidr-roa-validation]
as follows:
o Data from no cache has a covering ROA, so the result is 'unknown'.
o One or more closest covering ROAs exist but none match the AS of
the BGP update, so the result is 'invalid'.
o One or more closely covering ROAs have an AS match, while other
equally closely covering ROAs do not have an AS match, so the
result is 'valid'.
o There are multiple covering ROAs but none with an AS that matches
the BGP annoucement, so the result is 'invalid'.
When a more preferred cache becomes available, if resources allow, it
would be prudent for the client to start fetching from that cache.
The client MAY drop the data from older, less preferred cache(s) when
it is fully in synch with one or more other caches.
When a client loses connectivity to the cache it is currently using, When a client loses connectivity to the cache it is currently using,
or otherwise decides to switch to a new cache, it SHOULD retain the or otherwise decides to switch to a new cache, it SHOULD retain the
data from the previous cache and only switch to using the data from data from the previous cache until it has a full set of data from
the new cache once it has fully synchronized with it. It should do some other cache. It should do this regardless of whether it has
this regardless of whether it has chosen a different cache or chosen a different cache or established a new connection to the
established a new connection to the previous cache. However, a previous cache. However, a configurable timer MUST be provided to
configurable timer MUST be provided to bound how long it will retain bound how long it will retain the "stale" data.
the "stale" data.
8. Deployment Scenarios 8. Deployment Scenarios
For illustration, we present three likely deployment scenarios. For illustration, we present three likely deployment scenarios.
Small End Site: The small multi-homed end site may wish to outsource Small End Site: The small multi-homed end site may wish to outsource
the RPKI cache to one or more of their upstream ISPs. They would the RPKI cache to one or more of their upstream ISPs. They would
exchange authentication material with the ISP using some out of exchange authentication material with the ISP using some out of
band mechanism, and their router(s) would connect to one or more band mechanism, and their router(s) would connect to one or more
up-streams' caches. The ISPs would likely deploy caches intended up-streams' caches. The ISPs would likely deploy caches intended
skipping to change at page 18, line 49 skipping to change at page 18, line 49
with the new serial but MUST not be sent until the fetch is with the new serial but MUST not be sent until the fetch is
complete. A serial number is not commensurate between caches, nor complete. A serial number is not commensurate between caches, nor
need it be maintained across resets of the cache server. See need it be maintained across resets of the cache server. See
[RFC1982] on DNS Serial Number Arithmetic for too much detail on [RFC1982] on DNS Serial Number Arithmetic for too much detail on
serial number arithmetic. serial number arithmetic.
12. IANA Considerations 12. IANA Considerations
This document requests the IANA to create a registry for PDU types. This document requests the IANA to create a registry for PDU types.
This document requests the IANA to create a registry for Data Source
Codes.
This document requests the IANA to create a registry for Error Codes. This document requests the IANA to create a registry for Error Codes.
In addition, a registry for Version Numbers would be needed if new In addition, a registry for Version Numbers would be needed if new
Version Number is defined in a new RFC. Version Number is defined in a new RFC.
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,
Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Megumi Ninomiya, Robert Pradosh Mohapatra, Keyur Patel, Sandy Murphy, Robert Raszuk, John
Raszuk, John Scudder, Ruediger Volk, David Ward, and Bert Wijnen. Scudder, Ruediger Volk, and David Ward. Particular 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-roa-validation]
Huston, G. and G. Michaelson, "Validation of Route
Origination using the Resource Certificate PKI and ROAs",
draft-ietf-sidr-roa-validation-06 (work in progress),
May 2010.
[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", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, January 2006. Authentication Protocol", RFC 4252, January 2006.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
 End of changes. 27 change blocks. 
82 lines changed or deleted 77 lines changed or added

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