RFC 8206

BGPsec Considerations for Autonomous System (AS) Migration

📅 published September 2017, from ietf

BGPsec Considerations for Autonomous System (AS) Migration 🎀

Okay bestie, this one is all about ASN migrations and how BGPsec has to survive them. 💖 It's Standards Track (so it's the real deal, not just an idea), it's dated September 2017, and it's by W. George (Neustar) and S. Murphy (PARSONS, Inc.). It has ISSN 2070-1721 and it updates RFC 8205 ✨. It doesn't obsolete anything. Its whole job is to sort out how the RFC 8205 design handles a common AS migration method, safely.

Abstract ✨

This doc talks through the considerations and methods for supporting, and securing, a common way of doing Autonomous System (AS) migration inside the BGPsec protocol. 🦋

Status of This Memo 📜

This is an Internet Standards Track document. 💅

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841. 🌸

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8206. 🔥

Copyright (c) 2017 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, which you can find at https://trustee.ietf.org/license-info as they stood on the publication date. Please actually read those, because they lay out your rights and restrictions for this document. 🙈 If you extract Code Components from this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. ⚠️

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
  1.2.  Documentation Note  . . . . . . . . . . . . . . . . . . .   3
2.  General Scenario  . . . . . . . . . . . . . . . . . . . . . .   3
3.  RPKI Considerations . . . . . . . . . . . . . . . . . . . . .   3
  3.1.  Origin Validation . . . . . . . . . . . . . . . . . . . .   4
  3.2.  Path Validation . . . . . . . . . . . . . . . . . . . . .   5
    3.2.1.  Outbound Announcements (PE-->CE)  . . . . . . . . . .   5
    3.2.2.  Inbound Announcements (CE-->PE) . . . . . . . . . . .   6
4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
5.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
  5.1.  Outbound (PE-->CE)  . . . . . . . . . . . . . . . . . . .   8
  5.2.  Inbound (CE-->PE) . . . . . . . . . . . . . . . . . . . .   8
  5.3.  Other Considerations  . . . . . . . . . . . . . . . . . .   9
  5.4.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   9
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
  8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
  8.2.  Informative References  . . . . . . . . . . . . . . . . .  15
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1. Introduction 🌈

Here's the tea: RFC 7705 [RFC7705] describes a way to manage a BGP Autonomous System Number (ASN) migration. 🍓 Because it messes with AS_PATH attributes, BGPsec [RFC8205] has to be checked to make sure it properly supports the process and its features. ✨ That's because BGPsec is explicitly designed to protect against changes to the BGP AS_PATH, whether they happen on purpose, by misconfiguration, or from malicious intent. 😭 The BGPsec framework needs to support this operationally necessary tool without opening up an unacceptable security risk or exploit along the way. 💀

1.1. Requirements Language 🔑

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💜

1.2. Documentation Note 📝

This document uses ASNs from the range reserved for documentation, as described in RFC 5398 [RFC5398]. 🦋 In the examples, they're meant to stand in for Globally Unique ASNs, not the ASNs reserved for private use that are documented in Section 10 of RFC 1930 [RFC1930]. So no, these aren't private ASNs, babe. 🙅‍♀️

2. General Scenario 🌸

This doc assumes you've already read and understood the ASN migration method in RFC 7705 [RFC7705], including its examples (see Section 2 of the referenced document), because they get referenced a LOT here. 📚 The use case from RFC 7705 [RFC7705] goes like this: for whatever reason, a provider is merging two or more ASes, and eventually one of them absorbs the others. 🔥 BGP AS confederations [RFC5065] aren't turned on between the ASes. Instead, a mechanism tweaks BGP's default behavior so the migrating Provider Edge (PE) router can masquerade as the old ASN for the Provider-Edge-to-Customer-Edge (PE-CE) eBGP (external BGP) session, or manipulate the AS_PATH, or do both. 🎭

BGPsec [RFC8205] does have a way to handle standard confederation setups, but it doesn't apply to this exact case. 🙃 Migration needs a slightly different BGPsec solution than a standard confederation does, because unlike a confederation, eBGP peers might not be peering with the "correct" external ASN. Also, the forward-signed updates are for a public ASN instead of a private one. So there's no expectation that the BGP speaker would strip the affected signatures before passing the route on to its eBGP neighbors. 🫣

In the examples in Section 5.4, AS64510 is getting subsumed by AS64500, and both ASNs represent a Service Provider (SP) network (see Figures 1 and 2 in RFC 7705 [RFC7705]). ✨ AS64496 and 64499 are end-customer networks. 🏠 The PE, CE, and P router references match the diagrams and references in RFC 7705. 🧩

3. RPKI Considerations 🔐

The methods and implementation in RFC 7705 [RFC7705] get used a lot during network integrations from mergers and acquisitions, and during network redesigns too. 👑 So it's necessary to support this capability on any BGPsec-enabled routers/ASNs. 💅 What follows is a look at the potential issues to consider around how ASN migration and BGPsec [RFC8205] validation might interact. 🔍

Here's the big one: service providers (SPs) rarely stop after one merger, acquisition, or divestiture. 😩 They end up piling up several legacy ASNs over time. 🗂️ SPs use migration methods that are transparent to customers, so they don't need to coordinate with them. That means they don't have as much control over how long the transition takes as they would with something completely under their own administrative control, like a key roll. 🎢 SPs also aren't forcing a simultaneous migration, where both ends switch to the new ASN at an agreed-upon time. So there's no incentive for a given customer to finish the move from the old ASN to the new one. 🙄 That leaves many SPs with multiple legacy ASNs that don't go away very quickly, if ever. 💀

When solutions for Resource Public Key Infrastructure (RPKI) implementations were being proposed to handle this transition, the WG carefully considered operational complexity and hardware scaling issues. 🧠 Those issues come from maintaining multiple legacy ASN keys on routers across the combined network. SPs that choose to stay in this transition phase indefinitely invite added risks, because of that same operational complexity and scaling burden. 😬 Still, saying "don't do this" is of limited utility as a solution. 🙃 So this solution tries to minimize the extra complexity during the transition period, on the assumption that the transition will likely be protracted. ⏳ This doc mostly talks about service provider considerations, but it isn't solely for SPs. Enterprises often migrate between ASNs using the same functionality too. 🏢 Next up: origin and path validation, and how they interact with ASN migrations. 🎀

3.1. Origin Validation 🛡️

Route Origin Validation, as defined by RFC 6480 [RFC6480], doesn't need to be modified to enable AS migration. The existing protocol and procedure already allow for a solution. 🙌 In the scenario from RFC 7705 [RFC7705], AS64510 is getting replaced by AS64500. 🔄

If there are any existing routes originated by AS64510 on the router being moved into the new ASN, new Route Origination Authorizations (ROAs) for those routes with the new ASN should be generated. They should be treated as new routes to be added to AS64500. ✨ But we also need to think about the situation where one or more other PEs are still in AS64510 and originating routes that might be different from anything the router under migration is originating. 🤔 PE1 is now part of AS64500, and it's instructed to use "Replace Old AS" as defined in [RFC7705] to remove AS64510 from the path. So PE1 needs to be able to properly handle routes originated from AS64510. 🧐

If the route now shows up as originating from AS64500, any downstream peer's validation check will fail, unless a ROA is also available for AS64500 as the origin ASN. 😱 Besides generating a ROA for 65400 for any prefixes originated by the router being moved, it may be necessary to generate ROAs for 65400 for prefixes originating on routers still in 65410. The reason is that the AS replacement function will change the origin AS in some cases. 🔁

This means there will be multiple ROAs showing different ASes authorized to originate the same prefixes, until all routers originating prefixes from AS64510 are migrated to AS64500. 🌀 Multiple ROAs of this type are permissible per Section 3.2 of RFC 6480 [RFC6480]. So managing origin validation during a migration like this is just applying the defined case where a set of prefixes is originated from more than one ASN. 💁‍♀️

Therefore, for each ROA that authorizes the old ASN (e.g., AS64510) to originate a prefix, a new ROA MUST also be created that authorizes the replacing ASN (e.g., AS64500) to originate the same prefix. 🚨

3.2. Path Validation 🧵

BGPsec path validation requires that each router in the AS path cryptographically sign its update, to assert that "every Autonomous System (AS) on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route to the subsequent AS in the path" (see Section 1 of RFC 8205 [RFC8205]). 🔏

Here's the catch. The referenced AS-migration technique explicitly modifies the AS_PATH between two eBGP peers who aren't coordinating with each other, meaning they aren't in the same administrative domain. 🫠 So no level of trust can be assumed. That makes it kinda hard to tell legitimate AS_PATH manipulation done for migration apart from manipulation caused by misconfiguration or malicious intent. 🕵️‍♀️😈

3.2.1. Outbound Announcements (PE-->CE)

okay so when PE1 gets moved from AS64510 to AS64500 🦋, it gets the right keys for AS64500 so it can forward-sign routes as AS64500 💖. The catch is that the BGPsec protocol spec [RFC8205] doesn't say whether the forward-signed ASN has to match the configured remote AS for the route to validate 😭. So if CE1 has "remote AS 64510" configured and PE1 has "local AS 64510", the BGP session itself is happy and there's no ASN mismatch on the session 🌸. BUT if CE1 gets updates from PE1 that were forward-signed from AS64500, there's no guidance on whether CE1's BGPsec validator still treats them as valid by default 🤔. Section 6.3 of RFC 4271 [RFC4271] talks about this match between the peer's ASN and the AS_PATH data, but it's listed as an optional validation, not a requirement 💀. We can't assume vendor implementations will allow this mismatch, so using it to solve this migration case is likely to be problematic 🙈.

3.2.2. Inbound Announcements (CE-->PE)

inbound is messier 😩. The CE doesn't know PE1 changed ASNs, so it's forward-signing all of its routes with AS64510, not AS64500 ❌. A BGPsec speaker can't manipulate previous signatures, so it can't manipulate the previous AS path without causing a mismatch that invalidates the route 💔. If the updates are simply left intact, the ISP would still need to publish and maintain valid and active public keys for AS 64510 if it's going to appear in the BGPsec_PATH signature, so receivers can validate that the BGPsec_PATH signature arrived intact/whole 🔐. But if the updates are left intact, the AS path length gets increased, which is unacceptable as discussed in RFC 7705 [RFC7705] 🙅.

4. Requirements

In order to be deployable ✨, any solution to the described problem needs to consider the following requirements, listed in no particular order. BGPsec:

  • 💅 MUST support AS migration for both inbound and outbound route announcements (see Sections 3.2.1 and 3.2.2), without reducing BGPsec's protections for route path.
  • 🫶 MUST NOT require any reconfiguration on the remote eBGP neighbor (CE).
  • 🌈 SHOULD NOT require global (i.e., network-wide) configuration changes to support migration. The goal is to limit required configuration changes to the devices (PEs) being migrated.
  • 🦋 MUST NOT lengthen the AS path during migration.
  • 👑 MUST operate within existing trust boundaries, e.g., can't expect remote side to accept pCount=0 (see Section 4.2 of RFC 8205 [RFC8205]) from untrusted/non-confederation neighbor.

5. Solution

As noted in Section 4.2 of RFC 8205 [RFC8205], BGPsec already has a solution for hiding ASNs where increasing the AS path length is undesirable 🧚. So a simple solution would be to retain the keys for AS64510 on PE1 and forward-sign towards CE1 with AS64510 and pCount=0. However, this would mean passing a pCount=0 between two ASNs that are in different administrative and trust domains, so it could represent a significant attack vector to manipulate BGPsec-signed paths 🚨. The expectation for legitimate instances of pCount=0 (to make a route server that is not part of the transit path invisible) is that there's some sort of existing trust relationship between the operators of the route server and the downstream peers, so the peers could be explicitly configured by policy to accept pCount=0 announcements only on the sessions where they're expected 🍓. For the same reason that things like "Local AS" [RFC7705] are used for ASN migration without end-customer coordination, it's unrealistic to assume any sort of coordination between the SP and the administrators of CE1 to make sure they'll accept pCount=0 signatures by policy during the transition period 😤. So this is not a workable solution.

A better solution shows up when we think about how to handle routes coming from the CE toward the PE, where the routes are forward-signed to AS64510 but will eventually need to show AS64500 in the outbound route announcement 🎀. Because both AS64500 and AS64510 are in the same administrative domain, a signature from AS64510 forward-signed to AS64500 with pCount=0 would be acceptable, since it would be within the appropriate trust boundary, so each BGP speaker could be explicitly configured to accept pCount=0 where appropriate between the two ASNs ✨. At the very simplest, this could potentially be used at the eBGP boundary between the two ASNs during migration. Since the AS_PATH manipulation described above usually happens at the PE router on a per-session basis and doesn't happen network-wide all at once, it's not generally appropriate to apply this AS-hiding technique across all routes exchanged between the two ASNs, because it may result in routing loops and other undesirable behavior 🌀. Therefore, the most appropriate place to implement this is on the local PE that still has eBGP sessions with peers expecting to peer with AS64510 (using the transition mechanisms detailed in RFC 7705 [RFC7705]). Since that PE has been moved to AS64500, it's not possible for it to forward-sign AS64510 with pCount=0 without some minor changes to the BGPsec behavior to address this use case 🛠️.

AS migration is using AS_PATH and remote AS manipulation to act as if a PE under migration exists simultaneously in both ASNs, even though it's only configured with one global ASN 🪞. This document describes applying a similar technique to the BGPsec signatures generated for routing updates processed through this migration machinery. Each routing update that is received from or destined to an eBGP neighbor that is still using the old ASN (64510) will be signed twice: once with the ASN to be hidden and once with the ASN that will remain visible 👯. In essence, we're treating the update as if the PE had an internal BGP hop and the update was passed across an eBGP session between AS64500 and AS64510, configured to use and accept pCount=0, while skipping the processing and storage overhead of creating an actual eBGP session between the two ASNs within the PE router 💜. This will result in a properly secured AS path in the affected route updates, because the PE router will be provisioned with valid keys for both AS64500 and AS64510 🔥. An important distinction here is that while AS migration under standard BGP4 is manipulating the AS_PATH attribute, BGPsec uses an attribute called the "Secure_Path" (see Section 3.1 of RFC 8205 [RFC8205]), and BGPsec-capable neighbors do not exchange AS_PATH information in their route announcements 🦋. However, a BGPsec neighbor peering with a non-BGPsec-capable neighbor will use the information found in the Secure_Path to reconstruct a standard AS_PATH for updates sent to that neighbor 🧩. Unlike in the Secure_Path, where the ASN to be hidden is still present but ignored when considering the AS path (due to pCount=0), when reconstructing an AS_PATH for a non-BGPsec neighbor, the pCount=0 ASNs will not appear in the AS_PATH at all (see Section 4.4 of RFC 8205 [RFC8205]). This document is not changing existing AS_PATH reconstruction behavior, just highlighting it for clarity 📌.

The procedure to support AS migration in BGPsec is slightly different depending on whether the PE under migration is receiving the routes from one of its eBGP peers ("inbound" as in Section 3.2.2) or sending them toward its eBGP peers ("outbound" as in Section 3.2.1) 🌷.

5.1. Outbound (PE-->CE)

When a PE router receives an update destined for an eBGP neighbor that is locally configured with AS-migration mechanisms as discussed in RFC 7705 [RFC7705], it MUST generate a valid BGPsec signature as defined in RFC 8205 [RFC8205] for _both_ configured ASNs 💖. It MUST generate a signature from the new (global) ASN forward-signing to the old (local) ASN with pCount=0, and then it MUST generate a forward signature from the old (local) ASN to the target eBGP ASN with pCount=1 as normal 🎀.

5.2. Inbound (CE-->PE)

When a PE router receives an update from an eBGP neighbor that is locally configured with AS-migration mechanisms (i.e., the opposite direction of the previous route flow), it MUST generate a signature from the old (local) ASN forward-signing to the new (global) ASN with pCount=0 🔁. It's not necessary to generate the second signature from the new (global) ASN, because the Autonomous System Border Router (ASBR) will generate that when it forward-signs towards its eBGP peers as defined in normal BGPsec operation 🫧. Note that a signature is not normally added when a routing update is sent across an iBGP (internal BGP) session 🙈. The requirement to sign updates in iBGP represents a change to the normal behavior for this specific AS-migration scenario only ⭐.

5.3. Other Considerations

In the inbound case discussed in Section 5.2, the PE is adding BGPsec attributes to routes received from or destined to an iBGP neighbor and using pCount=0 to mask them 🌸. While this is not prohibited by BGPsec [RFC8205], BGPsec-capable routers that receive updates from BGPsec-enabled iBGP neighbors MUST accept updates with new (properly formed) BGPsec attributes, including the presence of pCount=0 on a previous signature, or they will interfere with this method 🛡️. In a similar fashion, any BGPsec-capable route-reflectors in the path of these updates MUST reflect them transparently to their BGPsec-capable clients 🪽.

In order to secure this set of signatures, the PE router MUST be provisioned with valid keys for _both_ configured ASNs (old and new), and the key for the old ASN MUST be kept valid until all eBGP sessions are migrated to the new ASN 🔐. Downstream neighbors will see this as a valid BGPsec path, because they will simply trust that their upstream neighbor accepted pCount=0 because it was explicitly configured to do so, based on a trust relationship and business relationship between the upstream and its neighbor (the old and new ASNs) 🤝.

Additionally, Section 4 of RFC 7705 [RFC7705] discusses methods in which AS migrations can be completed for iBGP peers, such that a session between two routers will be treated as iBGP even if the neighbor ASN is not the same ASN on each peer's global configuration 🧚‍♀️. As far as BGPsec is concerned, this requires the same procedure as when the migrating routers are applying AS-migration mechanisms to eBGP peers, but the router functioning as the "ASBR" between the old and new ASN is different 🌈. In eBGP, the router being migrated has direct eBGP sessions to the old ASN and signs from old ASN to new with pCount=0 before passing the update along to additional routers in its global (new) ASN 💅. In iBGP, the router being migrated is receiving updates (that may have originated either from eBGP neighbors or other iBGP neighbors) from its downstream neighbors in the old ASN, and it MUST sign those updates from old ASN to new with pCount=0 before sending them on to other peers 👑.

5.4. Example 💖

okay bestie, this is the part where we walk through the whole thing with actual routers 🎀 same cast as before: PE1 is the router getting migrated, and AS64510 is the old ASN that's getting subsumed by AS64500, the one that's staying forever 👑 64505 is another external peer, there so we can see what the announcements look like to a third party that's NOT part of the migration 👀

Quick notation check before the diagrams, because it's a lot of signatures stacked on top of each other 🥞 The origin BGPsec Signature Segment looks like this:

sig(Target ASN, (pCount,...,Origin ASN), NLRI) key

Intermediate BGPsec Signature Segments look like this:

sig(Target ASN,...,(pCount,...,Signer ASN),...,NLRI) key

(pCount,...,ASN) is the new Secure_Path Segment that gets added to the BGPsec_PATH attribute by the ASN (either the Origin ASN or the Signer ASN) 🧩

"Equivalent AS_PATH" is what the AS_PATH would look like if it got rebuilt for a non-BGPsec peer, while the Securedpath is how the AS path shows up between BGPsec peers 🦋

Okay so real talk, I simplified how the signature generation is shown here so it doesn't become a novel 😭 The actual details are in Sections 4.1 and 4.2 of [RFC8205]. For example, what gets covered by the signature also includes Flags, Algorithm Suite Identifier, NLRI length, and more. And the key isn't carried in the update at all. Instead, the Subject Key Identifier (SKI) is carried 🔑

Before Merger

                                       64505
                                       |
             ISP B                     ISP A
   CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
   64496     Old_ASN: 64510   Old_ASN: 64500     64499

   CE-2 to PE-2:  sig(64500, (pCount=1,...,64499), N)K_64499-CE2
                  Equivalent AS_PATH=(64499)
                  Securedpath=(64499)
                  length=sum(pCount)=1

   PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
                  sig(64500, (pCount=1,...,64499), N)K_64499-CE2
                  Equivalent AS_PATH=(64500,64499)
                  Securedpath=(64500,64499)
                  length=sum(pCount)=2

   PE-2 to PE-1:  sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
                  sig(64500, (pCount=1,...,64499), N)K_64499-CE2
                  Equivalent AS_PATH=(64500,64499)
                  Securedpath=(64500,64499)
                  length=sum(pCount)=2

   PE-1 to CE-1:  sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
                  sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
                  sig(64500, (pCount=1,...,64499), N)K_64499-CE2
                  Equivalent AS_PATH= (64510,64500,64499)
                  Securedpath=(64510,64500,64499)
                  length=sum(pCount)=3

Migrating, route flow outbound PE-1 to CE-1

                                     64505
                                     |
           ISP A'                    ISP A'
 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
 64496     Old_ASN: 64510   Old_ASN: 64500     64499
           New_ASN: 64500   New_ASN: 64500


 CE-2 to PE-2:  sig(64500, (pCount=1,...,64499), N)K_64499-CE2
                Equivalent AS_PATH=(64499)
                Securedpath=(64499)
                length=sum(pCount)=1

 PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
                sig(64500, (pCount=1,...,64499), N)K_64499-CE2
                Equivalent AS_PATH=(64500,64499)
                Securedpath=(64500,64499)
                length=sum(pCount)=2

 PE-2 to PE-1:  sig(64500, (pCount=1,...,64499), N)K_64499-CE2
                Equivalent AS_PATH=(64499)
                Securedpath=(64499)
                length=sum(pCount)=1
 #PE-2 sends to PE-1 (in iBGP) the exact same update
 #as it received from AS64499.


 PE-1 to CE-1:  sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
                sig(64510,...,(pCount=0,...,64500),...,N)K_64500-PE2 (*)
                sig(64500, (pCount=1,...,64499), N)K_64499-CE2
                Equivalent AS_PATH=(64510,64499)
                Securedpath=(64510, 64500 (pCount=0),64499)
                length=sum(pCount)=2 (length is NOT 3)
 #PE-1 adds the Secure_Path Segment in (*) acting as AS64500
 #PE-1 accepts (*) with pCount=0 acting as AS64510,
 #as it would if it received (*) from an eBGP peer

Migrating, route flow inbound CE-1 to PE-1

                                    64505
                                    |
          ISP A'                    ISP A'
CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2
64496     Old_ASN: 64510   Old_ASN: 64500     64499
          New_ASN: 64500   New_ASN: 64500


CE-1 to PE-1:  sig(64510, (pCount=1,...,64496), N)K_64496-CE1
               Equivalent AS_PATH=(64496)
               Securedpath=(64496)
               length=sum(pCount)=1

PE-1 to PE-2:  sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1 (**)
               sig(64510, (pCount=1,...,64496), N)K_64496-CE1
               Equivalent AS_PATH=(64496)
               Securedpath=(64510 (pCount=0),64496)
               length=sum(pCount)=1 (length is NOT 2)
#PE-1 adds the Secure_Path Segment in (**) acting as AS64510
#PE-1 accepts (**) with pCount=0 acting as AS64500,
#as it would if it received (**) from an eBGP peer
#PE-1, as AS64500, sends the update including (**) to PE-2 (in iBGP)

PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
               sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
               sig(64510, (pCount=1,...,64496), N)K_64496-CE1
               Equivalent AS_PATH=(64500,64496)
               Securedpath=(64500,64510 (pCount=0), 64496)
               length=sum(pCount)=2 (length is NOT 3)

PE-2 to CE-2:  sig(64499,...,(pCount=1,...,64500),...,N)K_64500-PE2
               sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
               sig(64510, (pCount=1,...,64496), N)K_64496-CE1
               Equivalent AS_PATH=(64500,64496)
               Securedpath=(64500, 64510 (pCount=0), 64496)
               length=sum(pCount)=2 (length is NOT 3)

6. IANA Considerations 🌸

Good news for the paperwork crew: this document does not require any IANA actions ✨

7. Security Considerations 🔥

Okay, this section is the serious one, so buckle up 😭 [RFC7705] talks about a process where one ASN gets migrated into another and subsumed by it. And here's the tea: that process messes with the AS_Path in a BGP route so it no longer matches the path it actually took through the network. So the migration is literally doing the exact thing BGPsec is built to stop 🙈 BGPsec MUST be able to handle this legit use of AS_Path manipulation WITHOUT opening a vulnerability in the RPKI route security infrastructure, and this document exists to define how the protocol can meet that need 🛡️

The solution above is considered reasonably secure against a malicious actor, because both signatures have to be secured as if they were forward-signed between two eBGP neighbors. That means any router using this solution has to be provisioned with valid keys for both the migrated ASN and the subsumed ASN, so it can generate valid signatures for each of the two ASNs it's adding to the path 🔐

If the AS's keys get compromised, or zero-length keys are permitted, this potentially enables an AS_PATH shortening attack. These are existing security risks for BGPsec, though, so they aren't new to this solution 🚨

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgements 🫶

Huge thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, Terry Manderson, Keyur Patel, Alia Atlas, and Alvaro Retana for their review comments 💜

The authors especially want to shout out Kotikalapudi Sriram, Oliver Borchert, and Michael Baer for their review and suggestions on the examples in Section 5.4, which made a real difference to the quality of the text 🙌

And the solution in this document is basically an amalgam of several Secure Inter-Domain Routing (SIDR) interim meeting discussions plus a discussion at IETF 85, all collected and articulated thanks to Sandy Murphy 🧚

Authors' Addresses 🦋

Wesley George Neustar 45980 Center Oak Plaza Sterling, VA 20166 United States of America

Email: wesgeorge@puck.nether.net

Sandy Murphy PARSONS, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 United States of America

Phone: +1 443-430-8000 Email: sandy@tislabs.com

📦 where this page comes from