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