idnits 2.17.1 draft-ietf-sidr-as-migration-00.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 13 instances of too long lines in the document, the longest one being 8 characters 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 (July 10, 2013) is 3941 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: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ga-idr-as-migration-01 == Outdated reference: A later version (-23) exists of draft-ietf-sidr-bgpsec-protocol-07 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. George 3 Internet-Draft Time Warner Cable 4 Intended status: Informational S. Murphy 5 Expires: January 11, 2014 SPARTA, Inc., a Parsons Company 6 July 10, 2013 8 BGPSec Considerations for AS Migration 9 draft-ietf-sidr-as-migration-00 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 January 11, 2014. 33 Copyright Notice 35 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . 12 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 70 9.2. Informative References . . . . . . . . . . . . . . . . . 14 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-ga- 82 idr-as-migration [I-D.ga-idr-as-migration]. Accordingly, it is 83 necessary to discuss this de facto standard to ensure that the 84 process and features are properly supported in BGPSec 85 [I-D.ietf-sidr-bgpsec-protocol], because BGPSec is explicitly 86 designed to protect against changes in the BGP AS_PATH, whether by 87 choice, by misconfiguration, or by malicious intent. It is critical 88 that the BGPSec protocol framework is able to support this 89 operationally necessary tool without creating an unacceptable 90 security risk or exploit in the process. 92 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-ga-idr-as-migration 109 [I-D.ga-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). Confederations RFC 5065 [RFC5065] are *not* 114 being implemented between the ASNs, but vendor-specific configuration 115 knobs are being used to allow the migrating PE to masquerade as the 116 old ASN for the PE-CE eBGP session, or to manipulate the AS_PATH, or 117 both. While BGPSec [I-D.ietf-sidr-bgpsec-protocol] does have a case 118 to handle standard confederation implementations, it is not 119 applicable in this exact case. The reason that this migration drives 120 a slightly different solution in BGPSec than a standard confederation 121 is that unlike in a confederation, eBGP peers may not be peering with 122 the "correct" external ASN, and the forward-signed updates are for a 123 public ASN, rather than a private one, so there is no expectation 124 that the BGP speaker should strip the affected signatures before 125 propagating the route to its eBGP neighbors. 127 In the following examples, AS64510 is being subsumed by AS64500, and 128 both ASNs represent a Service Provider (SP) network (see Figure 1 in 129 draft-ga-idr-as-migration [I-D.ga-idr-as-migration]). AS64496 and 130 64499 represent end customer networks. References to PE, CE, and P 131 routers mirror the diagrams and references in the above cited draft. 133 3. RPKI Considerations 135 Since the methods and implementation discussed in draft-ga-idr-as- 136 migration [I-D.ga-idr-as-migration] are not technically a part of the 137 BGP4 protocol implementation, but rather a vendor-specific feature, 138 BGPSec is not technically required to ensure that it continues 139 functioning as it does today. However, this is widely used during 140 network integrations resulting from mergers and acquisitions, as well 141 as network redesigns, and therefore it is not feasible to simply 142 eliminate this capability on any BGPSec-enabled routers/ASNs. What 143 follows is a discussion of the potential issues to be considered 144 regarding how ASN-migration and BGPSec 145 [I-D.ietf-sidr-bgpsec-protocol] validation might interact. 147 One of the primary considerations for this draft and migration is 148 that companies rarely stop after one merger/acquisition/divestiture, 149 and end up accumulating several legacy ASNs over time. Since they 150 are using methods to migrate that do not require coordination with 151 customers, they do not have a great deal of control over the length 152 of the transition period as they might with something completely 153 under their administrative control (e.g. a key roll). This leaves 154 many SPs with multiple legacy ASNs which don't go away very quickly, 155 if at all. As solutions were being proposed for RPKI implementations 156 to solve this transition case, operational complexity and hardware 157 scaling considerations associated with maintaining multiple legacy 158 ASN keys on routers throughout the combined network have been 159 carefully considered. While SPs SHOULD NOT remain in this transition 160 phase indefinitely because of the operational complexity and scaling 161 considerations associated with maintaining multiple legacy ASN keys 162 on routers throughout the combined network, this is of limited 163 utility as a solution, and so every effort has been made to keep the 164 additional complexity during the transition period to a minimum, on 165 the assumption that it will likely be protracted. 167 3.1. Origin Validation 169 Origin Validation does not need a unique solution to enable 170 migration, as the existing protocol and procedure allows for a 171 solution. In the scenario discussed, AS64510 is being replaced by 172 AS64500. If there are any existing routes originated by AS64510 on 173 the router being moved into the new ASN, this simply requires 174 generating new ROAs for the routes with the new ASN and treating them 175 as new routes to be added to AS64500. However, we also need to 176 consider the situation where one or more other PEs are still in 177 AS64510, and are originating one or more routes that may be distinct 178 from any that the router under migration is originating. PE1 (which 179 is now a part of AS64500 and instructed to use replace-as to remove 180 AS64510 from the path) needs to be able to properly handle routes 181 originated from AS64510. If the route now shows up as originating 182 from AS64500, any downstream peers' validation check will fail unless 183 a ROA is *also* available for AS64500 as the origin ASN, meaning that 184 there will be overlapping ROAs until all routers originating prefixes 185 from AS64510 are migrated to AS64500. Overlapping ROAs are 186 permissible perRFC 6480 [RFC6480] section 3.2, and so managing origin 187 validation during a migration like this is merely applying the 188 defined case where a set of prefixes are originated from more than 189 one ASN. Therefore, for each ROA that authorizes AS64510 to 190 originate a prefix, a new ROA SHOULD also be created that authorizes 191 AS64500 to originate the same prefix. 193 3.2. Path Validation 195 BGPSec Path Validation requires that each router in the AS Path 196 cryptographically sign its update to assert that "Every AS on the 197 path of ASes through which the update message passes has explicitly 198 authorized the advertisement of the route to the subsequent AS in the 199 path." (see point #2 in intro of [I-D.ietf-sidr-bgpsec-protocol]) 200 Since the referenced AS migration technique is explicitly modifying 201 the AS_PATH between two eBGP peers who are not coordinating with one 202 another (are not in the same administrative domain), no level of 203 trust can be assumed, and therefore it may be difficult to identify 204 legitimate manipulation of the AS_PATH for migration activities when 205 compared to manipulation due to misconfiguration or malicious intent. 207 3.2.1. Outbound announcements (PE-->CE) 209 When PE1 is moved from AS64510 to AS64500, it will be provisioned 210 with the appropriate keys for AS64500 to allow it to forward-sign 211 routes using AS64500. However, there is currently no guidance in the 212 BGPSec protocol specification on whether or not the forward-signed 213 ASN value MUST match the configured "remote-as" to validate properly. 214 That is, if CE1's BGP session is configured as "remote-as 64510", the 215 presence of "local-as 64510" on PE1 will ensure that there is no ASN 216 mismatch on the BGP session itself, but if CE1 receives updates from 217 its remote neighbor (PE1) forward-signed from AS64500, there is no 218 guidance as to whether the BGPSec validator on CE1 still consider 219 those valid by default. RFC4271 [RFC4271] section 6.3 mentions this 220 match between the ASN of the peer and the AS_PATH data, but it is 221 listed as an optional validation, rather than a requirement. 222 Assuming that this mismatch will be allowed by vendor implementations 223 and using it as a means to solve this migration case is likely to be 224 problematic. 226 3.2.2. Inbound announcements (CE-->PE) 228 Inbound is more complicated, because the CE doesn't know that PE1 has 229 changed ASNs, so it is forward-signing all of its routes with 230 AS64510, not AS64500. The BGPSec speaker cannot manipulate previous 231 signatures, and therefore cannot manipulate the previous AS Path 232 without causing a mismatch that will invalidate the route. If the 233 updates are simply left intact, the ISP would still need to publish 234 and maintain valid and active public-keys for AS 64510 if it is to 235 appear in the BGPSec_Path_Signature in order that receivers can 236 validate the BGPSEC_Path_Signature arrived intact/whole. However, if 237 the updates are left intact, this will cause the AS Path length to be 238 increased, which is undesirable as discussed in draft-ga-idr-as- 239 migration [I-D.ga-idr-as-migration]. 241 4. Requirements 243 These requirements are written under the assumption that the 244 currently vendor-specific implementations will be standardized via 245 draft-ga-idr-as-migration [I-D.ga-idr-as-migration], as it makes 246 little sense to build support into a standard for something that is 247 not actually a standard itself. However, should IETF choose not to 248 standardize the discussed method of AS migration, it is possible that 249 this draft could be considered implementation guidance for those 250 vendors that have support for this method of AS migration and wish to 251 support it in their BGPSec implementation. In order to be 252 deployable, any solution to the described problem needs to consider 253 the following requirements, listed in no particular order: 255 o BGPSec MUST support AS Migration for both inbound and outbound 256 route announcements (see Section 3.2.1 and 3.2.2). It SHOULD do 257 this without reducing BGPSec's protections for route path 259 o MUST NOT require any reconfiguration on the remote eBGP neighbor 260 (CE) 262 o SHOULD confine configuration changes to the migrating PEs e.g. 263 can't require global configuration changes to support migration 265 o MUST NOT lengthen AS Path during migration 267 o MUST operate within existing trust boundaries e.g. can't expect 268 remote side to accept pCount=0 (see Section 3 of 269 [I-D.ietf-sidr-bgpsec-protocol]) from untrusted/non-confed 270 neighbor 272 5. Solution 274 As noted in [I-D.ietf-sidr-bgpsec-protocol], section 4.2, BGPSec 275 already has a solution for hiding ASNs where increasing the AS Path 276 length is undesirable. So one might think that a simple solution 277 would be to retain the keys for AS64510 on PE1, and forward-sign 278 towards CE1 with AS64510 and pCount=0. However, this would mean 279 passing a pCount=0 between two ASNs that are in different 280 administrative and trust domains such that it could represent a 281 significant attack vector to manipulate BGPSec-signed paths. The 282 expectation for legitimate instances of pCount=0 (to make a route- 283 server that is not part of the transit path invisible) is that there 284 is some sort of existing trust relationship between the operators of 285 the route-server and the downstream peers such that the peers could 286 be explicitly configured by policy to accept pCount=0 announcements 287 only on the sessions where they are expected. For the same reason 288 that things like local-as are used for ASN migration without end 289 customer coordination, it is unrealistic to assume any sort of 290 coordination between the SP and the administrators of CE1 to ensure 291 that they will by policy accept pCount=0 signatures during the 292 transition period, and therefore this is not a workable solution. 294 A better solution presents itself when considering how to handle 295 routes coming from the CE toward the PE, where the routes are 296 forward-signed to AS64510, but will eventually need to show AS64500 297 in the outbound route announcement. Because both AS64500 and AS64510 298 are in the same administrative domain, a signature from AS64510 299 forward-signed to AS64500 with pCount=0 would be acceptable as it 300 would be within the appropriate trust boundary so that each BGP 301 speaker could be explicitly configured to accept pCount=0 where 302 appropriate between the two ASNs. At the very simplest, this could 303 potentially be used at the eBGP boundary between the two ASNs during 304 migration. Since the AS_PATH manipulation described above usually 305 happens at the PE router on a per-session basis, and does not happen 306 network-wide simultaneously, it is not generally appropriate to apply 307 this AS hiding technique across all routes exchanged between the two 308 ASNs, as it may result in routing loops and other undesirable 309 behavior. Therefore the most appropriate place to implement this is 310 on the local PE that still has eBGP sessions associated with AS64510 311 (using the transition knobs detailed in the companion draft). Since 312 that PE has been moved to AS64500, it is not possible for it to 313 forward-sign AS64510 with pCount=0 without some minor changes to the 314 BGPSec implementation to address this use case. 316 AS migration is using AS_PATH and remote-AS manipulation to act as if 317 a PE under migration exists simultaneously in both ASNs even though 318 it is only configured with one global ASN. This draft proposes 319 applying a similar technique to the BGPSec signatures generated for 320 routing updates processed through this migration machinery. Each 321 routing update that is received from or destined to an eBGP neighbor 322 that is still using the old ASN (64510) will be signed twice, once 323 with the ASN to be hidden and once with the ASN that will remain 324 visible. In essence, we are treating the update as if the PE had an 325 internal BGP hop and the update was passed across an eBGP session 326 between AS64500 and AS64510, configured to use and accept pCount=0, 327 while eliminating the processing and storage overhead of creating an 328 actual eBGP session between the two ASNs within the PE router. This 329 will result in a properly secured AS Path in the affected route 330 updates, because the PE router will be provisioned with valid keys 331 for both AS64500 and AS64510. An important distinction here is that 332 while AS migration under standard BGP4 is manipulating the AS_PATH 333 attribute, BGPSec uses an attribute called the Secure_Path (see 334 Section 3 of [I-D.ietf-sidr-bgpsec-protocol]), and BGPSec capable 335 neighbors do not exchange AS_PATH information in their route 336 announcements. However, a BGPSec neighbor peering with a non-BGPSec- 337 capable neighbor will use the information found in Secure_Path to 338 reconstruct a standard AS_PATH for updates sent to that neighbor. 339 Unlike in Secure_Path where the ASN to be hidden is still present, 340 but ignored when considering AS Path (due to pCount=0), when 341 reconstructing an AS_PATH for a non-BGPSec neighbor, the pCount=0 342 ASNs will not appear in the AS_PATH at all (see section 4.4 of the 343 above-referenced draft). This draft is not changing existing AS_PATH 344 reconstruction behavior, merely highlighting it for clarity. 346 The procedure to support AS Migration in BGPSec is slightly different 347 depending on whether the PE under migration is receiving the routes 348 from one of its eBGP peers ("inbound" as in section 3.2.2) or 349 destined toward the eBGP peers ("outbound" as in section 3.2.1). 351 5.1. Outbound (PE->CE) 353 When a PE router receives an update destined for an eBGP neighbor 354 that is locally configured with AS-migration knobs as discussed in 355 draft-ga-idr-as-migration [I-D.ga-idr-as-migration], it MUST generate 356 a valid BGPSec signature as defined in 357 [I-D.ietf-sidr-bgpsec-protocol] for _both_ configured ASNs. It MUST 358 generate a signature from the new (global) ASN forward signing to the 359 old (local) ASN with pCount=0, and then it MUST generate a forward 360 signature from the old (local) ASN to the target eBGP ASN with 361 pCount=1 as normal. 363 5.2. Inbound (CE->PE) 365 When a PE router receives an update from an eBGP neighbor that is 366 locally configured with AS-migration knobs (i.e. the opposite 367 direction of the previous route flow), it MUST generate a signature 368 from the old (local) ASN forward signing to the new (global) ASN with 369 pCount=0. It is not necessary to generate the second signature from 370 the new (global) ASN because the ASBR will generate that when it 371 forward signs towards its eBGP peers as defined in normal BGPSec 372 operation. This is a deviation from standard BGPSec behavior in that 373 typically a signature is not added when a routing update is sent 374 across an iBGP session, and the next signature is added by the ASBR 375 when it forward-signs toward its eBGP peer as the routing update 376 exits the ASN. 378 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 the current BGPSec 382 specification, routers that receive updates from iBGP neighbors MUST 383 NOT reject updates with new (valid) BGPSec attributes, including the 384 presence of pCount=0 on a previous signature, or they will interfere 385 with this implementation. In similar fashion, any route-reflectors 386 in the path of these updates MUST reflect them transparently to their 387 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 5.4. Example 401 The following example will illustrate the method being used above. 402 As with previous examples, PE1 is the router being migrated, AS64510 403 is the old AS, which is being subsumed by AS64500, the "keep" AS. 404 64505 is another external peer, used to demonstrate what the 405 announcements will look like to a third party peer that is not part 406 of the migration. Some additional notation is used to delineate the 407 details of each signature as follows: 409 The origin BGPSEC signature attribute takes the form: sig(, Origin ASN, pCount, NLRI Prefix) key 412 Intermediate BGPSEC signature attributes take the form: sig(, Signer ASN, pCount, ) key 415 Equivalent AS_PATH refers to what the AS_PATH would look like if it 416 was reconstructed to be sent to a non-BGPSec peer, while Secure_Path 417 shows the AS Path as represented between BGPSec peers. 419 Note: The representation of signature attribute generation is being 420 simplified here somewhat for the sake of brevity; the actual details 421 of the signing process are as described Sections 4.1 and 4.2 in 422 [I-D.ietf-sidr-bgpsec-protocol]. For example, what is covered by the 423 signature also includes Flags, Algorithm Suite ID, NLRI length, etc. 424 Also, the key is not carried in the update, instead the SKI is 425 carried. 427 Before Merger 429 64505 430 | 431 ISP B ISP A 432 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 433 64496 Old_ASN: 64510 Old_ASN: 64500 64499 435 CE-2 to PE-2: sig(<64500>, O=64499, pCount=1, N)K_64499-CE2 [sig1] 436 Equivalent AS_PATH=(64499) 437 Secure_Path=(64499) 438 length=sum(pCount)=1 440 PE-2 to 64505: sig(<64505>, 64500, pCount=1, )K_64500-PE2 [sig2] 441 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] 442 Equivalent AS_PATH=(64500,64499) 443 Secure_Path=(64500,64499) 444 length=sum(pCount)=2 446 PE-2 to PE-1: sig(<64510>, 64500, pCount=1, )K_64500-PE2 [sig3] 447 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] 448 Equivalent AS_PATH=(64500,64499) 449 Secure_Path=(64500,64499) 450 length=sum(pCount)=2 452 PE-1 to CE-1: sig(<64496>, 64510, pCount=1, )K_64510-PE1 [sig4] 453 sig(<64510>, 64500, pCount=1, )K_64500-PE2 [sig3] 454 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig1] 455 Equivalent AS_PATH= (64510,64500,64499) 456 Secure_Path=(64510,64500,64499) 457 length=sum(pCount)=3 459 Migrating, route flow outbound PE-1 to CE-1 460 64505 461 | 462 ISP A' ISP A' 463 CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2 464 64496 Old_ASN: 64510 Old_ASN: 64500 64499 465 New_ASN: 64500 New_ASN: 64500 467 CE-2 to PE-2: sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 468 Equivalent AS_PATH=(64499) 469 Secure_Path=(64499) 470 length=sum(pCount)=1 472 PE-2 to 64505: sig(<64505>, 64500, pCount=1, )K_64500-PE2 [sig12] 473 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 474 Equivalent AS_PATH=(64500,64499) 475 Secure_Path=(64500,64499) 476 length=sum(pCount)=2 478 PE-2 to PE-1: sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 479 Equivalent AS_PATH=(64499) 480 Secure_Path=(64499) 481 length=sum(pCount)=1 482 #PE-2 sends to PE-1 (in iBGP) the exact same update as received from AS64499. 484 PE-1 to CE-1: sig(<64496>, 64510, pCount=1, )K_64510-PE1 [sig14] 485 sig(<64510>, 64500, pCount=0, )K_64500-PE2 [sig13] 486 sig(<64500>, 64499, pCount=1, N)K_64499-CE2 [sig11] 487 Equivalent AS_PATH=(64510,64499) 488 Secure_Path=(64510, 64500(pCount=0),64499) 489 length=sum(pCount)=2 (length is NOT 3) 490 #PE1 adds [sig13] acting as AS64500 491 #PE1 accepts [sig13] with pCount=0 acting as AS64510, 492 #as it would if it received sig13 from an eBGP peer 494 Migrating, route flow inbound CE-1 to PE-1 495 64505 496 | 497 ISP A' ISP A' 498 CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2 499 64496 Old_ASN: 64510 Old_ASN: 64500 64499 500 New_ASN: 64500 New_ASN: 64500 502 CE-1 to PE-1: sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 503 Equivalent AS_PATH=(64496) 504 Secure_Path=(64496) 505 length=sum(pCount)=1 507 PE-1 to PE-2: sig(<64500>, 64510, pCount=0, )K_64510-PE1 [sig22] 508 sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 509 Equivalent AS_PATH=(64496) 510 Secure_Path=(64510 (pCount=0),64496) 511 length=sum(pCount)=1 (length is NOT 2) 512 #PE1 adds [sig22] acting as AS64510 513 #PE1 accepts [sig22] with pCount=0 acting as AS64500, 514 #as it would if it received sig22 from an eBGP peer 516 PE-2 to 64505: sig(<64505>, 64500, pCount=1, )K_64500-PE2 [sig23] 517 sig(<64500>, 64510, pCount=0, )K_64510-PE1 [sig22] 518 sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 519 Equivalent AS_PATH=(64500,64496) 520 Secure_Path=(64500,64510 (pCount=0), 64496) 521 length=sum(pCount)=2 (length is NOT 3) 523 PE-2 to CE-2: sig(<64499>, 64500, pCount=1, )K_64500-PE2 [sig24] 524 sig(<64500>, 64510, pCount=0, )K_64510-PE1 [sig22] 525 sig(<64510>, 64496, pCount=1, N)K_64496-CE1 [sig21] 526 Equivalent AS_PATH=(64500,64496) 527 Secure_Path=(64500, 64510 (pCount=0), 64496) 528 length=sum(pCount)=2 (length is NOT 3) 530 6. Acknowledgements 532 Thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, and Terry 533 Manderson for their review comments. 535 Additionally, the solution presented in this draft is an amalgam of 536 several SIDR interim meeting discussions plus a discussion at IETF85, 537 collected and articulated thanks to Sandy Murphy. 539 7. IANA Considerations 540 This memo includes no request to IANA. 542 8. Security Considerations 544 This draft discusses a process by which one ASN is migrated into and 545 subsumed by another. Because this process involves manipulating the 546 AS_Path in a BGP route to make it deviate from the actual path that 547 it took through the network, this migration process is attempting to 548 do exactly what BGPSec is working to prevent. BGPSec MUST be able to 549 manage this legitimate use of AS_Path manipulation without generating 550 a vulnerability in the RPKI route security infrastructure. 552 The solution discussed above is considered to be reasonably secure 553 from exploitation by a malicious actor because it requires both 554 signatures to be secured as if they were forward-signed between two 555 eBGP neighbors. This requires any router using this solution to be 556 provisioned with valid keys for both the migrated and subsumed ASN so 557 that it can generate valid signatures for each of the two ASNs it is 558 adding to the path. If the AS's keys are compromised, or zero-length 559 keys are permitted, this does potentially enable an AS_PATH 560 shortening attack, but this is not fundamentally altering the 561 existing security risks for BGPSec. 563 9. References 565 9.1. Normative References 567 [I-D.ga-idr-as-migration] 568 George, W. and S. Amante, "Autonomous System (AS) 569 Migration Features and Their Effects on the BGP AS_PATH 570 Attribute", draft-ga-idr-as-migration-01 (work in 571 progress), February 2013. 573 [I-D.ietf-sidr-bgpsec-protocol] 574 Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- 575 sidr-bgpsec-protocol-07 (work in progress), February 2013. 577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 578 Requirement Levels", BCP 14, RFC 2119, March 1997. 580 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 581 Documentation Use", RFC 5398, December 2008. 583 9.2. Informative References 585 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 586 selection, and registration of an Autonomous System (AS)", 587 BCP 6, RFC 1930, March 1996. 589 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 590 Protocol 4 (BGP-4)", RFC 4271, January 2006. 592 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 593 System Confederations for BGP", RFC 5065, August 2007. 595 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 596 Secure Internet Routing", RFC 6480, February 2012. 598 Authors' Addresses 600 Wesley George 601 Time Warner Cable 602 13820 Sunrise Valley Drive 603 Herndon, VA 20171 604 US 606 Phone: +1 703-561-2540 607 Email: wesley.george@twcable.com 609 Sandy Murphy 610 SPARTA, Inc., a Parsons Company 611 7110 Samuel Morse Drive 612 Columbia, MD 21046 613 US 615 Phone: +1 443-430-8000 616 Email: sandy@tislabs.com