in Index   Prev   Next

RFC 8374

BGPsec Design Choices and Summary of Supporting Discussions

Pages: 50
Part 3 of 3 – Pages 33 to 50
First   Prev   None

Top   ToC   RFC8374 - Page 33   prevText

8. BGPsec Validation

8.1. Sequence of BGPsec Validation Processing in a Receiver

It is natural to ask in what sequence a receiver must perform BGPsec update validation so that if a failure were to occur (i.e., the update was determined to be invalid) the processor would have spent the least amount of processing or other resources.

8.1.1. Decision

There was agreement that the following sequence of receiver operations is quite meaningful; the following steps are included in [BGPsec-Initial]. However, the ordering of these validation- processing steps is not a normative part of the BGPsec specification. 1. Verify that the signed update is syntactically correct. For example, check to see if the number of signatures matches the number of ASes in the AS path (after duly accounting for AS prepending). 2. Verify that the origin AS is authorized to advertise the prefix in question. This verification is based on data from ROAs and does not require any cryptographic operations. 3. Verify that the advertisement has not yet expired. 4. Verify that the target ASN in the signature data matches the ASN of the router that is processing the advertisement. Note that the target-ASN check is also a non-cryptographic operation and is fast. 5. Validate the signature data starting from the most recent AS to the origin. 6. Locate the public key for the router from which the advertisement was received, using the SKI from the signature data. 7. Hash the data covered by the signature algorithm. Invoke the signature validation algorithm on the following three inputs: the locally computed hash, the received signature, and the public key. There will be one output: valid or invalid. 8. Repeat steps 5 and 6 for each preceding signature in the Signature_Block until (a) the signature data for the origin AS is encountered and processed or (b) either of these steps fails.
Top   ToC   RFC8374 - Page 34
   Note: Significant refinements to the above list occurred in the
   progress towards RFC 8205.  The detailed syntactic-error checklist is
   presented and explained in Section 5.2 of [RFC8205].  Also, a logical
   sequence of steps to be followed in the validation of
   Signature_Blocks is described in Section 5.2 of [RFC8205].

8.1.2. Discussion

If the goal is to minimize computational costs associated with cryptographic operations, the sequence of receiver operations that is suggested above is viewed as appropriate. One additional interesting suggestion was that when there are two Signature_Blocks in an update, the validating router can first verify which of the two algorithms is cheaper, to save on processing. If that Signature_Block verifies, then the router can skip validating the other Signature_Block.

8.2. Signing and Forwarding Updates when Signatures Failed Validation

8.2.1. Decision

A BGPsec router should sign and forward a signed update to upstream peers if it selected the update as the best path, regardless of whether the update passed or failed validation (at this router).

8.2.2. Discussion

The availability of RPKI data at different routers (in the same AS or different ASes) may differ, depending on the sources used to acquire RPKI data. Hence, an update may fail validation in one AS, and the same update may pass validation in another AS. Also, an update may fail validation at one router in an AS, and the same update may pass validation at another router in the same AS. A BCP may be published later that will identify some update-failure conditions that may present unambiguous cases for rejecting the update (in which case the router would not select the AS path in the update). These cases are "TBD" (to be determined).
Top   ToC   RFC8374 - Page 35

8.3. Enumeration of Error Conditions

Enumeration of error conditions and the recommendations for how to react to them are still under discussion.

8.3.1. Decision

TBD. Also, please see Section 8.5 for the decision and discussion specifically related to syntactic errors in signatures. Note: Section 5.2 of RFC 8205 describes the detection of syntactic and protocol errors in BGPsec updates as well as how the updates with such errors are to be handled.

8.3.2. Discussion

The following list is a first attempt to provide some possible error conditions and recommended receiver reactions in response to the detection of those errors. Refinements will follow after further discussions. E1 Abnormalities where a peer (i.e., the preceding AS) should definitely not have propagated to a receiving eBGPsec router. For example, (A) the number of signatures does not match the number of ASes in the AS path (after accounting for AS prepending), (B) there is an AS_SET in the received update and the update has signatures, or (C) other syntactic errors with signatures have occurred. Reaction: See Section 8.5. E2 Situations where a receiving eBGPsec router cannot find the certificate for an AS in the AS path. Reaction: Mark the update as "Invalid". It is acceptable to consider the update in the best-path selection. If it is chosen, then the router should sign and propagate the update. E3 Situations where a receiving eBGPsec router cannot find a ROA for the {prefix, origin} pair in the update. Reaction: Same as in (E2) above. E4 Situations where the receiving eBGPsec router verifies signatures and finds that the update is "Invalid" (even though its peer might not have known, e.g., due to RPKI skew). Reaction: Same as in (E2) above.
Top   ToC   RFC8374 - Page 36
       In some networks, the best-path-selection policy may specify
       choosing an unsigned update over one with invalid signature(s).
       Hence, the signatures must not be stripped even if the update is
       "Invalid".  No evil bit is set in the update (when it is
       "Invalid") because an upstream peer may not get that same answer
       when it tries to validate.

8.4. Procedure for Processing Unsigned Updates

An update may come in unsigned from an eBGP peer or internally (e.g., as an iBGP update). In the latter case, the route is being originated from within the AS in question.

8.4.1. Decision

If an unsigned route is received from an eBGP peer and if it is selected, then the route will be forwarded unsigned to other eBGP peers -- even BGPsec-capable peers. If the route originated in this AS (IGP or iBGP) and is unsigned, then it should be signed and announced to external BGPsec-capable peers.

8.4.2. Discussion

It is also possible that an update received in IGP (or iBGP) may have private ASNs in the AS path. These private ASNs would normally appear in the rightmost portion of the AS path. It was noted that in this case the private ASNs to the right would be removed (as done in traditional BGP), and then the update will be signed by the originating AS and announced to BGPsec-capable eBGP peers. Note: See Section 7.5 of [RFC8205] for operational considerations for BGPsec in the context of private ASNs.

8.5. Response to Syntactic Errors in Signatures and Recommendations for How to React to Them

Note: The contents of this subsection (i.e., Section 8.5) differ substantially from the recommendations in RFC 8205 regarding the handling of syntactic errors and protocol errors. Hence, the reader may skip this subsection and instead read Section 5.2 of [RFC8205]. This subsection (Section 8.5) is kept here for the sake of archival value concerning design discussions. Different types of error conditions were discussed in Section 8.3. Here, the focus is only on syntactic-error conditions in signatures.
Top   ToC   RFC8374 - Page 37

8.5.1. Decision

If there are syntactic-error conditions such as (A) AS_SET and BGPsec_PATH both appearing in an update, (B) the number of signatures not matching the number of ASes (after accounting for any AS prepending), or (C) a parsing issue occurring with the BGPsec_PATH attribute, then the update (with the signatures stripped) will still be considered in the best-path-selection algorithm. (**Note: This is not true in RFC 8205**.) If the update is selected as the best path, then the update will be propagated unsigned. The error condition will be logged locally. A BGPsec router will follow whatever the current IETF (IDR WG) recommendations are for notifying a peer that it is sending malformed messages. In the case when there are two Signature_Blocks in an update, and one or more syntactic errors are found to occur within one of them but the other one is free of any syntactic errors, then the update will still be considered in the best-path-selection algorithm after the syntactically bad Signature_Block has been removed. (**Note: This is not true in RFC 8205**.) If the update is selected as the best path, then the update will be propagated with only one (i.e., the error-free) Signature_Block. The error condition will be logged locally.

8.5.2. Discussion

As stated above, a BGPsec router will follow whatever the current IETF (IDR WG) recommendations are for notifying a peer that it is sending malformed messages. Question: If the error is persistent and a full BGP table dump occurs, then would there be 500K such errors resulting in 500K "notify" messages sent to the peer that is generating the errors? Answer: Rate limiting would be applied to the notify messages and should prevent any overload due to these messages.

8.6. Enumeration of Validation States

Various validation conditions are possible that can be mapped to validation states for possible input to the BGPsec decision process. These conditions can be related to whether an update is signed, Expire Time is checked, route origin validation is checked against a ROA, signature verification passed, etc.
Top   ToC   RFC8374 - Page 38

8.6.1. Decision

It was decided that BGPsec validation outcomes will be mapped to one of only two validation states: (1) Valid -- passed all validation checks (i.e., Expire Time check, route origin and Signature_Block validation) and (2) Invalid -- all other possibilities. "Invalid" would include situations such as the following: 1. Due to a lack of RPKI data or insufficient RPKI data, validation was not performed. 2. The signature Expire Time check failed. 3. Route origin validation failed. 4. Signature checks were performed, and one or more of them failed. Note: Expire Time is obsolete (see the notes in Sections 2.2.1 and 2.2.2). RFC 8205 uses the states "Valid" and "Not Valid", but only with respect to AS path validation (i.e., not including the result of origin validation); see Section 5.1 of [RFC8205]. "Not Valid" includes all conditions in which path validation was attempted but a "Valid" result could not be reached. (Note: Path validation is not attempted in the case of syntactic or protocol errors in a BGPsec update; see Section 5.2 of [RFC8205].) Each Relying Party (RP) is expected to devise its own policy to suitably factor the results of origin validation [RFC6811] and path validation [RFC8205] into its path-selection decision.

8.6.2. Discussion

It may be noted that the result of update validation is just an additional input for the BGP decision process. The router's local policy ultimately has control over what action (regarding BGP path selection) is taken. Initially, four validation states were considered: 1. The update is not signed. 2. The update is signed, but the router does not have corresponding RPKI data to perform a validation check. 3. The validation check was performed, and the check failed (Invalid). 4. The validation check was performed, and the check passed (Valid).
Top   ToC   RFC8374 - Page 39
   As stated above, it was later decided that BGPsec validation outcomes
   will be mapped to one of only two validation states.  It was observed
   that an update can be invalid for many different reasons.  To begin
   to differentiate these numerous reasons and to try to enumerate
   different flavors of the Invalid state will not likely be
   constructive in route-selection decisions and may even introduce new
   vulnerabilities in the system.  However, some questions remain, such
   as the following:

   Question: Is there a need to define a separate validation state for
   the case when an update is not signed but the {prefix, origin} pair
   matches the ROA information?  After some discussion, a tentative
   conclusion was reached: this is in principle similar to validation
   based on partial path signing (which was ruled out; see Section 6.4).
   So, there is no need to add another validation state for this case;
   treat it as "Invalid", considering that it is unsigned.

   Another remaining question: Would the RP want to give the update a
   higher preference over another unsigned update that failed origin
   validation or over a signed update that failed both signature and ROA

8.7. Mechanism for Transporting Validation State through iBGP

8.7.1. Decision

BGPsec validation need be performed only at eBGP edges. The validation status of a BGP signed/unsigned update may be conveyed via iBGP from an ingress edge router to an egress edge router. Local policy in the AS will determine how the validation status is conveyed internally, using various preexisting mechanisms, e.g., setting a BGP community, or modifying a metric value such as Local_Pref or MED. A signed update that cannot be validated (except those with syntax errors) should be forwarded with signatures from the ingress router to the egress router, where it is signed when propagated towards other eBGPsec speakers in neighboring ASes. Based entirely on local policy settings, an egress router may trust the validation status conveyed by an ingress router, or it may perform its own validation. The latter approach may be used at an operator's discretion, under circumstances when RPKI skew is known to happen at different routers within an AS. Note: An extended community for carrying the origin validation state in iBGP has been specified in RFC 8097 [RFC8097].
Top   ToC   RFC8374 - Page 40

8.7.2. Discussion

The attribute used to represent the validation state can be carried between ASes, if desired. ISPs may like to carry it over their eBGP links between their own ASes (e.g., sibling ASes). A peer (or customer) may receive it over an eBGP link from a provider and may want to use it to shortcut their own validation check. However, the peer (or customer) should be aware that this validation-state attribute is just a preview of a neighbor's validation and must perform their own validation check to be sure of the actual state of the update's validation. Question: Should validation-state propagation be protected by attestation in cases where it is useful for diagnostics purposes? The decision was made to not protect the validation-state information using signatures. The following validation states may be needed for propagation via iBGP between edge routers in an AS: o Validation states communicated in iBGP for an unsigned update (route origin validation result): (1) Valid, (2) Invalid, (3) NotFound (see [RFC6811]), (4) Validation Deferred. * An update could be unsigned for either of the following two reasons, but they need not be distinguished: (a) it had no signatures (i.e., came in unsigned from an eBGP peer) or (b) signatures were present but stripped. o Validation states communicated in iBGP for a signed update: (1) Valid, (2) Invalid, (3) Validation Deferred. The reason for conveying the additional "Validation Deferred" state may be illustrated as follows. An ingress edge Router A receiving an update from an eBGPsec peer may not attempt to validate signatures (e.g., in a processor overload situation), and in that case Router A should convey "Validation Deferred" state for that signed update (if selected for best path) in iBGP to other edge routers. An egress edge Router B, upon receiving the update from ingress Router A, would then be able to perform its own validation (origin validation for an unsigned update or origin/signature validation for a signed update). As stated before, the egress router (Router B in this example) may always choose to perform its own validation when it receives an update from iBGP (independently of the update's validation status conveyed in iBGP) to account for the possibility of RPKI data skew at different routers. These various choices are local and entirely at the operator's discretion.
Top   ToC   RFC8374 - Page 41

9. Operational Considerations

Note: Significant thought has been devoted to operations and management considerations subsequent to the writing of [BGPsec-Initial]. The reader is referred to [RFC8207] and Section 7 of [RFC8205] for details.

9.1. Interworking with BGP Graceful Restart

BGP Graceful Restart (BGP-GR) [RFC4724] is a mechanism currently used to facilitate nonstop packet forwarding when the control plane is recovering from a fault (i.e., the BGP session is restarted) but the data plane is functioning. Two questions were raised: Are there any special concerns about how BGP-GR works while BGPsec is operational? Also, what happens if the BGP router operation transitions from traditional BGP operation to BGP-GR to BGPsec, in that order?

9.1.1. Decision

No decision was made relative to this issue (at the time that [BGPsec-Initial] was written). Note: See Section 7.7 of [RFC8205] for comments concerning the operation of BGP-GR with BGPsec. They are consistent with the discussion below.

9.1.2. Discussion

BGP-GR can be implemented with BGPsec, just as it is currently implemented with traditional BGP. The Restart State bit, Forwarding State bit, End-of-RIB marker, staleness marker (in the Adj-RIB-In), and Selection_Deferral_Timer are key parameters associated with BGP-GR [RFC4724]. These parameters would apply to BGPsec, just as they apply to traditional BGP. Regarding what happens if the BGP router transitions from traditional BGP to BGP-GR to BGPsec, the answer would simply be as follows. If there is a software upgrade to BGPsec during BGP-GR (assuming that the upgrade is being done on a live BGP speaker), then the BGP-GR session should be terminated before a BGPsec session is initiated. Once the eBGPsec peering session is established, the receiving eBGPsec speaker will see signed updates from the sending (newly upgraded) eBGPsec speaker. There is no apparent harm (it may, in fact, be desirable) if the receiving speaker continues to use previously learned unsigned BGP routes from the sending speaker until they are replaced by new BGPsec routes. However, if the Forwarding State bit is set to zero by the sending speaker (i.e., the newly upgraded speaker) during BGPsec session negotiation, then the
Top   ToC   RFC8374 - Page 42
   receiving speaker would mark all previously learned unsigned BGP
   routes from that sending speaker as "stale" in its Adj-RIB-In.  Then,
   as BGPsec updates are received (possibly interspersed with unsigned
   BGP updates), the "stale" routes will be replaced or refreshed.

9.2. BCP Recommendations for Minimizing Churn: Certificate Expiry/ Revocation and Signature Expire Time

9.2.1. Decision

Work related to this topic is still in progress.

9.2.2. Discussion

BCP recommendations for minimizing churn in BGPsec have been discussed. There are various potential strategies on how routers should react to such events as certificate expiry/revocation and signature Expire Time exhaustion [Dynamics]. The details will be documented in the near future after additional work is completed.

9.3. Outsourcing Update Validation

9.3.1. Decision

Update signature validation and signing can be outsourced to an off-board server or processor.

9.3.2. Discussion

Possibly, an off-router box (one or more per AS) can be used that performs path validation. For example, these capabilities might be incorporated into a route reflector. At an ingress router, one needs the Adj-RIB-In entries validated but not the RIB-out entries. So, the off-router box is probably unlike the traditional route reflector; it sits at the network edge and validates all incoming BGPsec updates. Thus, it appears that each router passes each BGPsec update it receives to the off-router box and receives a validation result before it stores the route in the Adj-RIB-In. Question: What about failure modes here? The failure modes would be dependent on the following: 1. How much of the control plane is outsourced. 2. How reliable the off-router box is (or, equivalently, communication to and from it). 3. How centralized vs. distributed this arrangement is.
Top   ToC   RFC8374 - Page 43
   When any kind of outsourcing is done, the user needs to be watchful
   and ensure that the outsourcing does not cross trust/security

9.4. New Hardware Capability

9.4.1. Decision

It is assumed that BGPsec routers (Provider Edge (PE) routers and route reflectors) will require significantly upgraded hardware -- much more memory for RIBs and hardware cryptographic assistance. However, stub ASes would not need to make such upgrades because they can negotiate asymmetric BGPsec capability with their upstream ASes, i.e., they sign updates to the upstream AS but receive only unsigned BGP updates (see Section 6.5).

9.4.2. Discussion

It is accepted that it might take several years to go beyond test deployment of BGPsec because of the need for additional route processor CPU and memory. However, because BGPsec deployment will be incremental and because signed updates are not sent outside of a set of contiguous BGPsec-enabled ASes, it is not clear how much additional (RIB) memory will be required during initial deployment. See [RIB_size] for preliminary results on modeling and estimation of BGPsec RIB size and its projected growth. Hardware cryptographic support reduces the computation burden on the route processor and offers good security for router private keys. However, given the incremental-deployment model, it also is not clear how substantial a cryptographic processing load will be incurred in the early phases of deployment. Note: There are recent detailed studies that considered software optimizations for BGPsec. In [Mehmet1] and [Mehmet2], computational optimizations for cryptographic processing (i.e., ECDSA speedup) are considered for BGPsec implementations on general-purpose CPUs. In [V_Sriram], software optimizations at the level of update processing and path selection are proposed and quantified for BGPsec implementations.
Top   ToC   RFC8374 - Page 44

9.5. Signed Peering Registrations

9.5.1. Decision

The idea of signed BGP peering registrations (for the purpose of path validation) was rejected.

9.5.2. Discussion

The idea of using a secure map of AS relationships to "validate" updates was discussed and rejected: such solutions were not pursued because they cannot provide strong guarantees regarding the validity of updates. Using these techniques, one can say only that an update is "plausible"; one cannot say that it is "definitely" valid (based on signed peering relations alone).

10. Security Considerations

This document requires no security considerations. See [RFC8205] for security considerations for the BGPsec protocol.

11. IANA Considerations

This document has no IANA actions.

12. Informative References

[ASset] Sriram, K. and D. Montgomery, "Measurement Data on AS_SET and AGGREGATOR: Implications for {Prefix, Origin} Validation Algorithms", IETF SIDR WG presentation, IETF 78, July 2010, < AS_SET_Aggregator_Stats.pdf>. [BGP-Ext-Msg] Bush, R., Patel, K., and D. Ward, "Extended Message support for BGP", Work in Progress, draft-ietf-idr-bgp- extended-messages-24, November 2017. [BGPsec-Initial] Lepinski, M., "BGPSEC Protocol Specification", Work in Progress, draft-lepinski-bgpsec-protocol-00, March 2011. [BGPsec-Rollover] Weis, B., Gagliano, R., and K. Patel, "BGPsec Router Certificate Rollover", Work in Progress, draft-ietf- sidrops-bgpsec-rollover-04, December 2017.
Top   ToC   RFC8374 - Page 45
              Borchert, O. and M. Baer, "Subject: Modifiation [sic]
              request: draft-ietf-sidr-bgpsec-protocol-14", message to
              the IETF SIDR WG Mailing List, 10 February 2016,

              "Cisco IOS: Configuring Route Dampening", February 2014,

              Sriram, K. and R. Bush, "Estimating CPU Cost of BGPSEC on
              a Router", Presented at RIPE-63; also at IETF 83 SIDR WG
              Meeting, March 2012, <

              Sriram, K., Montgomery, D., Borchert, O., Kim, O., and P.
              Gleichmann, "Potential Impact of BGPSEC Mechanisms on
              Global BGP Dynamics", Presentation to the BGPsec
              authors/designers team, October 2009,

   [Gueron]   Gueron, S. and V. Krasnov, "Fast and side channel
              protected implementation of the NIST P-256 Elliptic Curve
              for x86-64 platforms", OpenSSL patch ID 3149,
              October 2013, <

   [JunOS]    "Juniper JunOS: Using Routing Policies to Damp BGP Route
              Flapping", November 2010, <

              Mandelberg, D., "Subject: wglc for draft-ietf-sidr-bgpsec-
              protocol-11 (Specific topic: Include Address Family
              Identifier in the data protected under signature -- to
              alleviate a security concern)", message to the IETF SIDR
              WG Mailing List, 10 February 2015, <
Top   ToC   RFC8374 - Page 46
              Mandelberg, D., "Subject: draft-ietf-sidr-bgpsec-
              protocol-13's security guarantees (Specific topic: Sign
              all of the preceding signed data (rather than just the
              immediate, previous signature) -- to alleviate a security
              concern)", message to the IETF SIDR WG Mailing List,
              26 August 2015, <

   [Mao02]    Mao, Z., et al., "Route Flap Damping Exacerbates Internet
              Routing Convergence", August 2002,

   [Mehmet1]  Adalier, M., "Efficient and Secure Elliptic Curve
              Cryptography Implementation of Curve P-256", NIST Workshop
              on ECC Standards, June 2015,

   [Mehmet2]  Adalier, M., Sriram, K., Borchert, O., Lee, K., and D.
              Montgomery, "High Performance BGP Security: Algorithms and
              Architectures", North American Network Operators Group
              Meeting NANOG69, February 2017,

   [MsgSize]  Sriram, K., "Decoupling BGPsec Documents and Extended
              Messages draft", Presented at the IETF SIDROPS WG
              Meeting, IETF 98, March 2017,

              Sriram, K. and D. Montgomery, "Design Discussion and
              Comparison of Protection Mechanisms for Replay Attack and
              Withdrawal Suppression in BGPsec", Work in Progress,
              April 2018.

   [RFC2439]  Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
              Flap Damping", RFC 2439, DOI 10.17487/RFC2439,
              November 1998, <>.

   [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,
Top   ToC   RFC8374 - Page 47
   [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,

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,

   [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
              Curve Cryptography Algorithms", RFC 6090,
              DOI 10.17487/RFC6090, February 2011,

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

   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
              February 2012, <>.

   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
              Origin Authorizations (ROAs)", RFC 6482,
              DOI 10.17487/RFC6482, February 2012,

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

   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
              X.509 PKIX Resource Certificates", RFC 6487,
              DOI 10.17487/RFC6487, February 2012,

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793,
              DOI 10.17487/RFC6793, December 2012,
Top   ToC   RFC8374 - Page 48
   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,

   [RFC7132]  Kent, S. and A. Chi, "Threat Model for BGP Path Security",
              RFC 7132, DOI 10.17487/RFC7132, February 2014,

   [RFC7353]  Bellovin, S., Bush, R., and D. Ward, "Security
              Requirements for BGP Path Validation", RFC 7353,
              DOI 10.17487/RFC7353, August 2014,

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

   [RFC8097]  Mohapatra, P., Patel, K., Scudder, J., Ward, D., and R.
              Bush, "BGP Prefix Origin Validation State Extended
              Community", RFC 8097, DOI 10.17487/RFC8097, March 2017,

   [RFC8205]  Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol
              Specification", RFC 8205, DOI 10.17487/RFC8205,
              September 2017, <>.

   [RFC8207]  Bush, R., "BGPsec Operational Considerations", BCP 211,
              RFC 8207, DOI 10.17487/RFC8207, September 2017,

   [RFC8208]  Turner, S. and O. Borchert, "BGPsec Algorithms, Key
              Formats, and Signature Formats", RFC 8208,
              DOI 10.17487/RFC8208, September 2017,

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

              Sriram, K., et al., "RIB Size Estimation for BGPSEC",
              May 2011, <
Top   ToC   RFC8374 - Page 49
   [RIPE580]  Bush, R., et al., "RIPE-580: RIPE Routing Working Group
              Recommendations on Route Flap Damping", January 2013,

              Lynn, C., Mikkelson, J., and K. Seo, "Secure BGP (S-BGP)",
              Work in Progress, draft-clynn-s-bgp-protocol-01,
              June 2003.

              Sriram, V. and D. Montgomery, "Design and analysis of
              optimization algorithms to minimize cryptographic
              processing in BGP security protocols", Computer
              Communications, Vol. 106, pp. 75-85,
              DOI 10.1016/j.comcom.2017.03.007, July 2017,


The author would like to thank Jeff Haas and Wes George for serving as reviewers for this document for the Independent Submissions stream. The author is grateful to Nevil Brownlee for shepherding this document through the Independent Submissions review process. Many thanks are also due to Michael Baer, Oliver Borchert, David Mandelberg, Sean Turner, Alvaro Retana, Matthias Waehlisch, Tim Polk, Russ Mundy, Wes Hardaker, Sharon Goldberg, Ed Kern, Chris Hall, Shane Amante, Luke Berndt, 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.


The following people made significant contributions to this document and should be considered co-authors: Rob Austein Dragon Research Labs Email: Steven Bellovin Columbia University Email: Russ Housley Vigil Security, LLC Email:
Top   ToC   RFC8374 - Page 50
   Stephen Kent

   Warren Kumari

   Matt Lepinski
   New College of Florida

   Doug Montgomery
   USA National Institute of Standards and Technology

   Chris Morrow
   Google, Inc.

   Sandy Murphy
   Parsons, Inc.

   Keyur Patel

   John Scudder
   Juniper Networks

   Samuel Weiler

Author's Address

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