Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8210

 
 
 

The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1

Part 2 of 2, p. 20 to 35
Prev Section

 


prevText      Top      ToC       Page 20 
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.

Top      Up      ToC       Page 21 
   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.

Top      Up      ToC       Page 22 
   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.

Top      Up      ToC       Page 23 
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

Top      Up      ToC       Page 24 
   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.

Top      Up      ToC       Page 25 
   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.

Top      Up      ToC       Page 26 
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.

Top      Up      ToC       Page 27 
   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.

Top      Up      ToC       Page 28 
   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.

Top      Up      ToC       Page 29 
   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.

Top      Up      ToC       Page 30 
   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.

Top      Up      ToC       Page 31 
      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.

Top      Up      ToC       Page 32 
   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>.

Top      Up      ToC       Page 33 
   [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>.

Top      Up      ToC       Page 34 
   [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>.

Top      Up      ToC       Page 35 
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