idnits 2.17.1 draft-ietf-softwire-security-requirements-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 22, 2009) is 5447 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-ietf-softwire-hs-framework-l2tpv2-12 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Yamamoto 3 Internet-Draft NICT/KDDI R&D Labs 4 Intended status: Standards Track C. Williams 5 Expires: November 23, 2009 KDDI R&D Labs 6 F. Parent 7 Beon Solutions 8 H. Yokota 9 KDDI R&D Labs 10 May 22, 2009 12 Softwire Security Analysis and Requirements 13 draft-ietf-softwire-security-requirements-08 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 23, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes the security guidelines for the softwire 52 "Hubs and Spokes" and "Mesh" solutions. Together with the discussion 53 of the softwire deployment scenarios, the vulnerability to the 54 security attacks is analyzed to provide the security protection 55 mechanism such as authentication, integrity and confidentiality to 56 the softwire control and data packets. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 64 3. Hubs and Spokes Security Guidelines . . . . . . . . . . . . . 5 65 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5 66 3.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 7 67 3.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 8 68 3.4. Softwire Security Guidelines . . . . . . . . . . . . . . . 10 69 3.4.1. Authentication . . . . . . . . . . . . . . . . . . . . 11 70 3.4.2. Softwire Security Protocol . . . . . . . . . . . . . . 13 71 3.5. Guidelines for Usage of IPsec in Softwire . . . . . . . . 13 72 3.5.1. Authentication Issues . . . . . . . . . . . . . . . . 14 73 3.5.2. IPsec Pre-Shared Keys for Authentication . . . . . . . 14 74 3.5.3. Inter-Operability Guidelines . . . . . . . . . . . . . 15 75 3.5.4. IPsec Filtering Details . . . . . . . . . . . . . . . 15 76 4. Mesh Security Guidelines . . . . . . . . . . . . . . . . . . . 19 77 4.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 19 78 4.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 20 79 4.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 20 80 4.4. Applicability of Security Protection Mechanism . . . . . . 21 81 4.4.1. Security Protection Mechanism for Control Plane . . . 21 82 4.4.2. Security Protection Mechanism for Data Plane . . . . . 22 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 25 89 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 26 90 A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE . . . 26 91 A.2. IPv4 over IPv6 Softwire with example for IKE . . . . . . . 27 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 94 1. Introduction 96 The Softwire Working Group specifies the standardization of 97 discovery, control and encapsulation methods for connecting IPv4 98 networks across IPv6 networks and IPv6 networks across IPv4 networks. 99 The softwire provides the connectivity to enable global reachability 100 of both address families by reusing or extending existing technology. 101 The Softwire Working Group is focusing on the two scenarios that 102 emerged when discussing the traversal of networks composed of 103 differing address families. This document provides the security 104 guidelines for such two softwire solution spaces such as "Hubs and 105 Spokes" and "Mesh" scenarios. "Hubs and Spokes" and "Mesh" problems 106 are described in [RFC4925] Section 2 and Section 3, respectively. 107 The protocols selected for softwire connectivity require the security 108 considerations on more specific deployment scenarios for each 109 solution. The scope of this document provides the analysis on the 110 security vulnerabilities for the deployment scenarios and specifies 111 the proper usage of the security mechanisms applied to the softwire 112 deployment. 114 Layer Two Tunneling Protocol (L2TPv2) is selected as phase 1 protocol 115 to be deployed in the "Hubs and Spokes" solution space. If L2TPv2 is 116 used in the unprotected network, it will be vulnerable to various 117 security attacks and MUST be protected by appropriate security 118 protocol such as IPsec described in [RFC3193]. The new 119 implementation SHOULD use IKEv2 in the key management protocol for 120 IPsec because of more reliable protocol and integration of required 121 protocols in a single platform. This document provides the 122 implementation guidance and proper usage of IPsec as the security 123 protection mechanism by considering the security vulnerabilities in 124 "Hubs and Spokes" scenario. The document also addresses the cases 125 where the security protocol is not necessarily mandated. 127 The softwire "Mesh" solution MUST support various levels of security 128 mechanism to protect the data packets from an attacker being 129 transmitted on a softwire tunnel from the access networks with one 130 address family across the transit core operating with different 131 address family [RFC4925]. The security mechanism for the control 132 plane is also required to be protected from control data 133 modification, spoofing attack, etc. In the "Mesh" solution, BGP is 134 used for distributing softwire routing information in the transit 135 core while the security issues for BGP is being discussed in other 136 working groups. This document provides the proper usage of the 137 security mechanisms for the softwire mesh deployment scenarios. 139 2. Terminology 141 2.1. Abbreviations 143 The terminology is based on the softwire problem statement document 144 [RFC4925]. 146 AF(i) - Address Family. IPv4 or IPv6. Notation used to indicate 147 that prefixes, a node or network only deal with a single IP AF. 149 AF(i,j) - Notation used to indicate that a node is dual-stack or that 150 a network is composed of dual-stack nodes. 152 Address Family Border Router (AFBR) -A dual-stack router that 153 interconnects two networks that use either the same or different 154 address families. An AFBR forms peering relationships with other 155 AFBRs, adjacent core routers and attached CE routers, perform 156 softwire discovery and signaling, advertises client ASF(i) 157 reachability information and encapsulates/decapsulates customer 158 packets in softwire transport headers. 160 Customer Edge (CE) - A router located inside AF access island that 161 peers with other CE routers within the access island network and with 162 one or more upstream AFBRs. 164 Customer Premise Equipment (CPE) - An equipment, host or router, 165 located at a subscriber's premises and connected with a carrier's 166 access network. 168 Provider Edge (PE) - A router located at the edge of transit core 169 network that interfaces with CE in access island. 171 Softwire Concentrator (SC) - The node terminating the softwire in the 172 service provider network. 174 Softwire Initiator (SI) - The node initiating the softwire within the 175 customer network. 177 Softwire Encapsulation Set (SW-Encap) - A softwire encapsulation set 178 contains tunnel header parameters, order of preference of the tunnel 179 header types and the expected payload types (e.g. IPv4) carried 180 inside the softwire. 182 Softwire Next_Hop (SW-NHOP) - This attribute accompanies client AF 183 reachability advertisements and is used to reference a softwire on 184 the ingress AFBR leading to the specific prefixes. It contains a 185 softwire identifier value and a softwire next_hop IP address denoted 186 as . Its existence in the presence of client 187 AF prefixes (in advertisements or entries in a routing table) infers 188 the use of softwire to reach that prefix. 190 2.2. Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in [RFC2119]. 196 3. Hubs and Spokes Security Guidelines 198 3.1. Deployment Scenarios 200 To provide the security guidelines, the discussion of the possible 201 deployment scenario and the trust relationship in the network is 202 important. 204 The softwire initiator (SI) always resides in the customer network. 205 The node, in which the SI resides, can be the CPE access device, 206 another dedicated CPE router behind the original CPE access device or 207 any kind of host device such as PC, appliance, sensor etc. 209 However, the host device may not always have direct access to its 210 home carrier network, to which the user has subscribed. For example, 211 the SI in the laptop PC can access various access networks such as 212 Wi-Fi hot-spots, visited office network. This is the nomadic case, 213 which the softwire SHOULD support. 215 As the softwire deployment model, the following three cases as shown 216 in Figure 1 should be considered. Case 2 and 3 are typical for a 217 nomadic node, but are also applicable to a stationary node. In order 218 to securely connect legitimate SI and SC each other, the 219 authentication process between SI and SC is performed normally using 220 AAA servers. 222 visited network visited network 223 access provider service provider 224 +---------------------------------+ 225 | | 226 +......v......+ +.....................|......+ 227 . . . v . 228 +------+ . (case 3) . . +------+ +--------+ . 229 | |=====================.==| | | | . 230 | SI |__.________ . . | SC |<---->| AAAv | . 231 | |---------- \ . . | | | | . 232 +------+ . \\ . . +------+ +--------+ . 233 . \\ . . ^ . 234 ^ +..........\\.+ +.....................|......+ 235 | \\ | 236 | (case 2) \\ | 237 | \\ | 238 | \\ | 239 | +............+ \\ +.....................|......+ 240 . . \\. v . 241 +------+ . . \\__+------+ +--------+ . 242 | | . (case 1) . ---| | | | . 243 | SI |=====================.==| SC |<---->| AAAh | . 244 | | . . . | | | | . 245 +------+ . . . +------+ +--------+ . 246 . . . . 247 +............+ +............................+ 248 home network home network 249 access provider service provider 251 Figure 1: Authentication model for Hubs and Spokes 253 The AAA server shown in Figure 1 interacts with the SC which acts as 254 an AAA client. The AAA may consists of multiple AAA servers and the 255 proxy AAA may be intermediate between the SC and the AAA servers. 256 This document refers to the AAA server in the home network service 257 provider as the home AAA server (AAAh) and that in the visited 258 network service provider as the visited AAA server (AAAv). 260 The softwire problem statement [RFC4925] states that the softwire 261 solution must be able to be integrated with common deployed AAA 262 solution. L2TPv2 used in softwire supports PPP and L2TP 263 authentications which can be integrated with common AAA servers. 265 When the softwire is used in an unprotected network, a stronger 266 authentication process is required (e.g., IKEv2). The proper 267 selection of the authentication processes is discussed in Section 3.4 268 with respect to the various security threats. 270 Case 1: The SI connects to the SC that belongs to the home network 271 service provider via the home access provider network operating 272 different address family. It is assumed that the home access network 273 and the home network providing SC are under the same administrative 274 system. 276 Note that the IP address of the host device, in which SI resides, is 277 static or dynamic depending on the subscribed service. The discovery 278 of the SC may be automatic. But in this document, the information on 279 the SC, e.g. the DNS name or IP address, is assumed to be configured 280 by the user or the provider of the SI in advance. 282 Case 2: The SI connects to the SC that belongs to the home network 283 service provider network via the visited access network. For the 284 nomadic case, the SI/user does not subscribe to the visited access 285 provider. For the network access through the public network such as 286 WiFi hot-spots, the home network service provider does not have the 287 trust relationship with the access network. 289 Note that the IP address of the host device, in which SI resides, may 290 be changed periodically due to the home network service provider's 291 policy. 293 Case 3: The SI connects to the SC that belongs to the visited network 294 service provider via the visited access network. This is typical of 295 nomadic access case. When the SI is mobile, it may roam from the 296 home ISP providing the home access network to the visited access 297 network, e.g. WiFi hot-spot network provided by the different ISP. 298 The SI does not connect to the SC in the home network, for example, 299 due to the geographical reason. The SI/user does not subscribe to 300 the visited network service provider, but the visited network service 301 provider has some roaming agreement with the home network service 302 provider. 304 Note that the IP address of the host, in which SI resides, is 305 provided the visited network service provider's policy. 307 3.2. Trust Relationship 309 The establishment of the trust relationship between SI and SC is 310 different for three cases. The security consideration must be taken 311 into account for each case. 313 In Case 1, the SC and the home AAA server in the same network service 314 provider MUST have a trust relationship and communications between 315 them MUST be secured. When the SC authenticates the SI, the SC 316 transmits the authentication request message to the home AAA server 317 and obtains the accept message together with the Attribute Value Pair 318 for the SI authentication. Since the SI in the service provider 319 network, the provider can take measures to protect the entities 320 (e.g., SC, AAA servers) against a number of security threats, 321 including the communication between them. 323 In Case 2, when the SI is mobile, the access to the home network 324 service provider through the visited access network provider is 325 allowed. The trust relationship between SI and the SC in the home 326 network MUST be established. When the visited access network is a 327 public network, the various security attacks must be considered. 328 Especially for SI to connect to the legitimate SC, the authentication 329 from SI to SC MUST be performed together with that from SC to SI. 331 In Case3, if the SI roams into a different network service provider's 332 administrative domain and the visited AAA server communicates with 333 the home AAA server to obtain the information for SI authentication. 334 The visited AAA server MUST have a trust relationship with the home 335 AAA server and the communication between them MUST be secured in 336 order to properly perform the roaming services that have been agreed 337 upon under specified conditions. 339 Note that the path for the communications between the home AAA server 340 and the visited AAA server may consist of several AAA proxies. In 341 this case, AAA proxy threat model SHOULD be considered [RFC2607]. A 342 malicious AAA proxy may launch passive or active security attacks. 343 The trustworthiness of proxies in AAA proxy chains will be weaken 344 when the hop counts of the proxy chain is longer. For example, the 345 accounting information exchanged among AAA proxies is attractive for 346 an adversary. The communication between a home AAA server and a 347 visited AAA server MUST be protected. 349 3.3. Softwire Security Threat Scenarios 351 Softwire can be used to connect IPv6 networks across public IPv4 352 networks and IPv4 networks across public IPv6 networks. The control 353 and data packets used during the softwire session are vulnerable to 354 the security attacks. 356 A complete threat analysis of softwire requires examination of the 357 protocols used for the softwire setup, the encapsulation method used 358 to transport the payload, and other protocols used for configuration 359 (e.g., router advertisements, DHCP). 361 The softwire solution uses a subset of the Layer Two Tunneling 362 Protocol (L2TPv2) functionality [RFC2661], 363 [I-D.ietf-softwire-hs-framework-l2tpv2]. In the softwire "Hubs and 364 Spokes" model, L2TPv2 is used in a voluntary tunnel model only. The 365 SI acts as a L2TP Access Concentrator (LAC) and PPP endpoint. The 366 L2TPv2 tunnel is always initiated from the SI., 368 Generic threat analysis done for L2TP using IPsec [RFC3193] is 369 applicable to softwire "Hubs and Spokes" deployment. The threat 370 analysis for other protocols such as MIPv6 [RFC4225], PANA [RFC4016], 371 NSIS [RFC4081], and Routing Protocols [RFC4593] are applicable here 372 as well and should be used as references. 374 First, the SI resided in the customer network sends Start-Control- 375 Connection-Request(SCCRQ) packet to the SC for the initiation of the 376 softwire. L2TPv2 offers an optional CHAP-like tunnel authentication 377 system during control connection establishment. This requires a 378 shared secret between the SI and SC and no key management is offered 379 for this L2TPv2. 381 When L2TPv2 control connection is established, the SI and SC 382 optionally enter authentication phase after completing PPP Link 383 Control Protocol (LCP) negotiation. PPP authentication supports one 384 way or two way CHAP authentication, and can leverage existing AAA 385 infrastructure. PPP authentication does not provide per-packet 386 authentication. 388 PPP encryption is defined but PPP Encryption Control Protocol (ECP) 389 negotiation does not provide for a protected cipher suite 390 negotiation. PPP encryption provides a weak security solution 391 [RFC3193]. PPP ECP implementation cannot be expected. PPP 392 authentication also does not provide the scalable key management. 394 Once the L2TPv2 tunnel and PPP configuration are successfully 395 established, the SI is connected and can start using the connection. 397 These steps are vulnerable to man-in-the-middle (MITM), denial of 398 service (DoS), and service theft attacks, which are caused as the 399 consequence of the following adversary actions. 401 Adversary attacks on softwire include: 403 1. An adversary may try to discover identities by snooping data 404 packets. 406 2. An adversary may try to modify both control and data packets. 407 This type of attack involves integrity violations. 409 3. An adversary may try to eavesdrop and collect control messages. 410 By replaying these messages, an adversary may successfully hijack 411 the L2TP tunnel or the PPP connection inside the tunnel. An 412 adversary might mount MITM, DOS, and theft of service attacks. 414 4. An adversary can flood the softwire node with bogus signaling 415 messages to cause DoS attacks by terminating L2TP tunnels or PPP 416 connections. 418 5. An adversary may attempt to disrupt the softwire negotiation in 419 order to weaken or remove confidentiality protection. 421 6. An adversary may wish to disrupt the PPP LCP authentication 422 negotiation. 424 In environments where the link is shared without the cryptographic 425 protection and the weak authentication or one-way authentication is 426 used, these security attacks can be mounted on softwire control and 427 data packets. 429 When there is no prior trust relationship between the SI and SC, any 430 node can pretend to be a SC. In this case, an adversary may 431 impersonate the SC to intercept traffic (e.g. "rogue" softwire 432 concentrator). 434 The rogue SC can introduce a denial of service attack by blackholing 435 packets from the SI. The rogue SC can also eavesdrop on all packets 436 sent from or to the SI. Security threats of a rogue SC are similar 437 to a compromised router. 439 The deployment of ingress filtering is able to control the malicious 440 users' access [RFC4213]. Without specific ingress filtering checks 441 in the decapsulator at the SC, it would be possible for an attacker 442 to inject a false packet, leaving the system vulnerable to attacks 443 such as DoS. The inner address ingress filtering can reject invalid 444 inner source address. Without inner address ingress filtering, 445 another kind of attack can happen. The malicious users from another 446 ISP could start using its tunneling infrastructure to get free inner 447 address connectivity, transforming effectively the ISP into an inner 448 address transit provider. 450 While the ingress filtering does not provide the complete protection 451 in the case an address spoofing has been happened. In order to 452 provide better protection against address spoofing, authentication 453 with binding between the legitimate address and the authenticated 454 identity MUST be implemented. This can be implemented between the SC 455 and the SI using IPsec. 457 3.4. Softwire Security Guidelines 459 Based on the security threat analysis in Section 3.3 in this 460 document, the softwire security protocol MUST support the following 461 protections. 463 1. Softwire control messages between the SI and SC MUST be protected 464 against eavesdropping and spoofing attacks. 466 2. Softwire security protocol MUST be able to protect itself against 467 replay attacks. 469 3. Softwire security protocol MUST be able to protect the device 470 identifier against the impersonation when it is exchanged between 471 the SI and the SC. 473 4. Softwire security protocol MUST be able to securely bind the 474 authenticated session to the device identifier of the client, to 475 prevent service theft. 477 5. Softwire security protocol MUST be able to protect disconnect and 478 revocation messages. 480 The softwire security protocol requirement is comparable to 481 [RFC3193]. 483 For softwire control packets, authentication, integrity and replay 484 protection MUST be supported and confidentiality SHOULD be supported. 486 For softwire data packets, authentication, integrity and replay 487 protection SHOULD be supported and confidentiality MAY be supported. 489 The softwire problem statement [RFC4925] provides some requirements 490 for "Hubs and Spoke" solution that are taken into account in defining 491 the security protection mechanisms. 493 1. Control and/or data plane MUST be able to provide full payload 494 security when desired. 496 2. Deployed technology MUST be very strongly considered. 498 This additional security protection must be separable from the 499 softwire tunneling mechanism. 501 Note that the scope of the security is on the L2TP tunnel between the 502 SI and SC. If end-to-end security is required, a security protocol 503 SHOULD be used in the payload packets. But this is out of scope of 504 this document. 506 3.4.1. Authentication 508 The softwire security protocol MUST support user authentication in 509 the control plane, in order to authorize access to the service, and 510 provide adequate logging of activity. Although several 511 authentication protocols are available, the security threats must be 512 considered to choose the protocol. 514 For example, the SI/user using Password Authentication Protocol (PAP) 515 access to the SC with the cleartext password. In many circumstances, 516 this represents a large security risk. The adversary may spoof as a 517 legitimate user by using the stolen password. Challenge Handshake 518 Authentication Protocol (CHAP) [RFC1994] encrypts a password with 519 "challenge" sent from the SC. The theft of password can be 520 mitigated. However, as CHAP only supports unidirectional 521 authentication, the risk of a man-in-the-middle or rogue SC cannot be 522 avoided. Extensible Authentication Protocol-Transport Layer Security 523 (EAP-TLS) [RFC5216] mandates mutual authentication and avoid the 524 rogue SC. 526 When the SI established a connection to the SC through a public 527 network, the SI may want to a proof of the SC identity. Softwire 528 MUST support mutual authentication to allow for such scenario. 530 In some circumstances, however, the service provider may decide to 531 allow non-authenticated connection 532 [I-D.ietf-softwire-hs-framework-l2tpv2]. For example, when the 533 customer is already authenticated by some other means, such as closed 534 networks, cellular networks at Layer 2, etc., the service provider 535 may decide to turn authentication off. If no authentication is 536 conducted on any layer, the SC acts as a gateway for anonymous 537 connections. Running such a service MUST be configurable by the SC 538 administrator and the SC SHOULD take some security measures such as 539 ingress filtering and adequate logging of activity. It should be 540 noted that anonymous connection service cannot provide the security 541 functionalities described in this document (e.g. integrity, replay 542 protection and confidentiality). 544 L2TPv2 selected as Softwire phase 1 protocol supports PPP 545 authentication and L2TPv2 authentication. PPP authentication and 546 L2TPv2 have various security threats as stated in Section 3.3. They 547 will be used in the limited condition as described in the next 548 subsections. 550 3.4.1.1. PPP Authentication 552 PPP can provide mutual authentication between the SI and SC using 553 CHAP [RFC1994] during the connection establishment phase (Link 554 Control Protocol, LCP). PPP CHAP authentication can be used when the 555 SI and SC are on a trusted, non-public IP network. 557 Since CHAP does not provide per-packet authentication, integrity, or 558 replay protection, PPP CHAP authentication MUST NOT be used for 559 unprotected on a public IP network. If other appropriate protected 560 mechanism has been already applied, PPP CHAP authentication MAY be 561 used. 563 Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY 564 be supported. 566 3.4.1.2. L2TPv2 Authentication 568 L2TPv2 provides an optional CHAP-like tunnel authentication during 569 the control connection establishment [RFC2661, 5.1.1]. L2TPv2 570 authentication MUST NOT be used for unprotected on a public IP 571 network as the same restriction applied to PPP CHAP. 573 3.4.2. Softwire Security Protocol 575 To meet the above requirements, all softwire security compliant 576 implementations MUST implement the following security protocols. 578 IPsec ESP [RFC4303] in transport mode is used for securing softwire 579 control and data packets. Internet Key Exchange (IKE) 580 protocol[RFC4306] MUST be supported for authentication, security 581 association negotiation and key management for IPsec. The 582 applicability of different version of IKE is discussed in Section 583 3.5. 585 The softwire security protocol MUST support NAT traversal. UDP 586 encapsulation of IPsec ESP packets[RFC3948] and negotiation of NAT- 587 traversal in IKE[RFC3947] MUST be supported when IPsec is used. 589 3.5. Guidelines for Usage of IPsec in Softwire 591 When softwire "Hubs and Spokes" solution implemented by L2TPv2 is 592 used in untrustworthy network, softwire MUST be protected by 593 appropriate security protocol such as IPsec. This section provides 594 guidelines for the usage of IPsec in L2TPv2 based softwire. 596 [RFC3193] discusses how L2TP can use IKE [RFC2409] and IPsec 597 [RFC2401] to provide tunnel authentication, privacy protection, 598 integrity checking and replay protection. Since its publication, the 599 revision to IPsec protocols have been published (IKEv2 [RFC4306], ESP 600 [RFC4303], NAT-traversal for IKE [RFC3947] and ESP[RFC3948]). 602 Given that deployed technology must be very strongly considered 603 [RFC4925] for the 'time-to-market' solution, [RFC3193] MUST be 604 supported. However, the new implementation SHOULD use IKEv2 605 [RFC4306] for IPsec because of the numerous advantages over IKE 606 [RFC2409]. In new deployments, IKEv2 SHOULD be used as well. 608 Although [RFC3193] can be applied in the softwire "Hubs and Spokes" 609 solution, softwire requirements such as NAT-traversal, NAT-traversal 610 for IKE [RFC3947] and ESP [RFC3948] MUST be supported. 612 Meanwhile, IKEv2 [RFC4306] integrates NAT-traversal. IKEv2 also 613 supports EAP authentication with the authentication using shared 614 secrets (pre-shared key) or public key signature (certificate). 616 The selection of pre-shared key and certificate depends on the scale 617 of the network for softwire to be deployed as described in Section 618 3.5.2. However, pre-shared key and certificates only support the 619 machine authentication. When both machine and user authentications 620 are required, for example, in the nomadic case, EAP SHOULD be used. 622 Together with EAP, IKEv2 [RFC4306] supports legacy authentication 623 methods that may be useful in environments where username and 624 password based authentication is already deployed. 626 IKEv2 is more reliable protocol than IKE [RFC2409]in terms of the 627 replay protection capability, DoS protection enabled mechanism etc. 628 Therefore, new implementations SHOULD use IKEv2 over IKE. 630 The following sections will discuss using IPsec to protect L2TPv2 as 631 applied in the softwire "Hubs and Spokes" model. Unless otherwise 632 stated, IKEv2 and the new IPsec architecture [RFC4301] is assumed. 634 3.5.1. Authentication Issues 636 IPsec implementation using IKE only supports machine authentication. 637 There is no way to verify a user identity and to segregate the tunnel 638 traffic among users in the multi-user machine environment. IKEv2 can 639 support user authentication with EAP payload by leveraging existing 640 authentication infrastructure and credential database. This enables 641 the traffic segregation among users when user authentication is used 642 by combining the legacy authentication. The user identity asserted 643 within IKEv2 will be verified on a per-packet basis. 645 If the AAA server is involved in security association establishment 646 between the SI and SC, a session key can be derived from the 647 authentication between the SI and the AAA server. Successful EAP 648 exchanges within IKEv2 runs between the SI and the AAA server create 649 a session key and it is securely transferred to the SC from the AAA 650 server. The trust relationship between the involved entities follows 651 Section 3.2 of this document. 653 3.5.2. IPsec Pre-Shared Keys for Authentication 655 With IPsec, when the identity asserted in IKE is authenticated, the 656 resulting derived keys are used to provide per-packet authentication, 657 integrity and replay protection. As a result, the identity verified 658 in the IKE is subsequently verified on reception of each packet. 660 Authentication using pre-shared keys can be used when the number of 661 SI and SC is small. As the number of SI and SC grows, pre-shared 662 keys becomes increasingly difficult to manage. A softwire security 663 protocol MUST provide a scalable approach to key management. 664 Whenever possible, authentication with certificates is preferred. 666 When pre-shared keys are used, group pre-shared keys MUST NOT be used 667 because of its vulnerability to Man-In-The-Middle attacks ([RFC3193], 668 5.1.4). 670 3.5.3. Inter-Operability Guidelines 672 The L2TPv2/IPsec inter-operability concerning tunnel teardown, 673 fragmentation and per-packet security checks given in ([RFC3193] 674 section 3) must be taken into account. 676 Although the L2TP specification allows the responder (SC in softwire) 677 to use a new IP address or to change the port number when sending the 678 Start-Control-Connection-Request-Reply (SCCRP), a softwire 679 concentrator implementation SHOULD NOT do this ([RFC3193] section 4). 681 However, with some reasons, for example, "load-balancing" between 682 SCs, the IP address change is required. To signal an IP address 683 change, the SC sends a StopCCN message to the SI using the Result and 684 Error Code AVP in L2TPv2 message. A new IKE_SA and CHILD_SA MUST be 685 established to the new IP address. 687 Since ESP transport mode is used, the UDP header carrying the L2TP 688 packet will have an incorrect checksum due to the change of parts of 689 the IP header during transit. [RFC3948] section 3.1.2 defines 3 690 procedures that can be used to fix the checksum. A softwire 691 implementation MUST NOT use the "incremental update of checksum" 692 (option 1 described in[RFC3948]), because the IKEv2 does not have the 693 information required (NAT-OA payload) to compute that checksum. 694 Since ESP is already providing validation on the L2TP packet, a 695 simple approach is to use the "do not check" approach (option 3 in 696 [RFC3948]). 698 3.5.4. IPsec Filtering Details 700 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 701 the security policy database (SPD) examples in [RFC3193] appendix A 702 can be applied to softwire model. In that case, the initiator is 703 always the client (SI), and responder is the SC. IPsec SPD examples 704 for IKE [RFC2409] are also given in appendix A of this document. 706 The revised IPsec architecture [RFC4301] redefined the SPD entries to 707 provide more flexibility (multiple selectors per entry, list of 708 address range, peer authentication database (PAD), "populate from 709 packet"(PFP) flag, etc.). The Internet Key Exchange (IKE) has also 710 been revised and simplified in IKEv2 [RFC4306]. The following 711 sections provides the SPD examples for softwire to use the revised 712 IPsec architecture and IKEv2. 714 3.5.4.1. IPv6 over IPv4 Softwire L2TPv2 example for IKEv2 716 If IKEv2 is used as the key management protocol, RFC4301 provides the 717 guidance of the SPD entries. In IKEv2, we can use PFP flag to 718 specify SA and the port number can be selected with Traffic Selector 719 with TSr during CREATE_CHILD_SA. The following describes PAD entries 720 on the SI and SC, respectively. The PAD entries are only example 721 configurations. The PAD entry on the SC matches user identities to 722 the L2TP SPD entry. This is done using a symbolic name type 723 specified in [RFC4301]. 725 SI PAD: 726 - IF remote_identity = SI_identity 727 Then authenticate (shared secret/certificate/) 728 and authorize CHILD_SA for remote address SC_address 730 SC PAD: 731 - IF remote_identity = user_1 732 Then authenticate (shared secret/certificate/EAP) 733 and authorize CHILD_SAs for symbolic name "l2tp_spd_entry" 735 The following describes the SPD entries for the SI and SC, 736 respectively. Note that IKEv2 and ESP traffic MUST be allowed 737 (bypass). These include IP protocol 50 and UDP port 500 and 4500. 739 The IPv4 packet format of ESP protecting L2TPv2 carrying IPv6 packet 740 is shown in Table 1 by using the similar Table in [RFC4891]. 742 +----------------------------+------------------------------------+ 743 | Components (first to last) | Contains | 744 +----------------------------+------------------------------------+ 745 | IPv4 header | (src = IPv4-SI, dst = IPv4-SC) | 746 | ESP header | | 747 | UDP header | (src port=1701, dst port=1701) | 748 | L2TPv2 header | | 749 | PPP header | | 750 | IPv6 header | | 751 | (payload) | | 752 | ESP ICV | | 753 +----------------------------+------------------------------------+ 755 Table 1: Packet Format for L2TPv2 with ESP carrying IPv6 packet. 757 SPD for Softwire Initiator: 759 Softwire Initiator SPD-S 760 - IF local_address=IPv4-SI 761 remote_address=IPv4-SC 762 Next Layer Protocol=UDP 763 local_port=1701 764 remote_port=ANY (PFP=1) 765 Then use SA ESP transport mode 766 Initiate using IDi = user_1 to address IPv4-SC 767 SPD for Softwire Concentrator: 769 Softwire Concentrator SPD-S 770 - IF name="l2tp_spd_entry" 771 local_address=IPv4-SC 772 remote_address=ANY (PFP=1) 773 Next Layer Protocol=UDP 774 local_port=1701 775 remote_port=ANY (PFP=1) 776 Then use SA ESP transport mode 778 3.5.4.2. IPv4 over IPv6 Softwire L2TPv2 example for IKEv2 780 The PAD entries for SI and SC are shown as examples. These example 781 configurations are similar to those in 3.3.4.1.[RFC4301] 782 SI PAD: 783 - IF remote_identity = SI_identity 784 Then authenticate (shared secret/certificate/) 785 and authorize CHILD_SA for remote address SC_address 787 SC PAD: 788 - IF remote_identity = user_2 789 Then authenticate (shared secret/certificate/EAP) 790 and authorize CHILD_SAs for symbolic name "l2tp_spd_entry" 792 The following describes the SPD entries for the SI and SC, 793 respectively. In this example, the SI and SC are denoted with IPv6 794 addresses IPv6-SI and IPv6-SC, respectively. Note that IKEv2 and ESP 795 traffic MUST be allowed (bypass). These include IP protocol 50 and 796 UDP port 500 and 4500. 798 The IPv6 packet format of ESP protecting L2TPv2 carrying IPv4 packet 799 is shown in Table 2 by using similar one in [RFC4891]. 801 +----------------------------+------------------------------------+ 802 | Components (first to last) | Contains | 803 +----------------------------+------------------------------------+ 804 | IPv6 header | (src = IPv6-SI, dst = IPv6-SC) | 805 | ESP header | | 806 | UDP header | (src port=1701, dst port=1701) | 807 | L2TPv2 header | | 808 | PPP header | | 809 | IPv4 header | | 810 | (payload) | | 811 | ESP ICV | | 812 +----------------------------+------------------------------------+ 814 Table 2: Packet Format for L2TPv2 with ESP carrying IPv4 packet. 816 SPD for Softwire Initiator: 818 Softwire Initiator SPD-S 819 - IF local_address=IPv6-SI 820 remote_address=IPv6-SC 821 Next Layer Protocol=UDP 822 local_port=1701 823 remote_port=ANY (PFP=1) 824 Then use SA ESP transport mode 825 Initiate using IDi = user_2 to address IPv6-SC 827 SPD for Softwire Concentrator: 829 Softwire Concentrator SPD-S 830 - IF name="l2tp_spd_entry" 831 local_address=IPv6-SC 832 remote_address=ANY (PFP=1) 833 Next Layer Protocol=UDP 834 local_port=1701 835 remote_port=ANY (PFP=1) 836 Then use SA ESP transport mode 838 4. Mesh Security Guidelines 840 4.1. Deployment Scenario 842 In the softwire "Mesh" solution[RFC4925], 843 [I-D.ietf-softwire-mesh-framework], it is required to establish 844 connectivity to access network islands of one address family type 845 across a transit core of a differing address family type. To provide 846 reachability across the transit core, AFBRs are installed between 847 access network island and transit core network. These AFBRs can 848 perform as Provider Edge routers (PE) within an autonomous system or 849 perform peering across autonomous systems. The AFBRs establish and 850 encapsulate softwires in a mesh to the other islands across the 851 transit core network. The transit core network consists of one or 852 more service providers. 854 In the softwire "Mesh" solution, a pair of PE routers (AFBRs) use BGP 855 to exchange routing information. AFBR nodes in the transit network 856 are Internal BGP speakers and will peer with each other directly or 857 via a route reflector to exchange SW-encap sets, perform softwire 858 signaling, and advertise AF access island reachability information 859 and SW-NHOP information. If such information is advertised within an 860 autonomous system, the AFBR node receiving them from other AFBRs does 861 not forward them to other AFBR nodes. To exchange the information 862 among AFBRs, the full mesh connectivity will be established. 864 The connectivity between CE and PE routers includes dedicated 865 physical circuits, logical circuits (such as Frame Relay and ATM), 866 and shared medium access (such as Ethernet-based access). 868 When AFBRs are PE routers located at the edge of the provider core 869 networks, this is similar architecture of the L3VPN described in 870 [RFC4364]. The connectivity between a CE router in access island 871 network and a PE router in transit network is established by static 872 way. The access islands are enterprise networks accommodated through 873 PE routers in the provider's transit network. In this case, the 874 access island networks are administrated by the provider's autonomous 875 system. 877 The AFBRs may have the multiple connections to the core network, and 878 also may have the connections to the multiple client access networks. 879 The client access networks may connect each other through private 880 networks or through the Internet. When the client access networks 881 have their own AS number, a CE router located inside access islands 882 forms a private BGP peering with an AFBR. Further, an AFBR may need 883 to exchange a full Internet routing information with each network to 884 which it connects. 886 4.2. Trust Relationship 888 All AFBR nodes in the transit core MUST have a trust relationship or 889 an agreement with each other to establish softwires. When the 890 transit core consists of a single administrative domain, it is 891 assumed that all nodes (e.g. AFBR, PE or Route Reflector, if 892 applicable) are trusted with each other. 894 If the transit core consists of multiple administrative domains, 895 intermediate routers between AFBRs may not be trusted. 897 There MUST be a trust relationship between the PE in the transit core 898 and the CE in the corresponding island, although the link(s) between 899 the PE and the CE may not be protected. 901 4.3. Softwire Security Threat Scenarios 903 As the architecture of softwire mesh solution is very similar to that 904 of the provider provisioned VPN (PPVPN). The security threats 905 considerations on the PPVPN operation are applicable to those in the 906 softwire mesh solution [RFC4111]. 908 Examples of attacks to data packets being transmitted on a softwire 909 tunnel include: 911 1. An adversary may try to discover confidential information by 912 sniffing softwire packets. 914 2. An adversary may try to modify the contents of softwire packets. 916 3. An adversary may try to spoof the softwire packets that do not 917 belong the authorized domains and to insert copies of once- 918 legitimate packets that have been recorded and replayed. 920 4. An adversary can launch Denial-of-Service (DoS) attack by 921 deleting softwire data traffic. DoS attacks of the resource 922 exhaustion type can be mounted against the data plane by spoofing 923 a large amount of non-authenticated data into the softwire from 924 the outside of the softwire tunnel. 926 5. An adversary may try to sniff softwire packets and to examine 927 aspects or meta-aspects of them that may be visible even when the 928 packets themselves are encrypted. An attacker might gain useful 929 information based on the amount and timing of traffic, packet 930 sizes, sources and destination addresses, etc. 932 The security attacks can be mounted on the control plane as well. In 933 softwire mesh solution, softwires encapsulation will be set up by 934 using BGP. As described in [RFC4272], BGP is vulnerable to various 935 security threats such as confidential violation, replay attacks, 936 insertion, deletion and modification of BGP messages, main-in-the- 937 middle, and denial-of-service. 939 4.4. Applicability of Security Protection Mechanism 941 Given that security is generally a compromise between expense and 942 risk, it is also useful to consider the likelihood of different 943 attacks. There is at least a perceived difference in the likelihood 944 of most types of attacks being successfully mounted in different 945 deployment. 947 The trust relationship among users in access networks, transit core 948 provider, and other parts of networks described in section 4.2 is a 949 key element in determining the applicability of security protection 950 mechanism for the specific softwire mesh deployment. 952 4.4.1. Security Protection Mechanism for Control Plane 954 The Softwire Problem Statement [RFC4925] states that the softwire 955 mesh setup mechanism to advertise the softwire encapsulation MUST 956 support authentication, but the transit core provider may decide to 957 turn it off in some circumstances. 959 The BGP authentication mechanism is specified in [RFC2385]. The 960 mechanism defined in [RFC2385] is based on a one-way hash function 961 (MD5) and use of a secret key. The key is shared between a pair of 962 peer routers and is used to generate 16-byte message authentication 963 code values that are not readily computed by an attacker who does not 964 have access to the key. 966 However the security mechanism for BGP transport (e.g. TCP-MD5) is 967 inadequate in some circumstances and also requires operator 968 interaction to maintain a respectable level of security. The current 969 deployments of TCP-MD5 exhibit some shortcomings with respect of key 970 management as described in [RFC3562]. 972 Key management can be especially cumbersome for operators. The 973 number of keys required and the maintenance of keys (issue/revoke/ 974 renew) has had an additive effect as a barrier to deployment. Thus 975 automated means of managing keys, to reduce operational burdens, is 976 available in BGP security system [I-D.ietf-rpsec-bgpsecrec], 977 [RFC4107]. 979 Use of IPsec counters the message insertion, deletion, and 980 modification attacks, as well as man-in-the-middle attacks by 981 outsiders. If routing data confidentiality is desired, the use of 982 IPsec ESP could provide that service. If eavesdropping attack is 983 identified as a threat, ESP can be used to provide confidentiality 984 (encryption), integrity and authentication for the BGP session. 986 4.4.2. Security Protection Mechanism for Data Plane 988 To transport data packets across the transit core, the mesh solution 989 defines multiple encapsulations: L2TPv3, IP-in-IP, MPLS (LDP-based 990 and RSVP-TE based), and GRE. To securely transport such data packet, 991 the softwire MUST support IPsec tunnel. 993 IPsec can provide authentication and integrity. The implementation 994 MUST support ESP with null encryption [RFC4303] or else AH (IP 995 Authentication Header) [RFC4302]. If some part of the transit core 996 network is not trusted, ESP with encryption MAY be applied. 998 Since the softwires are created dynamically by BGP, the automated key 999 distribution MUST be performed by IKEv2 [RFC4306] with either pre- 1000 shared key or public key management. For the dynamic softwire IPsec 1001 tunnel creation, pre-shared key will be same in all routers. Namely 1002 pre-shared key indicates here group key instead of pairwise shared 1003 key. 1005 If security policy requires a stronger key management, the public key 1006 SHOULD be used. If a public key infrastructure is not available, the 1007 IPsec Tunnel Authentication sub-TLV specified in 1008 [I-D.ietf-softwire-encaps-ipsec] MUST be used before SA is 1009 established. 1011 If the link(s) between the user's site and the provider's PE is not 1012 trusted, then encryption MAY be used on the PE-CE link(s). 1014 Together with the cryptographic security protection, the access 1015 control technique reduces the exposure to attacks from outside the 1016 service provider networks (transit networks). The access control 1017 technique includes packet-by-packet or packet flow-by-packet flow 1018 access control by means of filters as well as by means of admitting a 1019 session for a control/signaling/management protocol that is being 1020 used to implement softwire mesh. 1022 The access control technique is an important protection against 1023 security attacks of DoS etc. and a necessary adjunct to cryptographic 1024 strength in encapsulation. Packets that match the criteria 1025 associated with a particular filter may be either discarded or given 1026 special treatment to prevent an attack or to mitigate the effect of a 1027 possible future attack. 1029 5. Security Considerations 1031 This document discusses various security threats for the softwire 1032 control and data packets in "Hubs and Spokes" and "Mesh" time-to- 1033 market solutions. With these discussions, the softwire security 1034 protocol implementations are provided referencing to Softwire Problem 1035 Statement [RFC4925], Securing L2TP using IPsec [RFC3193], Security 1036 Framework for PPVPNs [RFC4111], and Guidelines for Mandating the Use 1037 of IPsec [RFC5406]. The guidelines for the security protocol 1038 employment are also given considering the specific deployment 1039 context. 1041 Note that this document discusses the softwire tunnel security 1042 protection and does not address the end-to-end protection. 1044 6. IANA Considerations 1046 This document creates no new requirements on IANA namespaces 1047 [RFC5226]. 1049 7. Acknowledgments 1051 The authors would like to thank Tero Kivinen for reviewing the 1052 document and Francis Dupont for substantive suggestions. 1053 Acknowledgments to Jordi Palet Martinez, Shin Miyakawa, Yasuhiro 1054 Shirasaki, and Bruno Stevant for their feedback. 1056 We would like also to thank the authors of Softwire Hub & Spoke 1057 Deployment Framework document for providing the text concerning 1058 security. 1060 8. References 1061 8.1. Normative References 1063 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1064 Protocol (CHAP)", RFC 1994, August 1996. 1066 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1067 Requirement Levels", BCP 14, RFC 2119, March 1997. 1069 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1070 Signature Option", RFC 2385, August 1998. 1072 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1073 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1074 RFC 2661, August 1999. 1076 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1077 "Securing L2TP using IPsec", RFC 3193, November 2001. 1079 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1080 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1081 January 2005. 1083 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1084 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1085 RFC 3948, January 2005. 1087 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1088 Key Management", BCP 107, RFC 4107, June 2005. 1090 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1091 Internet Protocol", RFC 4301, December 2005. 1093 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1094 December 2005. 1096 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1097 RFC 4303, December 2005. 1099 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1100 RFC 4306, December 2005. 1102 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1103 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1104 May 2008. 1106 8.2. Informative References 1108 [I-D.ietf-rpsec-bgpsecrec] 1109 Christian, B. and T. Tauber, "BGP Security Requirements", 1110 draft-ietf-rpsec-bgpsecrec-10 (work in progress), 1111 November 2008. 1113 [I-D.ietf-softwire-encaps-ipsec] 1114 Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel 1115 Encapsulation Attribute", 1116 draft-ietf-softwire-encaps-ipsec-03 (work in progress), 1117 April 2009. 1119 [I-D.ietf-softwire-hs-framework-l2tpv2] 1120 Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. 1121 Tremblay, "Softwire Hub & Spoke Deployment Framework with 1122 L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-12 (work 1123 in progress), March 2009. 1125 [I-D.ietf-softwire-mesh-framework] 1126 Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 1127 Framework", draft-ietf-softwire-mesh-framework-06 (work in 1128 progress), February 2009. 1130 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1131 Internet Protocol", RFC 2401, November 1998. 1133 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1134 (IKE)", RFC 2409, November 1998. 1136 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1137 Implementation in Roaming", RFC 2607, June 1999. 1139 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1140 Signature Option", RFC 3562, July 2003. 1142 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1143 and Network Access (PANA) Threat Analysis and Security 1144 Requirements", RFC 4016, March 2005. 1146 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1147 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1149 [RFC4111] Fang, L., "Security Framework for Provider-Provisioned 1150 Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. 1152 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1153 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1155 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1156 Nordmark, "Mobile IP Version 6 Route Optimization Security 1157 Design Background", RFC 4225, December 2005. 1159 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1160 RFC 4272, January 2006. 1162 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1163 Networks (VPNs)", RFC 4364, February 2006. 1165 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1166 Routing Protocols", RFC 4593, October 2006. 1168 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 1169 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 1170 RFC 4891, May 2007. 1172 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1173 Problem Statement", RFC 4925, July 2007. 1175 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1176 Authentication Protocol", RFC 5216, March 2008. 1178 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1179 Version 2", BCP 146, RFC 5406, February 2009. 1181 Appendix A. 1183 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 1184 the SPD examples in [RFC3193] is applicable to "Hub & Spokes" model. 1185 In this model, the initiator is always the client (SI) and the 1186 responder is the SC. 1188 A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE 1190 IPv4 addresses of the softwire initiator and concentrator are denoted 1191 by IPv4-SI and IPv4-SC, respectively. If NAT traversal is used in 1192 IKE, UDP source and destination ports are 4500. In this SPD entry, 1193 IKE refers to UDP port 500. * denotes wildcard and indicates ANY port 1194 or address. 1196 Local Remote Protocol Action 1197 ----- ------ -------- ------ 1198 IPV4-SI IPV4-SC ESP BYPASS 1199 IPV4-SI IPV4-SC IKE BYPASS 1200 IPv4-SI IPV4-SC UDP, src 1701, dst 1701 PROTECT(ESP, 1201 transport) 1202 IPv4-SC IPv4-SI UDP, src * , dst 1701 PROTECT(ESP, 1203 transport) 1205 Softwire initiator SPD 1207 Remote Local Protocol Action 1208 ------ ------ -------- ------ 1209 * IPV4-SC ESP BYPASS 1210 * IPV4-SC IKE BYPASS 1211 * IPV4-SC UDP, src * , dst 1701 PROTECT(ESP, 1212 transport) 1214 Softwire concentrator SPD 1216 A.2. IPv4 over IPv6 Softwire with example for IKE 1218 IPv6 addresses of the softwire initiator and concentrator are denoted 1219 by IPv6-SI and IPv6-SC, respectively. If NAT traversal is used in 1220 IKE, UDP source and destination ports are 4500. In this SPD entry, 1221 IKE refers to UDP port 500. * denotes wildcard and indicates ANY port 1222 or address. 1224 Local Remote Protocol Action 1225 ----- ------ -------- ------ 1226 IPV6-SI IPV6-SC ESP BYPASS 1227 IPV6-SI IPV6-SC IKE BYPASS 1228 IPv6-SI IPV6-SC UDP, src 1701, dst 1701 PROTECT(ESP, 1229 transport) 1230 IPv6-SC IPv6-SI UDP, src * , dst 1701 PROTECT(ESP, 1231 transport) 1233 Softwire initiator SPD 1235 Remote Local Protocol Action 1236 ------ ------ -------- ------ 1237 * IPV6-SC ESP BYPASS 1238 * IPV6-SC IKE BYPASS 1239 * IPV6-SC UDP, src * , dst 1701 PROTECT(ESP, 1240 transport) 1242 Softwire concentrator SPD 1244 Authors' Addresses 1246 Shu Yamamoto 1247 NICT/KDDI R&D Labs 1248 1-13-16 Hakusan, Bunkyo-ku 1249 Tokyo, 113-0001 1250 Japan 1252 Phone: +81-3-3868-6913 1253 Email: shu@nict.go.jp 1255 Carl Williams 1256 KDDI R&D Labs 1257 Palo Alto, CA 94301 1258 USA 1260 Phone: +1-650-279-5903 1261 Email: carlw@mcsr-labs.org 1263 Florent Parent 1264 Beon Solutions 1265 Quebec, QC 1266 Canada 1268 Email: Florent.Parent@beon.ca 1269 Hidetoshi Yokota 1270 KDDI R&D Labs 1271 2-1-15 Ohara 1272 Fujimino, Saitama 356-8502 1273 Japan 1275 Phone: +81-49-278-7894 1276 Email: yokota@kddilabs.jp