idnits 2.17.1 draft-ietf-sidr-as-migration-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 7, 2016) is 2697 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-20 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIDR W. George 3 Internet-Draft 4 Intended status: Standards Track S. Murphy 5 Expires: June 10, 2017 SPARTA, Inc., a Parsons Company 6 December 7, 2016 8 BGPSec Considerations for AS Migration 9 draft-ietf-sidr-as-migration-06 11 Abstract 13 This document discusses considerations and methods for supporting and 14 securing a common method for AS-Migration within the BGPSec protocol. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 10, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 52 1.2. Documentation note . . . . . . . . . . . . . . . . . . . 3 53 2. General Scenario . . . . . . . . . . . . . . . . . . . . . . 3 54 3. RPKI Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Origin Validation . . . . . . . . . . . . . . . . . . . . 4 56 3.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 5 57 3.2.1. Outbound announcements (PE-->CE) . . . . . . . . . . 5 58 3.2.2. Inbound announcements (CE-->PE) . . . . . . . . . . . 6 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Outbound (PE->CE) . . . . . . . . . . . . . . . . . . . . 8 62 5.2. Inbound (CE->PE) . . . . . . . . . . . . . . . . . . . . 8 63 5.3. Other considerations . . . . . . . . . . . . . . . . . . 9 64 5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 8. Note for RFC Editor . . . . . . . . . . . . . . . . . . . . . 14 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 10.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 A method of managing a BGP Autonomous System Number (ASN) migration 77 is described in RFC7705 [RFC7705]. Since it concerns the handling of 78 AS_PATH attributes, it is necessary to ensure that the process and 79 features are properly supported in BGPSec 80 [I-D.ietf-sidr-bgpsec-protocol], because BGPSec is explicitly 81 designed to protect against changes in the BGP AS_PATH, whether by 82 choice, by misconfiguration, or by malicious intent. It is critical 83 that the BGPSec protocol framework is able to support this 84 operationally necessary tool without creating an unacceptable 85 security risk or exploit in the process. 87 1.1. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 1.2. Documentation note 95 This document uses Autonomous System Numbers (ASNs) from the range 96 reserved for documentation as described in RFC 5398 [RFC5398]. In 97 the examples used here, they are intended to represent Globally 98 Unique ASNs, not ASNs reserved for private use as documented in RFC 99 1930 [RFC1930] section 10. 101 2. General Scenario 103 This document assumes that the reader has read and understood the ASN 104 migration method discussed in RFC7705 [RFC7705] including its 105 examples (see section 2 of the referenced document), as they will be 106 heavily referenced here. The use case being discussed in the 107 referenced document is as follows: For whatever the reason, a 108 provider is in the process of merging two or more ASes, where 109 eventually one subsumes the other(s). BGP AS Confederations RFC 5065 110 [RFC5065] is not enabled between the ASes, but a mechanism is being 111 used to modify BGP's default behavior and allow the migrating 112 Provider Edge router (PE) to masquerade as the old ASN for the 113 Provider Edge to Customer Edge (PE-CE) eBGP session, or to manipulate 114 the AS_PATH, or both. While BGPSec [I-D.ietf-sidr-bgpsec-protocol] 115 does have a method to handle standard confederation implementations, 116 it is not applicable in this exact case. This migration requires a 117 slightly different solution in BGPSec than for a standard 118 confederation because unlike in a confederation, eBGP peers may not 119 be peering with the "correct" external ASN, and the forward-signed 120 updates are for a public ASN, rather than a private one, so there is 121 no expectation that the BGP speaker would strip the affected 122 signatures before propagating the route to its eBGP neighbors. 124 In the following examples (section 5.4) (Section 5.4), AS64510 is 125 being subsumed by AS64500, and both ASNs represent a Service Provider 126 (SP) network (see Figures 1 & 2 in RFC7705 [RFC7705]). AS64496 and 127 64499 represent end customer networks. References to PE, CE, and P 128 routers mirror the diagrams and references in the above cited draft. 130 3. RPKI Considerations 132 The methods and implementation discussed in RFC7705 [RFC7705] are 133 widely used during network integrations resulting from mergers and 134 acquisitions, as well as network redesigns, and therefore it is 135 necessary to support this capability on any BGPSec-enabled routers/ 136 ASNs. What follows is a discussion of the potential issues to be 137 considered regarding how ASN-migration and BGPSec 138 [I-D.ietf-sidr-bgpsec-protocol] validation might interact. 140 One of the primary considerations for this document and migration is 141 that service providers (SPs) rarely stop after one 142 merger/acquisition/divestiture, and end up accumulating several 143 legacy ASNs over time. Since they are using methods to migrate that 144 are transparent to and therefore do not require coordination with 145 customers, they do not have a great deal of control over the length 146 of the transition period as they might with something completely 147 under their administrative control (e.g. a key roll). Because they 148 are not forcing a simultaneous migration (i.e. both ends switch to 149 the new ASN at an agreed-upon time), there is no incentive for a 150 given customer to complete the move from the old ASN to the new. 151 This leaves many SPs with multiple legacy ASNs which don't go away 152 very quickly, if at all. As solutions were being proposed for RPKI 153 implementations to solve this transition case, the WG carefully 154 considered operational complexity and hardware scaling issues 155 associated with maintaining multiple legacy ASN keys on routers 156 throughout the combined network. While SPs who choose to remain in 157 this transition phase indefinitely invite added risks because of the 158 operational complexity and scaling considerations associated with 159 maintaining multiple legacy ASN keys on routers throughout the 160 combined network, saying "don't do this" is of limited utility as a 161 solution. As a result, this solution attempts to minimize the 162 additional complexity during the transition period, on the assumption 163 that it will likely be protracted. Note: While this document 164 primarily discusses service provider considerations, it is not solely 165 applicable to SPs, as enterprises often migrate between ASNs using 166 the same functionality. What follows is a discussion of origin and 167 path validation functions and how they interact with ASN migrations. 169 3.1. Origin Validation 171 Route Origin Validation as defined by RFC 6480 [RFC6480] does not 172 modification to enable AS migration, as the existing protocol and 173 procedure allows for a solution. In the scenario discussed in RFC 174 7705 [RFC7705], AS64510 is being replaced by AS64500. If there are 175 any existing routes originated by AS64510 on the router being moved 176 into the new ASN, this simply requires generating new Route 177 Origination Authorizations (ROAs) for the routes with the new ASN and 178 treating them as new routes to be added to AS64500. However, we also 179 need to consider the situation where one or more other PEs are still 180 in AS64510, and are originating one or more routes that may be 181 distinct from any that the router under migration is originating. 182 PE1 (which is now a part of AS64500 and instructed to use Replace Old 183 AS as defined in RFC 7705 [RFC7705] to remove AS64510 from the path) 184 needs to be able to properly handle routes originated from AS64510. 185 If the route now shows up as originating from AS64500, any downstream 186 peers' validation check will fail unless a ROA is *also* available 187 for AS64500 as the origin ASN. In addition to generating a ROA for 188 65400 for any prefixes originated by the router being moved, it may 189 be necessary to generate ROAs for 65400 for prefixes that are 190 originating on routers still in 65410, since the AS replacement 191 function will change the origin AS in some cases. This means that 192 there will be multiple ROAs showing different ASes authorized to 193 orignate the same prefixes until all routers originating prefixes 194 from AS64510 are migrated to AS64500. Multiple ROAs of this type are 195 permissible per RFC 6480 [RFC6480] section 3.2, and so managing 196 origin validation during a migration like this is merely applying the 197 defined case where a set of prefixes are originated from more than 198 one ASN. Therefore, for each ROA that authorizes the old ASN (e.g. 199 AS64510) to originate a prefix, a new ROA MUST also be created that 200 authorizes the replacing ASN (e.g. AS64500) to originate the same 201 prefix. 203 3.2. Path Validation 205 BGPSec Path Validation requires that each router in the AS Path 206 cryptographically sign its update to assert that "Every AS on the 207 path of ASes listed in the update message has explicitly authorized 208 the advertisement of the route to the subsequent AS in the path." 209 (see intro of [I-D.ietf-sidr-bgpsec-protocol]) Since the referenced 210 AS migration technique is explicitly modifying the AS_PATH between 211 two eBGP peers who are not coordinating with one another (are not in 212 the same administrative domain), no level of trust can be assumed, 213 and therefore it may be difficult to identify legitimate manipulation 214 of the AS_PATH for migration activities when compared to manipulation 215 due to misconfiguration or malicious intent. 217 3.2.1. Outbound announcements (PE-->CE) 219 When PE1 is moved from AS64510 to AS64500, it will be provisioned 220 with the appropriate keys for AS64500 to allow it to forward-sign 221 routes using AS64500. However, there is no guidance in the BGPSec 222 protocol specification [I-D.ietf-sidr-bgpsec-protocol] on whether or 223 not the forward-signed ASN value is required to match the configured 224 remote AS to validate properly. That is, if CE1's BGP session is 225 configured as "remote AS 64510", the presence of "local AS 64510" on 226 PE1 will ensure that there is no ASN mismatch on the BGP session 227 itself, but if CE1 receives updates from its remote neighbor (PE1) 228 forward-signed from AS64500, there is no guidance as to whether the 229 BGPSec validator on CE1 still considers those valid by default. 230 RFC4271 [RFC4271] section 6.3 mentions this match between the ASN of 231 the peer and the AS_PATH data, but it is listed as an optional 232 validation, rather than a requirement. We cannot assume that this 233 mismatch will be allowed by vendor implementations and thus using it 234 as a means to solve this migration case is likely to be problematic. 236 3.2.2. Inbound announcements (CE-->PE) 238 Inbound is more complicated, because the CE doesn't know that PE1 has 239 changed ASNs, so it is forward-signing all of its routes with 240 AS64510, not AS64500. The BGPSec speaker cannot manipulate previous 241 signatures, and therefore cannot manipulate the previous AS Path 242 without causing a mismatch that will invalidate the route. If the 243 updates are simply left intact, the ISP would still need to publish 244 and maintain valid and active public-keys for AS 64510 if it is to 245 appear in the BGPSec_Path_Signature in order that receivers can 246 validate the BGPSEC_Path_Signature arrived intact/whole. However, if 247 the updates are left intact, this will cause the AS Path length to be 248 increased, which is unacceptable as discussed in RFC7705 [RFC7705]. 250 4. Requirements 252 In order to be deployable, any solution to the described problem 253 needs to consider the following requirements, listed in no particular 254 order. BGPSec: 256 o MUST support AS Migration for both inbound and outbound route 257 announcements (see Section 3.2.1 and 3.2.2) without reducing 258 BGPSec's protections for route path 260 o MUST NOT require any reconfiguration on the remote eBGP neighbor 261 (CE) 263 o SHOULD NOT require global (i.e. network-wide) configuration 264 changes to support migration. The goal is to limit required 265 configuration changes to the devices (PEs) being migrated. 267 o MUST NOT lengthen AS Path during migration 269 o MUST operate within existing trust boundaries e.g. can't expect 270 remote side to accept pCount=0 (see Section 4.2 of 271 [I-D.ietf-sidr-bgpsec-protocol]) from untrusted/non-confed 272 neighbor 274 5. Solution 276 As noted in [I-D.ietf-sidr-bgpsec-protocol], section 4.2, BGPSec 277 already has a solution for hiding ASNs where increasing the AS Path 278 length is undesirable. So a simple solution would be to retain the 279 keys for AS64510 on PE1, and forward-sign towards CE1 with AS64510 280 and pCount=0. However, this would mean passing a pCount=0 between 281 two ASNs that are in different administrative and trust domains such 282 that it could represent a significant attack vector to manipulate 283 BGPSec-signed paths. The expectation for legitimate instances of 284 pCount=0 (to make a route-server that is not part of the transit path 285 invisible) is that there is some sort of existing trust relationship 286 between the operators of the route-server and the downstream peers 287 such that the peers could be explicitly configured by policy to 288 accept pCount=0 announcements only on the sessions where they are 289 expected. For the same reason that things like "Local AS" [RFC7705] 290 are used for ASN migration without end customer coordination, it is 291 unrealistic to assume any sort of coordination between the SP and the 292 administrators of CE1 to ensure that they will by policy accept 293 pCount=0 signatures during the transition period, and therefore this 294 is not a workable solution. 296 A better solution presents itself when considering how to handle 297 routes coming from the CE toward the PE, where the routes are 298 forward-signed to AS64510, but will eventually need to show AS64500 299 in the outbound route announcement. Because both AS64500 and AS64510 300 are in the same administrative domain, a signature from AS64510 301 forward-signed to AS64500 with pCount=0 would be acceptable as it 302 would be within the appropriate trust boundary so that each BGP 303 speaker could be explicitly configured to accept pCount=0 where 304 appropriate between the two ASNs. At the very simplest, this could 305 potentially be used at the eBGP boundary between the two ASNs during 306 migration. Since the AS_PATH manipulation described above usually 307 happens at the PE router on a per-session basis, and does not happen 308 network-wide simultaneously, it is not generally appropriate to apply 309 this AS hiding technique across all routes exchanged between the two 310 ASNs, as it may result in routing loops and other undesirable 311 behavior. Therefore the most appropriate place to implement this is 312 on the local PE that still has eBGP sessions with peers expecting to 313 peer with AS64510 (using the transition mechanisms detailed in 314 RFC7705 [RFC7705]). Since that PE has been moved to AS64500, it is 315 not possible for it to forward-sign AS64510 with pCount=0 without 316 some minor changes to the BGPSec behavior to address this use case. 318 AS migration is using AS_PATH and remote AS manipulation to act as if 319 a PE under migration exists simultaneously in both ASNs even though 320 it is only configured with one global ASN. This document describes 321 applying a similar technique to the BGPSec signatures generated for 322 routing updates processed through this migration machinery. Each 323 routing update that is received from or destined to an eBGP neighbor 324 that is still using the old ASN (64510) will be signed twice, once 325 with the ASN to be hidden and once with the ASN that will remain 326 visible. In essence, we are treating the update as if the PE had an 327 internal BGP hop and the update was passed across an eBGP session 328 between AS64500 and AS64510, configured to use and accept pCount=0, 329 while eliminating the processing and storage overhead of creating an 330 actual eBGP session between the two ASNs within the PE router. This 331 will result in a properly secured AS Path in the affected route 332 updates, because the PE router will be provisioned with valid keys 333 for both AS64500 and AS64510. An important distinction here is that 334 while AS migration under standard BGP4 is manipulating the AS_PATH 335 attribute, BGPSec uses an attribute called the Secure_Path (see 336 Section 3.1 of [I-D.ietf-sidr-bgpsec-protocol]), and BGPSec capable 337 neighbors do not exchange AS_PATH information in their route 338 announcements. However, a BGPSec neighbor peering with a non-BGPSec- 339 capable neighbor will use the information found in Secure_Path to 340 reconstruct a standard AS_PATH for updates sent to that neighbor. 341 Unlike in Secure_Path where the ASN to be hidden is still present, 342 but ignored when considering AS Path (due to pCount=0), when 343 reconstructing an AS_PATH for a non-BGPSec neighbor, the pCount=0 344 ASNs will not appear in the AS_PATH at all (see section 4.4 of the 345 [I-D.ietf-sidr-bgpsec-protocol]). This document is not changing 346 existing AS_PATH reconstruction behavior, merely highlighting it for 347 clarity. 349 The procedure to support AS Migration in BGPSec is slightly different 350 depending on whether the PE under migration is receiving the routes 351 from one of its eBGP peers ("inbound" as in section 3.2.2) or 352 destined toward the eBGP peers ("outbound" as in section 3.2.1). 354 5.1. Outbound (PE->CE) 356 When a PE router receives an update destined for an eBGP neighbor 357 that is locally configured with AS-migration mechanisms as discussed 358 in RFC7705 [RFC7705], it MUST generate a valid BGPSec signature as 359 defined in [I-D.ietf-sidr-bgpsec-protocol] for _both_ configured 360 ASNs. It MUST generate a signature from the new (global) ASN forward 361 signing to the old (local) ASN with pCount=0, and then it MUST 362 generate a forward signature from the old (local) ASN to the target 363 eBGP ASN with pCount=1 as normal. 365 5.2. Inbound (CE->PE) 367 When a PE router receives an update from an eBGP neighbor that is 368 locally configured with AS-migration mechanisms (i.e. the opposite 369 direction of the previous route flow), it MUST generate a signature 370 from the old (local) ASN forward signing to the new (global) ASN with 371 pCount=0. It is not necessary to generate the second signature from 372 the new (global) ASN because the Autonomous System Border Router 373 (ASBR) will generate that when it forward signs towards its eBGP 374 peers as defined in normal BGPSec operation. Note that a signature 375 is not normally added when a routing update is sent across an iBGP 376 session. The requirement to sign updates in iBGP represents a change 377 to the normal behavior for this specific AS-migration scenario only. 379 5.3. Other considerations 381 In this case, the PE is adding BGPSec attributes to routes received 382 from or destined to an iBGP neighbor, and using pCount=0 to mask 383 them. While this is not prohibited by BGPSec 384 [I-D.ietf-sidr-bgpsec-protocol], BGPSec-capable routers that receive 385 updates from BGPSec-enabled iBGP neighbors MUST accept updates with 386 new (properly-formed) BGPSec attributes, including the presence of 387 pCount=0 on a previous signature, or they will interfere with this 388 method. In similar fashion, any BGPSec-capable route-reflectors in 389 the path of these updates MUST reflect them transparently to their 390 BGPSec-capable clients. 392 In order to secure this set of signatures, the PE router MUST be 393 provisioned with valid keys for _both_ configured ASNs (old and new), 394 and the key for the old ASN MUST be kept valid until all eBGP 395 sessions are migrated to the new ASN. Downstream neighbors will see 396 this as a valid BGPSec path, as they will simply trust that their 397 upstream neighbor accepted pCount=0 because it was explicitly 398 configured to do so based on a trust relationship and business 399 relationship between the upstream and its neighbor (the old and new 400 ASNs). 402 Additionally, section 4 of RFC7705 [RFC7705] discusses methods in 403 which AS migrations can be completed for iBGP peers such that a 404 session between two routers will be treated as iBGP even if the 405 neighbor ASN is not the same ASN on each peer's global configuration. 406 As far as BGPSec is concerned, this requires the same procedure as 407 when the routers migrating are applying AS migration mechanisms to 408 eBGP peers, but the router functioning as the "ASBR" between old and 409 new ASN is different. In eBGP, the router being migrated has direct 410 eBGP sessions to the old ASN and signs from old ASN to new with 411 pCount=0 before passing the update along to additional routers in its 412 global (new) ASN. In iBGP, the router being migrated is receiving 413 updates (that may have originated either from eBGP neighbors or other 414 iBGP neighbors) from its downstream neighbors in the old ASN, and 415 MUST sign those updates from old ASN to new with pCount=0 before 416 sending them on to other peers. 418 5.4. Example 420 The following example will illustrate the method being used above. 421 As with previous examples, PE1 is the router being migrated, AS64510 422 is the old ASN, which is being subsumed by AS64500, the ASN to be 423 permanently retained. 64505 is another external peer, used to 424 demonstrate what the announcements will look like to a third party 425 peer that is not part of the migration. Some additional notation is 426 used to delineate the details of each signature as follows: 428 The origin BGPSEC signature attribute takes the form: sig(, Origin ASN, pCount, NLRI Prefix) key 431 Intermediate BGPSEC signature attributes take the form: sig(, Signer ASN, pCount, ) key 434 Equivalent AS_PATH refers to what the AS_PATH would look like if it 435 was reconstructed to be sent to a non-BGPSec peer, while Secure_Path 436 shows the AS Path as represented between BGPSec peers. 438 Note: The representation of signature attribute generation is being 439 simplified here somewhat for the sake of brevity; the actual details 440 of the signing process are as described Sections 4.1 and 4.2 in 441 [I-D.ietf-sidr-bgpsec-protocol]. For example, what is covered by the 442 signature also includes Flags, Algorithm Suite ID, NLRI length, etc. 443 Also, the key is not carried in the update, instead the SKI is 444 carried. 446 Before Merger 448 64505 449 | 450 ISP B ISP A 451 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 452 64496 Old_ASN: 64510 Old_ASN: 64500 64499 454 CE-2 to PE-2: sig(<64500>, O=64499, pCount=1, N)K_64499-CE2 [sig1] 455 Equivalent AS_PATH=(64499) 456 Secure_Path=(64499) 457 length=sum(pCount)=1 459 PE-2 to 64505: sig(<64505>, 64500, pCount=1, )K_64500-PE2 [sig2] 460 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] 461 Equivalent AS_PATH=(64500,64499) 462 Secure_Path=(64500,64499) 463 length=sum(pCount)=2 465 PE-2 to PE-1: sig(<64510>, 64500, pCount=1, )K_64500-PE2 [sig3] 466 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] 467 Equivalent AS_PATH=(64500,64499) 468 Secure_Path=(64500,64499) 469 length=sum(pCount)=2 471 PE-1 to CE-1: sig(<64496>, 64510, pCount=1, )K_64510-PE1 [sig4] 472 sig(<64510>, 64500, pCount=1, )K_64500-PE2 [sig3] 473 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] 474 Equivalent AS_PATH= (64510,64500,64499) 475 Secure_Path=(64510,64500,64499) 476 length=sum(pCount)=3 478 Migrating, route flow outbound PE-1 to CE-1 480 64505 481 | 482 ISP A' ISP A' 483 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 484 64496 Old_ASN: 64510 Old_ASN: 64500 64499 485 New_ASN: 64500 New_ASN: 64500 487 CE-2 to PE-2: sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 488 Equivalent AS_PATH=(64499) 489 Secure_Path=(64499) 490 length=sum(pCount)=1 492 PE-2 to 64505: sig(<64505>, 64500, pCount=1, )K_64500-PE2 [sig12] 493 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 494 Equivalent AS_PATH=(64500,64499) 495 Secure_Path=(64500,64499) 496 length=sum(pCount)=2 498 PE-2 to PE-1: sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 499 Equivalent AS_PATH=(64499) 500 Secure_Path=(64499) 501 length=sum(pCount)=1 502 #PE-2 sends to PE-1 (in iBGP) the exact same update 503 #as received from AS64499. 505 PE-1 to CE-1: sig(<64496>, 64510, pCount=1, )K_64510-PE1 [sig14] 506 sig(<64510>, 64500, pCount=0, )K_64500-PE2 [sig13] 507 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 508 Equivalent AS_PATH=(64510,64499) 509 Secure_Path=(64510, 64500(pCount=0),64499) 510 length=sum(pCount)=2 (length is NOT 3) 511 #PE1 adds [sig13] acting as AS64500 512 #PE1 accepts [sig13] with pCount=0 acting as AS64510, 513 #as it would if it received sig13 from an eBGP peer 514 Migrating, route flow inbound CE-1 to PE-1 516 64505 517 | 518 ISP A' ISP A' 519 CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2 520 64496 Old_ASN: 64510 Old_ASN: 64500 64499 521 New_ASN: 64500 New_ASN: 64500 523 CE-1 to PE-1: sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 524 Equivalent AS_PATH=(64496) 525 Secure_Path=(64496) 526 length=sum(pCount)=1 528 PE-1 to PE-2: sig(<64500>, 64510, pCount=0, )K_64510-PE1 [sig22] 529 sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 530 Equivalent AS_PATH=(64496) 531 Secure_Path=(64510 (pCount=0),64496) 532 length=sum(pCount)=1 (length is NOT 2) 533 #PE1 adds [sig22] acting as AS64510 534 #PE1 accepts [sig22] with pCount=0 acting as AS64500, 535 #as it would if it received sig22 from an eBGP peer 537 PE-2 to 64505: sig(<64505>, 64500, pCount=1, )K_64500-PE2 [sig23] 538 sig(<64500>, 64510, pCount=0, )K_64510-PE1 [sig22] 539 sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 540 Equivalent AS_PATH=(64500,64496) 541 Secure_Path=(64500,64510 (pCount=0), 64496) 542 length=sum(pCount)=2 (length is NOT 3) 544 PE-2 to CE-2: sig(<64499>, 64500, pCount=1, )K_64500-PE2 [sig24] 545 sig(<64500>, 64510, pCount=0, )K_64510-PE1 [sig22] 546 sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 547 Equivalent AS_PATH=(64500,64496) 548 Secure_Path=(64500, 64510 (pCount=0), 64496) 549 length=sum(pCount)=2 (length is NOT 3) 551 6. Acknowledgements 553 Thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, Terry 554 Manderson, Keyur Patel, Alia Atlas, and Alvaro Retana for their 555 review comments. 557 Additionally, the solution presented in this document is an amalgam 558 of several SIDR interim meeting discussions plus a discussion at 559 IETF85, collected and articulated thanks to Sandy Murphy. 561 7. IANA Considerations 563 This memo includes no request to IANA. 565 8. Note for RFC Editor 567 This section can be removed prior to publication. 569 RFC Editor - this document updates draft-ietf-sidr-bgpsec-protocol, 570 but the normal Updates= metadata method cannot be used until an RFC 571 number is assigned to the document being updated. Please ensure that 572 the metadata is corrected when the bgpsec-protocol document has been 573 assigned an RFC number. 575 9. Security Considerations 577 RFC7705 [RFC7705] discusses a process by which one ASN is migrated 578 into and subsumed by another. Because this process involves 579 manipulating the AS_Path in a BGP route to make it deviate from the 580 actual path that it took through the network, this migration process 581 is attempting to do exactly what BGPSec is working to prevent. 582 BGPSec MUST be able to manage this legitimate use of AS_Path 583 manipulation without generating a vulnerability in the RPKI route 584 security infrastructure, and this document was written to define the 585 method by which the protocol can meet this need. 587 The solution discussed above is considered to be reasonably secure 588 from exploitation by a malicious actor because it requires both 589 signatures to be secured as if they were forward-signed between two 590 eBGP neighbors. This requires any router using this solution to be 591 provisioned with valid keys for both the migrated and subsumed ASN so 592 that it can generate valid signatures for each of the two ASNs it is 593 adding to the path. If the AS's keys are compromised, or zero-length 594 keys are permitted, this does potentially enable an AS_PATH 595 shortening attack, but these are existing security risks for BGPSec. 597 10. References 599 10.1. Normative References 601 [I-D.ietf-sidr-bgpsec-protocol] 602 Lepinski, M. and K. Sriram, "BGPsec Protocol 603 Specification", draft-ietf-sidr-bgpsec-protocol-20 (work 604 in progress), December 2016. 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, 609 . 611 [RFC7705] George, W. and S. Amante, "Autonomous System Migration 612 Mechanisms and Their Effects on the BGP AS_PATH 613 Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015, 614 . 616 10.2. Informative References 618 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 619 selection, and registration of an Autonomous System (AS)", 620 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 621 . 623 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 624 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 625 DOI 10.17487/RFC4271, January 2006, 626 . 628 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 629 System Confederations for BGP", RFC 5065, 630 DOI 10.17487/RFC5065, August 2007, 631 . 633 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 634 Documentation Use", RFC 5398, DOI 10.17487/RFC5398, 635 December 2008, . 637 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 638 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 639 February 2012, . 641 Authors' Addresses 643 Wesley George 645 Email: wesgeorge@puck.nether.net 646 Sandy Murphy 647 SPARTA, Inc., a Parsons Company 648 7110 Samuel Morse Drive 649 Columbia, MD 21046 650 US 652 Phone: +1 443-430-8000 653 Email: sandy@tislabs.com