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