RFC 8210
The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1
7. Protocol Version Negotiation
A router MUST start each transport connection by issuing either a Reset Query or a Serial Query. This query will tell the cache which version of this protocol the router implements. If a cache which supports version 1 receives a query from a router which specifies version 0, the cache MUST downgrade to protocol 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 only supports version 0, one of two things will happen: 1. The cache may terminate the connection, perhaps with a version 0 Error Report PDU. In this case, the router MAY retry the connection using protocol version 0. 2. The cache may reply with a version 0 response. In this case, the router MUST either downgrade to version 0 or terminate the connection. In any of the downgraded combinations above, the new features of version 1 will not be available, and all PDUs will have 0 in their version fields. If either party receives a PDU containing an unrecognized Protocol Version (neither 0 nor 1) during this negotiation, it MUST either downgrade to a known version or terminate the connection, with an Error Report PDU unless the received PDU is itself an Error Report PDU. The router MUST ignore any Serial Notify PDUs it might receive from the cache during this initial startup period, regardless of the Protocol Version field in the Serial Notify PDU. Since Session ID and Serial Number values are specific to a particular protocol version, the values in the notification are not useful to the router. Even if these values were meaningful, the only effect that processing the notification would have would be to trigger exactly the same Reset Query or Serial Query that the router has already sent as part of the not-yet-complete version negotiation process, so there is nothing to be gained by processing notifications until version negotiation completes. Caches SHOULD NOT send Serial Notify PDUs before version negotiation completes. Routers, however, MUST handle such notifications (by ignoring them) for backwards compatibility with caches serving protocol version 0.
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 session. See Section 5.1 for a discussion of the interaction between Protocol Version and Session ID. If either party receives a PDU for a different Protocol Version once the above negotiation completes, that party MUST drop the session; unless the PDU containing the unexpected Protocol Version was itself an Error Report PDU, the party dropping the session SHOULD send an Error Report with an error code of 8 ("Unexpected Protocol Version").8. Protocol Sequences
The sequences of PDU transmissions fall into four conversations as follows:8.1. Start or Restart
Cache Router ~ ~ | <----- Reset Query -------- | R requests data (or Serial Query) | | | ----- Cache Response -----> | C confirms request | ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | or Router Key PDUs | ------- End of Data ------> | C sends End of Data | | and sends new serial ~ ~ When a transport connection is first established, the router MUST send either a Reset Query or a Serial Query. A Serial Query would be appropriate if the router has significant unexpired data from a broken session with the same cache and remembers the Session ID of that session, in which case a Serial Query containing the Session ID from the previous session will allow the router to bring itself up to date while ensuring that the Serial Numbers are commensurate and that the router and cache are speaking compatible versions of the protocol. In all other cases, the router lacks the necessary data for fast resynchronization and therefore MUST fall back to a Reset Query. The Reset Query sequence is also used when the router receives a Cache Reset, chooses a new cache, or fears that it has otherwise lost its way. See Section 7 for details on version negotiation.
To limit the length of time a cache must keep the data necessary to generate incremental updates, a router MUST send either a Serial 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 polling frequency.8.2. Typical Exchange
Cache Router ~ ~ | -------- Notify ----------> | (optional) | | | <----- Serial Query ------- | R requests data | | | ----- Cache Response -----> | C confirms request | ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | or Router Key PDUs | ------- End of Data ------> | C sends End of Data | | and sends new 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 router MAY then issue a Serial Query earlier than it otherwise might. This is analogous to DNS NOTIFY in [RFC1996]. The cache MUST rate-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 router or the cache has sent a Notify PDU, the router queries for new data by sending a Serial Query, and the cache sends all data newer than the serial in the Serial Query. To limit the length of time a cache must keep old withdraws, a router MUST send either a Serial Query or a Reset Query periodically. See Section 6 for details on the required polling frequency.
8.3. No Incremental Update Available
Cache Router ~ ~ | <------ Serial Query ------ | R requests data | ------- Cache Reset ------> | C cannot supply update | | from specified serial | <------ Reset Query ------- | R requests new data | ----- Cache Response -----> | C confirms request | ------- Payload PDU ------> | C sends zero or more | ------- Payload PDU ------> | IPv4 Prefix, IPv6 Prefix, | ------- Payload PDU ------> | or Router Key PDUs | ------- End of Data ------> | C sends End of Data | | and sends new serial ~ ~ 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 Serial Number specified by the router. This might be because the 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 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 arose, the cache replies with a Cache Reset to tell the router that it cannot honor the request. When a router receives this, the router 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 Query and get an entire new load from the cache.8.4. Cache Has No Data Available
Cache Router ~ ~ | <------ Serial Query ------ | R requests data | ---- Error Report PDU ----> | C No Data Available ~ ~ Cache Router ~ ~ | <------ Reset Query ------- | R requests data | ---- Error Report PDU ----> | C No Data Available ~ ~ 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. 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 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 initially connects and issues a Reset Query while the cache is still rebuilding its database. When a router receives this kind of error, the router SHOULD attempt to connect to any other caches in its cache list, in preference order. If no other caches are available, the router MUST issue periodic Reset Queries until it gets a new usable load from the cache.9. Transport
The transport-layer session between a router and a cache carries the binary PDUs in a persistent session. To prevent cache spoofing and DoS attacks by illegitimate routers, it is highly desirable that the router and the cache be authenticated to each other. Integrity protection for payloads is also desirable to protect against monkey-in-the-middle (MITM) attacks. Unfortunately, there is no protocol to do so on all currently used platforms. Therefore, as of the writing of this document, there is no mandatory- to-implement 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 the TCP Authentication Option (TCP-AO) [RFC5925] is available on all platforms deployed by operators, it will become the mandatory-to-implement transport. Caches and routers MUST implement unprotected transport over TCP using a port, rpki-rtr (323); see Section 14. Operators SHOULD use procedural means, e.g., access control lists (ACLs), to reduce the exposure to authentication issues. If unprotected TCP is the transport, the cache and routers MUST be on the same trusted and controlled network. If available to the operator, caches and routers MUST use one of the following more protected protocols: o Caches and routers SHOULD use TCP-AO transport [RFC5925] over the rpki-rtr port.
o Caches and routers MAY use Secure Shell version 2 (SSHv2)
transport [RFC4252] using the normal SSH port. For an example,
see Section 9.1.
o Caches and routers MAY use TCP MD5 transport [RFC2385] using the
rpki-rtr port. Note that TCP MD5 has been obsoleted by TCP-AO
[RFC5925].
o Caches and routers MAY use TCP over IPsec transport [RFC4301]
using the rpki-rtr port.
o Caches and routers MAY use Transport Layer Security (TLS)
transport [RFC5246] using port rpki-rtr-tls (324); see Section 14.
9.1. SSH Transport
To run over SSH, the client router first establishes an SSH transport
connection using the SSHv2 transport protocol, and the client and
server exchange keys for message integrity and encryption. The
client then invokes the "ssh-userauth" service to authenticate the
application, as described in the SSH authentication protocol
[RFC4252]. Once the application has been successfully authenticated,
the client invokes the "ssh-connection" service, also known as the
SSH connection protocol.
After the ssh-connection service is established, the client opens a
channel of type "session", which results in an SSH session.
Once the SSH session has been established, the application invokes
the application transport as an SSH subsystem called "rpki-rtr".
Subsystem support is a feature of SSHv2 and is not included in SSHv1.
Running this protocol as an SSH subsystem avoids the need for the
application to recognize shell prompts or skip over extraneous
information, such as a system message that is sent at shell startup.
It is assumed that the router and cache have exchanged keys out of
band by some reasonably secured means.
Cache servers supporting SSH transport MUST accept RSA authentication
and SHOULD accept Elliptic Curve Digital Signature Algorithm (ECDSA)
authentication. User authentication MUST be supported; host
authentication MAY be supported. Implementations MAY support
password authentication. Client routers SHOULD verify the public key
of the cache to avoid MITM attacks.
9.2. TLS Transport
Client routers using TLS transport MUST present client-side certificates to authenticate themselves to the cache in order to allow the cache to manage the load by rejecting connections from unauthorized routers. In principle, any type of certificate and Certification Authority (CA) may be used; however, in general, cache operators will wish to create their own small-scale CA and issue certificates to each authorized router. This simplifies credential rollover; any unrevoked, unexpired certificate from the proper CA may be used. Certificates used to authenticate client routers in this protocol MUST include a subjectAltName extension [RFC5280] containing one or more iPAddress identities; when authenticating the router's certificate, the cache MUST check the IP address of the TLS connection against these iPAddress identities and SHOULD reject the connection if none of the iPAddress identities match the connection. Routers MUST also verify the cache's TLS server certificate, using subjectAltName dNSName identities as described in [RFC6125], to avoid MITM attacks. The rules and guidelines defined in [RFC6125] apply here, with the following considerations: o Support for the DNS-ID identifier type (that is, the dNSName identity in the subjectAltName extension) is REQUIRED in rpki-rtr server and client implementations which use TLS. Certification authorities which issue rpki-rtr server certificates MUST support the DNS-ID identifier type, and the DNS-ID identifier type MUST be present in rpki-rtr server certificates. o DNS names in rpki-rtr server certificates SHOULD NOT contain the wildcard character "*". o rpki-rtr implementations which use TLS MUST NOT use Common Name (CN-ID) identifiers; a CN field may be present in the server certificate's subject name but MUST NOT be used for authentication within the rules described in [RFC6125]. o The client router MUST set its "reference identifier" to the DNS name of the rpki-rtr cache.9.3. TCP MD5 Transport
If TCP MD5 is used, implementations MUST support key lengths of at least 80 printable ASCII bytes, per Section 4.5 of [RFC2385]. Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits.
Key rollover with TCP MD5 is problematic. Cache servers SHOULD support [RFC4808].9.4. TCP-AO Transport
Implementations MUST support key lengths of at least 80 printable ASCII bytes. Implementations MUST also support hexadecimal sequences of at least 32 characters, i.e., 128 bits. Message Authentication Code (MAC) lengths of at least 96 bits MUST be supported, per Section 5.1 of [RFC5925]. The cryptographic algorithms and associated parameters described in [RFC5926] MUST be supported.10. Router-Cache Setup
A cache has the public authentication data for each router it is configured to support. 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 have the name of, and authentication data for, each peer. In addition, in a router, this list has a non-unique preference value for each server. This preference merely denotes proximity, not trust, preferred belief, et cetera. The client router attempts to establish a session with each potential serving 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: Preference: An unsigned integer denoting the router's preference to connect to that cache; the lower the value, the more preferred. Name: The IP address or fully qualified domain name of the cache. Cache Credential(s): Any credential (such as a public key) needed to authenticate the cache's identity to the router. Router Credential(s): Any credential (such as a private key or certificate) needed to authenticate the router's identity to the cache. Due to the distributed nature of the RPKI, caches simply cannot be rigorously synchronous. A client may hold data from multiple caches but MUST keep the data marked as to source, as later updates MUST affect the correct data.
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 as described in [RFC6811]. If data from multiple caches are held, implementations MUST NOT distinguish between data sources when performing validation of BGP announcements. 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 SHOULD attempt to maintain at least one set of data, regardless of whether it has chosen a different cache or established a new connection to the previous cache. A client MAY drop the data from a particular cache when it is fully in sync with one or more other caches. See Section 6 for details on what to do when the client is not able to refresh from a particular cache. If a client loses connectivity to a cache it is using or otherwise decides to switch to a new cache, it SHOULD retain the data from the previous cache until it has a full set of data from one or more other caches. Note that this may already be true at the point of connection loss if the client has connections to more than one cache.11. Deployment Scenarios
For illustration, we present three likely deployment scenarios: Small End Site: The small multihomed end site may wish to outsource the RPKI cache to one or more of their upstream ISPs. They would exchange authentication material with the ISP using some out-of- band mechanism, and their router(s) would connect to the cache(s) of one or more upstream ISPs. The ISPs would likely deploy caches intended for customer use separately from the caches with which their own BGP speakers peer. Large End Site: A larger multihomed end site might run one or more caches, arranging them in a hierarchy of client caches, each fetching from a serving cache which is closer to the Global RPKI. They might configure fallback peerings to upstream ISP caches. ISP Backbone: A large ISP would likely have one or more redundant caches in each major point of presence (PoP), and these caches would fetch from each other in an ISP-dependent topology so as not to place undue load on the Global RPKI.
Experience with large DNS cache deployments has shown that complex topologies are ill-advised, as it is easy to make errors in the graph, e.g., not maintain a loop-free condition. Of course, these are illustrations, and there are other possible deployment strategies. It is expected that minimizing load on the Global RPKI servers will be a major consideration. To keep load on Global RPKI services from unnecessary peaks, it is recommended that primary caches which load from the distributed Global RPKI not do so all at the same times, e.g., on the hour. Choose a random time, perhaps the ISP's AS number modulo 60, and jitter the inter-fetch timing.12. Error Codes
This section contains a preliminary list of error codes. The authors expect additions to the list during development of the initial implementations. There is an IANA registry where valid error codes are listed; see Section 14. Errors which are considered fatal MUST cause the session to be dropped. 0: Corrupt Data (fatal): The receiver believes the received PDU to be corrupt in a manner not specified by another error code. 1: Internal Error (fatal): The party reporting the error experienced some kind of internal error unrelated to protocol operation (ran out of memory, a coding assertion failed, et cetera). 2: No Data Available: The cache believes itself to be in good working order but is unable to answer either a Serial Query or a Reset Query because it has no useful data available at this time. This is likely to be a temporary error and most likely indicates that the cache has not yet completed pulling down an initial current data set from the Global RPKI system after some kind of event that invalidated whatever data it might have previously held (reboot, network partition, et cetera). 3: Invalid Request (fatal): The cache server believes the client's request to be invalid. 4: Unsupported Protocol Version (fatal): The Protocol Version is not known by the receiver of the PDU. 5: Unsupported PDU Type (fatal): The PDU Type is not known by the receiver of the PDU.
6: Withdrawal of Unknown Record (fatal): The received PDU has
Flag=0, but a matching record ({Prefix, Len, Max-Len, ASN} tuple
for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a
Router Key PDU) does not exist in the receiver's database.
7: Duplicate Announcement Received (fatal): The received PDU has
Flag=1, but a matching record ({Prefix, Len, Max-Len, ASN} tuple
for an IPvX PDU or {SKI, ASN, Subject Public Key} tuple for a
Router Key PDU) is already active in the router.
8: Unexpected Protocol Version (fatal): The received PDU has a
Protocol Version field that differs from the protocol version
negotiated in Section 7.
13. Security Considerations
As this document describes a security protocol, many aspects of
security interest are described in the relevant sections. This
section points out issues which may not be obvious in other sections.
Cache Validation: In order for a collection of caches as described
in Section 11 to guarantee a consistent view, they need to be
given consistent trust anchors to use in their internal validation
process. Distribution of a consistent trust anchor is assumed to
be out of band.
Cache Peer Identification: The router initiates a transport
connection to a cache, which it identifies by either IP address or
fully qualified domain name. Be aware that a DNS or address
spoofing attack could make the correct cache unreachable. No
session would be established, as the authorization keys would not
match.
Transport Security: The RPKI relies on object, not server or
transport, trust. That is, the IANA root trust anchor is
distributed 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 the tree. The inter-cache relationships are based on
this object security model; hence, the inter-cache transport can
be lightly protected.
However, this protocol document assumes that the routers cannot do
the validation cryptography. Hence, the last link, from cache to
router, is secured by server authentication and transport-level
security. This is dangerous, as server authentication and
transport have very different threat models than object security.
So the strength of the trust relationship and the transport
between the router(s) and the cache(s) are critical. You're
betting your routing on this.
While we cannot say the cache must be on the same LAN, if only due
to the issue of an enterprise wanting to offload the cache task to
their upstream ISP(s), locality, trust, and control are very
critical issues here. The cache(s) really SHOULD be as close, in
the sense of controlled and protected (against DDoS, MITM)
transport, to the router(s) as possible. It also SHOULD be
topologically close so that a minimum of validated routing data
are needed to bootstrap a router's access to a cache.
The identity of the cache server SHOULD be verified and
authenticated by the router client, and vice versa, before any
data are exchanged.
Transports which cannot provide the necessary authentication and
integrity (see Section 9) must rely on network design and
operational controls to provide protection against spoofing/
corruption attacks. As pointed out in Section 9, TCP-AO is the
long-term plan. Protocols which provide integrity and
authenticity SHOULD be used, and if they cannot, i.e., TCP is used
as the transport, the router and cache MUST be on the same
trusted, controlled network.
14. IANA Considerations
This section only discusses updates required in the existing IANA
protocol registries to accommodate version 1 of this protocol. See
[RFC6810] for IANA considerations from the original (version 0)
protocol.
All existing entries in the IANA "rpki-rtr-pdu" registry remain valid
for protocol version 0. All of the PDU types allowed in protocol
version 0 are also allowed in protocol version 1, with the addition
of the new Router Key PDU. To reduce the likelihood of confusion,
the PDU number used by the Router Key PDU in protocol version 1 is
hereby registered as reserved (and unused) in protocol version 0.
The policy for adding to the registry is RFC Required per [RFC8126];
the document must be either Standards Track or Experimental.
The "rpki-rtr-pdu" registry has been updated as follows:
Protocol PDU
Version Type Description
-------- ---- ---------------
0-1 0 Serial Notify
0-1 1 Serial Query
0-1 2 Reset Query
0-1 3 Cache Response
0-1 4 IPv4 Prefix
0-1 6 IPv6 Prefix
0-1 7 End of Data
0-1 8 Cache Reset
0 9 Reserved
1 9 Router Key
0-1 10 Error Report
0-1 255 Reserved
All existing entries in the IANA "rpki-rtr-error" registry remain
valid for all protocol versions. Protocol version 1 adds one new
error code:
Error
Code Description
----- ---------------------------
8 Unexpected Protocol Version
15. References
15.1. Normative References
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>. [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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>. [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)", RFC 5926, DOI 10.17487/RFC5926, June 2010, <https://www.rfc-editor.org/info/rfc5926>. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>. [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>. [RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <http://www.rfc-editor.org/info/rfc8208>.15.2. Informative References
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, <https://www.rfc-editor.org/info/rfc1996>. [RFC4808] Bellovin, S., "Key Change Strategies for TCP-MD5", RFC 4808, DOI 10.17487/RFC4808, March 2007, <https://www.rfc-editor.org/info/rfc4808>. [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, <https://www.rfc-editor.org/info/rfc5781>. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>. [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.
Acknowledgements
The authors wish to thank Nils Bars, Steve Bellovin, Tim Bruijnzeels, Rex Fernando, Richard Hansen, Paul Hoffman, Fabian Holler, Russ Housley, Pradosh Mohapatra, Keyur Patel, David Mandelberg, Sandy Murphy, Robert Raszuk, Andreas Reuter, Thomas C. Schmidt, John Scudder, Ruediger Volk, Matthias Waehlisch, and David Ward. Particular thanks go to Hannes Gredler for showing us the dangers of unnecessary fields. No doubt this list is incomplete. We apologize to any contributor whose name we missed.Authors' Addresses
Randy Bush Internet Initiative Japan 5147 Crystal Springs Bainbridge Island, Washington 98110 United States of America Email: randy@psg.com Rob Austein Dragon Research Labs Email: sra@hactrn.net