idnits 2.17.00 (12 Aug 2021) /tmp/idnits10054/draft-ietf-softwire-security-requirements-09.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 (June 12, 2009) is 4721 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: draft-ietf-softwire-hs-framework-l2tpv2 has been published as RFC 5571 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 5566 (Obsoleted by RFC 9012) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: December 14, 2009 KDDI R&D Labs 6 F. Parent 7 Beon Solutions 8 H. Yokota 9 KDDI R&D Labs 10 June 12, 2009 12 Softwire Security Analysis and Requirements 13 draft-ietf-softwire-security-requirements-09 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 December 14, 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 . . . . . . . . . . . . . . . 11 69 3.4.1. Authentication . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . 15 74 3.5.3. Inter-Operability Guidelines . . . . . . . . . . . . . 15 75 3.5.4. IPsec Filtering Details . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 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 and other 404 confidential informationby snooping data 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 When AAA servers are involved in softwire tunnel establishment, the 425 security attacks can be mounted on the communication associated with 426 AAA servers. Specifically for the case 3 stated in Section 3.2, an 427 adversary may eavesdrop the packets between AAA servers in the home 428 and visted network and compromise the authentication data. An 429 adversary may also disrupt the communication between the AAA servers, 430 causing a service denial. Security of AAA server communications is 431 out of scope of this document. 433 In environments where the link is shared without the cryptographic 434 protection and the weak authentication or one-way authentication is 435 used, these security attacks can be mounted on softwire control and 436 data packets. 438 When there is no prior trust relationship between the SI and SC, any 439 node can pretend to be a SC. In this case, an adversary may 440 impersonate the SC to intercept traffic (e.g. "rogue" softwire 441 concentrator). 443 The rogue SC can introduce a denial of service attack by blackholing 444 packets from the SI. The rogue SC can also eavesdrop on all packets 445 sent from or to the SI. Security threats of a rogue SC are similar 446 to a compromised router. 448 The deployment of ingress filtering is able to control the malicious 449 users' access [RFC4213]. Without specific ingress filtering checks 450 in the decapsulator at the SC, it would be possible for an attacker 451 to inject a false packet, leaving the system vulnerable to attacks 452 such as DoS. The inner address ingress filtering can reject invalid 453 inner source address. Without inner address ingress filtering, 454 another kind of attack can happen. The malicious users from another 455 ISP could start using its tunneling infrastructure to get free inner 456 address connectivity, transforming effectively the ISP into an inner 457 address transit provider. 459 While the ingress filtering does not provide the complete protection 460 in the case an address spoofing has been happened. In order to 461 provide better protection against address spoofing, authentication 462 with binding between the legitimate address and the authenticated 463 identity MUST be implemented. This can be implemented between the SC 464 and the SI using IPsec. 466 3.4. Softwire Security Guidelines 468 Based on the security threat analysis in Section 3.3 in this 469 document, the softwire security protocol MUST support the following 470 protections. 472 1. Softwire control messages between the SI and SC MUST be protected 473 against eavesdropping and spoofing attacks. 475 2. Softwire security protocol MUST be able to protect itself against 476 replay attacks. 478 3. Softwire security protocol MUST be able to protect the device 479 identifier against the impersonation when it is exchanged between 480 the SI and the SC. 482 4. Softwire security protocol MUST be able to securely bind the 483 authenticated session to the device identifier of the client, to 484 prevent service theft. 486 5. Softwire security protocol MUST be able to protect disconnect and 487 revocation messages. 489 The softwire security protocol requirement is comparable to 490 [RFC3193]. 492 For softwire control packets, authentication, integrity and replay 493 protection MUST be supported and confidentiality SHOULD be supported. 495 For softwire data packets, authentication, integrity and replay 496 protection SHOULD be supported and confidentiality MAY be supported. 498 The softwire problem statement [RFC4925] provides some requirements 499 for "Hubs and Spoke" solution that are taken into account in defining 500 the security protection mechanisms. 502 1. Control and/or data plane MUST be able to provide full payload 503 security when desired. 505 2. Deployed technology MUST be very strongly considered. 507 This additional security protection must be separable from the 508 softwire tunneling mechanism. 510 Note that the scope of the security is on the L2TP tunnel between the 511 SI and SC. If end-to-end security is required, a security protocol 512 SHOULD be used in the payload packets. But this is out of scope of 513 this document. 515 3.4.1. Authentication 517 The softwire security protocol MUST support user authentication in 518 the control plane, in order to authorize access to the service, and 519 provide adequate logging of activity. Although several 520 authentication protocols are available, the security threats must be 521 considered to choose the protocol. 523 For example, the SI/user using Password Authentication Protocol (PAP) 524 access to the SC with the cleartext password. In many circumstances, 525 this represents a large security risk. The adversary may spoof as a 526 legitimate user by using the stolen password. Challenge Handshake 527 Authentication Protocol (CHAP) [RFC1994] encrypts a password with 528 "challenge" sent from the SC. The theft of password can be 529 mitigated. However, as CHAP only supports unidirectional 530 authentication, the risk of a man-in-the-middle or rogue SC cannot be 531 avoided. Extensible Authentication Protocol-Transport Layer Security 532 (EAP-TLS) [RFC5216] mandates mutual authentication and avoid the 533 rogue SC. 535 When the SI established a connection to the SC through a public 536 network, the SI may want to a proof of the SC identity. Softwire 537 MUST support mutual authentication to allow for such scenario. 539 In some circumstances, however, the service provider may decide to 540 allow non-authenticated connection 541 [I-D.ietf-softwire-hs-framework-l2tpv2]. For example, when the 542 customer is already authenticated by some other means, such as closed 543 networks, cellular networks at Layer 2, etc., the service provider 544 may decide to turn authentication off. If no authentication is 545 conducted on any layer, the SC acts as a gateway for anonymous 546 connections. Running such a service MUST be configurable by the SC 547 administrator and the SC SHOULD take some security measures such as 548 ingress filtering and adequate logging of activity. It should be 549 noted that anonymous connection service cannot provide the security 550 functionalities described in this document (e.g. integrity, replay 551 protection and confidentiality). 553 L2TPv2 selected as Softwire phase 1 protocol supports PPP 554 authentication and L2TPv2 authentication. PPP authentication and 555 L2TPv2 have various security threats as stated in Section 3.3. They 556 will be used in the limited condition as described in the next 557 subsections. 559 3.4.1.1. PPP Authentication 561 PPP can provide mutual authentication between the SI and SC using 562 CHAP [RFC1994] during the connection establishment phase (Link 563 Control Protocol, LCP). PPP CHAP authentication can be used when the 564 SI and SC are on a trusted, non-public IP network. 566 Since CHAP does not provide per-packet authentication, integrity, or 567 replay protection, PPP CHAP authentication MUST NOT be used for 568 unprotected on a public IP network. If other appropriate protected 569 mechanism has been already applied, PPP CHAP authentication MAY be 570 used. 572 Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY 573 be supported. 575 3.4.1.2. L2TPv2 Authentication 577 L2TPv2 provides an optional CHAP-like tunnel authentication during 578 the control connection establishment [RFC2661, 5.1.1]. L2TPv2 579 authentication MUST NOT be used for unprotected on a public IP 580 network as the same restriction applied to PPP CHAP. 582 3.4.2. Softwire Security Protocol 584 To meet the above requirements, all softwire security compliant 585 implementations MUST implement the following security protocols. 587 IPsec ESP [RFC4303] in transport mode is used for securing softwire 588 control and data packets. Internet Key Exchange (IKE) 589 protocol[RFC4306] MUST be supported for authentication, security 590 association negotiation and key management for IPsec. The 591 applicability of different version of IKE is discussed in Section 592 3.5. 594 The softwire security protocol MUST support NAT traversal. UDP 595 encapsulation of IPsec ESP packets[RFC3948] and negotiation of NAT- 596 traversal in IKE[RFC3947] MUST be supported when IPsec is used. 598 3.5. Guidelines for Usage of IPsec in Softwire 600 When softwire "Hubs and Spokes" solution implemented by L2TPv2 is 601 used in untrustworthy network, softwire MUST be protected by 602 appropriate security protocol such as IPsec. This section provides 603 guidelines for the usage of IPsec in L2TPv2 based softwire. 605 [RFC3193] discusses how L2TP can use IKE [RFC2409] and IPsec 606 [RFC2401] to provide tunnel authentication, privacy protection, 607 integrity checking and replay protection. Since its publication, the 608 revision to IPsec protocols have been published (IKEv2 [RFC4306], ESP 609 [RFC4303], NAT-traversal for IKE [RFC3947] and ESP[RFC3948]). 611 Given that deployed technology must be very strongly considered 612 [RFC4925] for the 'time-to-market' solution, [RFC3193] MUST be 613 supported. However, the new implementation SHOULD use IKEv2 614 [RFC4306] for IPsec because of the numerous advantages over IKE 615 [RFC2409]. In new deployments, IKEv2 SHOULD be used as well. 617 Although [RFC3193] can be applied in the softwire "Hubs and Spokes" 618 solution, softwire requirements such as NAT-traversal, NAT-traversal 619 for IKE [RFC3947] and ESP [RFC3948] MUST be supported. 621 Meanwhile, IKEv2 [RFC4306] integrates NAT-traversal. IKEv2 also 622 supports EAP authentication with the authentication using shared 623 secrets (pre-shared key) or public key signature (certificate). 625 The selection of pre-shared key and certificate depends on the scale 626 of the network for softwire to be deployed as described in Section 627 3.5.2. However, pre-shared key and certificates only support the 628 machine authentication. When both machine and user authentications 629 are required, for example, in the nomadic case, EAP SHOULD be used. 631 Together with EAP, IKEv2 [RFC4306] supports legacy authentication 632 methods that may be useful in environments where username and 633 password based authentication is already deployed. 635 IKEv2 is more reliable protocol than IKE [RFC2409]in terms of the 636 replay protection capability, DoS protection enabled mechanism etc. 637 Therefore, new implementations SHOULD use IKEv2 over IKE. 639 The following sections will discuss using IPsec to protect L2TPv2 as 640 applied in the softwire "Hubs and Spokes" model. Unless otherwise 641 stated, IKEv2 and the new IPsec architecture [RFC4301] is assumed. 643 3.5.1. Authentication Issues 645 IPsec implementation using IKE only supports machine authentication. 646 There is no way to verify a user identity and to segregate the tunnel 647 traffic among users in the multi-user machine environment. IKEv2 can 648 support user authentication with EAP payload by leveraging existing 649 authentication infrastructure and credential database. This enables 650 the traffic segregation among users when user authentication is used 651 by combining the legacy authentication. The user identity asserted 652 within IKEv2 will be verified on a per-packet basis. 654 If the AAA server is involved in security association establishment 655 between the SI and SC, a session key can be derived from the 656 authentication between the SI and the AAA server. Successful EAP 657 exchanges within IKEv2 runs between the SI and the AAA server create 658 a session key and it is securely transferred to the SC from the AAA 659 server. The trust relationship between the involved entities follows 660 Section 3.2 of this document. 662 3.5.2. IPsec Pre-Shared Keys for Authentication 664 With IPsec, when the identity asserted in IKE is authenticated, the 665 resulting derived keys are used to provide per-packet authentication, 666 integrity and replay protection. As a result, the identity verified 667 in the IKE is subsequently verified on reception of each packet. 669 Authentication using pre-shared keys can be used when the number of 670 SI and SC is small. As the number of SI and SC grows, pre-shared 671 keys becomes increasingly difficult to manage. A softwire security 672 protocol MUST provide a scalable approach to key management. 673 Whenever possible, authentication with certificates is preferred. 675 When pre-shared keys are used, group pre-shared keys MUST NOT be used 676 because of its vulnerability to Man-In-The-Middle attacks ([RFC3193], 677 5.1.4). 679 3.5.3. Inter-Operability Guidelines 681 The L2TPv2/IPsec inter-operability concerning tunnel teardown, 682 fragmentation and per-packet security checks given in ([RFC3193] 683 section 3) must be taken into account. 685 Although the L2TP specification allows the responder (SC in softwire) 686 to use a new IP address or to change the port number when sending the 687 Start-Control-Connection-Request-Reply (SCCRP), a softwire 688 concentrator implementation SHOULD NOT do this ([RFC3193] section 4). 690 However, with some reasons, for example, "load-balancing" between 691 SCs, the IP address change is required. To signal an IP address 692 change, the SC sends a StopCCN message to the SI using the Result and 693 Error Code AVP in L2TPv2 message. A new IKE_SA and CHILD_SA MUST be 694 established to the new IP address. 696 Since ESP transport mode is used, the UDP header carrying the L2TP 697 packet will have an incorrect checksum due to the change of parts of 698 the IP header during transit. [RFC3948] section 3.1.2 defines 3 699 procedures that can be used to fix the checksum. A softwire 700 implementation MUST NOT use the "incremental update of checksum" 701 (option 1 described in[RFC3948]), because the IKEv2 does not have the 702 information required (NAT-OA payload) to compute that checksum. 704 Since ESP is already providing validation on the L2TP packet, a 705 simple approach is to use the "do not check" approach (option 3 in 706 [RFC3948]). 708 3.5.4. IPsec Filtering Details 710 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 711 the security policy database (SPD) examples in [RFC3193] appendix A 712 can be applied to softwire model. In that case, the initiator is 713 always the client (SI), and responder is the SC. IPsec SPD examples 714 for IKE [RFC2409] are also given in appendix A of this document. 716 The revised IPsec architecture [RFC4301] redefined the SPD entries to 717 provide more flexibility (multiple selectors per entry, list of 718 address range, peer authentication database (PAD), "populate from 719 packet"(PFP) flag, etc.). The Internet Key Exchange (IKE) has also 720 been revised and simplified in IKEv2 [RFC4306]. The following 721 sections provides the SPD examples for softwire to use the revised 722 IPsec architecture and IKEv2. 724 3.5.4.1. IPv6 over IPv4 Softwire L2TPv2 example for IKEv2 726 If IKEv2 is used as the key management protocol, RFC4301 provides the 727 guidance of the SPD entries. In IKEv2, we can use PFP flag to 728 specify SA and the port number can be selected with Traffic Selector 729 with TSr during CREATE_CHILD_SA. The following describes PAD entries 730 on the SI and SC, respectively. The PAD entries are only example 731 configurations. The PAD entry on the SC matches user identities to 732 the L2TP SPD entry. This is done using a symbolic name type 733 specified in [RFC4301]. 735 SI PAD: 736 - IF remote_identity = SI_identity 737 Then authenticate (shared secret/certificate/) 738 and authorize CHILD_SA for remote address SC_address 740 SC PAD: 741 - IF remote_identity = user_1 742 Then authenticate (shared secret/certificate/EAP) 743 and authorize CHILD_SAs for symbolic name "l2tp_spd_entry" 745 The following describes the SPD entries for the SI and SC, 746 respectively. Note that IKEv2 and ESP traffic MUST be allowed 747 (bypass). These include IP protocol 50 and UDP port 500 and 4500. 749 The IPv4 packet format of ESP protecting L2TPv2 carrying IPv6 packet 750 is shown in Table 1 by using the similar Table in [RFC4891]. 752 +----------------------------+------------------------------------+ 753 | Components (first to last) | Contains | 754 +----------------------------+------------------------------------+ 755 | IPv4 header | (src = IPv4-SI, dst = IPv4-SC) | 756 | ESP header | | 757 | UDP header | (src port=1701, dst port=1701) | 758 | L2TPv2 header | | 759 | PPP header | | 760 | IPv6 header | | 761 | (payload) | | 762 | ESP ICV | | 763 +----------------------------+------------------------------------+ 765 Table 1: Packet Format for L2TPv2 with ESP carrying IPv6 packet. 767 SPD for Softwire Initiator: 769 Softwire Initiator SPD-S 770 - IF local_address=IPv4-SI 771 remote_address=IPv4-SC 772 Next Layer Protocol=UDP 773 local_port=1701 774 remote_port=ANY (PFP=1) 775 Then use SA ESP transport mode 776 Initiate using IDi = user_1 to address IPv4-SC 777 SPD for Softwire Concentrator: 779 Softwire Concentrator SPD-S 780 - IF name="l2tp_spd_entry" 781 local_address=IPv4-SC 782 remote_address=ANY (PFP=1) 783 Next Layer Protocol=UDP 784 local_port=1701 785 remote_port=ANY (PFP=1) 786 Then use SA ESP transport mode 788 3.5.4.2. IPv4 over IPv6 Softwire L2TPv2 example for IKEv2 790 The PAD entries for SI and SC are shown as examples. These example 791 configurations are similar to those in 3.3.4.1.[RFC4301] 792 SI PAD: 793 - IF remote_identity = SI_identity 794 Then authenticate (shared secret/certificate/) 795 and authorize CHILD_SA for remote address SC_address 797 SC PAD: 798 - IF remote_identity = user_2 799 Then authenticate (shared secret/certificate/EAP) 800 and authorize CHILD_SAs for symbolic name "l2tp_spd_entry" 802 The following describes the SPD entries for the SI and SC, 803 respectively. In this example, the SI and SC are denoted with IPv6 804 addresses IPv6-SI and IPv6-SC, respectively. Note that IKEv2 and ESP 805 traffic MUST be allowed (bypass). These include IP protocol 50 and 806 UDP port 500 and 4500. 808 The IPv6 packet format of ESP protecting L2TPv2 carrying IPv4 packet 809 is shown in Table 2 by using similar one in [RFC4891]. 811 +----------------------------+------------------------------------+ 812 | Components (first to last) | Contains | 813 +----------------------------+------------------------------------+ 814 | IPv6 header | (src = IPv6-SI, dst = IPv6-SC) | 815 | ESP header | | 816 | UDP header | (src port=1701, dst port=1701) | 817 | L2TPv2 header | | 818 | PPP header | | 819 | IPv4 header | | 820 | (payload) | | 821 | ESP ICV | | 822 +----------------------------+------------------------------------+ 824 Table 2: Packet Format for L2TPv2 with ESP carrying IPv4 packet. 826 SPD for Softwire Initiator: 828 Softwire Initiator SPD-S 829 - IF local_address=IPv6-SI 830 remote_address=IPv6-SC 831 Next Layer Protocol=UDP 832 local_port=1701 833 remote_port=ANY (PFP=1) 834 Then use SA ESP transport mode 835 Initiate using IDi = user_2 to address IPv6-SC 837 SPD for Softwire Concentrator: 839 Softwire Concentrator SPD-S 840 - IF name="l2tp_spd_entry" 841 local_address=IPv6-SC 842 remote_address=ANY (PFP=1) 843 Next Layer Protocol=UDP 844 local_port=1701 845 remote_port=ANY (PFP=1) 846 Then use SA ESP transport mode 848 4. Mesh Security Guidelines 850 4.1. Deployment Scenario 852 In the softwire "Mesh" solution[RFC4925], [RFC5565], it is required 853 to establish connectivity to access network islands of one address 854 family type across a transit core of a differing address family type. 855 To provide reachability across the transit core, AFBRs are installed 856 between access network island and transit core network. These AFBRs 857 can perform as Provider Edge routers (PE) within an autonomous system 858 or perform peering across autonomous systems. The AFBRs establish 859 and encapsulate softwires in a mesh to the other islands across the 860 transit core network. The transit core network consists of one or 861 more service providers. 863 In the softwire "Mesh" solution, a pair of PE routers (AFBRs) use BGP 864 to exchange routing information. AFBR nodes in the transit network 865 are Internal BGP speakers and will peer with each other directly or 866 via a route reflector to exchange SW-encap sets, perform softwire 867 signaling, and advertise AF access island reachability information 868 and SW-NHOP information. If such information is advertised within an 869 autonomous system, the AFBR node receiving them from other AFBRs does 870 not forward them to other AFBR nodes. To exchange the information 871 among AFBRs, the full mesh connectivity will be established. 873 The connectivity between CE and PE routers includes dedicated 874 physical circuits, logical circuits (such as Frame Relay and ATM), 875 and shared medium access (such as Ethernet-based access). 877 When AFBRs are PE routers located at the edge of the provider core 878 networks, this is similar architecture of the L3VPN described in 879 [RFC4364]. The connectivity between a CE router in access island 880 network and a PE router in transit network is established by static 881 way. The access islands are enterprise networks accommodated through 882 PE routers in the provider's transit network. In this case, the 883 access island networks are administrated by the provider's autonomous 884 system. 886 The AFBRs may have the multiple connections to the core network, and 887 also may have the connections to the multiple client access networks. 888 The client access networks may connect each other through private 889 networks or through the Internet. When the client access networks 890 have their own AS number, a CE router located inside access islands 891 forms a private BGP peering with an AFBR. Further, an AFBR may need 892 to exchange a full Internet routing information with each network to 893 which it connects. 895 4.2. Trust Relationship 897 All AFBR nodes in the transit core MUST have a trust relationship or 898 an agreement with each other to establish softwires. When the 899 transit core consists of a single administrative domain, it is 900 assumed that all nodes (e.g. AFBR, PE or Route Reflector, if 901 applicable) are trusted with each other. 903 If the transit core consists of multiple administrative domains, 904 intermediate routers between AFBRs may not be trusted. 906 There MUST be a trust relationship between the PE in the transit core 907 and the CE in the corresponding island, although the link(s) between 908 the PE and the CE may not be protected. 910 4.3. Softwire Security Threat Scenarios 912 As the architecture of softwire mesh solution is very similar to that 913 of the provider provisioned VPN (PPVPN). The security threats 914 considerations on the PPVPN operation are applicable to those in the 915 softwire mesh solution [RFC4111]. 917 Examples of attacks to data packets being transmitted on a softwire 918 tunnel include: 920 1. An adversary may try to discover confidential information by 921 sniffing softwire packets. 923 2. An adversary may try to modify the contents of softwire packets. 925 3. An adversary may try to spoof the softwire packets that do not 926 belong the authorized domains and to insert copies of once- 927 legitimate packets that have been recorded and replayed. 929 4. An adversary can launch Denial-of-Service (DoS) attack by 930 deleting softwire data traffic. DoS attacks of the resource 931 exhaustion type can be mounted against the data plane by spoofing 932 a large amount of non-authenticated data into the softwire from 933 the outside of the softwire tunnel. 935 5. An adversary may try to sniff softwire packets and to examine 936 aspects or meta-aspects of them that may be visible even when the 937 packets themselves are encrypted. An attacker might gain useful 938 information based on the amount and timing of traffic, packet 939 sizes, sources and destination addresses, etc. 941 The security attacks can be mounted on the control plane as well. In 942 softwire mesh solution, softwires encapsulation will be set up by 943 using BGP. As described in [RFC4272], BGP is vulnerable to various 944 security threats such as confidential violation, replay attacks, 945 insertion, deletion and modification of BGP messages, main-in-the- 946 middle, and denial-of-service. 948 4.4. Applicability of Security Protection Mechanism 950 Given that security is generally a compromise between expense and 951 risk, it is also useful to consider the likelihood of different 952 attacks. There is at least a perceived difference in the likelihood 953 of most types of attacks being successfully mounted in different 954 deployment. 956 The trust relationship among users in access networks, transit core 957 provider, and other parts of networks described in section 4.2 is a 958 key element in determining the applicability of security protection 959 mechanism for the specific softwire mesh deployment. 961 4.4.1. Security Protection Mechanism for Control Plane 963 The Softwire Problem Statement [RFC4925] states that the softwire 964 mesh setup mechanism to advertise the softwire encapsulation MUST 965 support authentication, but the transit core provider may decide to 966 turn it off in some circumstances. 968 The BGP authentication mechanism is specified in [RFC2385]. The 969 mechanism defined in [RFC2385] is based on a one-way hash function 970 (MD5) and use of a secret key. The key is shared between a pair of 971 peer routers and is used to generate 16-byte message authentication 972 code values that are not readily computed by an attacker who does not 973 have access to the key. 975 However the security mechanism for BGP transport (e.g. TCP-MD5) is 976 inadequate in some circumstances and also requires operator 977 interaction to maintain a respectable level of security. The current 978 deployments of TCP-MD5 exhibit some shortcomings with respect of key 979 management as described in [RFC3562]. 981 Key management can be especially cumbersome for operators. The 982 number of keys required and the maintenance of keys (issue/revoke/ 983 renew) has had an additive effect as a barrier to deployment. Thus 984 automated means of managing keys, to reduce operational burdens, is 985 available in BGP security system [I-D.ietf-rpsec-bgpsecrec], 986 [RFC4107]. 988 Use of IPsec counters the message insertion, deletion, and 989 modification attacks, as well as man-in-the-middle attacks by 990 outsiders. If routing data confidentiality is desired, the use of 991 IPsec ESP could provide that service. If eavesdropping attack is 992 identified as a threat, ESP can be used to provide confidentiality 993 (encryption), integrity and authentication for the BGP session. 995 4.4.2. Security Protection Mechanism for Data Plane 997 To transport data packets across the transit core, the mesh solution 998 defines multiple encapsulations: L2TPv3, IP-in-IP, MPLS (LDP-based 999 and RSVP-TE based), and GRE. To securely transport such data packet, 1000 the softwire MUST support IPsec tunnel. 1002 IPsec can provide authentication and integrity. The implementation 1003 MUST support ESP with null encryption [RFC4303] or else AH (IP 1004 Authentication Header) [RFC4302]. If some part of the transit core 1005 network is not trusted, ESP with encryption MAY be applied. 1007 Since the softwires are created dynamically by BGP, the automated key 1008 distribution MUST be performed by IKEv2 [RFC4306] with either pre- 1009 shared key or public key management. For the dynamic softwire IPsec 1010 tunnel creation, pre-shared key will be same in all routers. Namely 1011 pre-shared key indicates here group key instead of pairwise shared 1012 key. 1014 If security policy requires a stronger key management, the public key 1015 SHOULD be used. If a public key infrastructure is not available, the 1016 IPsec Tunnel Authentication sub-TLV specified in [RFC5566] MUST be 1017 used before SA is established. 1019 If the link(s) between the user's site and the provider's PE is not 1020 trusted, then encryption MAY be used on the PE-CE link(s). 1022 Together with the cryptographic security protection, the access 1023 control technique reduces the exposure to attacks from outside the 1024 service provider networks (transit networks). The access control 1025 technique includes packet-by-packet or packet flow-by-packet flow 1026 access control by means of filters as well as by means of admitting a 1027 session for a control/signaling/management protocol that is being 1028 used to implement softwire mesh. 1030 The access control technique is an important protection against 1031 security attacks of DoS etc. and a necessary adjunct to cryptographic 1032 strength in encapsulation. Packets that match the criteria 1033 associated with a particular filter may be either discarded or given 1034 special treatment to prevent an attack or to mitigate the effect of a 1035 possible future attack. 1037 5. Security Considerations 1039 This document discusses various security threats for the softwire 1040 control and data packets in "Hubs and Spokes" and "Mesh" time-to- 1041 market solutions. With these discussions, the softwire security 1042 protocol implementations are provided referencing to Softwire Problem 1043 Statement [RFC4925], Securing L2TP using IPsec [RFC3193], Security 1044 Framework for PPVPNs [RFC4111], and Guidelines for Mandating the Use 1045 of IPsec [RFC5406]. The guidelines for the security protocol 1046 employment are also given considering the specific deployment 1047 context. 1049 Note that this document discusses the softwire tunnel security 1050 protection and does not address the end-to-end protection. 1052 6. IANA Considerations 1054 This document creates no new requirements on IANA namespaces 1055 [RFC5226]. 1057 7. Acknowledgments 1059 The authors would like to thank Tero Kivinen for reviewing the 1060 document and Francis Dupont for substantive suggestions. 1061 Acknowledgments to Jordi Palet Martinez, Shin Miyakawa, Yasuhiro 1062 Shirasaki, and Bruno Stevant for their feedback. 1064 We would like also to thank the authors of Softwire Hub & Spoke 1065 Deployment Framework document for providing the text concerning 1066 security. 1068 8. References 1070 8.1. Normative References 1072 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1073 Protocol (CHAP)", RFC 1994, August 1996. 1075 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1076 Requirement Levels", BCP 14, RFC 2119, March 1997. 1078 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1079 Signature Option", RFC 2385, August 1998. 1081 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1082 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1083 RFC 2661, August 1999. 1085 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1086 "Securing L2TP using IPsec", RFC 3193, November 2001. 1088 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1089 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1090 January 2005. 1092 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1093 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1094 RFC 3948, January 2005. 1096 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1097 Key Management", BCP 107, RFC 4107, June 2005. 1099 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1100 Internet Protocol", RFC 4301, December 2005. 1102 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1103 December 2005. 1105 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1106 RFC 4303, December 2005. 1108 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1109 RFC 4306, December 2005. 1111 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1112 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1113 May 2008. 1115 8.2. Informative References 1117 [I-D.ietf-rpsec-bgpsecrec] 1118 Christian, B. and T. Tauber, "BGP Security Requirements", 1119 draft-ietf-rpsec-bgpsecrec-10 (work in progress), 1120 November 2008. 1122 [I-D.ietf-softwire-hs-framework-l2tpv2] 1123 Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. 1124 Tremblay, "Softwire Hub & Spoke Deployment Framework with 1125 L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-12 (work 1126 in progress), March 2009. 1128 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1129 Internet Protocol", RFC 2401, November 1998. 1131 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1132 (IKE)", RFC 2409, November 1998. 1134 [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy 1135 Implementation in Roaming", RFC 2607, June 1999. 1137 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1138 Signature Option", RFC 3562, July 2003. 1140 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1141 and Network Access (PANA) Threat Analysis and Security 1142 Requirements", RFC 4016, March 2005. 1144 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1145 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1147 [RFC4111] Fang, L., "Security Framework for Provider-Provisioned 1148 Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. 1150 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1151 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1153 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1154 Nordmark, "Mobile IP Version 6 Route Optimization Security 1155 Design Background", RFC 4225, December 2005. 1157 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1158 RFC 4272, January 2006. 1160 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1161 Networks (VPNs)", RFC 4364, February 2006. 1163 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1164 Routing Protocols", RFC 4593, October 2006. 1166 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 1167 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 1168 RFC 4891, May 2007. 1170 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1171 Problem Statement", RFC 4925, July 2007. 1173 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1174 Authentication Protocol", RFC 5216, March 2008. 1176 [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec 1177 Version 2", BCP 146, RFC 5406, February 2009. 1179 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 1180 Framework", RFC 5565, June 2009. 1182 [RFC5566] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel 1183 Encapsulation Attribute", RFC 5566, June 2009. 1185 Appendix A. 1187 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 1188 the SPD examples in [RFC3193] is applicable to "Hub & Spokes" model. 1189 In this model, the initiator is always the client (SI) and the 1190 responder is the SC. 1192 A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE 1194 IPv4 addresses of the softwire initiator and concentrator are denoted 1195 by IPv4-SI and IPv4-SC, respectively. If NAT traversal is used in 1196 IKE, UDP source and destination ports are 4500. In this SPD entry, 1197 IKE refers to UDP port 500. * denotes wildcard and indicates ANY port 1198 or address. 1200 Local Remote Protocol Action 1201 ----- ------ -------- ------ 1202 IPV4-SI IPV4-SC ESP BYPASS 1203 IPV4-SI IPV4-SC IKE BYPASS 1204 IPv4-SI IPV4-SC UDP, src 1701, dst 1701 PROTECT(ESP, 1205 transport) 1206 IPv4-SC IPv4-SI UDP, src * , dst 1701 PROTECT(ESP, 1207 transport) 1209 Softwire initiator SPD 1211 Remote Local Protocol Action 1212 ------ ------ -------- ------ 1213 * IPV4-SC ESP BYPASS 1214 * IPV4-SC IKE BYPASS 1215 * IPV4-SC UDP, src * , dst 1701 PROTECT(ESP, 1216 transport) 1218 Softwire concentrator SPD 1220 A.2. IPv4 over IPv6 Softwire with example for IKE 1222 IPv6 addresses of the softwire initiator and concentrator are denoted 1223 by IPv6-SI and IPv6-SC, respectively. If NAT traversal is used in 1224 IKE, UDP source and destination ports are 4500. In this SPD entry, 1225 IKE refers to UDP port 500. * denotes wildcard and indicates ANY port 1226 or address. 1228 Local Remote Protocol Action 1229 ----- ------ -------- ------ 1230 IPV6-SI IPV6-SC ESP BYPASS 1231 IPV6-SI IPV6-SC IKE BYPASS 1232 IPv6-SI IPV6-SC UDP, src 1701, dst 1701 PROTECT(ESP, 1233 transport) 1234 IPv6-SC IPv6-SI UDP, src * , dst 1701 PROTECT(ESP, 1235 transport) 1237 Softwire initiator SPD 1239 Remote Local Protocol Action 1240 ------ ------ -------- ------ 1241 * IPV6-SC ESP BYPASS 1242 * IPV6-SC IKE BYPASS 1243 * IPV6-SC UDP, src * , dst 1701 PROTECT(ESP, 1244 transport) 1246 Softwire concentrator SPD 1248 Authors' Addresses 1250 Shu Yamamoto 1251 NICT/KDDI R&D Labs 1252 1-13-16 Hakusan, Bunkyo-ku 1253 Tokyo, 113-0001 1254 Japan 1256 Phone: +81-3-3868-6913 1257 Email: shu@nict.go.jp 1259 Carl Williams 1260 KDDI R&D Labs 1261 Palo Alto, CA 94301 1262 USA 1264 Phone: +1-650-279-5903 1265 Email: carlw@mcsr-labs.org 1267 Florent Parent 1268 Beon Solutions 1269 Quebec, QC 1270 Canada 1272 Email: Florent.Parent@beon.ca 1274 Hidetoshi Yokota 1275 KDDI R&D Labs 1276 2-1-15 Ohara 1277 Fujimino, Saitama 356-8502 1278 Japan 1280 Phone: +81-49-278-7894 1281 Email: yokota@kddilabs.jp