idnits 2.17.1 draft-ietf-sidr-as-migration-04.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 (October 16, 2015) is 3115 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-13 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 Time Warner Cable 4 Intended status: Standards Track S. Murphy 5 Expires: April 18, 2016 SPARTA, Inc., a Parsons Company 6 October 16, 2015 8 BGPSec Considerations for AS Migration 9 draft-ietf-sidr-as-migration-04 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 April 18, 2016. 33 Copyright Notice 35 Copyright (c) 2015 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. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 70 9.2. Informative References . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 A method of managing a BGP Autonomous System Number (ASN) migration 76 was just recently described in draft-ietf-idr-as-migration 77 [I-D.ietf-idr-as-migration]. 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 private ASNs as documented in RFC 1930 [RFC1930] 99 section 10. 101 2. General Scenario 103 This document assumes that the reader has read and understood the ASN 104 migration method discussed in draft-ietf-idr-as-migration 105 [I-D.ietf-idr-as-migration] including its examples (see section 2 of 106 the referenced document), as they will be heavily referenced here. 107 The use case being discussed in the referenced document is as 108 follows: For whatever the reason, a provider is in the process of 109 merging two or more ASNs, where eventually one subsumes the other(s). 110 BGP AS Confederations RFC 5065 [RFC5065] is not enabled between the 111 ASNs, but configuration knobs are being used to modify BGP's default 112 behavior and allow the migrating Provider Edge router (PE) to 113 masquerade as the old ASN for the Provider Edge to Customer Edge (PE- 114 CE) eBGP session, or to manipulate the AS_PATH, or both. While 115 BGPSec [I-D.ietf-sidr-bgpsec-protocol] does have a method to handle 116 standard confederation implementations, it is not applicable in this 117 exact case. The reason that this migration requires a slightly 118 different solution in BGPSec than for a standard confederation is 119 that unlike in a confederation, eBGP peers may not be peering with 120 the "correct" external ASN, and the forward-signed updates are for a 121 public ASN, rather than a private one, so there is no expectation 122 that the BGP speaker would strip the affected signatures before 123 propagating the route to its eBGP neighbors. 125 In the following examples (section 5.4) (Section 5.4), AS64510 is 126 being subsumed by AS64500, and both ASNs represent a Service Provider 127 (SP) network (see Figures 1 & 2 in draft-ietf-idr-as-migration 128 [I-D.ietf-idr-as-migration]). AS64496 and 64499 represent end 129 customer networks. References to PE, CE, and P routers mirror the 130 diagrams and references in the above cited draft. 132 3. RPKI Considerations 134 The methods and implementation discussed in draft-ietf-idr-as- 135 migration [I-D.ietf-idr-as-migration] are widely used during network 136 integrations resulting from mergers and acquisitions, as well as 137 network redesigns, and therefore it is necessary to support this 138 capability on any BGPSec-enabled routers/ASNs. What follows is a 139 discussion of the potential issues to be considered regarding how 140 ASN-migration and BGPSec [I-D.ietf-sidr-bgpsec-protocol] validation 141 might interact. 143 One of the primary considerations for this document and migration is 144 that service providers (SPs) rarely stop after one 145 merger/acquisition/divestiture, and end up accumulating several 146 legacy ASNs over time. Since they are using methods to migrate that 147 do not require coordination with customers, they do not have a great 148 deal of control over the length of the transition period as they 149 might with something completely under their administrative control 150 (e.g. a key roll). This leaves many SPs with multiple legacy ASNs 151 which don't go away very quickly, if at all. As solutions were being 152 proposed for RPKI implementations to solve this transition case, 153 operational complexity and hardware scaling considerations associated 154 with maintaining multiple legacy ASN keys on routers throughout the 155 combined network have been carefully considered. While SPs SHOULD 156 NOT remain in this transition phase indefinitely because of the 157 operational complexity and scaling considerations associated with 158 maintaining multiple legacy ASN keys on routers throughout the 159 combined network, this is of limited utility as a solution, and so 160 every effort has been made to keep the additional complexity during 161 the transition period to a minimum, on the assumption that it will 162 likely be protracted. Note: While this document primarily discusses 163 service provider considerations, it is not solely applicable to SPs, 164 as enterprises often migrate between ASNs using the same 165 functionality. 167 3.1. Origin Validation 169 Route Origin Validation as defined by RFC 6480 [RFC6480] does not 170 need a unique solution to enable migration, as the existing protocol 171 and procedure allows for a solution. In the scenario discussed, 172 AS64510 is being replaced by AS64500. If there are any existing 173 routes originated by AS64510 on the router being moved into the new 174 ASN, this simply requires generating new ROAs for the routes with the 175 new ASN and treating them as new routes to be added to AS64500. 176 However, we also need to consider the situation where one or more 177 other PEs are still in AS64510, and are originating one or more 178 routes that may be distinct from any that the router under migration 179 is originating. PE1 (which is now a part of AS64500 and instructed 180 to use replace-as as defined in RFC 6480 [RFC6480] to remove AS64510 181 from the path) needs to be able to properly handle routes originated 182 from AS64510. If the route now shows up as originating from AS64500, 183 any downstream peers' validation check will fail unless a ROA is 184 *also* available for AS64500 as the origin ASN. In addition to 185 generating a ROA for 65400 for any prefixes originated by the router 186 being moved, it may be necessary to generate ROAs for 65400 for 187 prefixes that are originating on routers still in 65410, since the AS 188 replacement function will change the origin AS in some cases. This 189 means that there will be multiple ROAs showing different ASes 190 authorized to orignate the same prefixes until all routers 191 originating prefixes from AS64510 are migrated to AS64500. Multiple 192 ROAs of this type are permissible per RFC 6480 [RFC6480] section 3.2, 193 and so managing origin validation during a migration like this is 194 merely applying the defined case where a set of prefixes are 195 originated from more than one ASN. Therefore, for each ROA that 196 authorizes AS64510 to originate a prefix, a new ROA MUST also be 197 created that authorizes AS64500 to originate the same prefix. 199 3.2. Path Validation 201 BGPSec Path Validation requires that each router in the AS Path 202 cryptographically sign its update to assert that "Every AS on the 203 path of ASes listed in the update message has explicitly authorized 204 the advertisement of the route to the subsequent AS in the path." 205 (see intro of [I-D.ietf-sidr-bgpsec-protocol]) Since the referenced 206 AS migration technique is explicitly modifying the AS_PATH between 207 two eBGP peers who are not coordinating with one another (are not in 208 the same administrative domain), no level of trust can be assumed, 209 and therefore it may be difficult to identify legitimate manipulation 210 of the AS_PATH for migration activities when compared to manipulation 211 due to misconfiguration or malicious intent. 213 3.2.1. Outbound announcements (PE-->CE) 215 When PE1 is moved from AS64510 to AS64500, it will be provisioned 216 with the appropriate keys for AS64500 to allow it to forward-sign 217 routes using AS64500. However, there is currently no guidance in the 218 BGPSec protocol specification [I-D.ietf-sidr-bgpsec-protocol] on 219 whether or not the forward-signed ASN value MUST match the configured 220 remote AS to validate properly. That is, if CE1's BGP session is 221 configured as "remote-as 64510", the presence of "local-as 64510" on 222 PE1 will ensure that there is no ASN mismatch on the BGP session 223 itself, but if CE1 receives updates from its remote neighbor (PE1) 224 forward-signed from AS64500, there is no guidance as to whether the 225 BGPSec validator on CE1 still considers those valid by default. 226 RFC4271 [RFC4271] section 6.3 mentions this match between the ASN of 227 the peer and the AS_PATH data, but it is listed as an optional 228 validation, rather than a requirement. Assuming that this mismatch 229 will be allowed by vendor implementations and using it as a means to 230 solve this migration case is likely to be problematic. 232 3.2.2. Inbound announcements (CE-->PE) 234 Inbound is more complicated, because the CE doesn't know that PE1 has 235 changed ASNs, so it is forward-signing all of its routes with 236 AS64510, not AS64500. The BGPSec speaker cannot manipulate previous 237 signatures, and therefore cannot manipulate the previous AS Path 238 without causing a mismatch that will invalidate the route. If the 239 updates are simply left intact, the ISP would still need to publish 240 and maintain valid and active public-keys for AS 64510 if it is to 241 appear in the BGPSec_Path_Signature in order that receivers can 242 validate the BGPSEC_Path_Signature arrived intact/whole. However, if 243 the updates are left intact, this will cause the AS Path length to be 244 increased, which is undesirable as discussed in draft-ietf-idr-as- 245 migration [I-D.ietf-idr-as-migration]. 247 4. Requirements 249 In order to be deployable, any solution to the described problem 250 needs to consider the following requirements, listed in no particular 251 order: 253 o BGPSec MUST support AS Migration for both inbound and outbound 254 route announcements (see Section 3.2.1 and 3.2.2). It SHOULD do 255 this without reducing BGPSec's protections for route path 257 o MUST NOT require any reconfiguration on the remote eBGP neighbor 258 (CE) 260 o SHOULD confine configuration changes to the migrating PEs e.g. 261 can't require global configuration changes to support migration 263 o MUST NOT lengthen AS Path during migration 265 o MUST operate within existing trust boundaries e.g. can't expect 266 remote side to accept pCount=0 (see Section 3 of 267 [I-D.ietf-sidr-bgpsec-protocol]) from untrusted/non-confed 268 neighbor 270 5. Solution 272 As noted in [I-D.ietf-sidr-bgpsec-protocol], section 4.2, BGPSec 273 already has a solution for hiding ASNs where increasing the AS Path 274 length is undesirable. So a simple solution would be to retain the 275 keys for AS64510 on PE1, and forward-sign towards CE1 with AS64510 276 and pCount=0. However, this would mean passing a pCount=0 between 277 two ASNs that are in different administrative and trust domains such 278 that it could represent a significant attack vector to manipulate 279 BGPSec-signed paths. The expectation for legitimate instances of 280 pCount=0 (to make a route-server that is not part of the transit path 281 invisible) is that there is some sort of existing trust relationship 282 between the operators of the route-server and the downstream peers 283 such that the peers could be explicitly configured by policy to 284 accept pCount=0 announcements only on the sessions where they are 285 expected. For the same reason that things like "Local AS" 286 [I-D.ietf-idr-as-migration] are used for ASN migration without end 287 customer coordination, it is unrealistic to assume any sort of 288 coordination between the SP and the administrators of CE1 to ensure 289 that they will by policy accept pCount=0 signatures during the 290 transition period, and therefore this is not a workable solution. 292 A better solution presents itself when considering how to handle 293 routes coming from the CE toward the PE, where the routes are 294 forward-signed to AS64510, but will eventually need to show AS64500 295 in the outbound route announcement. Because both AS64500 and AS64510 296 are in the same administrative domain, a signature from AS64510 297 forward-signed to AS64500 with pCount=0 would be acceptable as it 298 would be within the appropriate trust boundary so that each BGP 299 speaker could be explicitly configured to accept pCount=0 where 300 appropriate between the two ASNs. At the very simplest, this could 301 potentially be used at the eBGP boundary between the two ASNs during 302 migration. Since the AS_PATH manipulation described above usually 303 happens at the PE router on a per-session basis, and does not happen 304 network-wide simultaneously, it is not generally appropriate to apply 305 this AS hiding technique across all routes exchanged between the two 306 ASNs, as it may result in routing loops and other undesirable 307 behavior. Therefore the most appropriate place to implement this is 308 on the local PE that still has eBGP sessions with peers expecting to 309 peer with AS64510 (using the transition knobs detailed in draft-ietf- 310 idr-as-migration [I-D.ietf-idr-as-migration]). Since that PE has 311 been moved to AS64500, it is not possible for it to forward-sign 312 AS64510 with pCount=0 without some minor changes to the BGPSec 313 implementation to address this use case. 315 AS migration is using AS_PATH and remote AS manipulation to act as if 316 a PE under migration exists simultaneously in both ASNs even though 317 it is only configured with one global ASN. This document proposes 318 applying a similar technique to the BGPSec signatures generated for 319 routing updates processed through this migration machinery. Each 320 routing update that is received from or destined to an eBGP neighbor 321 that is still using the old ASN (64510) will be signed twice, once 322 with the ASN to be hidden and once with the ASN that will remain 323 visible. In essence, we are treating the update as if the PE had an 324 internal BGP hop and the update was passed across an eBGP session 325 between AS64500 and AS64510, configured to use and accept pCount=0, 326 while eliminating the processing and storage overhead of creating an 327 actual eBGP session between the two ASNs within the PE router. This 328 will result in a properly secured AS Path in the affected route 329 updates, because the PE router will be provisioned with valid keys 330 for both AS64500 and AS64510. An important distinction here is that 331 while AS migration under standard BGP4 is manipulating the AS_PATH 332 attribute, BGPSec uses an attribute called the Secure_Path (see 333 Section 3 of [I-D.ietf-sidr-bgpsec-protocol]), and BGPSec capable 334 neighbors do not exchange AS_PATH information in their route 335 announcements. However, a BGPSec neighbor peering with a non-BGPSec- 336 capable neighbor will use the information found in Secure_Path to 337 reconstruct a standard AS_PATH for updates sent to that neighbor. 338 Unlike in Secure_Path where the ASN to be hidden is still present, 339 but ignored when considering AS Path (due to pCount=0), when 340 reconstructing an AS_PATH for a non-BGPSec neighbor, the pCount=0 341 ASNs will not appear in the AS_PATH at all (see section 4.4 of the 342 above-referenced draft). This document is not changing existing 343 AS_PATH reconstruction behavior, merely highlighting it for clarity. 345 The procedure to support AS Migration in BGPSec is slightly different 346 depending on whether the PE under migration is receiving the routes 347 from one of its eBGP peers ("inbound" as in section 3.2.2) or 348 destined toward the eBGP peers ("outbound" as in section 3.2.1). 350 5.1. Outbound (PE->CE) 352 When a PE router receives an update destined for an eBGP neighbor 353 that is locally configured with AS-migration knobs as discussed in 354 draft-ietf-idr-as-migration [I-D.ietf-idr-as-migration], it MUST 355 generate a valid BGPSec signature as defined in 356 [I-D.ietf-sidr-bgpsec-protocol] for _both_ configured ASNs. It MUST 357 generate a signature from the new (global) ASN forward signing to the 358 old (local) ASN with pCount=0, and then it MUST generate a forward 359 signature from the old (local) ASN to the target eBGP ASN with 360 pCount=1 as normal. 362 5.2. Inbound (CE->PE) 364 When a PE router receives an update from an eBGP neighbor that is 365 locally configured with AS-migration knobs (i.e. the opposite 366 direction of the previous route flow), it MUST generate a signature 367 from the old (local) ASN forward signing to the new (global) ASN with 368 pCount=0. It is not necessary to generate the second signature from 369 the new (global) ASN because the Autonomous System Border Router 370 (ASBR) will generate that when it forward signs towards its eBGP 371 peers as defined in normal BGPSec operation. Note that a signature 372 is not normally added when a routing update is sent across an iBGP 373 session. The requirement to sign updates in iBGP represents a change 374 to the normal behavior for this specific AS-migration implementation 375 only. 377 5.3. Other considerations 379 In this case, the PE is adding BGPSec attributes to routes received 380 from or destined to an iBGP neighbor, and using pCount=0 to mask 381 them. While this is not prohibited by BGPSec 382 [I-D.ietf-sidr-bgpsec-protocol], routers that receive updates from 383 iBGP neighbors MUST accept updates with new (properly-formed) BGPSec 384 attributes, including the presence of pCount=0 on a previous 385 signature, or they will interfere with this implementation. In 386 similar fashion, any route-reflectors in the path of these updates 387 MUST reflect them transparently to their clients. 389 In order to secure this set of signatures, the PE router MUST be 390 provisioned with valid keys for _both_ configured ASNs (old and new), 391 and the key for the old ASN MUST be kept valid until all eBGP 392 sessions are migrated to the new ASN. Downstream neighbors will see 393 this as a valid BGPSec path, as they will simply trust that their 394 upstream neighbor accepted pCount=0 because it was explicitly 395 configured to do so based on a trust relationship and business 396 relationship between the upstream and its neighbor (the old and new 397 ASNs). 399 Additionally, section 4 of draft-ietf-idr-as-migration 400 [I-D.ietf-idr-as-migration] discusses methods in which AS migrations 401 can be completed for iBGP peers such that a session between two 402 routers will be treated as iBGP even if the neighbor ASN is not the 403 same ASN on each peer's global configuration. As far as BGPSec is 404 concerned, this requires the same procedure as when the routers 405 migrating are applying AS migration knobs to eBGP peers, but the 406 router functioning as the "ASBR" between old and new ASN is 407 different. In eBGP, the router being migrated has direct eBGP 408 sessions to the old ASN and signs from old ASN to new with pCount=0 409 before passing the update along to additional routers in its global 410 (new) ASN. In iBGP, the router being migrated is receiving updates 411 (that may have originated either from eBGP neighbors or other iBGP 412 neighbors) from its downstream neighbors in the old ASN, and MUST 413 sign those updates from old ASN to new with pCount=0 before sending 414 them on to other peers. 416 5.4. Example 418 The following example will illustrate the method being used above. 419 As with previous examples, PE1 is the router being migrated, AS64510 420 is the old AS, which is being subsumed by AS64500, the "keep" AS. 421 64505 is another external peer, used to demonstrate what the 422 announcements will look like to a third party peer that is not part 423 of the migration. Some additional notation is used to delineate the 424 details of each signature as follows: 426 The origin BGPSEC signature attribute takes the form: sig(, Origin ASN, pCount, NLRI Prefix) key 429 Intermediate BGPSEC signature attributes take the form: sig(, Signer ASN, pCount, ) key 432 Equivalent AS_PATH refers to what the AS_PATH would look like if it 433 was reconstructed to be sent to a non-BGPSec peer, while Secure_Path 434 shows the AS Path as represented between BGPSec peers. 436 Note: The representation of signature attribute generation is being 437 simplified here somewhat for the sake of brevity; the actual details 438 of the signing process are as described Sections 4.1 and 4.2 in 439 [I-D.ietf-sidr-bgpsec-protocol]. For example, what is covered by the 440 signature also includes Flags, Algorithm Suite ID, NLRI length, etc. 441 Also, the key is not carried in the update, instead the SKI is 442 carried. 444 Before Merger 446 64505 447 | 448 ISP B ISP A 449 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 450 64496 Old_ASN: 64510 Old_ASN: 64500 64499 452 CE-2 to PE-2: sig(<64500>, O=64499, pCount=1, N)K_64499-CE2 [sig1] 453 Equivalent AS_PATH=(64499) 454 Secure_Path=(64499) 455 length=sum(pCount)=1 457 PE-2 to 64505: sig(<64505>, 64500, pCount=1, )K_64500-PE2 [sig2] 458 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] 459 Equivalent AS_PATH=(64500,64499) 460 Secure_Path=(64500,64499) 461 length=sum(pCount)=2 463 PE-2 to PE-1: sig(<64510>, 64500, pCount=1, )K_64500-PE2 [sig3] 464 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] 465 Equivalent AS_PATH=(64500,64499) 466 Secure_Path=(64500,64499) 467 length=sum(pCount)=2 469 PE-1 to CE-1: sig(<64496>, 64510, pCount=1, )K_64510-PE1 [sig4] 470 sig(<64510>, 64500, pCount=1, )K_64500-PE2 [sig3] 471 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] 472 Equivalent AS_PATH= (64510,64500,64499) 473 Secure_Path=(64510,64500,64499) 474 length=sum(pCount)=3 476 Migrating, route flow outbound PE-1 to CE-1 478 64505 479 | 480 ISP A' ISP A' 481 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 482 64496 Old_ASN: 64510 Old_ASN: 64500 64499 483 New_ASN: 64500 New_ASN: 64500 485 CE-2 to PE-2: sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 486 Equivalent AS_PATH=(64499) 487 Secure_Path=(64499) 488 length=sum(pCount)=1 490 PE-2 to 64505: sig(<64505>, 64500, pCount=1, )K_64500-PE2 [sig12] 491 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 492 Equivalent AS_PATH=(64500,64499) 493 Secure_Path=(64500,64499) 494 length=sum(pCount)=2 496 PE-2 to PE-1: sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 497 Equivalent AS_PATH=(64499) 498 Secure_Path=(64499) 499 length=sum(pCount)=1 500 #PE-2 sends to PE-1 (in iBGP) the exact same update 501 #as received from AS64499. 503 PE-1 to CE-1: sig(<64496>, 64510, pCount=1, )K_64510-PE1 [sig14] 504 sig(<64510>, 64500, pCount=0, )K_64500-PE2 [sig13] 505 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 506 Equivalent AS_PATH=(64510,64499) 507 Secure_Path=(64510, 64500(pCount=0),64499) 508 length=sum(pCount)=2 (length is NOT 3) 509 #PE1 adds [sig13] acting as AS64500 510 #PE1 accepts [sig13] with pCount=0 acting as AS64510, 511 #as it would if it received sig13 from an eBGP peer 512 Migrating, route flow inbound CE-1 to PE-1 514 64505 515 | 516 ISP A' ISP A' 517 CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2 518 64496 Old_ASN: 64510 Old_ASN: 64500 64499 519 New_ASN: 64500 New_ASN: 64500 521 CE-1 to PE-1: sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 522 Equivalent AS_PATH=(64496) 523 Secure_Path=(64496) 524 length=sum(pCount)=1 526 PE-1 to PE-2: sig(<64500>, 64510, pCount=0, )K_64510-PE1 [sig22] 527 sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 528 Equivalent AS_PATH=(64496) 529 Secure_Path=(64510 (pCount=0),64496) 530 length=sum(pCount)=1 (length is NOT 2) 531 #PE1 adds [sig22] acting as AS64510 532 #PE1 accepts [sig22] with pCount=0 acting as AS64500, 533 #as it would if it received sig22 from an eBGP peer 535 PE-2 to 64505: sig(<64505>, 64500, pCount=1, )K_64500-PE2 [sig23] 536 sig(<64500>, 64510, pCount=0, )K_64510-PE1 [sig22] 537 sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 538 Equivalent AS_PATH=(64500,64496) 539 Secure_Path=(64500,64510 (pCount=0), 64496) 540 length=sum(pCount)=2 (length is NOT 3) 542 PE-2 to CE-2: sig(<64499>, 64500, pCount=1, )K_64500-PE2 [sig24] 543 sig(<64500>, 64510, pCount=0, )K_64510-PE1 [sig22] 544 sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 545 Equivalent AS_PATH=(64500,64496) 546 Secure_Path=(64500, 64510 (pCount=0), 64496) 547 length=sum(pCount)=2 (length is NOT 3) 549 6. Acknowledgements 551 Thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, Terry 552 Manderson, Keyur Patel, Alia Atlas, and Alvaro Retana for their 553 review comments. 555 Additionally, the solution presented in this document is an amalgam 556 of several SIDR interim meeting discussions plus a discussion at 557 IETF85, collected and articulated thanks to Sandy Murphy. 559 7. IANA Considerations 561 This memo includes no request to IANA. 563 8. Security Considerations 565 This document discusses a process by which one ASN is migrated into 566 and subsumed by another. Because this process involves manipulating 567 the AS_Path in a BGP route to make it deviate from the actual path 568 that it took through the network, this migration process is 569 attempting to do exactly what BGPSec is working to prevent. BGPSec 570 MUST be able to manage this legitimate use of AS_Path manipulation 571 without generating a vulnerability in the RPKI route security 572 infrastructure. 574 The solution discussed above is considered to be reasonably secure 575 from exploitation by a malicious actor because it requires both 576 signatures to be secured as if they were forward-signed between two 577 eBGP neighbors. This requires any router using this solution to be 578 provisioned with valid keys for both the migrated and subsumed ASN so 579 that it can generate valid signatures for each of the two ASNs it is 580 adding to the path. If the AS's keys are compromised, or zero-length 581 keys are permitted, this does potentially enable an AS_PATH 582 shortening attack, but this is not fundamentally altering the 583 existing security risks for BGPSec. 585 9. References 587 9.1. Normative References 589 [I-D.ietf-idr-as-migration] 590 George, W. and S. Amante, "Autonomous System Migration 591 Mechanisms and Their Effects on the BGP AS_PATH 592 Attribute", draft-ietf-idr-as-migration-06 (work in 593 progress), July 2015. 595 [I-D.ietf-sidr-bgpsec-protocol] 596 Lepinski, M., "BGPsec Protocol Specification", draft-ietf- 597 sidr-bgpsec-protocol-13 (work in progress), July 2015. 599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 600 Requirement Levels", BCP 14, RFC 2119, 601 DOI 10.17487/RFC2119, March 1997, 602 . 604 9.2. Informative References 606 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 607 selection, and registration of an Autonomous System (AS)", 608 BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, 609 . 611 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 612 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 613 DOI 10.17487/RFC4271, January 2006, 614 . 616 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 617 System Confederations for BGP", RFC 5065, 618 DOI 10.17487/RFC5065, August 2007, 619 . 621 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 622 Documentation Use", RFC 5398, DOI 10.17487/RFC5398, 623 December 2008, . 625 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 626 Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, 627 February 2012, . 629 Authors' Addresses 631 Wesley George 632 Time Warner Cable 633 13820 Sunrise Valley Drive 634 Herndon, VA 20171 635 US 637 Phone: +1 703-561-2540 638 Email: wesley.george@twcable.com 640 Sandy Murphy 641 SPARTA, Inc., a Parsons Company 642 7110 Samuel Morse Drive 643 Columbia, MD 21046 644 US 646 Phone: +1 443-430-8000 647 Email: sandy@tislabs.com