Tech-invite   World Map
3GPPspecs     Glossaries     T+       IETF     RFCs     Groups     SIP     ABNFs

RFC 8205

 
 
 

BGPsec Protocol Specification

Part 3 of 3, p. 29 to 45
Prev Section

 


prevText      Top      ToC       Page 29 
7.  Operations and Management Considerations

   Some operations and management issues that are closely relevant to
   BGPsec protocol specification and deployment are highlighted here.
   The best practices concerning operations and deployment of BGPsec are
   provided in [RFC8207].

7.1.  Capability Negotiation Failure

   Section 2.2 describes the negotiation required to establish a
   BGPsec-capable peering session.  Not only must the BGPsec capability
   be exchanged (and agreed on), but the BGP multiprotocol extension
   [RFC4760] for the same AFI and the 4-byte AS capability [RFC6793]
   MUST also be exchanged.  Failure to properly negotiate a BGPsec
   session -- due to a missing capability, for example -- may still
   result in the exchange of BGP (unsigned) UPDATE messages.  It is
   RECOMMENDED that an implementation log the failure to properly
   negotiate a BGPsec session.  Also, an implementation MUST have the
   ability to prevent a BGP session from being established if configured
   to only use BGPsec.

7.2.  Preventing Misuse of pCount=0

   A peer that is an Internet Exchange Point (IXP) (i.e., route server)
   with a transparent AS is expected to set pCount=0 in its Secure_Path
   Segment while forwarding an UPDATE message to a peer (see
   Section 4.2).  Clearly, such an IXP MUST configure its BGPsec router
   to set pCount=0 in its Secure_Path Segment.  This also means that a
   BGPsec speaker MUST be configured so that it permits pCount=0 from an
   IXP peer.  Two other cases where pCount is set to 0 are in the
   contexts of an AS confederation (see Section 4.3) and of AS migration
   [RFC8206].  In these two cases, pCount=0 is set and accepted within
   the same AS (albeit the AS has two different identities).  Note that

Top      Up      ToC       Page 30 
   if a BGPsec speaker does not expect a peer AS to set its pCount=0 and
   if an UPDATE message received from that peer violates this, then the
   UPDATE message MUST be considered to be in error (see the list of
   checks in Section 5.2).  See Section 8.4 for a discussion of security
   considerations concerning pCount=0.

7.3.  Early Termination of Signature Verification

   During the validation of a BGPsec UPDATE message, route processor
   performance speedup can be achieved by incorporating the following
   observations.  An UPDATE message is deemed 'Valid' if at least one of
   the Signature_Blocks is marked as 'Valid' (see Section 5.2).
   Therefore, if an UPDATE message contains two Signature_Blocks and the
   first one verified is found 'Valid', then the second Signature_Block
   does not have to be verified.  And if the UPDATE message is chosen
   for best path, then the BGPsec speaker adds its signature (generated
   with the respective algorithm) to each of the two Signature_Blocks
   and forwards the UPDATE message.  Also, a BGPsec UPDATE message is
   deemed 'Not Valid' if at least one signature in each of the
   Signature_Blocks is invalid.  This principle can also be used for
   route processor workload savings, i.e., the verification for a
   Signature_Block terminates early when the first invalid signature is
   encountered.

7.4.  Non-deterministic Signature Algorithms

   Many signature algorithms are non-deterministic.  That is, many
   signature algorithms will produce different signatures each time they
   are run (even when they are signing the same data with the same key).
   Therefore, if a BGPsec router receives a BGPsec UPDATE message from a
   peer and later receives a second BGPsec UPDATE message from the same
   peer for the same prefix with the same Secure_Path and SKIs, the
   second UPDATE message MAY differ from the first UPDATE message in the
   signature fields (for a non-deterministic signature algorithm).
   However, the two sets of signature fields will not differ if the
   sender caches and reuses the previous signature.  For a deterministic
   signature algorithm, the signature fields MUST be identical between
   the two UPDATE messages.  On the basis of these observations, an
   implementation MAY incorporate optimizations in update validation
   processing.

7.5.  Private AS Numbers

   It is possible that a stub customer of an ISP employs a private AS
   number.  Such a stub customer cannot publish a ROA in the Global RPKI
   for the private AS number and the prefixes that they use.  Also, the
   Global RPKI cannot support private AS numbers (i.e., BGPsec speakers
   in private ASes cannot be issued router certificates in the Global

Top      Up      ToC       Page 31 
   RPKI).  For interactions between the stub customer (with the private
   AS number) and the ISP, the following two scenarios are possible:

   1.  The stub customer sends an unsigned BGP UPDATE message for a
       prefix to the ISP's AS.  An edge BGPsec speaker in the ISP's AS
       may choose to propagate the prefix to its non-BGPsec and BGPsec
       peers.  If so, the ISP's edge BGPsec speaker MUST strip the
       AS_PATH with the private AS number and then (a) re-originate the
       prefix without any signatures towards its non-BGPsec peer and
       (b) re-originate the prefix including its own signature towards
       its BGPsec peer.  In both cases (i.e., (a) and (b)), the prefix
       MUST have a ROA in the Global RPKI authorizing the ISP's AS to
       originate it.

   2.  The ISP and the stub customer may use a local RPKI repository
       (using a mechanism such as one of the mechanisms described in
       [SLURM]).  Then, there can be a ROA for the prefix originated by
       the stub AS, and the eBGP speaker in the stub AS can be a BGPsec
       speaker having a router certificate, albeit the ROA and router
       certificate are valid only locally.  With this arrangement, the
       stub AS sends a signed UPDATE message for the prefix to the ISP's
       AS.  An edge BGPsec speaker in the ISP's AS validates the UPDATE
       message, using RPKI data based on the local RPKI view.  Further,
       it may choose to propagate the prefix to its non-BGPsec and
       BGPsec peers.  If so, the ISP's edge BGPsec speaker MUST strip
       the Secure_Path and the Signature Segment received from the stub
       AS with the private AS number and then (a) re-originate the
       prefix without any signatures towards its non-BGPsec peer and
       (b) re-originate the prefix including its own signature towards
       its BGPsec peer.  In both cases (i.e., (a) and (b)), the prefix
       MUST have a ROA in the Global RPKI authorizing the ISP's AS to
       originate it.

   It is possible that private AS numbers are used in an AS
   confederation [RFC5065].  The BGPsec protocol requires that when a
   BGPsec UPDATE message propagates through a confederation, each
   Member-AS that forwards it to a peer Member-AS MUST sign the UPDATE
   message (see Section 4.3).  However, the Global RPKI cannot support
   private AS numbers.  In order for the BGPsec speakers in Member-ASes
   with private AS numbers to have digital certificates, there MUST be a
   mechanism in place in the confederation that allows the establishment
   of a local, customized view of the RPKI, augmenting the Global RPKI
   repository data as needed.  Since this mechanism (for augmenting and
   maintaining a local image of RPKI data) operates locally within an AS
   or AS confederation, it need not be standard based.  However, a
   standard-based mechanism can be used (see [SLURM]).  Recall that in
   order to prevent exposure of the internals of AS confederations, a

Top      Up      ToC       Page 32 
   BGPsec speaker exporting to a non-member removes all
   intra-confederation Secure_Path Segments and Signatures (see
   Section 4.3).

7.6.  Robustness Considerations for Accessing RPKI Data

   The deployment structure, technologies, and best practices concerning
   Global RPKI data to reach routers (via local RPKI caches) are
   described in [RFC6810], [RFC8210], [RFC8181], [RFC7115], [RFC8207],
   and [RFC8182].  For example, Serial-Number-based incremental update
   mechanisms are used for efficient transfer of just the data records
   that have changed since the last update [RFC6810] [RFC8210].  The
   update notification file is used by Relying Parties (RPs) to discover
   whether any changes exist between the state of the Global RPKI
   repository and the RP's cache [RFC8182].  The notification describes
   the location of (1) the files containing the snapshot and
   (2) incremental deltas, which can be used by the RP to synchronize
   with the repository.  Making use of these technologies and best
   practices results in enabling robustness, efficiency, and better
   security for the BGPsec routers and RPKI caches in terms of the flow
   of RPKI data from repositories to RPKI caches to routers.  With these
   mechanisms, it is believed that an attacker wouldn't be able to
   meaningfully correlate RPKI data flows with BGPsec RP (or router)
   actions, thus avoiding attacks that may attempt to determine the set
   of ASes interacting with an RP via the interactions between the RP
   and RPKI servers.

7.7.  Graceful Restart

   During Graceful Restart (GR), restarting and receiving BGPsec
   speakers MUST follow the procedures specified in [RFC4724] for
   restarting and receiving BGP speakers, respectively.  In particular,
   the behavior of retaining the forwarding state for the routes in the
   Loc-RIB [RFC4271] and marking them as stale, as well as not
   differentiating between stale routing information and other
   information during forwarding, will be the same as the behavior
   specified in [RFC4724].

7.8.  Robustness of Secret Random Number in ECDSA

   The Elliptic Curve Digital Signature Algorithm (ECDSA) with curve
   P-256 is used for signing UPDATE messages in BGPsec [RFC8208].  For
   ECDSA, it is stated in Section 6.3 of [FIPS186-4] that a new secret
   random number "k" shall be generated prior to the generation of each
   digital signature.  A high-entropy random bit generator (RBG) must be
   used for generating "k", and any potential bias in the "k" generation
   algorithm must be mitigated (see the methods described in [FIPS186-4]
   and [SP800-90A]).

Top      Up      ToC       Page 33 
7.9.  Incremental/Partial Deployment Considerations

   What will migration from BGP to BGPsec look like?  What are the
   benefits for the first adopters?  Initially, small groups of
   contiguous ASes would be doing BGPsec.  There would possibly be one
   or more such groups in different geographic regions of the global
   Internet.  Only the routes originated within each group and
   propagated within its borders would get the benefits of cryptographic
   AS path protection.  As BGPsec adoption grows, each group grows in
   size, and eventually they join together to form even larger
   BGPsec-capable groups of contiguous ASes.  The benefit for early
   adopters starts with AS path security within the regions of
   contiguous ASes spanned by their respective groups.  Over time, they
   would see those regions of contiguous ASes grow much larger.

   During partial deployment, if an AS in the path doesn't support
   BGPsec, then BGP goes back to traditional mode, i.e., BGPsec UPDATE
   messages are converted to unsigned UPDATE messages before forwarding
   to that AS (see Section 4.4).  At this point, the assurance that the
   UPDATE message propagated via the sequence of ASes listed is lost.
   In other words, for the BGPsec routers residing in the ASes starting
   from the origin AS to the AS before the one not supporting BGPsec,
   the assurance can still be provided, but not beyond that (for the
   UPDATE messages in consideration).

8.  Security Considerations

   For a discussion of the BGPsec threat model and related security
   considerations, please see RFC 7132 [RFC7132].

8.1.  Security Guarantees

   When used in conjunction with origin validation (see RFC 6483
   [RFC6483] and RFC 6811 [RFC6811]), a BGPsec speaker who receives a
   valid BGPsec UPDATE message containing a route advertisement for a
   given prefix is provided with the following security guarantees:

   o  The origin AS number corresponds to an AS that has been
      authorized, in the RPKI, by the IP address space holder to
      originate route advertisements for the given prefix.

   o  For each AS in the path, a BGPsec speaker authorized by the holder
      of the AS number intentionally chose (in accordance with local
      policy) to propagate the route advertisement to the subsequent AS
      in the path.

Top      Up      ToC       Page 34 
   That is, the recipient of a valid BGPsec UPDATE message is assured
   that the UPDATE message propagated via the sequence of ASes listed in
   the Secure_Path portion of the BGPsec_PATH attribute.  (It should be
   noted that BGPsec does not offer any guarantee that the data packets
   would flow along the indicated path; it only guarantees that the BGP
   UPDATE message conveying the path indeed propagated along the
   indicated path.)  Furthermore, the recipient is assured that this
   path terminates in an AS that has been authorized by the IP address
   space holder as a legitimate destination for traffic to the given
   prefix.

   Note that although BGPsec provides a mechanism for an AS to validate
   that a received UPDATE message has certain security properties, the
   use of such a mechanism to influence route selection is completely a
   matter of local policy.  Therefore, a BGPsec speaker can make no
   assumptions about the validity of a route received from an external
   (eBGP) BGPsec peer.  That is, a compliant BGPsec peer may (depending
   on the local policy of the peer) send UPDATE messages that fail the
   validity test in Section 5.  Thus, a BGPsec speaker MUST completely
   validate all BGPsec UPDATE messages received from external peers.
   (Validation of UPDATE messages received from internal peers is also a
   matter of local policy; see Section 5.)

8.2.  On the Removal of BGPsec Signatures

   There may be cases where a BGPsec speaker deems 'Valid' (as per the
   validation algorithm in Section 5.2) a BGPsec UPDATE message that
   contains both a 'Valid' and a 'Not Valid' Signature_Block.  That is,
   the UPDATE message contains two sets of signatures corresponding to
   two algorithm suites, and one set of signatures verifies correctly
   and the other set of signatures fails to verify.  In this case, the
   protocol specifies that a BGPsec speaker choosing to propagate the
   route advertisement in such an UPDATE message MUST add its signature
   to each of the Signature_Blocks (see Section 4.2).  Thus, the BGPsec
   speaker creates a signature using both algorithm suites and creates a
   new UPDATE message that contains both the 'Valid' and the 'Not Valid'
   set of signatures (from its own vantage point).

   To understand the reason for such a design decision, consider the
   case where the BGPsec speaker receives an UPDATE message with both a
   set of algorithm A signatures that are 'Valid' and a set of algorithm
   B signatures that are 'Not Valid'.  In such a case, it is possible
   (perhaps even likely, depending on the state of the algorithm
   transition) that some of the BGPsec speaker's peers (or other
   entities further downstream in the BGP topology) do not support
   algorithm A.  Therefore, if the BGPsec speaker were to remove the
   'Not Valid' set of signatures corresponding to algorithm B, such
   entities would treat the message as though it were unsigned.  By

Top      Up      ToC       Page 35 
   including the 'Not Valid' set of signatures when propagating a route
   advertisement, the BGPsec speaker ensures that downstream entities
   have as much information as possible to make an informed opinion
   about the validation status of a BGPsec UPDATE message.

   Note also that during a period of partial BGPsec deployment, a
   downstream entity might reasonably treat unsigned messages
   differently from BGPsec UPDATE messages that contain a single set of
   'Not Valid' signatures.  That is, by removing the set of 'Not Valid'
   signatures, the BGPsec speaker might actually cause a downstream
   entity to 'upgrade' the status of a route advertisement from
   'Not Valid' to unsigned.  Finally, note that in the above scenario,
   the BGPsec speaker might have deemed algorithm A signatures 'Valid'
   only because of some issue with the RPKI state local to its AS (for
   example, its AS might not yet have obtained a Certificate Revocation
   List (CRL) indicating that a key used to verify an algorithm A
   signature belongs to a newly revoked certificate).  In such a case,
   it is highly desirable for a downstream entity to treat the UPDATE
   message as 'Not Valid' (due to the revocation) and not as 'unsigned'
   (which would happen if the 'Not Valid' Signature_Blocks were removed
   en route).

   A similar argument applies to the case where a BGPsec speaker (for
   some reason, such as a lack of viable alternatives) selects as its
   best path (to a given prefix) a route obtained via a 'Not Valid'
   BGPsec UPDATE message.  In such a case, the BGPsec speaker should
   propagate a signed BGPsec UPDATE message, adding its signature to the
   'Not Valid' signatures that already exist.  Again, this is to ensure
   that downstream entities are able to make an informed decision and
   not erroneously treat the route as unsigned.  It should also be noted
   that due to possible differences in RPKI data observed at different
   vantage points in the network, a BGPsec UPDATE message deemed 'Not
   Valid' at an upstream BGPsec speaker may be deemed 'Valid' by another
   BGP speaker downstream.

   Indeed, when a BGPsec speaker signs an outgoing UPDATE message, it is
   not attesting to a belief that all signatures prior to its own
   signature are valid.  Instead, it is merely asserting that:

   o  The BGPsec speaker received the given route advertisement with the
      indicated prefix, AFI, SAFI, and Secure_Path, and

   o  The BGPsec speaker chose to propagate an advertisement for this
      route to the peer (implicitly) indicated by the 'Target AS
      Number'.

Top      Up      ToC       Page 36 
8.3.  Mitigation of Denial-of-Service Attacks

   The BGPsec update validation procedure is a potential target for
   denial-of-service attacks against a BGPsec speaker.  The mitigation
   of denial-of-service attacks that are specific to the BGPsec protocol
   is considered here.

   To mitigate the effectiveness of such denial-of-service attacks,
   BGPsec speakers should implement an update validation algorithm that
   performs expensive checks (e.g., signature verification) after
   performing checks that are less expensive (e.g., syntax checks).  The
   validation algorithm specified in Section 5.2 was chosen so as to
   perform checks that are likely to be expensive after checks that are
   likely to be inexpensive.  However, the relative cost of performing
   required validation steps may vary between implementations, and thus
   the algorithm specified in Section 5.2 may not provide the best
   denial-of-service protection for all implementations.

   Additionally, sending UPDATE messages with very long AS paths (and
   hence a large number of signatures) is a potential mechanism to
   conduct denial-of-service attacks.  For this reason, it is important
   that an implementation of the validation algorithm stops attempting
   to verify signatures as soon as an invalid signature is found.  (This
   ensures that long sequences of invalid signatures cannot be used for
   denial-of-service attacks.)  Furthermore, implementations can
   mitigate such attacks by only performing validation on UPDATE
   messages that, if valid, would be selected as the best path.  That
   is, if an UPDATE message contains a route that would lose out in best
   path selection for other reasons (e.g., a very long AS path), then it
   is not necessary to determine the BGPsec-validity status of the
   route.

8.4.  Additional Security Considerations

   The mechanism of setting the pCount field to 0 is included in this
   specification to enable route servers in the control path to
   participate in BGPsec without increasing the length of the AS path.
   Two other scenarios where pCount=0 is utilized are in the contexts of
   an AS confederation (see Section 4.3) and of AS migration [RFC8206].
   In these two scenarios, pCount=0 is set and also accepted within the
   same AS (albeit the AS has two different identities).  However,
   entities other than route servers, confederation ASes, or migrating
   ASes could conceivably use this mechanism (set the pCount to 0) to
   attract traffic (by reducing the length of the AS path)
   illegitimately.  This risk is largely mitigated if every BGPsec
   speaker follows the operational guidance in Section 7.2 for
   configuration for setting pCount=0 and/or accepting pCount=0 from a
   peer.  However, note that a recipient of a BGPsec UPDATE message

Top      Up      ToC       Page 37 
   within which an upstream entity two or more hops away has set pCount
   to 0 is unable to verify for themselves whether pCount was set to 0
   legitimately.

   There is a possibility of passing a BGPsec UPDATE message via
   tunneling between colluding ASes.  For example, let's say that AS-X
   does not peer with AS-Y but colludes with AS-Y, and it signs and
   sends a BGPsec UPDATE message to AS-Y by tunneling.  AS-Y can then
   further sign and propagate the BGPsec UPDATE message to its peers.
   It is beyond the scope of the BGPsec protocol to detect this form of
   malicious behavior.  BGPsec is designed to protect messages sent
   within BGP (i.e., within the control plane) -- not when the control
   plane is bypassed.

   A variant of the collusion by tunneling mentioned above can happen in
   the context of AS confederations.  When a BGPsec router (outside of a
   confederation) is forwarding an UPDATE message to a Member-AS in the
   confederation, it signs the UPDATE message to the public AS number of
   the confederation and not to the member's AS number (see
   Section 4.3).  The Member-AS can tunnel the signed UPDATE message to
   another Member-AS as received (i.e., without adding a signature).
   The UPDATE message can then be propagated using BGPsec to other
   confederation members or to BGPsec neighbors outside of the
   confederation.  This kind of operation is possible, but no grave
   security or reachability compromise is feared for the following
   reasons:

   o  The confederation members belong to one organization, and strong
      internal trust is expected.

   o  Recall that the signatures that are internal to the confederation
      MUST be removed prior to forwarding the UPDATE message to an
      outside BGPsec router (see Section 4.3).

   BGPsec does not provide protection against attacks at the transport
   layer.  As with any BGP session, an adversary on the path between a
   BGPsec speaker and its peer is able to perform attacks such as
   modifying valid BGPsec UPDATE messages to cause them to fail
   validation, injecting (unsigned) BGP UPDATE messages without
   BGPsec_PATH attributes, injecting BGPsec UPDATE messages with
   BGPsec_PATH attributes that fail validation, or causing the peer to
   tear down the BGP session.  The use of BGPsec does nothing to
   increase the power of an on-path adversary -- in particular, even an
   on-path adversary cannot cause a BGPsec speaker to believe that a
   BGPsec-invalid route is valid.  However, as with any BGP session,
   BGPsec sessions SHOULD be protected by appropriate transport security
   mechanisms (see the Security Considerations section in [RFC4271]).

Top      Up      ToC       Page 38 
   There is a possibility of replay attacks, defined as follows.  In the
   context of BGPsec, a replay attack occurs when a malicious BGPsec
   speaker in the AS path suppresses a prefix withdrawal (implicit or
   explicit).  Further, a replay attack is said to occur also when a
   malicious BGPsec speaker replays a previously received BGPsec
   announcement for a prefix that has since been withdrawn.  The
   mitigation strategy for replay attacks involves router certificate
   rollover; please see [ROLLOVER] for details.

9.  IANA Considerations

   IANA has registered a new BGP capability described in Section 2.1 in
   the "Capability Codes" registry's "IETF Review" range [RFC8126].  The
   description for the new capability is "BGPsec Capability".  This
   document is the reference for the new capability.

   IANA has also registered a new path attribute described in Section 3
   in the "BGP Path Attributes" registry.  The code for this new
   attribute is "BGPsec_PATH".  This document is the reference for the
   new attribute.

   IANA has defined the "BGPsec Capability" registry in the "Resource
   Public Key Infrastructure (RPKI)" group.  The registry is as shown in
   Figure 10, with values assigned from Section 2.1:

        +------+------------------------------------+------------+
        | Bits | Field                              | Reference  |
        +------+------------------------------------+------------+
        | 0-3  | Version                            | [RFC8205]  |
        |      | Value = 0x0                        |            |
        +------+------------------------------------+------------+
        | 4    | Direction                          | [RFC8205]  |
        |      |(Both possible values 0 and 1 are   |            |
        |      | fully specified by this RFC)       |            |
        +------+------------------------------------+------------+
        | 5-7  | Unassigned                         | [RFC8205]  |
        |      | Value = 000 (in binary)            |            |
        +------+------------------------------------+------------+

              Figure 10: IANA Registry for BGPsec Capability

   The Direction bit (fourth bit) has a value of either 0 or 1, and both
   values are fully specified by this document.  Future Version values
   and future values of the Unassigned bits are assigned using the
   "Standards Action" registration procedures defined in RFC 8126
   [RFC8126].

Top      Up      ToC       Page 39 
   IANA has defined the "BGPsec_PATH Flags" registry in the "Resource
   Public Key Infrastructure (RPKI)" group.  The registry is as shown in
   Figure 11, with one value assigned from Section 3.1:

     +------+-------------------------------------------+------------+
     | Flag | Description                               | Reference  |
     +------+-------------------------------------------+------------+
     | 0    | Confed_Segment                            | [RFC8205]  |
     |      | Bit value = 1 means Flag set              |            |
     |      |                (indicates Confed_Segment) |            |
     |      | Bit value = 0 is default                  |            |
     +------+-------------------------------------------+------------+
     | 1-7  | Unassigned                                | [RFC8205]  |
     |      | Value: All 7 bits set to zero             |            |
     +------+-------------------------------------------+------------+

           Figure 11: IANA Registry for BGPsec_PATH Flags Field

   Future values of the Unassigned bits are assigned using the
   "Standards Action" registration procedures defined in RFC 8126
   [RFC8126].

10.  References

10.1.  Normative References

   [IANA-AF]  IANA, "Address Family Numbers",
              <https://www.iana.org/assignments/address-family-numbers>.

   [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>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4724]  Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
              Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
              DOI 10.17487/RFC4724, January 2007,
              <https://www.rfc-editor.org/info/rfc4724>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.

Top      Up      ToC       Page 40 
   [RFC5065]  Traina, P., McPherson, D., and J. Scudder, "Autonomous
              System Confederations for BGP", RFC 5065,
              DOI 10.17487/RFC5065, August 2007,
              <https://www.rfc-editor.org/info/rfc5065>.

   [RFC5492]  Scudder, J. and R. Chandra, "Capabilities Advertisement
              with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
              2009, <https://www.rfc-editor.org/info/rfc5492>.

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,
              <https://www.rfc-editor.org/info/rfc6482>.

   [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>.

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793,
              DOI 10.17487/RFC6793, December 2012,
              <https://www.rfc-editor.org/info/rfc6793>.

   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <https://www.rfc-editor.org/info/rfc7606>.

   [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,
              <https://www.rfc-editor.org/info/rfc8208>.

   [RFC8209]  Reynolds, M., Turner, S., and S. Kent, "A Profile for
              BGPsec Router Certificates, Certificate Revocation Lists,
              and Certification Requests", RFC 8209,
              DOI 10.17487/RFC8209, September 2017,
              <https://www.rfc-editor.org/info/rfc8209>.

Top      Up      ToC       Page 41 
10.2.  Informative References

   [Borchert] Borchert, O. and M. Baer, "Subject: Modification request:
              draft-ietf-sidr-bgpsec-protocol-14", message to the IETF
              SIDR WG Mailing List, 10 February 2016,
              <https://mailarchive.ietf.org/arch/msg/
              sidr/8B_e4CNxQCUKeZ_AUzsdnn2f5Mu>.

   [FIPS186-4]
              National Institute of Standards and Technology, "Digital
              Signature Standard (DSS)", NIST FIPS Publication
              186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013,
              <http://nvlpubs.nist.gov/nistpubs/FIPS/
              NIST.FIPS.186-4.pdf>.

   [RFC6472]  Kumari, W. and K. Sriram, "Recommendation for Not Using
              AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472,
              DOI 10.17487/RFC6472, December 2011,
              <https://www.rfc-editor.org/info/rfc6472>.

   [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>.

   [RFC6483]  Huston, G. and G. Michaelson, "Validation of Route
              Origination Using the Resource Certificate Public Key
              Infrastructure (PKI) and Route Origin Authorizations
              (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
              <https://www.rfc-editor.org/info/rfc6483>.

   [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>.

   [RFC7093]  Turner, S., Kent, S., and J. Manger, "Additional Methods
              for Generating Key Identifiers Values", RFC 7093,
              DOI 10.17487/RFC7093, December 2013,
              <https://www.rfc-editor.org/info/rfc7093>.

Top      Up      ToC       Page 42 
   [RFC7115]  Bush, R., "Origin Validation Operation Based on the
              Resource Public Key Infrastructure (RPKI)", BCP 185,
              RFC 7115, DOI 10.17487/RFC7115, January 2014,
              <https://www.rfc-editor.org/info/rfc7115>.

   [RFC7132]  Kent, S. and A. Chi, "Threat Model for BGP Path Security",
              RFC 7132, DOI 10.17487/RFC7132, February 2014,
              <https://www.rfc-editor.org/info/rfc7132>.

   [RFC8181]  Weiler, S., Sonalker, A., and R. Austein, "A Publication
              Protocol for the Resource Public Key Infrastructure
              (RPKI)", July 2017,
              <https://www.rfc-editor.org/info/rfc8181>.

   [RFC8182]  Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
              "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
              DOI 10.17487/RFC8182, July 2017,
              <https://www.rfc-editor.org/info/rfc8182>.

   [RFC8206]  George, W. and S. Murphy, "BGPsec Considerations for
              Autonomous System (AS) Migration", RFC 8206,
              DOI 10.17487/RFC8206, September 2017,
              <https://www.rfc-editor.org/info/rfc8206>.

   [RFC8207]  Bush, R., "BGPsec Operational Considerations", BCP 211,
              RFC 8207, DOI 10.17487/RFC8207, September 2017,
              <https://www.rfc-editor.org/info/rfc8207>.

   [RFC8210]  Bush, R. and R. Austein, "The Resource Public Key
              Infrastructure (RPKI) to Router Protocol, Version 1",
              RFC 8210, DOI 10.17487/RFC8210, September 2017,
              <https://www.rfc-editor.org/info/rfc8210>.

   [ROLLOVER] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router
              Certificate Rollover", Work in Progress,
              draft-ietf-sidrops-bgpsec-rollover-01, August 2017.

   [SLURM]    Mandelberg, D., Ma, D., and T. Bruijnzeels, "Simplified
              Local internet nUmber Resource Management with the RPKI",
              Work in Progress, draft-ietf-sidr-slurm-04, March 2017.

   [SP800-90A]
              National Institute of Standards and Technology,
              "Recommendation for Random Number Generation Using
              Deterministic Random Bit Generators", NIST SP 800-90A
              Rev 1, DOI 10.6028/NIST.SP.800-90Ar1, June 2015,
              <http://nvlpubs.nist.gov/nistpubs/SpecialPublications/
              NIST.SP.800-90Ar1.pdf>.

Top      Up      ToC       Page 43 
Acknowledgements

   The authors would like to thank Michael Baer, Oliver Borchert, David
   Mandelberg, Mehmet Adalier, Sean Turner, Wes George, Jeff Haas,
   Alvaro Retana, Nevil Brownlee, Matthias Waehlisch, Tim Polk, Russ
   Mundy, Wes Hardaker, Sharon Goldberg, Ed Kern, Doug Maughan, Pradosh
   Mohapatra, Mark Reynolds, Heather Schiller, Jason Schiller, Ruediger
   Volk, and David Ward for their review, comments, and suggestions
   during the course of this work.  Thanks are also due to many IESG
   reviewers whose comments greatly helped improve the clarity,
   accuracy, and presentation in the document.

   The authors particularly wish to acknowledge Oliver Borchert and
   Michael Baer for their review and suggestions [Borchert] concerning
   the sequence of octets to be hashed (Figures 8 and 9 in Sections 4.2
   and 5.2, respectively).  This was an important contribution based on
   their implementation experience.

Top      Up      ToC       Page 44 
Contributors

   The following people have made significant contributions to this
   document and should be considered co-authors:

   Rob Austein
   Dragon Research Labs
   Email: sra@hactrn.net

   Steven Bellovin
   Columbia University
   Email: smb@cs.columbia.edu

   Russ Housley
   Vigil Security
   Email: housley@vigilsec.com

   Stephen Kent
   BBN Technologies
   Email: kent@alum.mit.edu

   Warren Kumari
   Google
   Email: warren@kumari.net

   Doug Montgomery
   USA National Institute of Standards and Technology
   Email: dougm@nist.gov

   Chris Morrow
   Google, Inc.
   Email: morrowc@google.com

   Sandy Murphy
   SPARTA, Inc., a Parsons Company
   Email: sandy@tislabs.com

   Keyur Patel
   Arrcus
   Email: keyur@arrcus.com

   John Scudder
   Juniper Networks
   Email: jgs@juniper.net

   Samuel Weiler
   W3C/MIT
   Email: weiler@csail.mit.edu

Top      Up      ToC       Page 45 
Authors' Addresses

   Matthew Lepinski (editor)
   New College of Florida
   5800 Bay Shore Road
   Sarasota, FL  34243
   United States of America

   Email: mlepinski@ncf.edu


   Kotikalapudi Sriram (editor)
   USA National Institute of Standards and Technology
   100 Bureau Drive
   Gaithersburg, MD  20899
   United States of America

   Email: kotikalapudi.sriram@nist.gov