RFC 8374

BGPsec Design Choices and Summary of Supporting Discussions ✨

Independent Submission · Request for Comments: 8374 · Category: Informational · ISSN: 2070-1721 🎀

Editor: K. Sriram, Ed. (USA NIST) 💜 Date: April 2018 📅

Okay bestie, the title block is giving: this is an Informational doc, not a Standards Track spec, so nothing here is mandatory 🙈 It's an independent submission, meaning it's published on its own and not through any other RFC stream. It doesn't list anything it obsoletes or updates.

---

Abstract

Okay so this doc is the design diary for the very first draft of what became RFC 8205, the BGPsec protocol spec 🦋 The designers had to juggle a ton of competing priorities, so this doc lists which choices got made, and which ones got rejected, for each design question. It also gives quick summaries of the arguments that helped everyone decide 🧠 Where it makes sense, it also flags design decisions that changed during the SIDR Working Group's review, the ones that led to RFC 8205. These notes point you to the details and reasoning behind each change 💅

---

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8374.

---

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

---

Table of Contents 🌸

1. Introduction ....................................................4
2. Creating Signatures and the Structure of BGPsec Update
   Messages ........................................................5
   2.1. Origin Validation Using ROAs ...............................5
   2.2. Attributes Signed by an Originating AS .....................6
   2.3. Attributes Signed by an Upstream AS ........................7
   2.4. Attributes That Are Not Signed .............................8
   2.5. Receiving Router Actions ...................................9
   2.6. Prepending of ASes in AS Path .............................10
   2.7. RPKI Data That Needs to Be Included in Updates ............10
3. Withdrawal Protection ..........................................11
   3.1. Withdrawals Not Signed ....................................11
   3.2. Signature Expire Time for Withdrawal Protection
        (a.k.a. Mitigation of Replay Attacks) .....................12
   3.3. Should Route Expire Time be Communicated in a
        Separate Message? .........................................13
   3.4. Effect of Expire Time Updates in BGPsec on RFD ............14
4. Signature Algorithms and Router Keys ...........................16
   4.1. Signature Algorithms ......................................16
   4.2. Agility of Signature Algorithms ...........................17
   4.3. Sequential Aggregate Signatures ...........................18
   4.4. Protocol Extensibility ....................................19
   4.5. Key per Router (Rogue Router Problem) .....................20
   4.6. Router ID .................................................20
5. Optimizations and Resource Sizing ..............................21
   5.1. Update Packing and Repacking ..............................21
   5.2. Signature per Prefix vs. Signature per Update .............22
   5.3. Maximum BGPsec Update PDU Size ............................22
   5.4. Temporary Suspension of Attestations and Validations ......23

6. Incremental Deployment and Negotiation of BGPsec ...............24
   6.1. Downgrade Attacks .........................................24
   6.2. Inclusion of Address Family in Capability Advertisement ...24
   6.3. Incremental Deployment: Capability Negotiation ............25
   6.4. Partial Path Signing ......................................25
   6.5. Consideration of Stub ASes with Resource
        Constraints: Encouraging Early Adoption ...................26
   6.6. Proxy Signing .............................................27
   6.7. Multiple Peering Sessions between ASes ....................28
7. Interaction of BGPsec with Common BGP Features .................29
   7.1. Peer Groups ...............................................29
   7.2. Communities ...............................................29
   7.3. Consideration of iBGP Speakers and Confederations .........30
   7.4. Consideration of Route Servers in IXPs ....................31
   7.5. Proxy Aggregation (a.k.a. AS_SETs) ........................32
   7.6. 4-Byte AS Numbers .........................................32
8. BGPsec Validation ..............................................33
   8.1. Sequence of BGPsec Validation Processing in a Receiver ....33
   8.2. Signing and Forwarding Updates when Signatures
        Failed Validation .........................................34
   8.3. Enumeration of Error Conditions ...........................35
   8.4. Procedure for Processing Unsigned Updates .................36
   8.5. Response to Syntactic Errors in Signatures and
        Recommendations for How to React to Them ..................36
   8.6. Enumeration of Validation States ..........................37
   8.7. Mechanism for Transporting Validation State through iBGP ..39
9. Operational Considerations .....................................41
   9.1. Interworking with BGP Graceful Restart ....................41
   9.2. BCP Recommendations for Minimizing Churn:
        Certificate Expiry/Revocation and Signature Expire Time ...42
   9.3. Outsourcing Update Validation .............................42
   9.4. New Hardware Capability ...................................43
   9.5. Signed Peering Registrations ..............................44
10. Security Considerations .......................................44
11. IANA Considerations ...........................................44
12. Informative References ........................................44
Acknowledgements ..................................................49
Contributors ......................................................49
Author's Address ..................................................50

---

1. Introduction 🌈

Okay so the big goal of BGPsec is to make BGP way more secure by enabling full Autonomous System (AS) path validation using cryptography 🔐 The route origin validation side, built on a Resource PKI (RPKI), was already done or almost done over in the IETF SIDR WG [RFC6480] [RFC6482] [RFC6483] [RFC6487] [RFC6811]. BGPsec is all about reusing that same RPKI infrastructure to add cryptographic signatures to BGP updates, so routers can do full AS path validation [RFC7132] [RFC7353] [RFC8205]. The BGPsec protocol spec, [RFC8205], came out recently. The key high-level design goals, per [RFC7353], are these:

• Rigorous path validation for all announced prefixes -- not merely showing that a path is not impossible.
• Incremental deployment capability -- no flag-day requirement for global deployment.
• Protection of AS paths only in inter-domain routing (External BGP (eBGP)) -- not applicable to Internal BGP (iBGP) (or to IGPs).
• Aiming for no increase in a provider's data exposure (e.g., not requiring any disclosure of peering relations).

This doc gives the design justifications for the initial draft of the BGPsec protocol spec [BGPsec-Initial] 📝 The designers had to balance a lot of competing factors, so this doc lists the decisions made for and against each design choice. It also summarises the discussions that shaped the pros and cons and helped the decision process. Where it's relevant, this doc adds brief notes (starting with "Note:") on decisions that changed from that initial draft as the SIDR WG reviewed and updated the spec. Those changes resulted in RFC 8205 [RFC8205]. The notes point you to details and discussions about each change 🦋

The design choices and discussions are presented in the following sections, grouped under eight broad categories, with many subtopics inside each one 💅

• Section 2 ("Creating Signatures and the Structure of BGPsec Update Messages")
• Section 3 ("Withdrawal Protection")
• Section 4 ("Signature Algorithms and Router Keys")
• Section 5 ("Optimizations and Resource Sizing")
• Section 6 ("Incremental Deployment and Negotiation of BGPsec")
• Section 7 ("Interaction of BGPsec with Common BGP Features")
• Section 8 ("BGPsec Validation")
• Section 9 ("Operational Considerations")

---

2. Creating Signatures and the Structure of BGPsec Update Messages 🎀

2.1. Origin Validation Using ROAs 👑

2.1.1. Decision

Route origin validation using Route Origin Authorizations (ROAs) [RFC6482] [RFC6811] is necessary and complements AS path attestation based on signed updates 🔥 So the BGPsec design uses the origin validation capability that ROAs in the RPKI provide.

Note: In the finalised BGPsec protocol spec [RFC8205], BGPsec is basically a synonym for cryptographic AS path attestation. Origin validation and BGPsec (path signatures) are the two key pieces of the SIDR WG's solution for BGP security ✨

2.1.2. Discussion

Okay bestie, route origin validation using the RPKI constructs the SIDR WG developed is a necessary part of BGP security 🫶 It gives you cryptographic validation that the first-hop AS is authorised to originate a route for the prefix in question.

---

Part 1 of 11 done bestie, more coming up next 🌈💖

2.2.1. Decision ✨

Okay bestie, so the originating AS signs over the NLRI length, the NLRI prefix, its own AS number (ASN), the next ASN, the signature algorithm suite ID, and a signature Expire Time (see Section 3.2) for the update. 💌 All those signatures get carried in a new optional, non-transitive BGP attribute. 🎀

Note: The finalized BGPsec protocol specification [RFC8205] differs from the above. 🙈 RFC 8205 never mentions a signature Expire Time field in the BGPsec update, so that's a whole plot twist. There are also more details about the attributes an origin AS signs, and you can find those in Figure 8 in Section 4.2 of RFC 8205 [RFC8205]. The big one is that the signed data also includes the Address Family Identifier (AFI), as RFC 8205 describes. Adding the AFI to the covered data fixed a specific security concern, and you can check [Mandelberg1] (a post to the SIDR WG Mailing List) plus the discussion thread that came after it. 🧠 The AFI comes from the MP_REACH_NLRI attribute in the BGPsec update. As Section 4.1 of RFC 8205 says, a BGPsec update message "MUST use the MP_REACH_NLRI attribute [RFC4760] to encode the prefix." 💅

2.2.2. Discussion

The next-hop ASN is part of the data covered by the signature, and this matters a LOT. 😭 Without it, the AS path can't be secured. For example, a MITM (man in the middle) could shorten the path and nobody would notice. 👀

It was decided that only the originating AS needs to insert a signature Expire Time in the update, since it's the one that originated the route. 👑 The origin AS also re-originates the update, which is called beaconing, before the Expire Time of the advertisement runs out (see Section 3.2). (If you're wondering why upstream ASes don't add their own signature Expire Times, see Section 3.2.2. 🦋)

Note: Expire Time and beaconing were eventually replaced by router key rollover. ✨ The BGPsec protocol [RFC8205] is expected to use router key rollover to mitigate replay attacks and withdrawal suppression [BGPsec-Rollover] [Replay-Protection]. Glow-up energy, honestly. 🌈

It was decided that each signed update would include only one NLRI prefix. If an update carried more than one NLRI prefix, and an upstream AS chose to propagate the advertisement for only a subset of them, the signature(s) on the update would break (see Sections 5.1 and 5.2). 💀 And if some mechanism were used to keep the prefixes that got dropped, it would reveal info to later ASes that normal BGP operation doesn't reveal. 🙅‍♀️ So a trade-off was made: keep the level of route information exposure that's built into BGP, even though limiting each update to one prefix costs some performance. 🍓

The signature data is carried in an optional, non-transitive BGP attribute. It's optional because that's BGP's standard way to spread new types of data. 🫶 It was decided that the attribute should be non-transitive because of concern about the impact of sending the (potentially large) signatures to routers that don't understand them. Also, if a router that doesn't understand BGPsec somehow gets an update with path signatures (meaning the update includes the BGPsec_PATH attribute, see Section 3 of RFC 8205), it would be undesirable for that router to forward the update to all its neighbors. Especially the ones who don't understand BGPsec and might choke on lots of updates with large optional BGP attributes. 😵‍💫 BGPsec and traditional BGP are expected to coexist while BGPsec gets deployed bit by bit. 🌸

2.3. Attributes Signed by an Upstream AS

In the context of BGPsec, and throughout this document, an "upstream AS" just means an AS that's further along in an AS path. The origin AS is the closest one to a prefix. 🧚 In principle, an AS upstream from an originating AS would digitally sign the combined info, including the NLRI length, NLRI prefix, AS path, next ASN, signature algorithm suite ID, and Expire Time. There are multiple choices for what an upstream AS signs, and they are:

• Method 1: The signature protects the combination of the NLRI length, NLRI prefix, AS path, next ASN, signature algorithm suite ID, and Expire Time. 💖
• Method 2: The signature protects just the combination of the previous signature (meaning the signature of the neighbor AS who forwarded the update) and the next ASN, or
• Method 3: The signature protects everything that was received from the preceding AS plus the next (meaning target) ASN. So ASi signs over the NLRI length, NLRI prefix, signature algorithm suite ID, Expire Time, {ASi, AS(i-1), AS(i-2), ..., AS2, AS1}, AS(i+1) (i.e., the next ASN), and {Sig(i-1), Sig(i-2), ..., Sig2, Sig1}. 🔥

Note: Please see the notes in Sections 2.2.1 and 2.2.2 about the elimination of the Expire Time field in the finalized BGPsec protocol specification [RFC8205]. 💜

2.3.1. Decision

It was decided that Method 2 will be used. For more protocol details and syntax, check [BGPsec-Initial]. 📚

Note: The finalized BGPsec protocol specification [RFC8205] essentially uses Method 3 (except for Expire Time). More details on what an upstream AS signs are in Figure 8 in Section 4.2 of RFC 8205 [RFC8205]. The decision to go with Method 3 (with suitable additions to the data signed) was motivated by a security concern associated with Method 2. Check [Mandelberg2] (a post to the SIDR WG Mailing List) and the discussion thread that followed it. 🕵️‍♀️ Also, there's a strong rationale for the sequence of octets to be hashed (as shown in Figure 8 in Section 4.2 of RFC 8205). This sequencing of data is motivated by implementation efficiency considerations. For an explanation, see [Borchert] (a post to the SIDR WG Mailing List). ⚡

2.3.2. Discussion

So the reasoning behind this choice (Method 2) went like this. 🧐 Signatures get computed over hash blocks. When the number of bytes to sign goes past one hash block, the leftover bytes spill into a second hash block, and that costs performance. So it's a W to minimize how many bytes get hashed. 💅 And an analysis of the three options above didn't find any vulnerabilities with this approach. ✅

2.4. Attributes That Are Not Signed

2.4.1. Decision

Any attributes other than the ones identified in Sections 2.2 and 2.3 are not signed. Examples of these unsigned attributes include the community attribute, the NO-EXPORT attribute, and Local_Pref. 🌷

2.4.2. Discussion

Any of the unsigned attributes mentioned above are seen as local (meaning they don't need to propagate beyond the next hop), or they just don't have clear security needs. 🤷‍♀️ NO-EXPORT is sent over a secured next hop, so it doesn't need signing. The BGPsec design should work with any transport-layer protections. It's well understood that the transport layer must be protected hop by hop (if only to prevent malicious session termination). 🛡️

2.5. Receiving Router Actions

2.5.1. Decision

Here's the example of the expected router actions when a signed update is received. 📬 Picture an update that was originated by AS1 with NLRI prefix p, and it has traversed the AS path [AS(i-1) AS(i-2) ... AS2 AS1] before it arrives at ASi. Let the Expire Time (inserted by AS1) for the signature in this update be called Te. Let AlgID be the ID of the signature algorithm suite in use. The update gets processed at ASi and possibly forwarded to AS(i+1). Let the attestations (signatures) inserted by each router in the AS path be called Sig1, Sig2, ..., Sig(i-2), and Sig(i-1), corresponding to AS1, AS2, ..., AS(i-2), and AS(i-1), respectively. 🧩

The method selected for signing (Method 2 in Section 2.3) requires a receiving router in ASi to do the following:

• Validate the route origin pair (p, AS1) by performing a ROA match. ✅
• Verify that Te is greater than the clock time at the router performing these checks. ⏰
• Check Sig1 with inputs {NLRI length, p, AlgID, Te, AS1, AS2}. 🔍
• Check Sig2 with inputs {Sig1, AS3}. 🔍
• Check Sig3 with inputs {Sig2, AS4}. 🔍
• ...
• ...
• Check Sig(i-2) with inputs {Sig(i-3), AS(i-1)}. 🔍
• Check Sig(i-1) with inputs {Sig(i-2), ASi}. 🔍
• If the route that has been verified is selected as the best path (for prefix p), then generate Sig(i) with inputs {Sig(i-1), AS(i+1)}, and generate an update including Sig(i) to AS(i+1). 🚀

Note: The above description of BGPsec update validation and forwarding differs in its details from the published BGPsec protocol specification [RFC8205]. For the real deal, see Sections 4 and 5 of [RFC8205]. 📖

2.5.2. Discussion

For suggestions on efficiently sequencing BGPsec validation processing in a receiving router, see Section 8.1. 🧁 Some or all of the validation actions may be performed by an off-board server (see Section 9.3). 🖥️

2.6. Prepending of ASes in AS Path

2.6.1. Decision

Prepending will be allowed. Prepending is defined as including more than one instance of the AS number (ASN) of the router that is signing the update. 🎀

Note: The finalized BGPsec protocol specification [RFC8205] uses a pCount field associated with each AS in the path to indicate the number of prepends for that AS (see Figure 5 in Section 3.1 of [RFC8205]). 🌟

2.6.2. Discussion

The initial version [BGPsec-Initial] of the BGPsec specification called for a signature to be associated with each prepended AS. Later on, people went for the optimization of having just one signature cover multiple prepended ASes. Now the pCount field represents AS prepends. See Section 3.1 in RFC 8205. 🧠

2.7. RPKI Data That Needs to Be Included in Updates

2.7.1. Decision

About including RPKI data in an update, it was decided that only the Subject Key Identifier (SKI) of the router certificate must be included in a signed update. 🔐 This info identifies the router certificate, based on the SKI generation criteria defined in [RFC6487]. 🪪

2.7.2. Discussion

People debated whether each router public key certificate should be included in a signed update. Including it could help routers that don't have access to RPKI servers, or that temporarily lose connectivity to them. 🥺 It's safe to assume that in most network environments, intermittent connectivity wouldn't be a problem. So it's best to avoid this extra complexity, since most use environments don't have connectivity constraints. 💁‍♀️ And because the SKI of a router certificate is a hash of that certificate's public key, it's enough to just select the public key from the certificate. This design assumes that each BGPsec router has access to a cache containing the relevant data from (validated) router certificates. 🗂️

3. Withdrawal Protection 🦋

3.1. Withdrawals Not Signed

3.1.1. Decision

Withdrawals are not signed. 🙌

3.1.2. Discussion 💅

okay so, in current BGP, any AS can withdraw any prefix it announced before, at any time 🙈. withdrawals aren't signed because BGPsec assumes transport security between neighboring BGPsec routers 🔐. that means no outside entity can inject an update that withdraws a route, or replay an earlier update containing a withdrawal 🛡️. but here's the tea 🍵: the reason a router withdraws a route isn't visible to its neighboring BGPsec router, so withdrawals still have leftover vulnerabilities 💀. for example, a router that advertised a (valid) route might fail to withdraw it once it's no longer viable 😬. a router might also re-advertise a route it withdrew before the route is viable again. this second one gets mitigated by the Expire Time on the origin AS's signature (see Section 3.2), so it's giving safety net 🧚

repeated withdrawals and announcements for a prefix can run up the BGP Route Flap Damping (RFD) penalty [RFC2439] and may leave that prefix unreachable at upstream routers 😭. but ngl, what would the attacker even gain from that? 🤔 this is intrinsic to how RFD is designed and operated, fr fr.

3.2. Signature Expire Time for Withdrawal Protection (a.k.a. Mitigation of Replay Attacks) 🦋

3.2.1. Decision

Note: As mentioned earlier (Section 2.2.2), the Expire Time approach to mitigation of replay attacks and withdrawal suppression was later changed to an approach based on router key rollover [BGPsec-Rollover] [Replay-Protection]. 🔄

only the originating AS inserts a signature Expire Time in the update 🎀. all the other ASes along an AS path do not insert Expire Times for their own signatures. the originating AS also re-originates a route well ahead of the Expire Time of its signature, so the other ASes along the path will typically get the re-originated route long before the current Expire Time for that route ✨.

it is recommended that the signature Expire Time be on the order of days (preferably) 📅, but it may be on the order of hours (about 4 to 8 hours) in some cases, based on a perceived need for extra protection from replay attacks (i.e., where extra replay protection is perceived to be critical) 🚨.

each AS should stagger the Expire Time values in the routes it originates 🌈. re-origination will be done, say, at time Tb after origination or the last re-origination, where Tb equals a certain percentage of the Expire Time, Te (for example, Tb = 0.75 x Te). the percentage will be configurable. more guidance can come later via an operational considerations document 📚. also, the actual re-origination time should be jittered with a uniform random distribution over a short interval {Tb1, Tb2} centered at Tb 🎲.

it is also recommended that a receiving BGPsec router detect when the only attribute change in an announcement (relative to the current best path) is the Expire Time (besides, of course, the signatures) 👀. in that case, assuming the update is found valid, the route processor should not re-announce the route to non-BGPsec peers. (it should sign and re-announce the route to BGPsec speakers only.) this procedure reduces BGP chattiness for the non-BGPsec border routers 🫶.

3.2.2. Discussion 🧠

mitigation of BGPsec update replay attacks can be thought of as protection against malicious re-advertisements of withdrawn routes 🛡️. if each AS along a path inserted its own signature Expire Time, there would be a lot of extra BGP chattiness and more BGP processing load, because routers would need to detect and react to multiple (possibly redundant) signature Expire Times 😵‍💫. and there would be no extra benefit for replay mitigation compared to having a single Expire Time tied to the signature of the originating AS. no notes, just facts 💅

as noted in Section 3.2.1, the recommended Expire Time value is on the order of days, but 4 to 8 hours may be used in some cases, based on a perceived need for extra protection from replay attacks 🌸. so different ASes may choose different values based on how much they feel the need to protect against malicious route replays. (a shorter Expire Time shrinks the window in which an AS can maliciously replay the route. however, shorter Expire Time values mean routes get refreshed more often, which causes more BGP chatter 🗣️.) even a 4-hour duration seems long enough to keep the re-origination workload manageable 💪. for example, if 500K routes are re-originated every 4 hours, that amounts to an increase in BGP update load of 35 updates per second, which can be considered reasonable ✅. however, further analysis is needed to confirm these recommendations 🔍.

as stated in Section 3.2.1, the originating AS will re-originate a route sufficiently in advance of its Expire Time. so what counts as "sufficiently in advance"? 🤷‍♀️ to answer that, modeling should be performed to determine the 95th-percentile convergence time of update propagation in a BGPsec-enabled Internet 📈.

each BGPsec router should stagger the Expire Time values in the updates it originates, especially during table dumps to a neighbor or during its own recovery from a BGP session failure 🔁. by doing this, the re-origination (i.e., beaconing) workload at the router gets dispersed, which is honestly so smart 🧩.

3.3. Should Route Expire Time be Communicated in a Separate Message? 📨

3.3.1. Decision

the idea of sending a new signature Expire Time in a special message (rather than retransmitting the entire update with signatures) was considered 🤔. however, the decision was made not to do this. re-origination to communicate a new signature Expire Time will be done by propagating a normal update message, so no special type of message will be required 🙌.

3.3.2. Discussion 💬

it was suggested that if the re-beaconing of the signature Expire Time is carried in a separate special message, then the processing load related to the update might be reduced 🤏. but it was recognized that such a re-beaconing message necessarily carries AS path and prefix information and, hence, cannot be separated from the update 🙃.

it was observed that at the edge of the Internet, there are frequent updates that result from simple situations, like a BGP session being switched from one interface to another (e.g., from primary to backup) between two peering ASes (e.g., customer and provider) 🔀. with traditional BGP, these updates don't propagate beyond the two ASes involved 🙅‍♀️. but with BGPsec, the customer AS puts in a new signature Expire Time each time such an event happens, so the update needs to propagate throughout the Internet (limited only by the process of best-path selection) 🌍. it was accepted that this cost of added churn will be unavoidable 😤.

3.4. Effect of Expire Time Updates in BGPsec on RFD 🎢

3.4.1. Decision

with regard to the RFD protocol [RFC2439] [JunOS] [CiscoIOS], no differential treatment is required for Expire-Time-triggered (re-beaconed) BGPsec updates 🙆‍♀️.

however, it was noted that it would be preferable if these updates did not cause route churn (and perhaps did not even require any RFD-related processing), since they are identical except for the change in the Expire Time value 🥰. this can be accomplished by not assigning an RFD penalty to Expire-Time-triggered updates. if the community agrees, this could be accommodated, but a change to the BGP-RFD protocol will be required 🛠️.

3.4.2. Discussion 📝

to summarize, this decision is supported by the following observations:

1. Expire-Time-triggered updates are generally not preceded by withdrawals, so the path hunting and associated RFD exacerbation [Mao02] [RIPE580] problems are not anticipated 🙌.
2. such updates would not normally change the best path (unless another concurrent event impacts the best path) 🧭.
3. Expire-Time-triggered updates would have a negligible impact on RFD penalty accumulation, because the re-advertisement interval is much longer relative to the half-time of RFD penalty decay ⏳.

elaborating on the third observation above, the re-advertisements (i.e., beacons) of a route for a given address prefix from a given peer will be received at intervals of several hours (see Section 3.2) 🕰️. during that time period, any incremental contribution to the RFD penalty from an Expire-Time-triggered update would decay enough to have negligible (if any) impact on damping the address prefix in question 🫧.

more details on this analysis and justification follow 🤓:

the frequency with which RFD penalty increments may be triggered for a given prefix from a given peer is the same as the re-beaconing frequency for that prefix from its origin AS. the re-beaconing frequency is on the order of once every several hours (see Section 3.2). the incremental RFD penalty assigned to a prefix due to a re-beaconed update varies, depending on the implementation. for example, it appears that the JunOS implementation [JunOS] would assign a penalty of 1000 or 500, depending on whether the re-beaconed update is regarded as a re-advertisement or an attribute change, respectively. normally, a re-beaconed update would be treated as an attribute change 🔎. on the other hand, the Cisco implementation [CiscoIOS] assigns an RFD penalty only in the case of an actual flap (i.e., a route is available, then unavailable, or vice versa) ⚡. so it appears that Cisco's implementation of RFD would not assign any penalty for a re-beaconed update (i.e., a route was already advertised previously and was not withdrawn, and the re-beaconed update is merely updating the Expire Time attribute) 🙌.

even if one assumes that an RFD penalty of 500 is assigned (corresponding to an attribute change according to the JunOS RFD implementation), it can be shown that the incremental effect on damping the prefix in question would be negligible 🧮. the half-time of RFD penalty decay is normally set to 15 minutes, whereas the re-beaconing frequency is on the order of once every several hours ⏱️. an incremental penalty of 500 would decay to 31.25 in 1 hour, 0.12 in 2 hours, and 3x10^(-5) in 3 hours 📉. it may also be noted that the threshold for route suppression is 3000 in JunOS and 2000 in Cisco IOS 🚫. based on the foregoing analysis, it may be concluded that routine re-beaconing by itself would not result in RFD suppression of routes in the BGPsec protocol 🎉.

4. Signature Algorithms and Router Keys 🔑

4.1. Signature Algorithms 🧪

4.1.1. Decision

initially, the Elliptic Curve Digital Signature Algorithm (ECDSA) with curve P-256 and SHA-256 will be used for generating BGPsec path signatures 💖. one other signature algorithm, e.g., RSA-2048, will also be used during prototyping and testing 🧑‍💻. the use of a second signature algorithm is needed to verify that BGPsec implementations can change from a current algorithm to the next algorithm 🔄.

Note: The BGPsec cryptographic algorithms document [RFC8208] specifies only the ECDSA with curve P-256 and SHA-256. 📖

4.1.2. Discussion

okay so RSA-2048 was the first contender for BGPsec update signatures bc it's used ubiquitously across the RPKI system 💅. but the team went with ECDSA P-256 because it gives a smaller signature size ✨. that means the update size and, in turn, the RIB size needed in BGPsec routers would be much smaller [RIB_size] 🦋.

Using two different signature algorithms (e.g., ECDSA P-256 and RSA-2048) to test the transition from one algorithm to the other will increase confidence in prototype implementations 🧚.

Optimizations and specialized algorithms (e.g., for speedups) built on Elliptic Curve Cryptography (ECC) algorithms may have active IPR (intellectual property rights) 😭, but at the time of publication of this document no IPR had been disclosed to the IETF for the basic (unoptimized) algorithms. (To understand this better, [RFC6090] can be useful as a starting point.)

Note: Recently, even open-source implementations have incorporated certain cryptographic optimizations and demonstrated significant performance speedup [Gueron]. Researchers continue to devote significant effort toward demonstrating substantial speedup for the ECDSA as part of BGPsec implementations [Mehmet1] [Mehmet2] 🔥.

4.2. Agility of Signature Algorithms

4.2.1. Decision

during the transition period from one algorithm (i.e., the current algorithm) to the next (new) algorithm, the updates will carry two sets of signatures (i.e., two Signature_Blocks), one corresponding to each algorithm 🌈. each Signature_Block will be preceded by its type-length field and an algorithm suite identifier. a BGPsec speaker that has been upgraded to handle the new algorithm should validate both Signature_Blocks and then add its corresponding signature to each Signature_Block for forwarding the update to the next AS. a BGPsec speaker that has not been upgraded to handle the new algorithm will strip off the Signature_Block of the new algorithm and then will forward the update after adding its own signature to the Signature_Block of the current algorithm 🎀.

it was decided that there will be at most two Signature_Blocks per update 💜.

Note: BGPsec path signatures are carried in the Signature_Block, which is an attribute contained in the BGPsec_PATH attribute (see Section 3.2 in [RFC8205]). The algorithm agility scheme described in the published BGPsec protocol specification is consistent with the above; see Section 6.1 of [RFC8205] ✨.

4.2.2. Discussion

a length field in the Signature_Block allows for delineation of the two signature blocks 🫶. so a BGPsec router that doesn't know about a particular algorithm suite (and, hence, doesn't know how long signatures were for that algorithm suite) could still skip over the corresponding Signature_Block when parsing the message.

the overlap period between the two algorithms is expected to last 2 to 4 years ⭐. the RIB memory and cryptographic processing capacity will have to be sized to cope with such overlap periods when updates would contain two sets of signatures [RIB_size].

the lifetime of a signature algorithm is anticipated to be much longer than the duration of a transition period from the current algorithm to a new algorithm 🧚. it is fully expected that all ASes will have converted to the required new algorithm within a certain amount of time that is much shorter than the interval in which a subsequent newer algorithm may be investigated and standardized for BGPsec. hence, the need for more than two Signature_Blocks per update is not envisioned 🙈.

4.3. Sequential Aggregate Signatures

4.3.1. Decision

there is currently weak or no support for the Sequential Aggregate Signature (SAS) approach 💀. Please see Section 4.3.2 for a brief description of what the SAS is and what its pros and cons are.

4.3.2. Discussion

in the SAS method, there would be only one (aggregated) signature per signature block, irrespective of the number of AS hops 🍓. for example, ASn (the nth AS) takes as input the signatures of all previous ASes [AS1, ..., AS(n-1)] and produces a single composite signature. this composite signature has the property that a recipient who has the public keys for AS1, ..., ASn can verify (using only the single composite signature) that all of the ASes actually signed the message. the SAS could potentially result in savings in bandwidth and in Protocol Data Unit (PDU) size, and maybe in RIB size, but the signature generation and validation costs will be higher as compared to one signature per AS hop.

SAS schemes exist in the literature, typically based on RSA or its equivalent. for a SAS with RSA and for the cryptographic strength needed for BGPsec signatures, a 2048-bit signature size (RSA-2048) would be required. however, without a SAS, the ECDSA with a 512-bit signature (256-bit key) would suffice for equivalent cryptographic strength 💖. the larger signature size of RSA used with a SAS undermines the advantages of the SAS, because the average hop count, i.e., the number of ASes, for a route is about 3.8 😭. in the end, it may turn out that the SAS has more complexity and does not provide sufficient savings in PDU size or RIB size to merit its use. further exploration of this is needed to better understand SAS properties and applicability for BGPsec. there is also a concern that the SAS is not a time-tested cryptographic technique, and thus its adoption is potentially risky 🚨.

4.4. Protocol Extensibility

there is clearly a need to specify a transition path from a current protocol specification to a new version 🦋. when changes to the processing of the BGPsec path signatures are required, a new version of BGPsec will be required. examples of this include changes to the data that is protected by the BGPsec signatures or adoption of a signature algorithm in which the number of signatures in the signature block may not correspond to one signature per AS in the AS path (e.g., aggregate signatures) 🌸.

4.4.1. Decision

this protocol-version transition mechanism is analogous to the algorithm transition discussed in Section 4.2. during the transition period from one protocol version (i.e., the current version) to the next (new) version, updates will carry two sets of signatures (i.e., two Signature_Blocks), one corresponding to each version. a protocol-version identifier is associated with each Signature_Block. hence, each Signature_Block will be preceded by its type-length field and a protocol-version identifier. a BGPsec speaker that has been upgraded to handle the new version should validate both Signature_Blocks and then add its corresponding signature to each Signature_Block for forwarding the update to the next AS. a BGPsec speaker that has not been upgraded to handle the new protocol version will strip off the Signature_Block of the new version and then will forward the update with an attachment of its own signature to the Signature_Block of the current version 🎀.

Note: The details of protocol extensibility (i.e., transition to a new version of BGPsec) in the published BGPsec protocol specification (see Section 6.3 in [RFC8205]) differ somewhat from the above. In particular, the protocol-version identifier is not part of the BGPsec update. Instead, it is negotiated during the BGPsec capability exchange portion of BGPsec session negotiation 🤓.

4.4.2. Discussion

in the case that a change to BGPsec is deemed desirable, it is expected that a subsequent version of BGPsec would be created and that this version of BGPsec would specify a new BGP path attribute (let's call it "BGPsec_PATH_TWO") that is designed to accommodate the desired changes to BGPsec 🧁. at this point, a transition would begin that is analogous to the algorithm transition discussed in Section 4.2. during the transition period, all BGPsec speakers will simultaneously include both the BGPsec_PATH (current) attribute (see Section 3 of RFC 8205) and the new BGPsec_PATH_TWO attribute. once the transition is complete, the use of BGPsec_PATH could then be deprecated, at which point BGPsec speakers will include only the new BGPsec_PATH_TWO attribute. such a process could facilitate a transition to new BGPsec semantics in a backwards-compatible fashion 👑.

4.5. Key per Router (Rogue Router Problem)

4.5.1. Decision

within each AS, each individual BGPsec router can have a unique pair of private and public keys [RFC8207] 🔑.

4.5.2. Discussion

given a unique key pair per router, if a router is compromised, its key pair can be revoked independently, without disrupting the other routers in the AS 😤. each per-router key pair will be represented in an end-entity certificate issued under the certification authority (CA) certificate of the AS. the Subject Key Identifier (SKI) in the signature points to the router certificate (and thus the unique public key) of the router that affixed its signature, so that a validating router can reliably identify the public key to use for signature verification 🫶.

4.6. Router ID

4.6.1. Decision

the router certificate subject name will be the string "ROUTER" followed by a decimal representation of a 4-byte ASN followed by the router ID. (Note: The details are specified in Section 3.1 in [RFC8209] 🧠.)

4.6.2. Discussion

every X.509 certificate requires a subject name [RFC6487]. the stylized subject name adopted here is intended to facilitate debugging by including the ASN and router ID 🐞.

5. Optimizations and Resource Sizing

5.1. Update Packing and Repacking

with traditional BGP [RFC4271], an originating BGP router normally packs multiple prefix announcements into one update if the prefixes all share the same BGP attributes 📦. when an upstream BGP router forwards eBGP updates to its peers, it can also pack multiple prefixes (based on the shared AS path and attributes) into one update. the update propagated by the upstream BGP router may include only a subset of the prefixes that were packed in a received update.

5.1.1. Decision

each update contains exactly one prefix 1️⃣. this avoids a level of complexity that would otherwise be inevitable if the origin had packed and signed multiple prefixes in an update and an upstream AS decided to propagate an update containing only a subset of the prefixes in that update. BGPsec recommendations regarding packing and repacking may be revisited when optimizations are considered in the future 🔮.

5.1.2. Discussion

currently, with traditional BGP, there are, on average, approximately four prefixes announced per update [RIB_size]. so, the number of BGP updates (carrying announcements) is about four times fewer, on average, as compared to the number of prefixes announced 📉.

the current decision is to include only one prefix per secured update (see Section 2.2.2). when optimizations are considered in the future, the possibility of packing multiple prefixes into an update can also be considered. (Please see Section 5.2 for a discussion of signature per prefix vs. signature per update.) repacking could be performed if signatures were generated on a per-prefix basis. however, one problem regarding this approach -- multiple prefixes in a BGP update but with a separate signature for each prefix -- is that the resulting BGP update violates the basic definition of a BGP update: the different prefixes will have different signatures and Expire Time attributes, while a BGP update (by definition) must have the same set of shared attributes for all prefixes it carries 🥺.

5.2. Signature per Prefix vs. Signature per Update ✨

5.2.1. Decision 💌

okay so the big call here is that the initial design includes exactly one prefix per update 🎀 which means there is only one signature in each secured update (modulo algorithm transition conditions) 💅

5.2.2. Discussion 🧠

bestie, here are some notes to help with future optimization chats 🌸

so in the general case of one signature per update, multiple prefixes can be signed with one signature together with their shared AS path, next ASN, and Expire Time 🦋 if the "signature per update" technique is used, there are potential savings in update PDU size as well as RIB memory size 💜 but if there are any changes made to the announced prefix set along the AS path, then the AS where the change occurs would need to insert an Explicit Path Attribute (EPA) [Secure-BGP] 😭 the EPA conveys information regarding what the prefix set contained prior to the change 👀 there would be one EPA for each AS that made such a modification, and there would be a way to associate each EPA with its corresponding AS 🔗 this enables an upstream AS to know and verify what was announced and signed by prior ASes in the AS path (in spite of changes made to the announced prefix set along the way) ✨ the EPA adds complexity to processing (signature generation and validation), further increases the size of updates and, thus, of the RIB, and exposes data to downstream ASes that would not otherwise be exposed 💀 not all of the pros and cons of packing and repacking in the context of signature per prefix vs. signature per update (with packing) have been evaluated 🙈 but the current recommendation is for having only one prefix per update (no packing), so there is no need for the EPA 🎀

5.3. Maximum BGPsec Update PDU Size 📦

The current BGP update message PDU size is limited to 4096 bytes [RFC4271] 📏 the question was raised as to whether or not BGPsec would require a larger update PDU size 🤔

5.3.1. Decision 🌈

the current thinking is that the maximum PDU size should be increased to 64 KB [BGP-Ext-Msg] so that there is sufficient room to accommodate two Signature_Blocks (i.e., one block with a current algorithm and another block with a new signature algorithm during a future transition period) for long AS paths 🦋

Note: RFC 8205 states the following: "All BGPsec UPDATE messages MUST conform to BGP's maximum message size. If the resulting message exceeds the maximum message size, then the guidelines in Section 9.2 of RFC 4271 [RFC4271] MUST be followed." 📜

5.3.2. Discussion 💬

the current maximum message size for BGP updates is 4096 octets 📏 an effort is underway in the IETF to extend it to a larger size [BGP-Ext-Msg] 🚀 BGPsec will conform to whatever maximum message size is available for BGP while adhering to the guidelines in Section 9.2 of RFC 4271 [RFC4271] 💅

Note: Estimates for the average and maximum sizes anticipated for BGPsec update messages are provided in [MsgSize] 🍓

5.4. Temporary Suspension of Attestations and Validations ⏸️

5.4.1. Decision 🫶

if a BGPsec-capable router needs to temporarily suspend/defer signing and/or validation of BGPsec updates during periods of route processor overload, the router may do so even though such suspension/deferment is not desirable 😬 the specification does not forbid it 🙅‍♀️ following any temporary suspension, the router should subsequently send signed updates corresponding to the updates for which validation and signing were skipped 🔁 the router also may choose to skip only validation but still sign and forward updates during periods of congestion 🧚

5.4.2. Discussion 🌙

in some situations, a BGPsec router may be unable to keep up with the workload of performing signing and/or validation 😵‍💫 this can happen, for example, during BGP session recovery when a router has to send the entire routing table to a recovering router in a neighboring AS (see [CPUworkload]) 📚 so, it is possible that a BGPsec router temporarily pauses performing the validation or signing of updates 💤 when the workload eases, the BGPsec router should clear the validation or signing backlog and send signed updates corresponding to the updates for which validation and signing were skipped 🧹 during periods of overload, the router may simply send unsigned updates (with signatures dropped) or may sign and forward the updates with signatures (even though the router itself has not yet verified the signatures it received) 🫠

a BGPsec-capable AS may request (out of band) that a BGPsec-capable peer AS never downgrade a signed update to an unsigned update 🤝 however, in partial-deployment scenarios, it is not possible for a BGPsec router to require a BGPsec-capable eBGP peer to send only signed updates, except for prefixes originated by the peer's AS 🥺

Note: If BGPsec has not been negotiated with a peer, then a BGPsec router forwards only unsigned updates to that peer 📭 the sending router does so by following the reconstruction procedure in Section 4.4 of [RFC8205] to generate an AS_PATH attribute corresponding to the BGPsec_PATH attribute in a received signed update 🛠️ if the above-mentioned temporary suspension is ever applied, then the same AS_PATH reconstruction procedure should be utilized 🔧

---

6. Incremental Deployment and Negotiation of BGPsec 🦋

6.1. Downgrade Attacks 🚫

6.1.1. Decision 🙅‍♀️

no attempt will be made in the BGPsec design to prevent downgrade attacks 😤 i.e., a BGPsec-capable router sending unsigned updates when it is capable of sending signed updates 🫥

6.1.2. Discussion 🤔

BGPsec allows routers to temporarily suspend signing updates (see Section 5.4) 🙃 therefore, it would be contradictory if we were to try to incorporate in the BGPsec protocol a way to detect and reject downgrade attacks 🙈 one proposed way to detect downgrade attacks was considered, based on signed peering registrations (see Section 9.5) 🧐

6.2. Inclusion of Address Family in Capability Advertisement 🌐

6.2.1. Decision 💜

it was decided that during capability negotiation, the address family for which the BGPsec speaker is advertising support for BGPsec will be shared using the Address Family Identifier (AFI) 🪪 initially, two address families would be included, namely, IPv4 and IPv6 🌍 BGPsec for use with other address families may be specified in the future 🔮 simultaneous use of the two (i.e., IPv4 and IPv6) address families for the same BGPsec session will require that the BGPsec speaker include two instances of this capability (one for each address family) during BGPsec capability negotiation 👯

6.2.2. Discussion 💬

if new address families are supported in the future, they will be added in future versions of the specification 📅 a comment was made that too many version numbers are bad for interoperability 😬 renegotiation on the fly to add a new address family (i.e., without changeover to a new version number) is desirable ✨

6.3. Incremental Deployment: Capability Negotiation 🧩

6.3.1. Decision 🌸

BGPsec will be incrementally deployable 🍰 BGPsec routers will use capability negotiation to agree to run BGPsec between them 🤝 if a BGPsec router's peer does not agree to run BGPsec, then the BGPsec router will run only traditional BGP with that peer, i.e., it will not send BGPsec (i.e., signed) updates to the peer 📮

Note: See Section 7.9 of [RFC8205] for a discussion of incremental / partial-deployment considerations 📖 also, Section 6 of [RFC8207] describes how edge sites (stub ASes) can sign updates that they originate but can receive only unsigned updates 🏠 this facilitates a less expensive upgrade to BGPsec in resource-limited stub ASes and expedites incremental deployment 🏃‍♀️💨

6.3.2. Discussion 🏝️

the partial-deployment approach to incremental deployment will result in "BGPsec islands" 🏝️ updates that originate within a BGPsec island will generally propagate with signed AS paths to the edges of that island 🌊 as BGPsec adoption grows, the BGPsec islands will expand outward (subsuming non-BGPsec portions of the Internet) and/or pairs of islands may join to form larger BGPsec islands 🌈

6.4. Partial Path Signing ✍️

"Partial path signing" means that a BGPsec AS can be permitted to sign an update that was received unsigned from a downstream neighbor 🫣 that is, the AS would add its ASN to the AS path and sign the (previously unsigned) update to other neighboring (upstream) BGPsec ASes 📬

6.4.1. Decision 👑

it was decided that partial path signing in BGPsec will not be allowed 🚷 a BGPsec update must be fully signed, i.e., each AS in the AS path must sign the update 🖊️ so, in a signed update, there must be a signature corresponding to each AS in the AS path 🧾

6.4.2. Discussion 😱

partial path signing (as described above) implies that the AS path is not rigorously protected 🚨 rigorous AS path protection is a key requirement of BGPsec [RFC7353] 🔐 partial path signing clearly reintroduces the following attack vulnerability: if a BGPsec speaker is allowed to sign an unsigned update and if signed (i.e., partially or fully signed) updates would be preferred over unsigned updates, then a faulty, misconfigured, or subverted BGPsec speaker can manufacture any unsigned update it wants (by inserting a valid origin AS) and add a signature to it to increase the chance that its update will be preferred 💀🦹‍♀️

6.5. Consideration of Stub ASes with Resource Constraints: Encouraging Early Adoption 🐣

6.5.1. Decision 🥰

the protocol permits each pair of BGPsec-capable ASes to asymmetrically negotiate the use of BGPsec 🧸 thus, a stub AS (or downstream customer AS) can agree to perform BGPsec only in the transmit direction and speak traditional BGP in the receive direction 📤 in this arrangement, the ISP's (upstream) AS will not send signed updates to this stub or customer AS 📥 thus, the stub AS can avoid the need to hardware-upgrade its route processor and RIB memory to support BGPsec update validation 💖

6.5.2. Discussion 🧚

okay so bestie, here's the tea on the other options the group looked at for helping a resource-constrained stub AS 💅

1. First up is an arrangement that can be set up outside the BGPsec spec 🫶. Through a private deal (invisible to other ASes), an ISP's AS (the upstream AS) can truncate the stub AS (the downstream AS) from the path and sign the update as if the prefix is originating from the ISP's AS, even though the update came in unsigned from the customer AS. That way the path looks fully signed to the rest of the network ✨. This option would need the owner of the prefix at the stub AS to issue a ROA for the upstream AS, so the upstream AS is authorized to originate routes for the prefix.
2. Another outside-the-spec arrangement is giving the stub AS main-character energy 👑. The stub AS doesn't sign updates, but it gets an RPKI (CA) certificate, issues a router certificate under that CA certificate, and passes the private key for that router certificate to its upstream provider. That ISP (the second-hop AS) then inserts a signature on behalf of the stub AS using the key it got from the stub AS. This arrangement is called "proxy signing" (see Section 6.6) 🦋.
3. Next, an extended ROA gets created that lists the stub AS as the originator of the prefix and the upstream provider as the second-hop AS, and partial signatures would be allowed (so the stub AS doesn't need to sign the updates). It's recognized that this approach is also authoritative and not trust based 🔥. It was observed that the extended ROA isn't that different from what happens with the ROA (in its current form) when a Provider-Independent (PI) address is originated from a provider's AS. This approach was rejected because of possible complications with creating and using a new RPKI object, namely, the extended ROA 🙈. Also, the validating BGPsec router has to do a level of indirection here: it has to detect that an update isn't fully signed and then go look for the extended ROA to validate it.
4. Last but not least, another method based on a different form of indirection 🧠. The customer (stub) AS registers something like a Proxy Signer Authorization, which authorizes the second-hop (provider) AS to sign on behalf of the customer AS using the provider's own key [Dynamics]. This method allows for fully signed updates (unlike the extended ROA approach) 🌈. But it also requires creating a new RPKI object, namely, the Proxy Signer Authorization. In this approach, the second-hop AS and the validating ASes have to do a level of indirection. This approach was also rejected 💀.

The various inputs on ISP preferences were taken into consideration, and eventually the decision in favor of asymmetric BGPsec was reached (Section 6.5.1) 🍓. An advantage for a stub AS doing asymmetric BGPsec is that it only needs to minimally upgrade so it can sign updates to its upstream AS, while it still receives only unsigned updates. So it can skip the extra processing and memory costs of performing update validations and storing signed updates in the RIBs, respectively. Iconic ✨.

---

6.6. Proxy Signing 🎀

6.6.1. Decision

An ISP's AS (or upstream AS) can proxy-sign BGP announcements for a customer (downstream) AS, provided that the customer AS obtains an RPKI (CA) certificate, issues a router certificate under that CA certificate, and passes the private key for that certificate to its upstream provider. That ISP (the second-hop AS) inserts a signature on behalf of the customer AS using the private key the customer AS provided. This is a private arrangement between the two ASes and is invisible to other ASes, so it's not part of the BGPsec protocol specification 🫶.

BGPsec will not make any special provisions for an ISP to use its own private key to proxy-sign updates for a customer's AS. This type of proxy signing is considered a bad idea 🙅‍♀️.

6.6.2. Discussion

Picture this: a customer's AS (say, AS8) is multihomed to two ISPs. AS8 peers with AS1 and AS2 of ISP-1 and ISP-2, respectively 🌸. In this case, AS8 would have an RPKI (CA) certificate. It issues two separate router certificates (corresponding to AS1 and AS2) under that CA certificate, and it passes the respective private keys for those two certificates to its upstream providers AS1 and AS2. So AS8 has a proxy-signing service from both of its upstream ASes 👑. In the future, if AS8 were to disconnect from ISP-2, it would revoke the router certificate corresponding to AS2 💅.

---

6.7. Multiple Peering Sessions between ASes 🦋

6.7.1. Decision

No problems are anticipated when BGPsec-capable ASes have multiple peering sessions between them (between distinct routers) ✨.

6.7.2. Discussion

In traditional BGP, multiple peering sessions between different pairs of routers (between two neighboring ASes) can be used at the same time for load sharing. BGPsec-capable ASes can also have multiple peering sessions between them 🌈. Because routers in an AS can have distinct private keys, the same update, when propagated over these multiple peering sessions, results in multiple updates that may differ in their signatures. The peer (upstream) AS applies its normal procedures for selecting a best path from those multiple updates (and updates from other peers) 🧠.

Whether to load balance (versus using one peering session as the primary for carrying data and another as the backup) is entirely local and is up to the two neighboring ASes 🍓.

---

7. Interaction of BGPsec with Common BGP Features 🌈

7.1. Peer Groups

In traditional BGP, peer groups are used in BGP routers to save on processing when generating and sending updates. Multiple peers for whom the same policies apply can be organized into peer groups. A peer group can typically have tens of ASes (and maybe as many as 300) in it 🧚.

7.1.1. Decision

It was decided that BGPsec updates are generated to target unique AS peers, so there is no support for peer groups in BGPsec 🙈.

7.1.2. Discussion

BGPsec router processing can make use of peer groups before the signing of updates to peers. Some of the update processing prior to forwarding to members of a peer group can be done only once per update, as is done in traditional BGP. Prior to forwarding the update, a BGPsec speaker adds the peer's ASN to the data that needs to be signed and signs the update for each peer AS in the group individually 💖.

If updates were signed per peer group, information about the forward AS set that makes up a peer group would have to be divulged (since the ASN of each peer would have to be included in the update). Some ISPs don't like to share this kind of info globally 🔥.

7.2. Communities 🎀

The need to provide protection in BGPsec for the community attribute was discussed 💅.

7.2.1. Decision

Community attribute(s) will not be included in any message that is signed in BGPsec 🙅‍♀️.

7.2.2. Discussion

From a security standpoint, the community attribute, as currently defined, may be inherently defective 😭. A substantial amount of work on the semantics of the community attribute is needed, and additional work on its security aspects also needs to be done. The community attribute is not necessarily transitive; it's often used only between neighbors. In those contexts, transport-security mechanisms suffice to provide integrity and authentication. (There's no need to sign data when it's only passed between peers 🫶.) It was suggested that one could include only the transitive community attributes in any message that is signed and propagated across the AS path.

It was noted that there is a flag available (i.e., unused) in the community attribute, and it might be used by BGPsec (in some fashion). However, little information is available right now about the use and function of this flag. It was speculated that this flag could potentially be used to indicate to BGPsec whether or not the community attribute needs protection 🤔. For now, community attributes will not be secured by BGPsec path signatures 💀.

7.3. Consideration of iBGP Speakers and Confederations 🧚‍♀️

7.3.1. Decision

An iBGP speaker that is also an eBGP speaker and that executes BGPsec will by necessity carry BGPsec data and perform eBGPsec functions ✨. Confederations are eBGP clouds for administrative purposes and contain multiple Member-ASes. A Member-AS is not required to sign updates sent to another Member-AS within the same confederation. However, if BGPsec signing is applied in eBGP within a confederation, i.e., each Member-AS signs to the next Member-AS in the path within the confederation, then upon egress from the confederation, the Member-AS at the boundary must remove any and all signatures applied within the confederation. The Member-AS at the boundary of the confederation will sign the update to an eBGPsec peer using the public ASN of the confederation and its private key. The BGPsec specification will not specify how to perform this process 🎀.

Note: In RFC 8205, signing a BGPsec update between Member-ASes within a confederation is required if the update is going to propagate with signatures within the confederation. A Confed_Segment flag exists in each Secure_Path segment, and when set, it indicates that the corresponding signature belongs to a Member-AS. At the confederation boundary, all signatures with Confed_Segment flags set are removed from the update. RFC 8205 specifies in detail how all of this is done. Please see Figure 5 in Section 3.1 of [RFC8205], as well as Section 4.3 of [RFC8205], for details 📚.

7.3.2. Discussion

This topic may need to be revisited to flesh out the details carefully 🙈.

7.4. Consideration of Route Servers in IXPs 🌸

7.4.1. Decision

[BGPsec-Initial] made no special provisions to accommodate route servers in Internet Exchange Points (IXPs) 🥺.

Note: The above decision subsequently changed. RFC 8205 allows the accommodation of IXPs, especially for transparent route servers. The pCount (AS prepend count) field is set to zero for transparent route servers (see Section 4.2 of [RFC8205]). The operational guidance for preventing the misuse of pCount=0 is given in Section 7.2 of RFC 8205. Also, see Section 8.4 of RFC 8205 for a discussion of security considerations concerning pCount=0 🔐.

7.4.2. Discussion 💬

okay bestie, so there are basically three ways an IXP can pass routes around 🦋: (A) direct bilateral peering straight through the IXP, (B) BGP peering between clients via peering with a route server at the IXP, where the IXP does not stick its ASN in the path, and (C) BGP peering with an IXP route server where the IXP does insert its ASN in the path. (Note: the route server doesn't change the NEXT_HOP attribute, even if it inserts its ASN in the path 🍓)

Method C is super rare because clients are not fans when their AS path length goes up by one just because of the IXP 🙈. You can measure how much each method gets used by looking at the IP traffic load percentages. At a major European IXP, it's about 80% for Method A and 20% for Method B (this data is based on private communication with IXPs circa 2011 📅). BUT as the IXP grows in number of clients, it tends to migrate more toward Method B, because managing up to n x (n-1)/2 direct interconnections between n peers in Method A is a whole mess 😭.

To the extent that an IXP is doing direct bilateral peering between clients (Method A), that model works naturally with BGPsec 💖. Also, if the route server in the IXP acts like a regular BGPsec speaker (minus the routing part for payload) and inserts its own ASN in the path (Method C), then that model would also work well in the BGPsec Internet, and this case is trivially supported in BGPsec ✨.

---

7.5. Proxy Aggregation (a.k.a. AS_SETs) 🎀

7.5.1. Decision

Proxy aggregation (i.e., the use of AS_SETs in the AS path) will not be supported in BGPsec 🚫. There is no provision in BGPsec to sign an update when an AS_SET is part of an AS path. If a BGPsec-capable router receives an update that contains an AS_SET and also finds that the update is signed, then the router will consider the update malformed (i.e., a protocol error) 💀.

Note: Section 5.2 of RFC 8205 specifies that a receiving BGPsec router "MUST handle any syntactical or protocol errors in the BGPsec_PATH attribute by using the 'treat-as-withdraw' approach as defined in RFC 7606 [RFC7606]."

7.5.2. Discussion

Proxy aggregation does happen on the Internet today, but it's very rare 🌸. Only a tiny fraction (about 0.1%) of observed updates contain AS_SETs in the AS path [ASset]. Since traditional BGP still allows proxy aggregation with AS_SETs in the AS path, BGPsec has to specify what a receiving router must do if one of these updates shows up with attestation 🧐. BCP 172 [RFC6472] recommends against using AS_SETs in updates, so it's expected that AS_SETs will diminish over time 📉.

7.6. 4-Byte AS Numbers 🧚

Not all (currently deployed) BGP speakers can deal with 4-byte ASNs [RFC6793] 😬. The standard mechanism for accommodating those speakers requires a peer AS to translate each 4-byte ASN in the AS path to the reserved 2-byte ASN (23456) before forwarding the update. This mechanism is incompatible with BGPsec, since the ASN translation is equivalent to a route modification attack and will cause signatures corresponding to the translated 4-byte ASNs to fail validation 🚨.

7.6.1. Decision

BGP speakers that are BGPsec capable are required to process 4-byte ASNs 💅.

7.6.2. Discussion

It's reasonable to assume that upgrades for 4-byte ASN support will be in place before BGPsec gets deployed 🌈.

---

8. BGPsec Validation ✨

8.1. Sequence of BGPsec Validation Processing in a Receiver 🔍

It's natural to ask what order a receiver should do BGPsec update validation in, so that if something fails (i.e., the update is determined to be invalid), the processor has 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 suggested above is seen as appropriate 👑. One additional interesting suggestion was that when there are two Signature_Blocks in an update, the validating router can first check 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 🌍. So 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 that same AS 😵‍💫.

A BCP may be published later that identifies 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 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 detecting 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). So 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 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's 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 💅

okay so, if there are syntactic-error situations like (A) AS_SET and BGPsec_PATH both showing up in one update, (B) the number of signatures not matching the number of ASes (after accounting for any AS prepending), or (C) a parsing issue with the BGPsec_PATH attribute, then the update (with the signatures stripped) will still get considered in the best-path-selection algorithm 🫶 (Note: This is not true in RFC 8205.) if it gets picked as the best path, it gets propagated unsigned. the error gets logged locally 📝

a BGPsec router will follow whatever the current IETF (IDR WG) recommendations are for telling a peer that it's sending malformed messages 📬

now the case with two Signature_Blocks in one update. if one or more syntax errors happen in one of them but the other one is totally clean, then the update still gets considered in the best-path-selection algorithm, once the syntactically bad Signature_Block has been removed 🧹 (Note: This is not true in RFC 8205.) if it's picked as the best path, it gets propagated with only one Signature_Block, the error-free one. and yep, the error gets logged locally 🎀

8.5.2. Discussion 🌸

so, like we said, a BGPsec router will follow whatever the current IETF (IDR WG) recommendations are for telling a peer it's sending malformed messages. but here's the spicy question 🌶️: if the error is persistent and a full BGP table dump happens, would there be 500K of these errors, which means 500K "notify" messages sent to the peer that's generating them? 😭 the answer is that rate limiting would be applied to the notify messages, and that should stop any overload caused by them 🛑✨

8.6. Enumeration of Validation States 🦋

okay so there are a bunch of validation conditions that can be mapped to validation states, for the input to the BGPsec decision process 🧚 these conditions can have to do with whether an update is signed, whether the Expire Time is checked, whether route origin validation is checked against a ROA, whether signature verification passed, and so on 💜

8.6.1. Decision 👑

it was decided that BGPsec validation outcomes get mapped to only two validation states: (1) Valid, which means it passed all the validation checks (the Expire Time check, route origin, and Signature_Block validation), and (2) Invalid, which is everything else 🙈 "Invalid" would include situations like these:

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's worth noting 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) gets 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 we said before, it was later decided that BGPsec validation outcomes get mapped to only two validation states. it was observed that an update can be invalid for lots of different reasons. trying to split those reasons up and enumerate different flavors of the Invalid state won't likely be constructive in route-selection decisions, and it might even introduce new vulnerabilities into the system 🚨 but some questions are still open, like these:

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's no need to add another validation state for this case. treat it as "Invalid", considering that it's unsigned 🙅‍♀️

another open 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 or unsigned update may be conveyed via iBGP, from an ingress edge router to an egress edge router. local policy in the AS determines how the validation status gets 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 can't be validated (except the ones with syntax errors) should be forwarded with signatures from the ingress router to the egress router, where it gets signed when it's propagated toward 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, in circumstances where 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 they 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's useful for diagnostics purposes? the decision was made not to protect the validation-state information using signatures 🔐

the following validation states may be needed for propagation via iBGP between edge routers in an AS:

• 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 don't need to be distinguished: (a) it had no signatures (i.e., came in unsigned from an eBGP peer), or (b) signatures were present but stripped.
• Validation states communicated in iBGP for a signed update: (1) Valid, (2) Invalid, (3) Validation Deferred.

the reason for conveying the extra "Validation Deferred" state can be illustrated like this. 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). 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 and signature validation for a signed update) 🫶 as said before, the egress router (Router B in this example) may always choose to perform its own validation when it receives an update from iBGP, no matter the update's validation status conveyed in iBGP, to account for the possibility of RPKI data skew at different routers. these choices are all local and entirely at the operator's discretion 🎀

9. Operational Considerations 🧚

Note: Significant thought has been devoted to operations and management considerations since [BGPsec-Initial] was written. 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 still functioning. two questions were raised: are there any special concerns about how BGP-GR works while BGPsec is operational? and 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 [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 like it's 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 the key parameters associated with BGP-GR [RFC4724]. these parameters would apply to BGPsec, just like they apply to traditional BGP 💅

about what happens if the BGP router transitions from traditional BGP to BGP-GR to BGPsec, the answer is pretty simple. if there's a software upgrade to BGPsec during BGP-GR (assuming the upgrade is happening 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's no apparent harm (it may, in fact, be desirable) if the receiving speaker keeps using previously learned unsigned BGP routes from the sending speaker until they're 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

okay so BCP recs for minimizing churn in BGPsec have been talked about 💬✨ There are a bunch of possible strategies for how routers should react to stuff like certificate expiry/revocation and signature Expire Time exhaustion [Dynamics]. The details will be documented in the near future, once more work gets done 🫶

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

okay so possibly, an off-router box (one or more per AS) can be used to do path validation 🦋 For example, these capabilities might get folded into a route reflector. At an ingress router, you need the Adj-RIB-In entries validated but not the RIB-out entries. So the off-router box is probably not like a traditional route reflector. It sits at the network edge and validates all incoming BGPsec updates 🌸 Thus, it looks like each router passes each BGPsec update it receives to the off-router box and gets back a validation result before it stores the route in the Adj-RIB-In.

Question: what about failure modes here? 😭 The failure modes would depend on:

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. In other words, 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, BGPsec deployment will be incremental, and signed updates are not sent outside of a set of contiguous BGPsec-enabled ASes. So 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 🔐 Given the incremental-deployment model, though, 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, and they're giving main character energy 🌈 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). Not me being a little dramatic about this 🙈

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 ✨

okay bestie, this is where the RFC shows its receipts 🧾💅 every source it leans on is listed here, with all the deets 💖

• [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 ✨

okay the shoutouts 🫶💖 The author wants to say a big thank you to Jeff Haas and Wes George for being reviewers of this document for the Independent Submissions stream 🎀 The author is also super grateful to Nevil Brownlee for shepherding this document through the Independent Submissions review process 🌸 And a massive thank you 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 💖

These people made big contributions to this doc and should be counted as 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.edu

---

Author's Address 🎀

This is the editor who pulled the whole thing together, so give them some love 💖

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

Email: ksriram@nist.gov