idnits 2.17.1 draft-ietf-softwire-security-requirements-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1219. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1232. 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 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 (December 24, 2007) is 5961 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 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-07 == Outdated reference: A later version (-07) exists of draft-eronen-ipsec-ikev2-eap-auth-05 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-09 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-hs-framework-l2tpv2-07 == Outdated reference: A later version (-06) exists of draft-ietf-softwire-mesh-framework-02 -- 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 (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Yamamoto 3 Internet-Draft C. Williams 4 Intended status: Standards Track KDDI R&D Labs 5 Expires: June 26, 2008 F. Parent 6 Beon Solutions 7 H. Yokota 8 KDDI R&D Labs 9 December 24, 2007 11 Softwire Security Analysis and Requirements 12 draft-ietf-softwire-security-requirements-05 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on June 26, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document describes the security Guidelines for the Softwire 46 "Hubs and Spokes" and "Mesh" solutions. Together with the discussion 47 of the Softwire deployment scenarios, the vulnerability to the 48 security attacks is analyzed to provide the security protection 49 mechanism such as authentication, integrity and confidentiality to 50 the softwire control and data packets. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 58 3. Hubs and Spokes Security Guidelines . . . . . . . . . . . . . 5 59 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5 60 3.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 7 61 3.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 7 62 3.4. Softwire Security Guidelines . . . . . . . . . . . . . . . 10 63 3.4.1. Authentication . . . . . . . . . . . . . . . . . . . . 11 64 3.4.2. Softwire Security Protocol . . . . . . . . . . . . . . 12 65 3.5. Guidelines for Usage of IPsec in Softwire . . . . . . . . 12 66 3.5.1. Authentication Issues . . . . . . . . . . . . . . . . 12 67 3.5.2. IPsec Pre-Shared Keys for Authentication . . . . . . . 13 68 3.5.3. Inter-operability guidelines . . . . . . . . . . . . . 13 69 3.5.4. IPsec filtering details . . . . . . . . . . . . . . . 14 70 4. Mesh Security Guidelines . . . . . . . . . . . . . . . . . . . 17 71 4.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 17 72 4.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 18 73 4.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 18 74 4.4. Applicability of Security Protection Mechanism . . . . . . 19 75 4.4.1. Security Protection Mechanism for Control Plane . . . 19 76 4.4.2. Security Protection Mechanism for Data Plane . . . . . 20 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 83 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE . . . 24 85 A.2. IPv4 over IPv6 Softwire with example for IKE . . . . . . . 25 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 87 Intellectual Property and Copyright Statements . . . . . . . . . . 27 89 1. Introduction 91 The Softwire Working Group specifies the standardization of 92 discovery, control and encapsulation methods for connecting IPv4 93 networks across IPv6 networks and IPv6 networks across IPv4 networks. 94 The Softwire provides the connectivity to enable global reachability 95 of both address families by reusing or extending exisiting 96 technology. The Softwire Working Group is focusing on the two 97 scenarios that emerged when discussing the traversal of networks 98 composed of differing address families. This document provides the 99 security Guidelines for such two Softwire solution spaces such as 100 "Hubs and Spokes" and "Mesh" scenarios "Hubs and Spokes" and "Mesh" 101 problems described in [RFC4925] Section 2 and Section 3, 102 respectively. The protocols selected for Softwire connectivity 103 require the Security consideration on more specific deployment 104 scenarios for each solution. 106 Layer Two Tunneling Protocol (L2TPv2) is selected for "Hubs and 107 Spokes" solution. If L2TPv2 is used in the unprotected network, it 108 will be vulnerable to various security attacks and MUST be protected 109 by appropriate security protocol such as IPsec described in 110 [RFC3193]. Note that other adequate security mechanisms are 111 applicable, the security protocol for softwire is not necessarily 112 mandated. This document provides the implementation guidance (and 113 proper usage) of IPsec as the security protection mechanism by 114 considering the security vulnerabilities in "Hubs and Spokes" 115 scenarios. The new implementation SHOULD use IKEv2 in the key 116 management protocol for IPsec because of more reliable protocol and 117 integration of required protocols in a sigle platform. 119 The softwire "Mesh" solution should support various levels of 120 security mechanism to protect the data packets from an attacker being 121 transmitted on a softwire tunnel from the access networks with one 122 address family across the transit core operating with different 123 address family [RFC4925]. The security mechanism are also required 124 to be protected from control data modification, spoofing attack, etc. 125 As the security considerations for BGP is being discussed in other 126 working groups, this document provide general guidelines for the 127 deployment scenario being envisaged. 129 2. Terminology 131 2.1. Abbreviations 133 The terminology is based on the softwire problem statement document 134 [RFC4925]. 136 AF(i) - Address Family. IPv4 or IPv6. Notation used to indicate 137 that prefixes, a node or network only deal with a single IP AF. 139 AF(i,j) - Notation used to indicate that a node is dual-stack or that 140 a network is composed of dual-stack nodes. 142 Address Family Border Router (AFBR) -A dual-stack router that 143 interconnects two networks that use either the same or different 144 address families. An AFBR forms peering relationships with other 145 AFBRs, adjacent core routers and attached CE routers, perform 146 softwire discovery and signaling, advertises client ASF(i) 147 reachability information and encapsulates/decapsulates customer 148 packets in softwire transport headers. 150 Customer Edge (CE) - A router located inside AF access island that 151 peers with other CE routers within the access island network and with 152 one or more upstream AFBRs. 154 Customer Premise Equipment (CPE) - An equipment, host or router, 155 located at a subscriber's premises and connected with a carrier's 156 access network. 158 Provider Edge (PE) - A router located at the edge of transit core 159 network that interfaces with CE in access island. 161 Softwire Concentrator (SC) - The node terminating the softwire in the 162 service provider network. 164 Softwire Initiator (SI) - The node initiating the softwire within the 165 customer network. 167 Softwire Encapsulation Set (SW-Encap) - A softwire encapsulation set 168 contains tunnel header parameters, order of preference of the tunnel 169 header types and the expected payload types (e.g. IPv4) carried 170 inside the softwire. 172 Softwire Next_Hop (SW-NHOP) - This attribute accompanies client AF 173 reachability advertisements and is used to reference a softwire on 174 the ingress AFBR leading to the specific prefixes. It contains a 175 softwire identifier value and a softwire next_hop IP address denoted 176 as . Its existence in the presence of client 177 AF prefixes (in advertisements or entries in a routing table) infers 178 the use of softwire to reach that prefix. 180 2.2. Requirements Language 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in [RFC2119]. 186 3. Hubs and Spokes Security Guidelines 188 3.1. Deployment Scenarios 190 To provide the security Guidelines, the discussion of the possible 191 deployment scenario and the trust relationship in the network is 192 important. 194 The Softwire initiator (SI) always resides in the customer network. 195 The node, in which the SI resides, can be the CPE access device, 196 another dedicated CPE router behind the original CPE access device or 197 any kind of host device such as PC, appliance, sensor etc. 199 However, the host device may not always have direct access to its 200 home carrier network, to which the user has subscribed. For example, 201 the softwire initiator in the laptop PC can access various access 202 networks such as Wi-Fi hot-spots, visited office network. This is 203 the nomadic case, which the Softwire SHOULD support. 205 As the softwire deployment models, the following three cases as shown 206 in Figure 1 should be considered. In these cases, the automated 207 discovery of the softwire concentrator (SC) may be used. But in this 208 document, the information on the SC such as the DNS name or IP 209 address is assumed to be configured by the user, or by the provider 210 of the softwire initiator in advance. 212 Case 1: The SI connects to the SC that belongs to the home network 213 service provider via the home access provider network. The IP 214 address of the host may be changed periodically due to the home 215 network service provider's policy. 217 Case 2: The SI connects to the SC that belongs to the home network 218 service provider via the visited access network. This is typical of 219 nomadic access use case. The host does not subscribe to the visited 220 access provider, but this provider has some roaming agreement with 221 the home network service provider of the host. The IP address of the 222 host may be changed periodically due to the home network service 223 provider's policy. 225 Case 3: The SI connects to the SC that belongs to the visited network 226 service provider via the visited access network. This is also 227 typical of nomadic access use case. The host does not subscribe to 228 the visited network service provider, but this provider has some 229 roaming agreement with the home network service provider of the host. 230 In this case, the IP address of the host is determined by the visited 231 network service provider's policy. 233 The trust relationship for these three cases will also be different. 234 The security consideration must take them into account. In 235 particular, to allow cases 2 and 3, the authentication infrastructure 236 between the SI and the SC is needed to establish the trust 237 relationship. The softwire problem statement states that the 238 softwire solution must be able to be integrated with commonly 239 deployed AAA solution. In these cases, AAA interactions between the 240 home network service provider and visited access/service provider 241 should be considered. The details of this scenario are given in 242 Section Section 3.2. 244 visited network visited network 245 access provider service provider 246 +---------------------------------+ 247 | | 248 +......v......+ +.....................|......+ 249 . . . v . 250 +------+ . (case 3) . . +------+ +--------+ . 251 | |=====================.==| | | | . 252 | SI |__.________ . . | SC |<---->| AAAv | . 253 | |---------- \ . . | | | | . 254 +------+ . \\ . . +------+ +--------+ . 255 . \\ . . ^ . 256 ^ +..........\\.+ +.....................|......+ 257 | \\ | 258 | (case 2) \\ | 259 | \\ | 260 | \\ | 261 | +............+ \\ +.....................|......+ 262 . . \\. v . 263 +------+ . . \\__+------+ +--------+ . 264 | | . (case 1) . ---| | | | . 265 | SI |=====================.==| SC |<---->| AAAh | . 266 | | . . . | | | | . 267 +------+ . . . +------+ +--------+ . 268 . . . . 269 +............+ +............................+ 270 home network home network 271 access provider service provider 273 Figure 1: Hubs and Spokes model 275 3.2. Trust Relationship 277 To perform authentication between the SC and the SI, the AAA server 278 needs to be involved. One or more AAA servers should reside in the 279 same administrative domain as the SC to authenticate the SI. When 280 the SI is mobile, it may roam from the home ISP network to another, 281 e.g. a WiFi hot-spot network. In such a situation, the SI may not 282 always connect to the same SC. From the SI's viewpoint, the AAA 283 server that is in the same administrative domain is called the home 284 AAA server and those not in the same administrative domain are called 285 visited AAA servers. The trust relationships between those nodes are 286 as follows: 288 It can be assumed that the SC and the AAA in the same administrative 289 domain share a trust relationship. When the SC needs to authenticate 290 the SI, the SC communicates with the AAA server to request 291 authentication and/or to obtain security information. If the SI 292 roams into a network that is not in the same administrative domain, 293 the visited AAA server communicates with the home AAA server that has 294 the SI's security information. Therefore, the communication between 295 the SC and the AAA server must be protected. It can be usually 296 assumed that the home and visited AAA servers share a trust 297 relationship and the connection between them is protected. 299 It can be assumed that the SI and the home AAA server share a trust 300 relationship. The home AAA server provides security information on 301 the SI when it is requested by the visited AAA server. The SI and 302 the visited AAA server do not usually have a trust relationship; 303 however, if the SI can confirm that the home AAA server is involved 304 with the authentication of the SI and the visited AAA server does not 305 alter security information from the home AAA server, the visited AAA 306 server can be trusted by the SI. The communication between the SI, 307 the home and visited AAA servers must be protected. 309 The SI and the SC do not necessarily share a trust relationship 310 especially when the SI roams into a different administrative domain. 311 When they are mutually authenticated by means of e.g. AAA servers, 312 they can start trusting each other. Unless authentication is 313 successfully performed, the softwire protocol should not be 314 initiated. 316 3.3. Softwire Security Threat Scenarios 318 Softwire can be used to connect IPv6 networks across public IPv4 319 networks and IPv4 networks across public IPv6 networks. The control 320 and data packets used during the softwire session are vulnerable to 321 attack. 323 A complete threat analysis of softwire requires examination of the 324 protocols used for the softwire setup, the encapsulation method used 325 to transport the payload, and other protocols used for configuration 326 (e.g., router advertisements, DHCP). 328 The softwire solution uses a subset of the Layer2Tunneling Protocol 329 (L2TPv2) functionality[RFC2661], [I-D.ietf-softwire-hs-framework- 330 l2tpv2]. In the Softwire "Hubs and Spokes" model, L2TPv2 is used in 331 a voluntary tunnel model only. The Softwire Initiator (SI) acts as a 332 L2TP Access Concentrator (LAC) and PPP endpoint. The L2TPv2 tunnel 333 is always initiated from the SI. 335 Generic threat analysis done for L2TP using IPsec [RFC3193] is 336 applicable to Softwire "Hubs and Spokes" deployment. The threat 337 analysis for other protocols such as PANA [RFC4016], NSIS [RFC4081], 338 and Routing Protocols [RFC4593] are applicable here as well and 339 should be used as reference. 341 First, SI resided in the customer network sends Start-Control- 342 Connection-Request(SCCRQ) packet to SC for the initiation of 343 Softwire. Optionally, L2TP exchanges Challenge and Response AVPs for 344 tunnel mutual authentication in L2TPv2 tunnel creation. For the CHAP 345 authentication key, L2TPv2 protocol does not provide the key 346 management facilities. 348 Once L2TPv2 process has been completed, the SI and SC optionally 349 enter authentication phase after completing PPP Link Control Protocol 350 (LCP) negotiation. PPP authentication supports one way or two way 351 CHAP authentication, which can be interworked with AAA. Other 352 authentication of PAP authentication, MS-CHAP, and EAP MAY be 353 supported. But PPP authentication does not provide per-packet 354 authentication. 356 PPP encryption is defined but PPP Encryption Control Protocol (ECP) 357 negotiation does not provide for a protected cipher suite 358 negotiation. PPP encryption provides a weak security solution 359 [RFC3193]. PPP ECP implementation cannot be expected. PPP 360 authentication also does not provide the scalable key management. 362 Once the access is granted to the SI, other protocols start for 363 network configuration and the node in the SI side will exchange data 364 with other nodes in the network connected through SC. 366 These steps are vulnerable to man-in-the-middle (MITM), denial of 367 service (DoS), and Service theft attacks, which are caused as the 368 consequence of the following adversary actions. 370 Adversary attacks on softwire include: 372 1. An adversary may try to discover identities by snooping data 373 packets. 375 2. An adversary may try to modify both control and data packets. 376 This type of attack involves integrity violations. 378 3. An adversary may try to eavesdrop and collect control messages. 379 By replaying these messages, an adversary may successfully hijack 380 the L2TP tunnel or the PPP connection inside the tunnel. An 381 adversary might mount MITM, DOS, and theft of service attacks. 383 4. An adversary can flood the Softwire node with bogus signaling 384 messages to cause DoS attacks by terminating L2TP tunnels or PPP 385 connections. 387 5. An adversary may attempt to disrupt the softwire negotiation in 388 order to weaken or remove confidentiality protection. 390 6. An adversary may wish to disrupt the PPP LCP authentication 391 negotiation. 393 In environments where the link is shared without cryptographic 394 protections and the weak authentication or one-way authentication is 395 used, these security attacks can be mounted on softwire control and 396 data packets. 398 To access the SC through the public networks, any node can pretend to 399 be a SC, if there is no prior trust relationship between SI and SC. 400 In this case, an adversary may impersonate the SC to intercept 401 traffic ("rogue" softwire concentrator). 403 The rogue SC captures all of necessary information (including keys if 404 security is present) of a legitimate Softwire node and remove the 405 message of the subgroup of the network. The rogue SC can introduce a 406 black hole attack in which the attacker sends out forged routing 407 packets and setup a route to some destination via itself and when the 408 actual data packets get in they are simply dropped, forming a black 409 hole at the SC - where data enters but never leaves. Another 410 possibility is for the attacker to forge routes pointing into an area 411 where the destination node is not located. Everything will be routed 412 into this area but nothing will leave. 414 The deployment of ingress filtering is able to control the malicious 415 users' access. Without specific ingress filtering checks in the 416 decapsulator at SC, it would be possible for an attacker to inject a 417 false packet. This causes DoS attack. The inner address ingress 418 filtering can reject invalid inner source address. Without inner 419 address ingress filtering, another kind of attack can happen. The 420 malicious users from another ISP could start using its tunneling 421 infrastructure to get free inner address connectivity, transforming 422 effectively the ISP into an inner address transit provider. 424 While this does not provide the complete protection in the case an 425 address spoofing has been happened. To protect address spoofing, 426 authentication MUST be implemented in the tunnel encapsulation. 428 3.4. Softwire Security Guidelines 430 Based on the security threat analysis in Section 3.3 in this 431 document, Softwire security protocol must support the following 432 protections. 434 1. Softwire control messages between the SI and the SC MUST BE 435 protected against eavesdropping and spoofing attacks. 437 2. Softwire security protocol MUST be able to protect itself against 438 replay attacks. 440 3. Softwire security protocol MUST be able to protect the device 441 identifier against the impersonation when it is exchanged between 442 the SI and the SC. 444 4. Softwire security protocol MUST be able to securely bind the 445 authenticated session to the device identifier of the client, to 446 prevent service theft. 448 5. Softwire security protocol MUST be able to protect disconnect and 449 revocation messages. 451 The Softwire security protocol requirement is comparable to RFC3193. 452 For Softwire control packets, authentication, integrity and replay 453 protection MUST be supported and confidentiality SHOULD be supported. 454 For Softwire data packets, authentication, integrity and replay 455 protection MUST be supported and confidentiality MAY be supported. 457 The Softwire problem statement [RFC4925] provides some requirements 458 for "Hubs and Spoke" solution that are taken into account in defining 459 the security protection mechanisms. 461 1. control and/or data plane must be able to provide full payload 462 security when desired. 464 2. deployed technology must be very strongly considered 466 This additional security protection must be separable from the 467 Softwire tunneling mechanism. 469 Note that the scope of the security is on the L2TP tunnel between the 470 SI and SC. If end to end security is required, a security protocol 471 should be used in the payload packets. But this is out of scope of 472 this document. 474 3.4.1. Authentication 476 The softwire security protocol MUST support user authentication in 477 the control plane, in order to authorize access to the service, and 478 provide adequate logging of activity. The protocol SHOULD offer 479 mutual authentication in scenarios where the SI requires identity 480 proof from the SC, for example, SI accesses to SC across the public 481 network. 483 In some circumstances, the service provider may decide to allow non- 484 authenticated connection [I-D.ietf-softwire-hs-framework-l2tpv2]. 485 For example, when the customer is already authenticated by some other 486 means, such as closed networks, cellular networks at Layer 2, etc., 487 the service provider may decide to turn it off. If no authentication 488 is conducted on any layer, the SC acts as a gateway for anonymous 489 connections. Running such a service MUST be configurable by the SC 490 administrator and the SC SHOULD take some security measures such as 491 ingress filtering and adequate logging of activity. It should be 492 noted that anonymous connection service cannot provide the security 493 functionalities described in this document (e.g. integrity, replay 494 protection and confidentiality). 496 3.4.1.1. PPP Authentication 498 PPP can provide mutual authentication between the SI and SC using 499 CHAP [RFC1994] during the connection establishment phase (Link 500 Control Protocol, LCP). PPP CHAP authentication can be used when the 501 SI and SC are on a trusted, non-public IP network. 503 Since CHAP does not provide per-packet authentication, integrity, or 504 replay protection, PPP CHAP authentication MUST NOT be used for 505 unprotected on a public IP network. This means that there is no 506 reason to prohibit PPP CHAP authentication if appropriate protected 507 mechanism has been applied. 509 Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY 510 be supported. 512 3.4.1.1.1. L2TPv2 Authentication 514 L2TPv2 provides an optional CHAP-like[RFC1994] tunnel authentication 515 during the control connection establishment [RFC2661, 5.1.1]. L2TPv2 516 authentication MUST NOT be used for unprotected on a public IP 517 network as the same restriction applied to PPP CHAP. 519 3.4.2. Softwire Security Protocol 521 To meet the above requirements, all softwire security compliant 522 implementations MUST implement the following security protocols. 524 IPsec ESP [RFC4303] in transport mode is used for securing softwire 525 control and data packets. Internet Key Exchange (IKE) 526 protocol[RFC4306] MUST be supported for authentication, security 527 association negotiation and key management for IPsec. The 528 applicability of different version of IKE is discussed in Section 529 3.5. 531 The softwire security protocol MUST support NAT traversal. UDP 532 encapsulation of IPsec ESP packets[RFC3948] and negotiation of NAT- 533 traversal in IKE[RFC3947] MUST be supported when IPsec is used. 535 3.5. Guidelines for Usage of IPsec in Softwire 537 [RFC3193] discusses how L2TP can use IPsec to provide tunnel 538 authentication, privacy protection, integrity checking and replay 539 protection. Since it's publication, revision to IPsec protocols have 540 been published (IKEv2 [RFC4306], ESP [RFC4303], NAT-traversal for IKE 541 [RFC3947] and ESP[RFC3948]). 543 Although [RFC3193] can be applied in the softwire "Hubs and Spokes" 544 solution, softwire requirements such as NAT-traversal, NAT-traversal 545 for IKE [RFC3947] and ESP [RFC3948] MUST be supported. 547 IKEv2 [RFC4306] integrates NAT-traversal. IKEv2 also supports EAP 548 authentication with the authentication using shared secrets and 549 public key signatures. IKEv2 is more reliable protocol than IKE 550 [RFC2409] for the replay protection capability, DoS protection 551 enabled mechanism etc. Therefore, new implementations SHOULD use 552 IKEv2 over IKE. 554 IKEv2 [RFC4306] supports legacy authentication methods that may be 555 useful in environments where username and password based 556 authentication is already deployed. 558 The following sections will discuss using IPsec to protect L2TPv2 as 559 applied in the softwire "Hubs and Spokes" model. Unless otherwise 560 stated, IKEv2 and the new IPsec architecture [RFC4301] is assumed. 562 3.5.1. Authentication Issues 564 IPsec implementation using IKE only supports machine authentication. 566 There is no way to verify a user identity and to segregate the tunnel 567 traffic among users in the multi-user machine environment. IKEv2 can 568 support user authentication with EAP payload by leveraging existing 569 authentication infrastructure and credential database. This enables 570 the traffic segregation among users when user authentication is used 571 by combining the legacy authentication. The user identity asserted 572 within IKEv2 will be verified on a per-packet basis. 574 If the AAA server is involved in security association establishment 575 between the SI and SC, a session key can be derived from the 576 authentication between the SI and the AAA server. Such a scenario 577 can be found in[I-D.eronen-ipsec-ikev2-eap-auth]. Successful EAP 578 exchanges within IKEv2 runs between the SI and the AAA server create 579 a session key and it is securely transferred to the SC from the AAA 580 server. The trust relationship between the involved entities follows 581 Section 3.2 of this document. 583 3.5.2. IPsec Pre-Shared Keys for Authentication 585 With IPsec, when the identity asserted in IKE is authenticated, the 586 resulting derived keys are used to provide per-packet authentication, 587 integrity and replay protection. As a result, the identity verified 588 in the IKE is subsequently verified on reception of each packet. 590 Authentication using pre-shared keys can be used when the number of 591 SI and SC is small. As the number of SI and SC grows, pre-shared 592 keys becomes increasingly difficult to manage. A softwire security 593 protocol must provide a scalable approach to key management. 594 Whenever possible, authentication with certificates is preferred. 596 When pre-shared keys are used, group pre-shared keys MUST NOT be used 597 because of its vulnerability to Man-In-The-Middle attacks ([RFC3193], 598 5.1.4). 600 3.5.3. Inter-operability guidelines 602 The L2TPv2/IPsec inter-operability concerning tunnel teardown, 603 fragmentation and per-packet security checks given in ([RFC3193] 604 section 3) must be taken into account. 606 Although the L2TP specification allows the responder (SC in softwire) 607 to use a new IP address or to change the port number when sending the 608 Start-Control-Connection-Request-Reply (SCCRP), a softwire 609 concentrator implementation SHOULD NOT do this ([RFC3193] section 4). 611 However, with some reasons, for example, "load-balancing" between 612 SCs, the IP address change is required. To signal an IP address 613 change, the SC sends a StopCCN message to the SI using the Result and 614 Error Code AVP in L2TPv2 message. A new IKE_SA and CHILD_SA must be 615 established to the new IP address. 617 Since ESP transport mode is used, the UDP header carrying the L2TP 618 packet will have an incorrect checksum due to the change of parts of 619 the IP header during transit. [RFC3948] section 3.1.2 defines 3 620 procedures that can be used to fix the checksum. A softwire 621 implementation MUST NOT use the "incremental update of checksum" 622 (option 1 described in[RFC3948]), because the IKEv2 does not have the 623 information required (NAT-OA payload) to compute that checksum. 624 Since ESP is already providing validation on the L2TP packet, a 625 simple approach is to use the "do not check" approach (option 3 in 626 [RFC3948]). 628 3.5.4. IPsec filtering details 630 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 631 the security policy database (SPD) examples in [RFC3193] appendix A 632 can be applied to softwire model. In that case, the initiator is 633 always the client (SI), and responder is the SC. IPsec SPD examples 634 for IKE [RFC2409] are also given in appendix A of this document. 636 The revised IPsec architecture [RFC4301] redefined the SPD entries to 637 provide more flexibility (multiple selectors per entry, list of 638 address range, peer authentication database (PAD), "populate from 639 packet"(PFP) flag, etc.). The Internet Key Exchange (IKE) has also 640 been revised and simplified in IKEv2 [RFC4306]. The following 641 sections provides the SPD examples for softwire to use the revised 642 IPsec architecture and IKEv2. 644 3.5.4.1. IPv6 over IPv4 Softwire L2TPv2 example for IKEv2 646 If IKEv2 is used as the key management protocol, RFC4301 provides the 647 guidance of the SPD etnries. In IKEv2, we can use PFP flag to 648 specify SA and the port number can be selected with Traffic Selector 649 with TSr during CREATE_CHILD_SA. The following describes PAD entries 650 on the SI and SC, respectively. The PAD entries are only example 651 configurations. The PAD entry on the SC matches user identities to 652 the L2TP SPD entry. This is done using a symbolic name. 653 SI PAD: 654 - IF remote_identity = SI_identity 655 Then authenticate (shared secret/certificate/) 656 and authorize CHILD_SA for remote address SC_address 658 SC PAD: 659 - IF remote_identity = user_1 660 Then authenticate (shared secret/certificate/EAP) 661 and authorize CHILD_SAs for symbolic name "l2tp_spd_entry" 663 The following describes the SPD entries for the SI and SC, 664 respectively. Note that IKEv2 and ESP traffic MUST be allowed 665 (bypass). These include IP protocol 50 and UDP port 500 and 4500. 667 The IPv4 packet format of ESP protecting L2TPv2 carrying IPv6 packet 668 is shown in Table 1 by using the similar Table in [RFC4891]. 670 +----------------------------+------------------------------------+ 671 | Components (first to last) | Contains | 672 +----------------------------+------------------------------------+ 673 | IPv4 header | (src = IPv4-SI, dst = IPv4-SC) | 674 | ESP header | | 675 | UDP header | (src port=1701, dst port=1701) | 676 | L2TPv2 header | | 677 | PPP header | | 678 | IPv6 header | | 679 | (payload) | | 680 | ESP ICV | | 681 +----------------------------+------------------------------------+ 683 Table 1: Packet Format for L2TPv2 with ESP carrying IPv6 packet. 685 SPD for Softwire Initiator: 687 Softwire Initiator SPD-S 688 - IF local_address=IPv4-SI 689 remote_address=IPv4-SC 690 Next Layer Protocol=UDP 691 local_port=1701 692 remote_port=ANY (PFP=1) 693 Then use SA ESP transport mode 694 Initiate using IDi = user_1 to address IPv4-SC 695 SPD for Softwire Concentrator: 697 Softwire Concentrator SPD-S 698 - IF name="l2tp_spd_entry" 699 local_address=IPv4-SC 700 remote_address=ANY (PFP=1) 701 Next Layer Protocol=UDP 702 local_port=1701 703 remote_port=ANY (PFP=1) 704 Then use SA ESP transport mode 706 3.5.4.2. IPv4 over IPv6 Softwire L2TPv2 example for IKEv2 708 The PAD entries are only example configurations. The PAD entries 709 specify that the IP address in the traffic selector payload 710 (SC_address and SI_address) is used for matching against the SPD. 712 SI PAD: 713 - IF remote_identity = SI_identity 714 Then authenticate (shared secret/certificate/) 715 and authorize CHILD_SA for remote address SC_address 717 SC PAD: 718 - IF remote_identity = user_2 719 Then authenticate (shared secret/certificate/EAP) 720 and authorize CHILD_SAs for remote address SI_address 722 The following describes the SPD entries for the SI and SC, 723 respectively. In this example, the softwire initiator and 724 concentrator are denoted with IPv6 addresses IPv6-SI and IPv6-SC, 725 respectively. Note that IKEv2 and ESP traffic MUST be allowed 726 (bypass). These include IP protocol 50 and UDP port 500 and 4500. 728 The IPv6 packet format of ESP protecting L2TPv2 carrying IPv4 packet 729 is shown in Table 2 by using similar one in [RFC4891]. 731 +----------------------------+------------------------------------+ 732 | Components (first to last) | Contains | 733 +----------------------------+------------------------------------+ 734 | IPv6 header | (src = IPv6-SI, dst = IPv6-SC) | 735 | ESP header | | 736 | UDP header | (src port=1701, dst port=1701) | 737 | L2TPv2 header | | 738 | PPP header | | 739 | IPv4 header | | 740 | (payload) | | 741 | ESP ICV | | 742 +----------------------------+------------------------------------+ 744 Table 2: Packet Format for L2TPv2 with ESP carrying IPv4 packet. 746 SPD for Softwire Initiator: 748 Softwire Initiator SPD-S 749 - IF local_address=IPv6-SI 750 remote_address=IPv6-SC 751 Next Layer Protocol=UDP 752 local_port=1701 753 remote_port=ANY (PFP=1) 754 Then use SA ESP transport mode 755 Initiate using IDi = user_2 to address IPv6-SC 757 SPD for Softwire Concentrator: 759 Softwire Concentrator SPD-S 760 - IF local_address=IPv6-SC 761 remote_address=ANY (PFP=1) 762 Next Layer Protocol=UDP 763 local_port=1701 764 remote_port=ANY (PFP=1) 765 Then use SA ESP transport mode 767 4. Mesh Security Guidelines 769 4.1. Deployment Scenario 771 In the softwire "Mesh" solution[RFC4925], 772 [I-D.ietf-softwire-mesh-framework], it is required to establish 773 connectivity to access network islands of one address family type 774 across a transit core of a differing address family type. To provide 775 reachability across the transit core, AFBRs are installed between 776 access network island and transit core network. These AFBRs can 777 perform as Provider Edge routers (PE) within an autonomous system or 778 perform peering across autonomous systems. The AFBRs establish and 779 encapsulate softwires in a mesh to the other islands across the 780 transit core network. The transit core network consists of one or 781 more service providers. 783 In the softwire "Mesh" solution, a pair of PE routers (AFBRs) use BGP 784 to exchange routing information. AFBR nodes in the transit network 785 are Internal BGP speakers and will peer with each other directly or 786 via a route reflector to exchange SW-encap sets, perform softwire 787 signaling, and advertise AF access island reachability information 788 and SW-NHOP information. If such information is advertised within an 789 autonomous system, the AFBR node receiving them from other AFBRs does 790 not forward them to other AFBR nodes. To exchange the information 791 among AFBRs, the full mesh connectivity will be established. 793 The connectivity between CE and PE routers includes dedicated 794 physical circuits, logical circuits (such as Frame Relay and ATM), 795 and shared medium access (such as Ethernet-based access). 797 When AFBRs are PE routers located at the edge of the provider core 798 networks, this is similar architecture of the L3VPN described in 799 [RFC4364]. The connectivity between a CE router in access island 800 network and a PE router in transit network is established by static 801 way. The access islands are enterprise networks accommodated through 802 PE routers in the provider's transit network. In this case, the 803 access island networks are administrated by the provider's autonomous 804 system. 806 The AFBRs may have the multiple connections to the core network, and 807 also may have the connections to the multiple client access networks. 808 The client access networks may connect each other through private 809 networks or through the Internet. When the client access networks 810 have their own AS number, a CE router located inside access islands 811 forms a private BGP peering with an AFBR. Further, an AFBR may need 812 to exchange a full Internet routing information with each network to 813 which it connects. 815 4.2. Trust Relationship 817 All AFBR nodes in the transit core MUST have a trust relationship or 818 an agreement with each other to establish softwires. When the 819 transit core consists of a single administrative domain, it is 820 assumed that all nodes (e.g. AFBR, PE or Route Reflector, if 821 applicable) are trusted with each other. 823 If the transit core consists of multiple administrative domains, 824 intermediate routers between AFBRs may not be trusted. 826 There MUST be a trust relationship between the PE in the transit core 827 and the CE in the corresponding island, although the link(s) between 828 the PE and the CE may not be protected. 830 4.3. Softwire Security Threat Scenarios 832 AS the architecture of softwire mesh solution is very similar to that 833 of the provider provisioned VPN (PPVPN). The security threats 834 considerations on the PPVPN operation are applicable to those in the 835 softwire mesh solution [RFC4111]. 837 Examples of attacks to data packets being transmitted on a softwire 838 tunnel include: 840 1. An adversary may try to discover confidential information by 841 sniffing softwire packets. 843 2. An adversary may try to modify the contents of softwire packets. 845 3. An adversary may try to spoof the softwire packets that do not 846 belong the authorized domains and to insert copies of once- 847 legitimate packets that have been recorded and replayed. 849 4. An adversary can launch Denial-of-Service (DoS) attack by 850 deleting softwire data traffic. DoS attacks of the resource 851 exhaustion type can be mounted against the data plane by spoofing 852 a large amount of non-authenticated data into the softwire from 853 the outside of the softwire tunnel. 855 5. An adversary may try to sniff softwire packets and to examine 856 aspects or meta-aspects of them that may be visible even when the 857 packets themselves are encrypted. An attacker might gain useful 858 information based on the amount and timing of traffic, packet 859 sizes, sources and destination addresses, etc. 861 The security attacks can be mounted on the control plane as well. In 862 softwire mesh solution, softwires encapsulation will be setup by 863 using BGP. As described in [RFC4272], BGP is vulnerable to various 864 security threats such as confidential violation, replay attacks, 865 insertion, deletion and modification of BGP messages, main-in-the- 866 middle, and denial-of-service. 868 4.4. Applicability of Security Protection Mechanism 870 Given that security is generally a compromise between expense and 871 risk, it is also useful to consider the likelihood of different 872 attacks. There is at least a perceived difference in the likelihood 873 of most types of attacks being successfully mounted in different 874 deployment. 876 The trust relationship among users in access networks, transit core 877 provider, and other parts of networks described in section 4.2 is a 878 key element in determining the applicability of security protection 879 mechanism for the specific softwire mesh deployment. 881 4.4.1. Security Protection Mechanism for Control Plane 883 The Softwire Problem Statement [RFC4925] states that the softwire 884 mesh setup mechanism to advertise the softwire encapsulation MUST 885 support authentication, but the transit core provider may decide to 886 turn it off in some circumstances. 888 The BGP authentication mechanism is specified in [RFC2385]. The 889 mechanism defined in [RFC2385] is based on a one-way hash function 890 (MD5) and use of a secret key. The key is shared between a pair of 891 peer routers and is used to generate 16-byte message authentication 892 code values that are not readily computed by an attacker who does not 893 have access to the key. 895 However the security mechanism for BGP transport (e.g. TCP-MD5) is 896 inadequate in some circumstances and also requires operator 897 interaction to maintain a respectable level of security. The current 898 deployments of TCP-MD5 exhibit some shortcomings with respect of key 899 management as described in [RFC3562]. 901 Key management can be especially cumbersome for operators. The 902 number of keys required and the maintenance of keys (issue/revoke/ 903 renew) has had an additive effect as a barrier to deployment. Thus 904 automated means of managing keys, to reduce operational burdens, is 905 available in BGP security system [I-D.ietf-rpsec-bgpsecrec], 906 [RFC4107]. 908 Use of IPsec counters the message insertion, deletion, and 909 modification attacks, as well as man-in-the-middle attacks by 910 outsiders. If routing data confidentiality is desired, the use of 911 IPsec ESP could provide that service. If eavesdropping attack is 912 identified as a threat, ESP can be used to provide confidentiality 913 (encryption), integrity and authentication for the BGP session. 915 4.4.2. Security Protection Mechanism for Data Plane 917 To transport data packets across the transit core, the mesh solution 918 defines multiple encapsulations: L2TPv3, IP-in-IP, MPLS (LDP-based 919 and RSVP-TE based), and GRE. To securely transport such data packet, 920 the softwire must support IPsec tunnel. 922 IPsec can provide authentication and integrity. The implementation 923 MUST support ESP with null encryption RFC4303. If some part of the 924 transit core network is not trusted, ESP with encryption may be 925 applied. 927 The automated key distribution can be performed by IKE with the pre- 928 shared key management. But the implementation of IPsec with 929 automatic key management depends on the operational requirements, for 930 example, the scalability requirement, etc. 932 To provide replay protection, automated key management system using 933 IKEv2 can be used. IKEv2 can be applied using shared secrets for 934 authentication when the number of BGP peers is small. When the 935 number of BGP peers is large, managing the shared secrets on all 936 peers does not scale. In this scenario, public-key digital signature 937 or key encryption authentication in IKE SHOULD be used. 939 If the link(s) between the user's site and the provider's PE is not 940 trusted, then encryption may be used on the PE-CE link(s). 942 Together with the cryptographic security protection, the access 943 control technique reduces the exposure to attacks from outside the 944 service provider networks (transit networks). The access control 945 technique includes packet-by-packet or packet flow-by-packet flow 946 access control by means of filters as well as by means of admitting a 947 session for a control/signaling/management protocol that is being 948 used to implement softwire mesh. 950 The access control technique is an important protection against 951 security attacks of DoS etc. and a necessary adjunct to cryptographic 952 strength in encapsulation. Packets that match the criteria 953 associated with a particular filter may be either discarded or given 954 special treatment to prevent an attack or to mitigate the effect of a 955 possible future attack. 957 5. Security Considerations 959 This document discusses various security threats for the softwire 960 control and data packets in "Hubs and Spokes" and "Mesh" time-to- 961 market solutions. With these discussions, the softwire security 962 protocol implementations are provided referencing to Softwire Problem 963 Statement [RFC4925], Securing L2TP using IPsec [RFC3193], Security 964 Framework for PPVPNs [RFC4111], and Guidelines for Mandating the Use 965 of IPsec [I-D.bellovin-useipsec]. The guidelines for the security 966 protocol employment are also given considering the specific 967 deployment context. 969 Note that this document discusses the softwire tunnel security 970 protection and does not address the end-to-end protection. 972 6. IANA Considerations 974 This document creates no new requirements on IANA namespaces 975 [RFC2434]. 977 7. Acknowledgments 979 The authors would like to thank Tero Kivinen for reviewing the 980 document and Francis Dupont for substative suggestions. 981 Acknowledgments to Jordi Palet Martinez, Shin Miyakawa, Yasuhiro 982 Shirasaki, and Bruno Stevant for their feedback. 984 We would like also to thank the authors of Softwire Hub & Spoke 985 Deployment Framework document for providing the text concerning 986 security. 988 8. References 990 8.1. Normative References 992 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 993 Protocol (CHAP)", RFC 1994, August 1996. 995 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 996 Requirement Levels", BCP 14, RFC 2119, March 1997. 998 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 999 Signature Option", RFC 2385, August 1998. 1001 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1002 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1003 October 1998. 1005 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1006 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1007 RFC 2661, August 1999. 1009 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1010 "Securing L2TP using IPsec", RFC 3193, November 2001. 1012 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1013 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1014 January 2005. 1016 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1017 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1018 RFC 3948, January 2005. 1020 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1021 Key Management", BCP 107, RFC 4107, June 2005. 1023 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1024 Internet Protocol", RFC 4301, December 2005. 1026 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1027 RFC 4303, December 2005. 1029 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1030 RFC 4306, December 2005. 1032 8.2. Informative References 1034 [I-D.bellovin-useipsec] 1035 Bellovin, S., "Guidelines for Mandating the Use of IPsec 1036 Version 2", draft-bellovin-useipsec-07 (work in progress), 1037 October 2007. 1039 [I-D.eronen-ipsec-ikev2-eap-auth] 1040 Tschofenig, H. and P. Eronen, "Extension for EAP 1041 Authentication in IKEv2", 1042 draft-eronen-ipsec-ikev2-eap-auth-05 (work in progress), 1043 June 2006. 1045 [I-D.ietf-rpsec-bgpsecrec] 1046 Christian, B. and T. Tauber, "BGP Security Requirements", 1047 draft-ietf-rpsec-bgpsecrec-09 (work in progress), 1048 November 2007. 1050 [I-D.ietf-softwire-hs-framework-l2tpv2] 1051 Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. 1052 Tremblay, "Softwires Hub & Spoke Deployment Framework with 1053 L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-07 (work 1054 in progress), September 2007. 1056 [I-D.ietf-softwire-mesh-framework] 1057 Wu, J., "Softwire Mesh Framework", 1058 draft-ietf-softwire-mesh-framework-02 (work in progress), 1059 July 2007. 1061 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1062 Internet Protocol", RFC 2401, November 1998. 1064 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1065 (IKE)", RFC 2409, November 1998. 1067 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1068 Signature Option", RFC 3562, July 2003. 1070 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1071 and Network Access (PANA) Threat Analysis and Security 1072 Requirements", RFC 4016, March 2005. 1074 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1075 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1077 [RFC4111] Fang, L., "Security Framework for Provider-Provisioned 1078 Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. 1080 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1081 RFC 4272, January 2006. 1083 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1084 Networks (VPNs)", RFC 4364, February 2006. 1086 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1087 Routing Protocols", RFC 4593, October 2006. 1089 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 1090 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 1091 RFC 4891, May 2007. 1093 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1094 Problem Statement", RFC 4925, July 2007. 1096 Appendix A. 1098 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 1099 the SPD examples in [RFC3193] is applicable to "Hub & Spokes" model. 1100 In this model, the initiator is always the client (SI) and the 1101 responder is the SC. 1103 A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE 1105 IPv4 addresses of the softwire initiator and concentrator are denoted 1106 by IPv4-SI and IPv4-SC, respectively. If NAT traversal is used in 1107 IKE, UDP source and destination ports are 4500. In this SPD entry, 1108 IKE refers to UDP port 500. * denotes wildcard and indicates ANY port 1109 or address. 1111 Local Remote Protocol Action 1112 ----- ------ -------- ------ 1113 IPV4-SI IPV4-SC ESP BYPASS 1114 IPV4-SI IPV4-SC IKE BYPASS 1115 IPv4-SI IPV4-SC UDP, src 1701, dst 1701 PROTECT(ESP, 1116 transport) 1117 IPv4-SC IPv4-SI UDP, src * , dst 1701 PROTECT(ESP, 1118 transport) 1120 Softwire initiator SPD 1122 Remote Local Protocol Action 1123 ------ ------ -------- ------ 1124 * IPV4-SC ESP BYPASS 1125 * IPV4-SC IKE BYPASS 1126 * IPV4-SC UDP, src * , dst 1701 PROTECT(ESP, 1127 transport) 1129 Softwire concentrator SPD 1131 A.2. IPv4 over IPv6 Softwire with example for IKE 1133 IPv6 addresses of the softwire initiator and concentrator are denoted 1134 by IPv6-SI and IPv6-SC, respectively. If NAT traversal is used in 1135 IKE, UDP source and destination ports are 4500. In this SPD entry, 1136 IKE refers to UDP port 500. * denotes wildcard and indicates ANY port 1137 or address. 1139 Local Remote Protocol Action 1140 ----- ------ -------- ------ 1141 IPV6-SI IPV6-SC ESP BYPASS 1142 IPV6-SI IPV6-SC IKE BYPASS 1143 IPv6-SI IPV6-SC UDP, src 1701, dst 1701 PROTECT(ESP, 1144 transport) 1145 IPv6-SC IPv6-SI UDP, src * , dst 1701 PROTECT(ESP, 1146 transport) 1148 Softwire initiator SPD 1150 Remote Local Protocol Action 1151 ------ ------ -------- ------ 1152 * IPV6-SC ESP BYPASS 1153 * IPV6-SC IKE BYPASS 1154 * IPV6-SC UDP, src * , dst 1701 PROTECT(ESP, 1155 transport) 1157 Softwire concentrator SPD 1159 Authors' Addresses 1161 Shu Yamamoto 1162 KDDI R&D Labs 1163 2-1-15 Fujimino-shi 1164 Saitama, 356-8502 1165 Japan 1167 Phone: 81 (49) 278-7311 1168 Email: shu@kddilabs.jp 1169 Carl Williams 1170 KDDI R&D Labs 1171 Palo Alto, CA 94301 1172 USA 1174 Phone: +1.650.279.5903 1175 Email: carlw@mcsr-labs.org 1177 Florent Parent 1178 Beon Solutions 1179 Quebec, QC 1180 Canada 1182 Phone: +1 418 353 0857 1183 Email: Florent.Parent@beon.ca 1185 Hidetoshi Yokota 1186 KDDI R&D Labs 1187 2-1-15 Ohara 1188 Fujimino, Saitama 356-8502 1189 Japan 1191 Phone: 81 (49) 278-7894 1192 Email: yokota@kddilabs.jp 1194 Full Copyright Statement 1196 Copyright (C) The IETF Trust (2007). 1198 This document is subject to the rights, licenses and restrictions 1199 contained in BCP 78, and except as set forth therein, the authors 1200 retain all their rights. 1202 This document and the information contained herein are provided on an 1203 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1204 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1205 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1206 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1207 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1208 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1210 Intellectual Property 1212 The IETF takes no position regarding the validity or scope of any 1213 Intellectual Property Rights or other rights that might be claimed to 1214 pertain to the implementation or use of the technology described in 1215 this document or the extent to which any license under such rights 1216 might or might not be available; nor does it represent that it has 1217 made any independent effort to identify any such rights. Information 1218 on the procedures with respect to rights in RFC documents can be 1219 found in BCP 78 and BCP 79. 1221 Copies of IPR disclosures made to the IETF Secretariat and any 1222 assurances of licenses to be made available, or the result of an 1223 attempt made to obtain a general license or permission for the use of 1224 such proprietary rights by implementers or users of this 1225 specification can be obtained from the IETF on-line IPR repository at 1226 http://www.ietf.org/ipr. 1228 The IETF invites any interested party to bring to its attention any 1229 copyrights, patents or patent applications, or other proprietary 1230 rights that may cover technology that may be required to implement 1231 this standard. Please address the information to the IETF at 1232 ietf-ipr@ietf.org. 1234 Acknowledgment 1236 Funding for the RFC Editor function is provided by the IETF 1237 Administrative Support Activity (IASA).