idnits 2.17.1 draft-ietf-softwire-security-requirements-07.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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 10, 2009) is 5525 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 (~~), 2 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: September 11, 2009 KDDI R&D Labs 6 F. Parent 7 Beon Solutions 8 H. Yokota 9 KDDI R&D Labs 10 March 10, 2009 12 Softwire Security Analysis and Requirements 13 draft-ietf-softwire-security-requirements-07 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 September 11, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . 18 77 4.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 18 78 4.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 19 79 4.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 20 80 4.4. Applicability of Security Protection Mechanism . . . . . . 20 81 4.4.1. Security Protection Mechanism for Control Plane . . . 21 82 4.4.2. Security Protection Mechanism for Data Plane . . . . . 21 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 89 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 25 90 A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE . . . 25 91 A.2. IPv4 over IPv6 Softwire with example for IKE . . . . . . . 26 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 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 exisiting 101 technology. The Softwire Working Group is focusing on the two 102 scenarios that emerged when discussing the traversal of networks 103 composed of differing address families. This document provides the 104 security guidelines for such two softwire solution spaces such as 105 "Hubs and Spokes" and "Mesh" scenarios . "Hubs and Spokes" and 106 "Mesh" problems are described in [RFC4925] Section 2 and Section 3, 107 respectively. The protocols selected for softwire connectivity 108 require the security consideration on more specific deployment 109 scenarios for each solution. 111 Layer Two Tunneling Protocol (L2TPv2) is selected as phase 1 protocol 112 to be deployed in the "Hubs and Spokes" solution space. If L2TPv2 is 113 used in the unprotected network, it will be vulnerable to various 114 security attacks and MUST be protected by appropriate security 115 protocol such as IPsec described in [RFC3193]. Note that other 116 adequate security mechanisms are applicable, the security protocol 117 for softwire is not necessarily mandated. This document provides the 118 implementation guidance and proper usage of IPsec as the security 119 protection mechanism by considering the security vulnerabilities in 120 "Hubs and Spokes" scenario. The new implementation SHOULD use IKEv2 121 in the key management protocol for IPsec because of more reliable 122 protocol and integration of required protocols in a sigle platform. 124 The softwire "Mesh" solution should support various levels of 125 security mechanism to protect the data packets from an attacker being 126 transmitted on a softwire tunnel from the access networks with one 127 address family across the transit core operating with different 128 address family [RFC4925]. The security mechanism for the control 129 plane is also required to be protected from control data 130 modification, spoofing attack, etc. In the "Mesh" solution, BGP is 131 used for distributing softwire routing information in the transit 132 core. As the security considerations for BGP is being discussed in 133 other working groups, this document provides general guidelines for 134 the deployment scenario being envisaged. 136 2. Terminology 137 2.1. Abbreviations 139 The terminology is based on the softwire problem statement document 140 [RFC4925]. 142 AF(i) - Address Family. IPv4 or IPv6. Notation used to indicate 143 that prefixes, a node or network only deal with a single IP AF. 145 AF(i,j) - Notation used to indicate that a node is dual-stack or that 146 a network is composed of dual-stack nodes. 148 Address Family Border Router (AFBR) -A dual-stack router that 149 interconnects two networks that use either the same or different 150 address families. An AFBR forms peering relationships with other 151 AFBRs, adjacent core routers and attached CE routers, perform 152 softwire discovery and signaling, advertises client ASF(i) 153 reachability information and encapsulates/decapsulates customer 154 packets in softwire transport headers. 156 Customer Edge (CE) - A router located inside AF access island that 157 peers with other CE routers within the access island network and with 158 one or more upstream AFBRs. 160 Customer Premise Equipment (CPE) - An equipment, host or router, 161 located at a subscriber's premises and connected with a carrier's 162 access network. 164 Provider Edge (PE) - A router located at the edge of transit core 165 network that interfaces with CE in access island. 167 Softwire Concentrator (SC) - The node terminating the softwire in the 168 service provider network. 170 Softwire Initiator (SI) - The node initiating the softwire within the 171 customer network. 173 Softwire Encapsulation Set (SW-Encap) - A softwire encapsulation set 174 contains tunnel header parameters, order of preference of the tunnel 175 header types and the expected payload types (e.g. IPv4) carried 176 inside the softwire. 178 Softwire Next_Hop (SW-NHOP) - This attribute accompanies client AF 179 reachability advertisements and is used to reference a softwire on 180 the ingress AFBR leading to the specific prefixes. It contains a 181 softwire identifier value and a softwire next_hop IP address denoted 182 as . Its existence in the presence of client 183 AF prefixes (in advertisements or entries in a routing table) infers 184 the use of softwire to reach that prefix. 186 2.2. Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 3. Hubs and Spokes Security Guidelines 194 3.1. Deployment Scenarios 196 To provide the security guidelines, the discussion of the possible 197 deployment scenario and the trust relationship in the network is 198 important. 200 The softwire initiator (SI) always resides in the customer network. 201 The node, in which the SI resides, can be the CPE access device, 202 another dedicated CPE router behind the original CPE access device or 203 any kind of host device such as PC, appliance, sensor etc. 205 However, the host device may not always have direct access to its 206 home carrier network, to which the user has subscribed. For example, 207 the SI in the laptop PC can access various access networks such as 208 Wi-Fi hot-spots, visited office network. This is the nomadic case, 209 which the softwire SHOULD support. 211 As the softwire deployment model, the following three cases as shown 212 in Figure 1 should be considered taking account of the nomadic case. 213 In order to securely connect legitimate SI and SC each other, the 214 authentication process between SI and SC is performed normally using 215 AAA servers. 217 visited network visited network 218 access provider service provider 219 +---------------------------------+ 220 | | 221 +......v......+ +.....................|......+ 222 . . . v . 223 +------+ . (case 3) . . +------+ +--------+ . 224 | |=====================.==| | | | . 225 | SI |__.________ . . | SC |<---->| AAAv | . 226 | |---------- \ . . | | | | . 227 +------+ . \\ . . +------+ +--------+ . 228 . \\ . . ^ . 229 ^ +..........\\.+ +.....................|......+ 230 | \\ | 231 | (case 2) \\ | 232 | \\ | 233 | \\ | 234 | +............+ \\ +.....................|......+ 235 . . \\. v . 236 +------+ . . \\__+------+ +--------+ . 237 | | . (case 1) . ---| | | | . 238 | SI |=====================.==| SC |<---->| AAAh | . 239 | | . . . | | | | . 240 +------+ . . . +------+ +--------+ . 241 . . . . 242 +............+ +............................+ 243 home network home network 244 access provider service provider 246 Figure 1: Hubs and Spokes model 248 The AAA server shown in Figure 1 interacts with the SC which acts as 249 an AAA client. The AAA may consists of multiple AAA servers and the 250 proxy AAA may be intermediate between the SC and the AAA servers. 251 This document refers to the AAA server in the home network service 252 provider as the home AAA server (AAAh) and that in the visited 253 network service provider as the visited AAA server (AAAv). 255 The softwire problem statement [RFC4925] states that the softwire 256 solution must be able to be integrated with common deployed AAA 257 solution. L2TPv2 used in softwire supports PPP and L2TP 258 authentications which can be integrated with common AAA servers. 260 When the softwire is used in an unprotected network, a stronger 261 authentication process is required (e.g., IKEv2). The proper 262 selection of the authentication processes is discussed in Section 3.4 263 with respect to the various security threats. 265 Case 1: The SI connects to the SC that belongs to the home network 266 service provider via the home access provider network operating 267 different address family. It is assumed that the home access network 268 and the home network providing SC are under the same administrative 269 system. 271 Note that the IP address of the host device, in which SI resides, is 272 static or dynamic depending on the subscribed service. The discovery 273 of the SC may be automatic. But in this document, the information on 274 the SC, e.g. the DNS name or IP address, is assumed to be configured 275 by the user or the provider of the SI in advance. 277 Case 2: The SI connects to the SC that belongs to the home network 278 service provider network via the visited access network. For the 279 nomadic case, the SI/user does not subscribe to the visited access 280 provider. For the network access through the public network such as 281 WiFi hot-spots, the home network service provider does not have the 282 trust relationship with the access network. 284 Note that the IP address of the host device, in which SI resides, may 285 be changed periodically due to the home network service provider's 286 policy. 288 Case 3: The SI connects to the SC that belongs to the visited network 289 service provider via the visited access network. This is typical of 290 nomadic access case. When the SI is mobile, it may roam from the 291 home ISP providing the home access network to the visited access 292 network, e.g. WiFi hot-spot network provided by the different ISP. 293 The SI does not connect to the SC in the home network, for example, 294 due to the geographical reason. The SI/user does not subscribe to 295 the visited network service provider, but the visited network service 296 provider has some roaming agreement with the home network service 297 provider. 299 Note that the IP address of the host, in which SI resides, is 300 provided the visited network service provider's policy. 302 3.2. Trust Relationship 304 The establishment of the trust relationship between SI and SC is 305 different for three cases. The security consideration must be taken 306 into account for each case. 308 In Case 1, the SC and the home AAA server in the same network service 309 provider MUST have a trust relationship and communications between 310 them MUST be secured. When the SC authenticates the SI, the SC 311 transmits the authentication request message to the home AAA server 312 and obtains the accept message together with the Attribute Value Pair 313 for the SI authentication. Since the SI in the service provider 314 network, the provider can take measures to protect the entities 315 (e.g., SC, AAA servers) against a number of security threats, 316 including the communication between them. 318 In Case 2, when the SI is mobile, the access to the home network 319 service provider through the visited access network provider is 320 allowed. The trust relationship between SI and the SC in the home 321 network must be established. When the visited access network is a 322 public network, the various security attacks must be considered. 323 Especially for SI to connect to the legitimate SC, the authentication 324 from SI to SC must be performed together with that from SC to SI. 326 In Case3, if the SI roams into a different network service provider's 327 administrative domain and the visited AAA server communicates with 328 the home AAA server to obtain the information for SI authentication. 329 The visited AAA server MUST have a trust relationship with the home 330 AAA server and the communication between them MUST be secured in 331 order to properly perform the roaming services that have been agreed 332 upon under specified conditions. 334 Note that the path for the communications between the home AAA server 335 and the visited AAA server may consist of several AAA proxies. In 336 this case, AAA proxy threat model should be considered.[RFC2607] A 337 malicious AAA proxy may launch passive or active security attacks. 338 The trustworthiness of proxies in AAA proxy chains will be weaken 339 when the hop counts of the proxy chain is longer. For example, the 340 accounting information exchanged among AAA proxies is attracive for 341 an adversary. The communication between a home AAA server and a 342 visited AAA server must be protected. 344 3.3. Softwire Security Threat Scenarios 346 Softwire can be used to connect IPv6 networks across public IPv4 347 networks and IPv4 networks across public IPv6 networks. The control 348 and data packets used during the softwire session are vulnerable to 349 the security attacks. 351 A complete threat analysis of softwire requires examination of the 352 protocols used for the softwire setup, the encapsulation method used 353 to transport the payload, and other protocols used for configuration 354 (e.g., router advertisements, DHCP). 356 The softwire solution uses a subset of the Layer Two Tunneling 357 Protocol (L2TPv2) functionality [RFC2661], [I-D.ietf-softwire-hs- 358 framework-l2tpv2]. In the softwire "Hubs and Spokes" model, L2TPv2 359 is used in a voluntary tunnel model only. The SI acts as a L2TP 360 Access Concentrator (LAC) and PPP endpoint. The L2TPv2 tunnel is 361 always initiated from the SI. 363 Generic threat analysis done for L2TP using IPsec [RFC3193] is 364 applicable to softwire "Hubs and Spokes" deployment. The threat 365 analysis for other protocols such as PANA [RFC4016], NSIS [RFC4081], 366 and Routing Protocols [RFC4593] are applicable here as well and 367 should be used as reference. 369 First, the SI resided in the customer network sends Start-Control- 370 Connection-Request(SCCRQ) packet to the SC for the initiation of the 371 softwire. L2TPv2 offers an optional CHAP-like tunnel authentication 372 system during control connection establishment. This requires a 373 shared secret between the SI and SC and no key management is offered 374 for this L2TPv2. 376 When L2TPv2 control connection is established, the SI and SC 377 optionally enter authentication phase after completing PPP Link 378 Control Protocol (LCP) negotiation. PPP authentication supports one 379 way or two way CHAP authentication, and can leverage existing AAA 380 infrastructure. PPP authentication does not provide per-packet 381 authentication. 383 PPP encryption is defined but PPP Encryption Control Protocol (ECP) 384 negotiation does not provide for a protected cipher suite 385 negotiation. PPP encryption provides a weak security solution 386 [RFC3193]. PPP ECP implementation cannot be expected. PPP 387 authentication also does not provide the scalable key management. 389 Once the L2TPv2 tunnel and PPP configuration are successfully 390 established, the SI is connected and can start using the connection. 392 These steps are vulnerable to man-in-the-middle (MITM), denial of 393 service (DoS), and service theft attacks, which are caused as the 394 consequence of the following adversary actions. 396 Adversary attacks on softwire include: 398 1. An adversary may try to discover identities by snooping data 399 packets. 401 2. An adversary may try to modify both control and data packets. 402 This type of attack involves integrity violations. 404 3. An adversary may try to eavesdrop and collect control messages. 405 By replaying these messages, an adversary may successfully hijack 406 the L2TP tunnel or the PPP connection inside the tunnel. An 407 adversary might mount MITM, DOS, and theft of service attacks. 409 4. An adversary can flood the softwire node with bogus signaling 410 messages to cause DoS attacks by terminating L2TP tunnels or PPP 411 connections. 413 5. An adversary may attempt to disrupt the softwire negotiation in 414 order to weaken or remove confidentiality protection. 416 6. An adversary may wish to disrupt the PPP LCP authentication 417 negotiation. 419 In environments where the link is shared without the cryptographic 420 protection and the weak authentication or one-way authentication is 421 used, these security attacks can be mounted on softwire control and 422 data packets. 424 When there is no prior trust relationship between the SI and SC, any 425 node can pretend to be a SC. In this case, an adversary may 426 impersonate the SC to intercept traffic (e.g. "rogue" softwire 427 concentrator). 429 The rogue SC can introduce a dinial of service attack by blackholing 430 packets from the SI. The rogue SC can also eavesdrop on all packets 431 sent from or to the SI. Security threats of a rogue SC are similar 432 to a compromisd router. 434 The deployment of ingress filtering is able to control the malicious 435 users' access.[RFC4213] Without specific ingress filtering checks in 436 the decapsulator at the SC, it would be possible for an attacker to 437 inject a false packet. This causes DoS attack. The inner address 438 ingress filtering can reject invalid inner source address. Without 439 inner address ingress filtering, another kind of attack can happen. 440 The malicious users from another ISP could start using its tunneling 441 infrastructure to get free inner address connectivity, transforming 442 effectively the ISP into an inner address transit provider. 444 While the ingress filtering does not provide the complete protection 445 in the case an address spoofing has been happened. To protect 446 address spoofing, authentication MUST be implemented in the tunnel 447 encapsulation. 449 3.4. Softwire Security Guidelines 451 Based on the security threat analysis in Section 3.3 in this 452 document, the softwire security protocol must support the following 453 protections. 455 1. Softwire control messages between the SI and SC MUST BE protected 456 against eavesdropping and spoofing attacks. 458 2. Softwire security protocol MUST be able to protect itself against 459 replay attacks. 461 3. Softwire security protocol MUST be able to protect the device 462 identifier against the impersonation when it is exchanged between 463 the SI and the SC. 465 4. Softwire security protocol MUST be able to securely bind the 466 authenticated session to the device identifier of the client, to 467 prevent service theft. 469 5. Softwire security protocol MUST be able to protect disconnect and 470 revocation messages. 472 The softwire security protocol requirement is comparable to 473 [RFC3193]. 475 For softwire control packets, authentication, integrity and replay 476 protection MUST be supported and confidentiality SHOULD be supported. 478 For softwire data packets, authentication, integrity and replay 479 protection MUST be supported and confidentiality MAY be supported. 481 The softwire problem statement [RFC4925] provides some requirements 482 for "Hubs and Spoke" solution that are taken into account in defining 483 the security protection mechanisms. 485 1. Control and/or data plane must be able to provide full payload 486 security when desired. 488 2. Deployed technology must be very strongly considered. 490 This additional security protection must be separable from the 491 softwire tunneling mechanism. 493 Note that the scope of the security is on the L2TP tunnel between the 494 SI and SC. If end-to-end security is required, a security protocol 495 should be used in the payload packets. But this is out of scope of 496 this document. 498 3.4.1. Authentication 500 The softwire security protocol MUST support user authentication in 501 the control plane, in order to authorize access to the service, and 502 provide adequate logging of activity. Although several 503 authentication protocols are available, the security threats must be 504 considered to choose the protocol. 506 For example, the SI/user using Password Authentication Protocol (PAP) 507 access to the SC with the cleartext password. In many circumstances, 508 this represents a large security risk. The adversary may spoof as a 509 legitimate user by using the stolen password. Challenge Handshake 510 Authentication Protocol (CHAP) [RFC1994] encrypts a password with 511 "challenge" sent from the SC. The theft of password can be 512 mitigated. However, as CHAP only supports unidirectional 513 authentication, the risk of a man-in-the-middle or rogue SC cannot be 514 avoided. Extensible Authentication Protocol-Transport Layer Security 515 (EAP-TLS) [RFC5216] mandates mutual authentication and avoid the 516 rogue SC. 518 When the SI established a connection to the SC through a public 519 network, the SI may want to a proof of the SC identity. Softwire 520 MUST support mutual authentication to allow for such scenario. 522 In some circumstances, however, the service provider may decide to 523 allow non-authenticated connection 524 [I-D.ietf-softwire-hs-framework-l2tpv2]. For example, when the 525 customer is already authenticated by some other means, such as closed 526 networks, cellular networks at Layer 2, etc., the service provider 527 may decide to turn authentication off. If no authentication is 528 conducted on any layer, the SC acts as a gateway for anonymous 529 connections. Running such a service MUST be configurable by the SC 530 administrator and the SC SHOULD take some security measures such as 531 ingress filtering and adequate logging of activity. It should be 532 noted that anonymous connection service cannot provide the security 533 functionalities described in this document (e.g. integrity, replay 534 protection and confidentiality). 536 L2TPv2 selected as Softwire phase 1 protocol supports PPP 537 authentication and L2TPv2 authentication. PPP authentication and 538 L2TPv2 have various security threats as stated in Section 3.3. They 539 will be used in the limited condition as described in the next 540 subsections. 542 3.4.1.1. PPP Authentication 544 PPP can provide mutual authentication between the SI and SC using 545 CHAP [RFC1994] during the connection establishment phase (Link 546 Control Protocol, LCP). PPP CHAP authentication can be used when the 547 SI and SC are on a trusted, non-public IP network. 549 Since CHAP does not provide per-packet authentication, integrity, or 550 replay protection, PPP CHAP authentication MUST NOT be used for 551 unprotected on a public IP network. If other appropriate protected 552 mechanism has been already applied, PPP CHAP authentication may be 553 used. 555 Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY 556 be supported. 558 3.4.1.2. L2TPv2 Authentication 560 L2TPv2 provides an optional CHAP-like tunnel authentication during 561 the control connection establishment [RFC2661, 5.1.1]. L2TPv2 562 authentication MUST NOT be used for unprotected on a public IP 563 network as the same restriction applied to PPP CHAP. 565 3.4.2. Softwire Security Protocol 567 To meet the above requirements, all softwire security compliant 568 implementations MUST implement the following security protocols. 570 IPsec ESP [RFC4303] in transport mode is used for securing softwire 571 control and data packets. Internet Key Exchange (IKE) 572 protocol[RFC4306] MUST be supported for authentication, security 573 association negotiation and key management for IPsec. The 574 applicability of different version of IKE is discussed in Section 575 3.5. 577 The softwire security protocol MUST support NAT traversal. UDP 578 encapsulation of IPsec ESP packets[RFC3948] and negotiation of NAT- 579 traversal in IKE[RFC3947] MUST be supported when IPsec is used. 581 3.5. Guidelines for Usage of IPsec in Softwire 583 When softwire "Hubs and Spokes" solution implemented by L2TPv2 is 584 used in untrustworthy network, softwire MUST be protected by 585 appropriate security protocol such as IPsec. This section provides 586 guidelines for the usage of IPsec in L2TPv2 based softwire. 588 [RFC3193] discusses how L2TP can use IPsec to provide tunnel 589 authentication, privacy protection, integrity checking and replay 590 protection. Since its publication, the revision to IPsec protocols 591 have been published (IKEv2 [RFC4306], ESP [RFC4303], NAT-traversal 592 for IKE [RFC3947] and ESP[RFC3948]). 594 Although [RFC3193] can be applied in the softwire "Hubs and Spokes" 595 solution, softwire requirements such as NAT-traversal, NAT-traversal 596 for IKE [RFC3947] and ESP [RFC3948] MUST be supported. 598 IKEv2 [RFC4306] integrates NAT-traversal. IKEv2 also supports EAP 599 authentication with the authentication using shared secrets (pre- 600 shared key) or public key signature (certificate). The selection of 601 pre-shared key and certificate depends on the scale of the network 602 for softwire to be deployed as described in Section 3.5.2. However, 603 pre-shared key and certificates only support the machine 604 authentication. When both machine and user authentications are 605 required, for example, in the nomadic case, EAP should be used. 607 Together with EAP, IKEv2 [RFC4306]supports legacy authentication 608 methods that may be useful in environments where username and 609 password based authentication is already deployed. 611 IKEv2 is more reliable protocol than IKE [RFC2409]in terms of the 612 replay protection capability, DoS protection enabled mechanism etc. 613 Therefore, new implementations SHOULD use IKEv2 over IKE. 615 The following sections will discuss using IPsec to protect L2TPv2 as 616 applied in the softwire "Hubs and Spokes" model. Unless otherwise 617 stated, IKEv2 and the new IPsec architecture [RFC4301] is assumed. 619 3.5.1. Authentication Issues 621 IPsec implementation using IKE only supports machine authentication. 622 There is no way to verify a user identity and to segregate the tunnel 623 traffic among users in the multi-user machine environment. IKEv2 can 624 support user authentication with EAP payload by leveraging existing 625 authentication infrastructure and credential database. This enables 626 the traffic segregation among users when user authentication is used 627 by combining the legacy authentication. The user identity asserted 628 within IKEv2 will be verified on a per-packet basis. 630 If the AAA server is involved in security association establishment 631 between the SI and SC, a session key can be derived from the 632 authentication between the SI and the AAA server. Successful EAP 633 exchanges within IKEv2 runs between the SI and the AAA server create 634 a session key and it is securely transferred to the SC from the AAA 635 server. The trust relationship between the involved entities follows 636 Section 3.2 of this document. 638 3.5.2. IPsec Pre-Shared Keys for Authentication 640 With IPsec, when the identity asserted in IKE is authenticated, the 641 resulting derived keys are used to provide per-packet authentication, 642 integrity and replay protection. As a result, the identity verified 643 in the IKE is subsequently verified on reception of each packet. 645 Authentication using pre-shared keys can be used when the number of 646 SI and SC is small. As the number of SI and SC grows, pre-shared 647 keys becomes increasingly difficult to manage. A softwire security 648 protocol must provide a scalable approach to key management. 649 Whenever possible, authentication with certificates is preferred. 651 When pre-shared keys are used, group pre-shared keys MUST NOT be used 652 because of its vulnerability to Man-In-The-Middle attacks ([RFC3193], 653 5.1.4). 655 3.5.3. Inter-Operability Guidelines 657 The L2TPv2/IPsec inter-operability concerning tunnel teardown, 658 fragmentation and per-packet security checks given in ([RFC3193] 659 section 3) must be taken into account. 661 Although the L2TP specification allows the responder (SC in softwire) 662 to use a new IP address or to change the port number when sending the 663 Start-Control-Connection-Request-Reply (SCCRP), a softwire 664 concentrator implementation SHOULD NOT do this ([RFC3193] section 4). 666 However, with some reasons, for example, "load-balancing" between 667 SCs, the IP address change is required. To signal an IP address 668 change, the SC sends a StopCCN message to the SI using the Result and 669 Error Code AVP in L2TPv2 message. A new IKE_SA and CHILD_SA must be 670 established to the new IP address. 672 Since ESP transport mode is used, the UDP header carrying the L2TP 673 packet will have an incorrect checksum due to the change of parts of 674 the IP header during transit. [RFC3948] section 3.1.2 defines 3 675 procedures that can be used to fix the checksum. A softwire 676 implementation MUST NOT use the "incremental update of checksum" 677 (option 1 described in[RFC3948]), because the IKEv2 does not have the 678 information required (NAT-OA payload) to compute that checksum. 679 Since ESP is already providing validation on the L2TP packet, a 680 simple approach is to use the "do not check" approach (option 3 in 681 [RFC3948]). 683 3.5.4. IPsec Filtering Details 685 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 686 the security policy database (SPD) examples in [RFC3193] appendix A 687 can be applied to softwire model. In that case, the initiator is 688 always the client (SI), and responder is the SC. IPsec SPD examples 689 for IKE [RFC2409] are also given in appendix A of this document. 691 The revised IPsec architecture [RFC4301] redefined the SPD entries to 692 provide more flexibility (multiple selectors per entry, list of 693 address range, peer authentication database (PAD), "populate from 694 packet"(PFP) flag, etc.). The Internet Key Exchange (IKE) has also 695 been revised and simplified in IKEv2 [RFC4306]. The following 696 sections provides the SPD examples for softwire to use the revised 697 IPsec architecture and IKEv2. 699 3.5.4.1. IPv6 over IPv4 Softwire L2TPv2 example for IKEv2 701 If IKEv2 is used as the key management protocol, RFC4301 provides the 702 guidance of the SPD entries. In IKEv2, we can use PFP flag to 703 specify SA and the port number can be selected with Traffic Selector 704 with TSr during CREATE_CHILD_SA. The following describes PAD entries 705 on the SI and SC, respectively. The PAD entries are only example 706 configurations. The PAD entry on the SC matches user identities to 707 the L2TP SPD entry. This is done using a symbolic name. 709 SI PAD: 710 - IF remote_identity = SI_identity 711 Then authenticate (shared secret/certificate/) 712 and authorize CHILD_SA for remote address SC_address 714 SC PAD: 715 - IF remote_identity = user_1 716 Then authenticate (shared secret/certificate/EAP) 717 and authorize CHILD_SAs for symbolic name "l2tp_spd_entry" 719 The following describes the SPD entries for the SI and SC, 720 respectively. Note that IKEv2 and ESP traffic MUST be allowed 721 (bypass). These include IP protocol 50 and UDP port 500 and 4500. 723 The IPv4 packet format of ESP protecting L2TPv2 carrying IPv6 packet 724 is shown in Table 1 by using the similar Table in [RFC4891]. 726 +----------------------------+------------------------------------+ 727 | Components (first to last) | Contains | 728 +----------------------------+------------------------------------+ 729 | IPv4 header | (src = IPv4-SI, dst = IPv4-SC) | 730 | ESP header | | 731 | UDP header | (src port=1701, dst port=1701) | 732 | L2TPv2 header | | 733 | PPP header | | 734 | IPv6 header | | 735 | (payload) | | 736 | ESP ICV | | 737 +----------------------------+------------------------------------+ 739 Table 1: Packet Format for L2TPv2 with ESP carrying IPv6 packet. 741 SPD for Softwire Initiator: 743 Softwire Initiator SPD-S 744 - IF local_address=IPv4-SI 745 remote_address=IPv4-SC 746 Next Layer Protocol=UDP 747 local_port=1701 748 remote_port=ANY (PFP=1) 749 Then use SA ESP transport mode 750 Initiate using IDi = user_1 to address IPv4-SC 751 SPD for Softwire Concentrator: 753 Softwire Concentrator SPD-S 754 - IF name="l2tp_spd_entry" 755 local_address=IPv4-SC 756 remote_address=ANY (PFP=1) 757 Next Layer Protocol=UDP 758 local_port=1701 759 remote_port=ANY (PFP=1) 760 Then use SA ESP transport mode 762 3.5.4.2. IPv4 over IPv6 Softwire L2TPv2 example for IKEv2 764 The PAD entries are only example configurations. The PAD entries 765 specify that the IP address in the traffic selector payload 766 (SC_address and SI_address) is used for matching against the SPD. 768 SI PAD: 769 - IF remote_identity = SI_identity 770 Then authenticate (shared secret/certificate/) 771 and authorize CHILD_SA for remote address SC_address 773 SC PAD: 774 - IF remote_identity = user_2 775 Then authenticate (shared secret/certificate/EAP) 776 and authorize CHILD_SAs for remote address SI_address 778 The following describes the SPD entries for the SI and SC, 779 respectively. In this example, the SI and SC are denoted with IPv6 780 addresses IPv6-SI and IPv6-SC, respectively. Note that IKEv2 and ESP 781 traffic MUST be allowed (bypass). These include IP protocol 50 and 782 UDP port 500 and 4500. 784 The IPv6 packet format of ESP protecting L2TPv2 carrying IPv4 packet 785 is shown in Table 2 by using similar one in [RFC4891]. 787 +----------------------------+------------------------------------+ 788 | Components (first to last) | Contains | 789 +----------------------------+------------------------------------+ 790 | IPv6 header | (src = IPv6-SI, dst = IPv6-SC) | 791 | ESP header | | 792 | UDP header | (src port=1701, dst port=1701) | 793 | L2TPv2 header | | 794 | PPP header | | 795 | IPv4 header | | 796 | (payload) | | 797 | ESP ICV | | 798 +----------------------------+------------------------------------+ 800 Table 2: Packet Format for L2TPv2 with ESP carrying IPv4 packet. 802 SPD for Softwire Initiator: 804 Softwire Initiator SPD-S 805 - IF local_address=IPv6-SI 806 remote_address=IPv6-SC 807 Next Layer Protocol=UDP 808 local_port=1701 809 remote_port=ANY (PFP=1) 810 Then use SA ESP transport mode 811 Initiate using IDi = user_2 to address IPv6-SC 813 SPD for Softwire Concentrator: 815 Softwire Concentrator SPD-S 816 - IF local_address=IPv6-SC 817 remote_address=ANY (PFP=1) 818 Next Layer Protocol=UDP 819 local_port=1701 820 remote_port=ANY (PFP=1) 821 Then use SA ESP transport mode 823 4. Mesh Security Guidelines 825 4.1. Deployment Scenario 827 In the softwire "Mesh" solution[RFC4925], 828 [I-D.ietf-softwire-mesh-framework], it is required to establish 829 connectivity to access network islands of one address family type 830 across a transit core of a differing address family type. To provide 831 reachability across the transit core, AFBRs are installed between 832 access network island and transit core network. These AFBRs can 833 perform as Provider Edge routers (PE) within an autonomous system or 834 perform peering across autonomous systems. The AFBRs establish and 835 encapsulate softwires in a mesh to the other islands across the 836 transit core network. The transit core network consists of one or 837 more service providers. 839 In the softwire "Mesh" solution, a pair of PE routers (AFBRs) use BGP 840 to exchange routing information. AFBR nodes in the transit network 841 are Internal BGP speakers and will peer with each other directly or 842 via a route reflector to exchange SW-encap sets, perform softwire 843 signaling, and advertise AF access island reachability information 844 and SW-NHOP information. If such information is advertised within an 845 autonomous system, the AFBR node receiving them from other AFBRs does 846 not forward them to other AFBR nodes. To exchange the information 847 among AFBRs, the full mesh connectivity will be established. 849 The connectivity between CE and PE routers includes dedicated 850 physical circuits, logical circuits (such as Frame Relay and ATM), 851 and shared medium access (such as Ethernet-based access). 853 When AFBRs are PE routers located at the edge of the provider core 854 networks, this is similar architecture of the L3VPN described in 855 [RFC4364]. The connectivity between a CE router in access island 856 network and a PE router in transit network is established by static 857 way. The access islands are enterprise networks accommodated through 858 PE routers in the provider's transit network. In this case, the 859 access island networks are administrated by the provider's autonomous 860 system. 862 The AFBRs may have the multiple connections to the core network, and 863 also may have the connections to the multiple client access networks. 864 The client access networks may connect each other through private 865 networks or through the Internet. When the client access networks 866 have their own AS number, a CE router located inside access islands 867 forms a private BGP peering with an AFBR. Further, an AFBR may need 868 to exchange a full Internet routing information with each network to 869 which it connects. 871 4.2. Trust Relationship 873 All AFBR nodes in the transit core MUST have a trust relationship or 874 an agreement with each other to establish softwires. When the 875 transit core consists of a single administrative domain, it is 876 assumed that all nodes (e.g. AFBR, PE or Route Reflector, if 877 applicable) are trusted with each other. 879 If the transit core consists of multiple administrative domains, 880 intermediate routers between AFBRs may not be trusted. 882 There MUST be a trust relationship between the PE in the transit core 883 and the CE in the corresponding island, although the link(s) between 884 the PE and the CE may not be protected. 886 4.3. Softwire Security Threat Scenarios 888 AS the architecture of softwire mesh solution is very similar to that 889 of the provider provisioned VPN (PPVPN). The security threats 890 considerations on the PPVPN operation are applicable to those in the 891 softwire mesh solution [RFC4111]. 893 Examples of attacks to data packets being transmitted on a softwire 894 tunnel include: 896 1. An adversary may try to discover confidential information by 897 sniffing softwire packets. 899 2. An adversary may try to modify the contents of softwire packets. 901 3. An adversary may try to spoof the softwire packets that do not 902 belong the authorized domains and to insert copies of once- 903 legitimate packets that have been recorded and replayed. 905 4. An adversary can launch Denial-of-Service (DoS) attack by 906 deleting softwire data traffic. DoS attacks of the resource 907 exhaustion type can be mounted against the data plane by spoofing 908 a large amount of non-authenticated data into the softwire from 909 the outside of the softwire tunnel. 911 5. An adversary may try to sniff softwire packets and to examine 912 aspects or meta-aspects of them that may be visible even when the 913 packets themselves are encrypted. An attacker might gain useful 914 information based on the amount and timing of traffic, packet 915 sizes, sources and destination addresses, etc. 917 The security attacks can be mounted on the control plane as well. In 918 softwire mesh solution, softwires encapsulation will be setup by 919 using BGP. As described in [RFC4272], BGP is vulnerable to various 920 security threats such as confidential violation, replay attacks, 921 insertion, deletion and modification of BGP messages, main-in-the- 922 middle, and denial-of-service. 924 4.4. Applicability of Security Protection Mechanism 926 Given that security is generally a compromise between expense and 927 risk, it is also useful to consider the likelihood of different 928 attacks. There is at least a perceived difference in the likelihood 929 of most types of attacks being successfully mounted in different 930 deployment. 932 The trust relationship among users in access networks, transit core 933 provider, and other parts of networks described in section 4.2 is a 934 key element in determining the applicability of security protection 935 mechanism for the specific softwire mesh deployment. 937 4.4.1. Security Protection Mechanism for Control Plane 939 The Softwire Problem Statement [RFC4925] states that the softwire 940 mesh setup mechanism to advertise the softwire encapsulation MUST 941 support authentication, but the transit core provider may decide to 942 turn it off in some circumstances. 944 The BGP authentication mechanism is specified in [RFC2385]. The 945 mechanism defined in [RFC2385] is based on a one-way hash function 946 (MD5) and use of a secret key. The key is shared between a pair of 947 peer routers and is used to generate 16-byte message authentication 948 code values that are not readily computed by an attacker who does not 949 have access to the key. 951 However the security mechanism for BGP transport (e.g. TCP-MD5) is 952 inadequate in some circumstances and also requires operator 953 interaction to maintain a respectable level of security. The current 954 deployments of TCP-MD5 exhibit some shortcomings with respect of key 955 management as described in [RFC3562]. 957 Key management can be especially cumbersome for operators. The 958 number of keys required and the maintenance of keys (issue/revoke/ 959 renew) has had an additive effect as a barrier to deployment. Thus 960 automated means of managing keys, to reduce operational burdens, is 961 available in BGP security system [I-D.ietf-rpsec-bgpsecrec], 962 [RFC4107]. 964 Use of IPsec counters the message insertion, deletion, and 965 modification attacks, as well as man-in-the-middle attacks by 966 outsiders. If routing data confidentiality is desired, the use of 967 IPsec ESP could provide that service. If eavesdropping attack is 968 identified as a threat, ESP can be used to provide confidentiality 969 (encryption), integrity and authentication for the BGP session. 971 4.4.2. Security Protection Mechanism for Data Plane 973 To transport data packets across the transit core, the mesh solution 974 defines multiple encapsulations: L2TPv3, IP-in-IP, MPLS (LDP-based 975 and RSVP-TE based), and GRE. To securely transport such data packet, 976 the softwire must support IPsec tunnel. 978 IPsec can provide authentication and integrity. The implementation 979 MUST support ESP with null encryption RFC4303. If some part of the 980 transit core network is not trusted, ESP with encryption may be 981 applied. 983 The automated key distribution can be performed by IKE with the pre- 984 shared key management. But the implementation of IPsec with 985 automatic key management depends on the operational requirements, for 986 example, the scalability requirement, etc. 988 To provide replay protection, automated key management system using 989 IKEv2 can be used. IKEv2 can be applied using shared secrets for 990 authentication when the number of BGP peers is small. When the 991 number of BGP peers is large, managing the shared secrets on all 992 peers does not scale. In this scenario, public-key digital signature 993 or key encryption authentication in IKE SHOULD be used. 995 If the link(s) between the user's site and the provider's PE is not 996 trusted, then encryption may be used on the PE-CE link(s). 998 Together with the cryptographic security protection, the access 999 control technique reduces the exposure to attacks from outside the 1000 service provider networks (transit networks). The access control 1001 technique includes packet-by-packet or packet flow-by-packet flow 1002 access control by means of filters as well as by means of admitting a 1003 session for a control/signaling/management protocol that is being 1004 used to implement softwire mesh. 1006 The access control technique is an important protection against 1007 security attacks of DoS etc. and a necessary adjunct to cryptographic 1008 strength in encapsulation. Packets that match the criteria 1009 associated with a particular filter may be either discarded or given 1010 special treatment to prevent an attack or to mitigate the effect of a 1011 possible future attack. 1013 5. Security Considerations 1015 This document discusses various security threats for the softwire 1016 control and data packets in "Hubs and Spokes" and "Mesh" time-to- 1017 market solutions. With these discussions, the softwire security 1018 protocol implementations are provided referencing to Softwire Problem 1019 Statement [RFC4925], Securing L2TP using IPsec [RFC3193], Security 1020 Framework for PPVPNs [RFC4111], and Guidelines for Mandating the Use 1021 of IPsec [RFC5406]. The guidelines for the security protocol 1022 employment are also given considering the specific deployment 1023 context. 1025 Note that this document discusses the softwire tunnel security 1026 protection and does not address the end-to-end protection. 1028 6. IANA Considerations 1030 This document creates no new requirements on IANA namespaces 1031 [RFC5226]. 1033 7. Acknowledgments 1035 The authors would like to thank Tero Kivinen for reviewing the 1036 document and Francis Dupont for substative suggestions. 1037 Acknowledgments to Jordi Palet Martinez, Shin Miyakawa, Yasuhiro 1038 Shirasaki, and Bruno Stevant for their feedback. 1040 We would like also to thank the authors of Softwire Hub & Spoke 1041 Deployment Framework document for providing the text concerning 1042 security. 1044 8. References 1046 8.1. Normative References 1048 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1049 Protocol (CHAP)", RFC 1994, August 1996. 1051 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1052 Requirement Levels", BCP 14, RFC 2119, March 1997. 1054 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1055 Signature Option", RFC 2385, August 1998. 1057 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1058 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1059 RFC 2661, August 1999. 1061 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1062 "Securing L2TP using IPsec", RFC 3193, November 2001. 1064 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1065 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1066 January 2005. 1068 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1069 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1070 RFC 3948, January 2005. 1072 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1073 Key Management", BCP 107, RFC 4107, June 2005. 1075 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1076 Internet Protocol", RFC 4301, December 2005. 1078 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1079 RFC 4303, December 2005. 1081 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1082 RFC 4306, December 2005. 1084 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1085 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1086 May 2008. 1088 8.2. Informative References 1090 [I-D.ietf-rpsec-bgpsecrec] 1091 Christian, B. and T. Tauber, "BGP Security Requirements", 1092 draft-ietf-rpsec-bgpsecrec-10 (work in progress), 1093 November 2008. 1095 [I-D.ietf-softwire-hs-framework-l2tpv2] 1096 Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. 1097 Tremblay, "Softwire Hub & Spoke Deployment Framework with 1098 L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-12 (work 1099 in progress), March 2009. 1101 [I-D.ietf-softwire-mesh-framework] 1102 Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 1103 Framework", draft-ietf-softwire-mesh-framework-06 (work in 1104 progress), February 2009. 1106 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1107 Internet Protocol", RFC 2401, November 1998. 1109 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1110 (IKE)", RFC 2409, November 1998. 1112 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1113 Implementation in Roaming", RFC 2607, June 1999. 1115 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1116 Signature Option", RFC 3562, July 2003. 1118 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1119 and Network Access (PANA) Threat Analysis and Security 1120 Requirements", RFC 4016, March 2005. 1122 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1123 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1125 [RFC4111] Fang, L., "Security Framework for Provider-Provisioned 1126 Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. 1128 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1129 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1131 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1132 RFC 4272, January 2006. 1134 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1135 Networks (VPNs)", RFC 4364, February 2006. 1137 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1138 Routing Protocols", RFC 4593, October 2006. 1140 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 1141 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 1142 RFC 4891, May 2007. 1144 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1145 Problem Statement", RFC 4925, July 2007. 1147 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1148 Authentication Protocol", RFC 5216, March 2008. 1150 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1151 Version 2", BCP 146, RFC 5406, February 2009. 1153 Appendix A. 1155 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 1156 the SPD examples in [RFC3193] is applicable to "Hub & Spokes" model. 1157 In this model, the initiator is always the client (SI) and the 1158 responder is the SC. 1160 A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE 1162 IPv4 addresses of the softwire initiator and concentrator are denoted 1163 by IPv4-SI and IPv4-SC, respectively. If NAT traversal is used in 1164 IKE, UDP source and destination ports are 4500. In this SPD entry, 1165 IKE refers to UDP port 500. * denotes wildcard and indicates ANY port 1166 or address. 1168 Local Remote Protocol Action 1169 ----- ------ -------- ------ 1170 IPV4-SI IPV4-SC ESP BYPASS 1171 IPV4-SI IPV4-SC IKE BYPASS 1172 IPv4-SI IPV4-SC UDP, src 1701, dst 1701 PROTECT(ESP, 1173 transport) 1174 IPv4-SC IPv4-SI UDP, src * , dst 1701 PROTECT(ESP, 1175 transport) 1177 Softwire initiator SPD 1179 Remote Local Protocol Action 1180 ------ ------ -------- ------ 1181 * IPV4-SC ESP BYPASS 1182 * IPV4-SC IKE BYPASS 1183 * IPV4-SC UDP, src * , dst 1701 PROTECT(ESP, 1184 transport) 1186 Softwire concentrator SPD 1188 A.2. IPv4 over IPv6 Softwire with example for IKE 1190 IPv6 addresses of the softwire initiator and concentrator are denoted 1191 by IPv6-SI and IPv6-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 IPV6-SI IPV6-SC ESP BYPASS 1199 IPV6-SI IPV6-SC IKE BYPASS 1200 IPv6-SI IPV6-SC UDP, src 1701, dst 1701 PROTECT(ESP, 1201 transport) 1202 IPv6-SC IPv6-SI UDP, src * , dst 1701 PROTECT(ESP, 1203 transport) 1205 Softwire initiator SPD 1207 Remote Local Protocol Action 1208 ------ ------ -------- ------ 1209 * IPV6-SC ESP BYPASS 1210 * IPV6-SC IKE BYPASS 1211 * IPV6-SC UDP, src * , dst 1701 PROTECT(ESP, 1212 transport) 1214 Softwire concentrator SPD 1216 Authors' Addresses 1218 Shu Yamamoto 1219 NICT/KDDI R&D Labs 1220 1-13-16 Hakusan, Bunkyo-ku 1221 Tokyo, 113-0001 1222 Japan 1224 Phone: +81-3-3868-6913 1225 Email: shu@nict.go.jp 1227 Carl Williams 1228 KDDI R&D Labs 1229 Palo Alto, CA 94301 1230 USA 1232 Phone: +1-650-279-5903 1233 Email: carlw@mcsr-labs.org 1235 Florent Parent 1236 Beon Solutions 1237 Quebec, QC 1238 Canada 1240 Phone: +1-418-353-0857 1241 Email: Florent.Parent@beon.ca 1242 Hidetoshi Yokota 1243 KDDI R&D Labs 1244 2-1-15 Ohara 1245 Fujimino, Saitama 356-8502 1246 Japan 1248 Phone: +81-49-278-7894 1249 Email: yokota@kddilabs.jp