RFC 8374
BGPsec Design Choices and Summary of Supporting Discussions
Pages: 50
Informational
Informational
Part 3 of 3 – Pages 33 to 50
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.
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).
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.
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.
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.
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).
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
validation?
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].
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.
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
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.
When any kind of outsourcing is done, the user needs to be watchful and ensure that the outsourcing does not cross trust/security boundaries.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.
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, <http://www.nist.gov/itl/antd/upload/ 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.
[Borchert] 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, <https://www.ietf.org/mail-archive/web/sidr/current/ msg07509.html>. [CiscoIOS] "Cisco IOS: Configuring Route Dampening", February 2014, <https://www.cisco.com/c/en/us/td/docs/ios/12_2/ip/ configuration/guide/fipr_c/1cfbgp.html>. [CPUworkload] 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, <https://www.ietf.org/proceedings/ 83/slides/slides-83-sidr-7.pdf>. [Dynamics] 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, <https://www.nist.gov/file/448631>. [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, <https://rt.openssl.org/Ticket/ Display.html?id=3149&user=guest&pass=guest>. [JunOS] "Juniper JunOS: Using Routing Policies to Damp BGP Route Flapping", November 2010, <http://www.juniper.net/ techpubs/en_US/junos10.4/topics/usage-guidelines/ policy-using-routing-policies-to-damp-bgp-route- flapping.html>. [Mandelberg1] 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, <https://www.ietf.org/ mail-archive/web/sidr/current/msg06930.html>.
[Mandelberg2] 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, <https://www.ietf.org/mail-archive/ web/sidr/current/msg07241.html>. [Mao02] Mao, Z., et al., "Route Flap Damping Exacerbates Internet Routing Convergence", August 2002, <http://www.eecs.umich.edu/~zmao/Papers/sig02.pdf>. [Mehmet1] Adalier, M., "Efficient and Secure Elliptic Curve Cryptography Implementation of Curve P-256", NIST Workshop on ECC Standards, June 2015, <http://csrc.nist.gov/groups/ST/ecc-workshop-2015/papers/ session6-adalier-Mehmet.pdf>. [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, <https://www.nanog.org/meetings/abstract?id=3043>. [MsgSize] Sriram, K., "Decoupling BGPsec Documents and Extended Messages draft", Presented at the IETF SIDROPS WG Meeting, IETF 98, March 2017, <https://www.ietf.org/proceedings/98/slides/ slides-98-sidrops-decoupling-bgpsec-documents-and- extended-messages-draft-00.pdf>. [Replay-Protection] Sriram, K. and D. Montgomery, "Design Discussion and Comparison of Protection Mechanisms for Replay Attack and Withdrawal Suppression in BGPsec", Work in Progress, draft-sriram-replay-protection-design-discussion-10, April 2018. [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November 1998, <https://www.rfc-editor.org/info/rfc2439>. [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>. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/info/rfc6090>. [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>. [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>. [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>. [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>.
[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>. [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>. [RFC7353] Bellovin, S., Bush, R., and D. Ward, "Security Requirements for BGP Path Validation", RFC 7353, DOI 10.17487/RFC7353, August 2014, <https://www.rfc-editor.org/info/rfc7353>. [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>. [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, <https://www.rfc-editor.org/info/rfc8097>. [RFC8205] Lepinski, M., Ed., and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>. [RFC8207] Bush, R., "BGPsec Operational Considerations", BCP 211, RFC 8207, DOI 10.17487/RFC8207, September 2017, <https://www.rfc-editor.org/info/rfc8207>. [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>. [RIB_size] Sriram, K., et al., "RIB Size Estimation for BGPSEC", May 2011, <http://www.nist.gov/itl/antd/upload/ BGPSEC_RIB_Estimation.pdf>.
[RIPE580] Bush, R., et al., "RIPE-580: RIPE Routing Working Group Recommendations on Route Flap Damping", January 2013, <http://www.ripe.net/ripe/docs/ripe-580>. [Secure-BGP] Lynn, C., Mikkelson, J., and K. Seo, "Secure BGP (S-BGP)", Work in Progress, draft-clynn-s-bgp-protocol-01, June 2003. [V_Sriram] 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, <https://www.sciencedirect.com/science/article/pii/ S0140366417303365>.Acknowledgements
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.Contributors
The following people 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, LLC Email: housley@vigilsec.com
Stephen Kent Independent Email: kent@alum.mit.edu Warren Kumari Google Email: warren@kumari.net Matt Lepinski New College of Florida Email: mlepinski@ncf.edu Doug Montgomery USA National Institute of Standards and Technology Email: dougm@nist.gov Chris Morrow Google, Inc. Email: morrowc@google.com Sandy Murphy Parsons, Inc. 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.eduAuthor's Address
Kotikalapudi Sriram (editor) USA National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, MD 20899 United States of America Email: ksriram@nist.gov