idnits 2.17.1 draft-ietf-softwire-security-requirements-04.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 1167. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1178. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1191. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 6 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 105: '...security attacks and MUST be protected...' RFC 2119 keyword, line 112: '...w implementation SHOULD use IKEv2 in t...' RFC 2119 keyword, line 192: '...se, which the Softwire SHOULD support....' RFC 2119 keyword, line 341: '...uthentication, MS-CHAP, and EAP MAY be...' RFC 2119 keyword, line 415: '... authentication MUST be implemented i...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: L2TPv2 provides an optional CHAP-like[RFC1994] tunnel authentication during the control connection establishment [RFC2661, 5.1.1]. L2TPv2 authentication MUST not be used for unprotected on a public IP network as the same restriction applied to PPP CHAP. -- 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 (November 19, 2007) is 6001 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) == Missing Reference: 'I-D.softwire-hs-framework-l2tpv2' is mentioned on line 473, but not defined == Missing Reference: 'I-D.draft-eronen-ipsec-ikev2-eap-auth-05' is mentioned on line 564, but not defined == Unused Reference: 'I-D.ietf-softwire-hs-framework-l2tpv2' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-softwire-mesh-framework' is defined on line 1026, but no explicit reference was found in the text == Unused Reference: 'I-D.v6ops-tunneling-requirements' is defined on line 1036, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 3562 ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Downref: Normative reference to an Informational RFC: RFC 4593 ** Downref: Normative reference to an Informational RFC: RFC 4925 == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-04 == Outdated reference: A later version (-06) exists of draft-ietf-softwire-mesh-framework-02 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-06 Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 7 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 Expires: May 22, 2008 KDDI R&D Labs 5 F. Parent 6 Beon Solutions 7 H. Yokota 8 KDDI R&D Labs 9 November 19, 2007 11 Softwire Security Analysis and Requirements 12 draft-ietf-softwire-security-requirements-04 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 May 22, 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 3. Hubs and Spokes Security Guidelines . . . . . . . . . . . . . 4 57 3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 4 58 3.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 7 60 3.4. Softwire Security Guidelines . . . . . . . . . . . . . . . 10 61 3.4.1. Authentication . . . . . . . . . . . . . . . . . . . . 11 62 3.4.2. Softwire Security Protocol . . . . . . . . . . . . . . 11 63 3.5. Guidelines for Usage of IPsec in Softwire . . . . . . . . 12 64 3.5.1. Authentication Issues . . . . . . . . . . . . . . . . 12 65 3.5.2. IPsec Pre-Shared Keys for Authentication . . . . . . . 13 66 3.5.3. Inter-operability guidelines . . . . . . . . . . . . . 13 67 3.5.4. IPsec filtering details . . . . . . . . . . . . . . . 14 68 4. Mesh Security Guidelines . . . . . . . . . . . . . . . . . . . 17 69 4.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 17 70 4.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 18 71 4.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 18 72 4.4. Applicability of Security Protection Mechanism . . . . . . 19 73 4.4.1. Security Protection Mechanism for Control Plane . . . 19 74 4.4.2. Security Protection Mechanism for Data Plane . . . . . 20 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 76 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 22 80 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 23 81 A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE . . . 24 82 A.2. IPv4 over IPv6 Softwire with example for IKE . . . . . . . 24 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 84 Intellectual Property and Copyright Statements . . . . . . . . . . 27 86 1. Introduction 88 The Softwire Working Group specifies the standardization of 89 discovery, control and encapsulation methods for connecting IPv4 90 networks across IPv6 networks and IPv6 networks across IPv4 networks. 91 The Softwire provides the connectivity to enable global reachability 92 of both address families by reusing or extending exisiting 93 technology. The Softwire Working Group is focusing on the two 94 scenarios that emerged when discussing the traversal of networks 95 composed of differing address families. This document provides the 96 security Guidelines for such two Softwire solution spaces such as 97 "Hubs and Spokes" and "Mesh" scenarios "Hubs and Spokes" and "Mesh" 98 problems described in [RFC4925] Section 2 and Section 3, 99 respectively. The protocols selected for Softwire connectivity 100 require the Security consideration on more specific deployment 101 scenarios for each solution. 103 Layer Two Tunneling Protocol (L2TPv2) is selected for "Hubs and 104 Spokes" solution. If L2TPv2 is used in the unprotected network, it 105 will be vulnerable to various security attacks and MUST be protected 106 by appropriate security protocol such as IPsec described in 107 [RFC3193]. Note that other adequate security mechanisms are 108 applicable, the security protocol for softwire is not necessarily 109 mandated. This document provides the implementation guidance (and 110 proper usage) of IPsec as the security protection mechanism by 111 considering the security vulnerabilities in "Hubs and Spokes" 112 scenarios. The new implementation SHOULD use IKEv2 in the key 113 management protocol for IPsec because of more reliable protocol and 114 integration of required protocols in a sigle platform. 116 The softwire "Mesh" solution should support various levels of 117 security mechanism to protect the data packets from an attacker being 118 transmitted on a softwire tunnel from the access networks with one 119 address family across the transit core operating with different 120 address family [RFC4925]. The security mechanism are also required 121 to be protected from control data modification, spoofing attack, etc. 122 As the security considerations for BGP is being discussed in other 123 working groups, this document provide general guidelines for the 124 deployment scenario being envisaged. 126 2. Terminology 128 The terminology is based on the softwire problem statement document 129 [RFC4925]. 131 AF(i) - Address Family. IPv4 or IPv6. Notation used to indicate 132 that prefixes, a node or network only deal with a single IP AF. 134 AF(i,j) - Notation used to indicate that a node is dual-stack or that 135 a network is composed of dual-stack nodes. 137 Address Family Border Router (AFBR) -A dual-stack router that 138 interconnects two networks that use either the same or different 139 address families. An AFBR forms peering relationships with other 140 AFBRs, adjacent core routers and attached CE routers, perform 141 softwire discovery and signaling, advertises client ASF(i) 142 reachability information and encapsulates/decapsulates customer 143 packets in softwire transport headers. 145 Customer Edge (CE) - A router located inside AF access island that 146 peers with other CE routers within the access island network and with 147 one or more upstream AFBRs. 149 Customer Premise Equipment (CPE) - An equipment, host or router, 150 located at a subscriber's premises and connected with a carrier's 151 access network. 153 Provider Edge (PE) - A router located at the edge of transit core 154 network that interfaces with CE in access island. 156 Softwire Concentrator (SC) - The node terminating the softwire in the 157 service provider network. 159 Softwire Initiator (SI) - The node initiating the softwire within the 160 customer network. 162 Softwire Encapsulation Set (SW-Encap) - A softwire encapsulation set 163 contains tunnel header parameters, order of preference of the tunnel 164 header types and the expected payload types (e.g. IPv4) carried 165 inside the softwire. 167 Softwire Next_Hop (SW-NHOP) - This attribute accompanies client AF 168 reachability advertisements and is used to reference a softwire on 169 the ingress AFBR leading to the specific prefixes. It contains a 170 softwire identifier value and a softwire next_hop IP address denoted 171 as . Its existence in the presence of client 172 AF prefixes (in advertisements or entries in a routing table) infers 173 the use of softwire to reach that prefix. 175 3. Hubs and Spokes Security Guidelines 177 3.1. Deployment Scenarios 179 To provide the security Guidelines, the discussion of the possible 180 deployment scenario and the trust relationship in the network is 181 important. 183 The Softwire initiator (SI) always resides in the customer network. 184 The node, in which the SI resides, can be the CPE access device, 185 another dedicated CPE router behind the original CPE access device or 186 any kind of host device such as PC, appliance, sensor etc. 188 However, the host device may not always have direct access to its 189 home carrier network, to which the user has subscribed. For example, 190 the softwire initiator in the laptop PC can access various access 191 networks such as Wi-Fi hot-spots, visited office network. This is 192 the nomadic case, which the Softwire SHOULD support. 194 As the softwire deployment models, the following three cases as shown 195 in Figure 1 should be considered. In these cases, the automated 196 discovery of the softwire concentrator (SC) may be used. But in this 197 document, the information on the SC such as the DNS name or IP 198 address is assumed to be configured by the user, or by the provider 199 of the softwire initiator in advance. 201 Case 1: The SI connects to the SC that belongs to the home network 202 service provider via the home access provider network. The IP 203 address of the host may be changed periodically due to the home 204 network service provider's policy. 206 Case 2: The SI connects to the SC that belongs to the home network 207 service provider via the visited access network. This is typical of 208 nomadic access use case. The host does not subscribe to the visited 209 access provider, but this provider has some roaming agreement with 210 the home network service provider of the host. The IP address of the 211 host may be changed periodically due to the home network service 212 provider's policy. 214 Case 3: The SI connects to the SC that belongs to the visited network 215 service provider via the visited access network. This is also 216 typical of nomadic access use case. The host does not subscribe to 217 the visited network service provider, but this provider has some 218 roaming agreement with the home network service provider of the host. 219 In this case, the IP address of the host is determined by the visited 220 network service provider's policy. 222 The trust relationship for these three cases will also be different. 223 The security consideration must take them into account. In 224 particular, to allow cases 2 and 3, the authentication infrastructure 225 between the SI and the SC is needed to establish the trust 226 relationship. The softwire problem statement states that the 227 softwire solution must be able to be integrated with commonly 228 deployed AAA solution. In these cases, AAA interactions between the 229 home network service provider and visited access/service provider 230 should be considered. The details of this scenario are given in 231 Section Section 3.2. 233 visited network visited network 234 access provider service provider 235 +---------------------------------+ 236 | | 237 +......v......+ +.....................|......+ 238 . . . v . 239 +------+ . (case 3) . . +------+ +--------+ . 240 | |=====================.==| | | | . 241 | SI |__.________ . . | SC |<---->| AAAv | . 242 | |---------- \ . . | | | | . 243 +------+ . \\ . . +------+ +--------+ . 244 . \\ . . ^ . 245 ^ +..........\\.+ +.....................|......+ 246 | \\ | 247 | (case 2) \\ | 248 | \\ | 249 | \\ | 250 | +............+ \\ +.....................|......+ 251 . . \\. v . 252 +------+ . . \\__+------+ +--------+ . 253 | | . (case 1) . ---| | | | . 254 | SI |=====================.==| SC |<---->| AAAh | . 255 | | . . . | | | | . 256 +------+ . . . +------+ +--------+ . 257 . . . . 258 +............+ +............................+ 259 home network home network 260 access provider service provider 262 Figure 1: Hubs and Spokes model 264 3.2. Trust Relationship 266 To perform authentication between the SC and the SI, the AAA server 267 needs to be involved. One or more AAA servers should reside in the 268 same administrative domain as the SC to authenticate the SI. When 269 the SI is mobile, it may roam from the home ISP network to another, 270 e.g. a WiFi hot-spot network. In such a situation, the SI may not 271 always connect to the same SC. From the SI's viewpoint, the AAA 272 server that is in the same administrative domain is called the home 273 AAA server and those not in the same administrative domain are called 274 visited AAA servers. The trust relationships between those nodes are 275 as follows: 277 It can be assumed that the SC and the AAA in the same administrative 278 domain share a trust relationship. When the SC needs to authenticate 279 the SI, the SC communicates with the AAA server to request 280 authentication and/or to obtain security information. If the SI 281 roams into a network that is not in the same administrative domain, 282 the visited AAA server communicates with the home AAA server that has 283 the SI's security information. Therefore, the communication between 284 the SC and the AAA server must be protected. It can be usually 285 assumed that the home and visited AAA servers share a trust 286 relationship and the connection between them is protected. 288 It can be assumed that the SI and the home AAA server share a trust 289 relationship. The home AAA server provides security information on 290 the SI when it is requested by the visited AAA server. The SI and 291 the visited AAA server do not usually have a trust relationship; 292 however, if the SI can confirm that the home AAA server is involved 293 with the authentication of the SI and the visited AAA server does not 294 alter security information from the home AAA server, the visited AAA 295 server can be trusted by the SI. The communication between the SI, 296 the home and visited AAA servers must be protected. 298 The SI and the SC do not necessarily share a trust relationship 299 especially when the SI roams into a different administrative domain. 300 When they are mutually authenticated by means of e.g. AAA servers, 301 they can start trusting each other. Unless authentication is 302 successfully performed, the softwire protocol should not be 303 initiated. 305 3.3. Softwire Security Threat Scenarios 307 Softwire can be used to connect IPv6 networks across public IPv4 308 networks and IPv4 networks across public IPv6 networks. The control 309 and data packets used during the softwire session are vulnerable to 310 attack. 312 A complete threat analysis of softwire requires examination of the 313 protocols used for the softwire setup, the encapsulation method used 314 to transport the payload, and other protocols used for configuration 315 (e.g., router advertisements, DHCP). 317 The softwire solution uses a subset of the Layer2Tunneling Protocol 318 (L2TPv2) functionality[RFC2661], [I-D.ietf-softwire-hs-framework- 319 l2tpv2]. In the Softwire "Hubs and Spokes" model, L2TPv2 is used in 320 a voluntary tunnel model only. The Softwire Initiator (SI) acts as a 321 L2TP Access Concentrator (LAC) and PPP endpoint. The L2TPv2 tunnel 322 is always initiated from the SI. 324 Generic threat analysis done for L2TP using IPsec [RFC3193] is 325 applicable to Softwire "Hubs and Spokes" deployment. The threat 326 analysis for other protocols such as PANA [RFC4016], NSIS [RFC4081], 327 and Routing Protocols [RFC4593] are applicable here as well and 328 should be used as reference. 330 First, SI resided in the customer network sends Start-Control- 331 Connection-Request(SCCRQ) packet to SC for the initiation of 332 Softwire. Optionally, L2TP exchanges Challenge and Response AVPs for 333 tunnel mutual authentication in L2TPv2 tunnel creation. For the CHAP 334 authentication key, L2TPv2 protocol does not provide the key 335 management facilities. 337 Once L2TPv2 process has been completed, the SI and SC optionally 338 enter authentication phase after completing PPP Link Control Protocol 339 (LCP) negotiation. PPP authentication supports one way or two way 340 CHAP authentication, which can be interworked with AAA. Other 341 authentication of PAP authentication, MS-CHAP, and EAP MAY be 342 supported. But PPP authentication does not provide per-packet 343 authentication. 345 PPP encryption is defined but PPP Encryption Control Protocol (ECP) 346 negotiation does not provide for a protected cipher suite 347 negotiation. PPP encryption provides a weak security solution 348 [RFC3193]. PPP ECP implementation cannot be expected. PPP 349 authentication also does not provide the scalable key management. 351 Once the access is granted to the SI, other protocols start for 352 network configuration and the node in the SI side will exchange data 353 with other nodes in the network connected through SC. 355 These steps are vulnerable to man-in-the-middle (MITM), denial of 356 service (DoS), and Service theft attacks, which are caused as the 357 consequence of the following adversary actions. 359 Adversary attacks on softwire include: 361 1. An adversary may try to discover identities by snooping data 362 packets. 364 2. An adversary may try to modify both control and data packets. 365 This type of attack involves integrity violations. 367 3. An adversary may try to eavesdrop and collect control messages. 368 By replaying these messages, an adversary may successfully hijack 369 the L2TP tunnel or the PPP connection inside the tunnel. An 370 adversary might mount MITM, DOS, and theft of service attacks. 372 4. An adversary can flood the Softwire node with bogus signaling 373 messages to cause DoS attacks by terminating L2TP tunnels or PPP 374 connections. 376 5. An adversary may attempt to disrupt the softwire negotiation in 377 order to weaken or remove confidentiality protection. 379 6. An adversary may wish to disrupt the PPP LCP authentication 380 negotiation. 382 In environments where the link is shared without cryptographic 383 protections and the weak authentication or one-way authentication is 384 used, these security attacks can be mounted on softwire control and 385 data packets. 387 To access the SC through the public networks, any node can pretend to 388 be a SC, if there is no prior trust relationship between SI and SC. 389 In this case, an adversary may impersonate the SC to intercept 390 traffic ("rogue" softwire concentrator). 392 The rogue SC captures all of necessary information (including keys if 393 security is present) of a legitimate Softwire node and remove the 394 message of the subgroup of the network. The rogue SC can introduce a 395 black hole attack in which the attacker sends out forged routing 396 packets and setup a route to some destination via itself and when the 397 actual data packets get in they are simply dropped, forming a black 398 hole at the SC - where data enters but never leaves. Another 399 possibility is for the attacker to forge routes pointing into an area 400 where the destination node is not located. Everything will be routed 401 into this area but nothing will leave. 403 The deployment of ingress filtering is able to control the malicious 404 users' access. Without specific ingress filtering checks in the 405 decapsulator at SC, it would be possible for an attacker to inject a 406 false packet. This causes DoS attack. The inner address ingress 407 filtering can reject invalid inner source address. Without inner 408 address ingress filtering, another kind of attack can happen. The 409 malicious users from another ISP could start using its tunneling 410 infrastructure to get free inner address connectivity, transforming 411 effectively the ISP into an inner address transit provider. 413 While this does not provide the complete protection in the case an 414 address spoofing has been happened. To protect address spoofing, 415 authentication MUST be implemented in the tunnel encapsulation. 417 3.4. Softwire Security Guidelines 419 Based on the security threat analysis in Section 3.3 in this 420 document, Softwire security protocol must support the following 421 protections. 423 1. Softwire control messages between the SI and the SC MUST BE 424 protected against eavesdropping and spoofing attacks. 426 2. Softwire security protocol MUST be able to protect itself against 427 replay attacks. 429 3. Softwire security protocol MUST be able to protect the device 430 identifier against the impersonation when it is exchanged between 431 the SI and the SC. 433 4. Softwire security protocol MUST be able to securely bind the 434 authenticated session to the device identifier of the client, to 435 prevent service theft. 437 5. Softwire security protocol MUST be able to protect disconnect and 438 revocation messages. 440 The Softwire security protocol requirement is comparable to RFC3193. 441 For Softwire control packets, authentication, integrity and replay 442 protection MUST be supported and confidentiality SHOULD be supported. 443 For Softwire data packets, authentication, integrity and replay 444 protection MUST be supported and confidentiality MAY be supported. 446 The Softwire problem statement [RFC4925] provides some requirements 447 for "Hubs and Spoke" solution that are taken into account in defining 448 the security protection mechanisms. 450 1. control and/or data plane must be able to provide full payload 451 security when desired. 453 2. deployed technology must be very strongly considered 455 This additional security protection must be separable from the 456 Softwire tunneling mechanism. 458 Note that the scope of the security is on the L2TP tunnel between the 459 SI and SC. If end to end security is required, a security protocol 460 should be used in the payload packets. But this is out of scope of 461 this document. 463 3.4.1. Authentication 465 The softwire security protocol MUST support user authentication in 466 the control plane, in order to authorize access to the service, and 467 provide adequate logging of activity. The protocol SHOULD offer 468 mutual authentication in scenarios where the SI requires identity 469 proof from the SC, for example, SI accesses to SC across the public 470 network. 472 In some circumstances, the service provider may decide to allow non- 473 authenticated connection [I-D.softwire-hs-framework-l2tpv2]. For 474 example, when the customer is already authenticated by some other 475 means, such as closed networks, cellular networks at Layer 2, etc., 476 the service provider may decide to turn it off. If no authentication 477 is conducted on any layer, the SC acts as a gateway for anonymous 478 connections. Running such a service MUST be configurable by the SC 479 administrator and the SC SHOULD take some security measures such as 480 ingress filtering and adequate logging of activity. It should be 481 noted that anonymous connection service cannot provide the security 482 functionalities described in this document (e.g. integrity, replay 483 protection and confidentiality). 485 3.4.1.1. PPP Authentication 487 PPP can provide mutual authentication between the SI and SC using 488 CHAP [RFC1994] during the connection establishment phase (Link 489 Control Protocol, LCP). PPP CHAP authentication can be used when the 490 SI and SC are on a trusted, non-public IP network. 492 Since CHAP does not provide per-packet authentication, integrity, or 493 replay protection, PPP CHAP authentication MUST NOT be used for 494 unprotected on a public IP network. This means that there is no 495 reason to prohibit PPP CHAP authentication if appropriate protected 496 mechanism has been applied. 498 Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY 499 be supported. 501 3.4.1.1.1. L2TPv2 Authentication 503 L2TPv2 provides an optional CHAP-like[RFC1994] tunnel authentication 504 during the control connection establishment [RFC2661, 5.1.1]. L2TPv2 505 authentication MUST not be used for unprotected on a public IP 506 network as the same restriction applied to PPP CHAP. 508 3.4.2. Softwire Security Protocol 510 To meet the above requirements, all softwire security compliant 511 implementations MUST implement the following security protocols. 513 IPsec ESP[RFC4303]in transport mode for securing softwire control and 514 data packets. Internet Key Exchange (IKE) protocol[RFC4306] MUST be 515 supported for authentication, security association negotiation and 516 key management for IPsec. The applicability of different version of 517 IKE is discussed in Section 3.5. 519 The softwire security protocol MUST support NAT traversal. UDP 520 encapsulation of IPsec ESP packets[RFC3948] and negotiation of NAT- 521 traversal in IKE[RFC3947] MUST be supported when IPsec is used. 523 3.5. Guidelines for Usage of IPsec in Softwire 525 [RFC3193] discusses how L2TP can use IPsec to provide tunnel 526 authentication, privacy protection, integrity checking and replay 527 protection. Since it's publication, revision to IPsec protocols have 528 been published (IKEv2 [RFC4306], ESP [RFC4303], NAT-traversal for IKE 529 [RFC3947] and ESP[RFC3948]). 531 Although [RFC3193] can be applied in the softwire "Hubs and Spokes" 532 solution, softwire requirements such as NAT-traversal, NAT-traversal 533 for IKE [RFC3947] and ESP [RFC3948] MUST be supported. 535 IKEv2 [RFC4306] integrates NAT-traversal. IKEv2 also supports EAP 536 authentication with the authentication using shared secrets and 537 public key signatures. IKEv2 is more reliable protocol than IKE 538 [RFC2409] for the replay protection capability, DoS protection 539 enabled mechanism etc. Therefore, new implementations SHOULD use 540 IKEv2 over IKE. 542 IKEv2 [RFC4306] supports legacy authentication methods that may be 543 useful in environments where username and password based 544 authentication is already deployed. 546 The following sections will discuss using IPsec to protect L2TPv2 as 547 applied in the softwire "Hubs and Spokes" model. Unless otherwise 548 stated, IKEv2 and the new IPsec architecture [RFC4301] is assumed. 550 3.5.1. Authentication Issues 552 IPsec implementation using IKE only supports machine authentication. 553 There is no way to verify a user identity and to segregate the tunnel 554 traffic among users in the multi-user machine environment. IKEv2 can 555 support user authentication with EAP payload by leveraging existing 556 authentication infrastructure and credential database. This enables 557 the traffic segregation among users when user authentication is used 558 by combining the legacy authentication. The user identity asserted 559 within IKEv2 will be verified on a per-packet basis. 561 If the AAA server is involved in security association establishment 562 between the SI and SC, a session key can be derived from the 563 authentication between the SI and the AAA server. Such a scenario 564 can be found in [I-D.draft-eronen-ipsec-ikev2-eap-auth-05]. 565 Successful EAP exchanges within IKEv2 runs between the SI and the AAA 566 server create a session key and it is securely transferred to the SC 567 from the AAA server. The trust relationship between the involved 568 entities follows Section 3.2 of this document. 570 3.5.2. IPsec Pre-Shared Keys for Authentication 572 With IPsec, when the identity asserted in IKE is authenticated, the 573 resulting derived keys are used to provide per-packet authentication, 574 integrity and replay protection. As a result, the identity verified 575 in the IKE is subsequently verified on reception of each packet. 577 Authentication using pre-shared keys can be used when the number of 578 SI and SC is small. AS the number of SI and SC grows, pre-shared 579 keys becomes increasingly difficult to manage. A softwire security 580 protocol must provide a scalable approach to key management. 581 Whenever possible, authentication with certificates is preferred. 583 When pre-shared keys are used, group pre-shared keys MUST NOT be used 584 because of its vulnerability to Man-In-The-Middle attacks ([RFC3193], 585 5.1.4). 587 3.5.3. Inter-operability guidelines 589 The L2TPv2/IPsec inter-operability concerning tunnel teardown, 590 fragmentation and per-packet security checks given in ([RFC3193] 591 section 3) must be taken into account. 593 Although the L2TP specification allows the responder (SC in softwire) 594 to use a new IP address or to change the port number when sending the 595 Start-Control-Connection-Request-Reply (SCCRP), a softwire 596 concentrator implementation SHOULD NOT do this ([RFC3193] section 4). 598 However, with some reasons, for example, "load-balancing" between 599 SCs, the IP address change is required. To signal an IP address 600 change, the SC sends a StopCCN message to the SI using the Result and 601 Error Code AVP in L2TPv2 message. A new IKE_SA and CHILD_SA must be 602 established to the new IP address. 604 3.5.4. IPsec filtering details 606 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 607 the security policy database (SPD) examples in[RFC3193] appendix A 608 can be applied to softwire model. In that case, the initiator is 609 always the client (SI), and responder is the SC. IPsec SPD examples 610 for IKE [RFC2409] are also given in appendix A of this document. 612 The revised IPsec architecture [RFC4301] redefined the SPD entries to 613 provide more flexibility (multiple selectors per entry, list of 614 address range, peer authentication database (PAD), "populate from 615 packet"(PFP) flag, etc.). The Internet Key Exchange (IKE) has also 616 been revised and simplified in IKEv2 [RFC4306], [RFC4306]. The 617 following sections provides the SPD examples for softwire to use the 618 revised IPsec architecture and IKEv2. 620 3.5.4.1. IPv6 over IPv4 Softwire L2TPv2 example for IKEv2 622 If IKEv2 is used as the key management protocol, RFC4301 provides the 623 guidance of the SPD etnries. In IKEv2, we can use PFP flag to 624 specify SA and the port number can be selected with Traffic Selector 625 with TSr during CREATE_CHILD_SA. The following describes PAD entries 626 on the SI and SC, respectively. The PAD entries are only example 627 configurations. The PAD entries specify that the IP address in the 628 traffic selector payload (SC_address and SI_address) is used for 629 matching against the SPD. 631 SI PAD: 632 - IF remote_identity = SI_identity 633 Then authenticate (shared secret/certificate/) 634 and authorize CHILD_SA for remote address SC_address 636 SC PAD: 637 - IF remote_identity = user_1 638 Then authenticate (shared secret/certificate/EAP) 639 and authorize CHILD_SAs for remote address SI_address 641 The following describes the SPD entries for the SI and SC, 642 respectively. Note that IKEv2 and ESP traffic MUST be allowed 643 (bypass). These include IP protocol 50 and UDP port 500 and 4500. 645 The IPv4 packet format of ESP protecting L2TPv2 carrying IPv6 packet 646 is shown in Table 1 by uning the similar Table in [RFC4891]. 648 +----------------------------+------------------------------------+ 649 | Components (first to last) | Contains | 650 +----------------------------+------------------------------------+ 651 | IPv4 header | (src = IPv4-SI, dst = IPv4-SC) | 652 | ESP header | | 653 | UDP header | (src port=1701, dst port=1701) | 654 | L2TPv2 header | | 655 | PPP header | | 656 | IPv6 header | | 657 | (payload) | | 658 | ESP ICV | | 659 +----------------------------+------------------------------------+ 661 Table 1: Packet Format for L2TPv2 with ESP carrying IPv6 packet. 663 SPD for Softwire Initiator: 665 Softwire Initiator SPD-S 666 - IF local_address=IPv4-SI 667 remote_address=IPv4-SC 668 proto=UDP 669 local_port=1701 670 remote_port=ANY (PFP=1) 671 Then use SA ESP transport mode 672 Initiate using IDi = user_1 to address IPv4-SC 674 SPD for Softwire Concentrator: 676 Softwire Concentrator SPD-S 677 - IF local_address=IPv4-SC 678 remote_address=ANY (PFP=1) 679 proto=UDP 680 local_port=1701 681 remote_port=ANY (PFP=1) 682 Then use SA ESP transport mode 684 3.5.4.2. IPv4 over IPv6 Softwire L2TPv2 example for IKEv2 686 The PAD entries are only example configurations. The PAD entries 687 specify that the IP address in the traffic selector payload 688 (SC_address and SI_address) is used for matching against the SPD. 690 SI PAD: 691 - IF remote_identity = SI_identity 692 Then authenticate (shared secret/certificate/) 693 and authorize CHILD_SA for remote address SC_address 695 SC PAD: 696 - IF remote_identity = user_2 697 Then authenticate (shared secret/certificate/EAP) 698 and authorize CHILD_SAs for remote address SI_address 700 The following describes the SPD entries for the SI and SC, 701 respectively. In this example, the softwire initiator and 702 concentrator are denoted with IPv6 addresses IPv6-SI and IPv6-SC, 703 respectively. Note that IKEv2 and ESP traffic MUST be allowed 704 (bypass). These include IP protocol 50 and UDP port 500 and 4500. 706 The IPv6 packet format of ESP protecting L2TPv2 carrying IPv4 packet 707 is shown in Table 2 by using similar one in [RFC4891]. 709 +----------------------------+------------------------------------+ 710 | Components (first to last) | Contains | 711 +----------------------------+------------------------------------+ 712 | IPv6 header | (src = IPv6-SI, dst = IPv6-SC) | 713 | ESP header | | 714 | UDP header | (src port=1701, dst port=1701) | 715 | L2TPv2 header | | 716 | PPP header | | 717 | IPv4 header | | 718 | (payload) | | 719 | ESP ICV | | 720 +----------------------------+------------------------------------+ 722 Table 2: Packet Format for L2TPv2 with ESP carrying IPv4 packet. 724 SPD for Softwire Initiator: 726 Softwire Initiator SPD-S 727 - IF local_address=IPv6-SI 728 remote_address=IPv6-SC 729 proto=UDP 730 local_port=1701 731 remote_port=ANY (PFP=1) 732 Then use SA ESP transport mode 733 Initiate using IDi = user_2 to address IPv6-SC 735 SPD for Softwire Concentrator: 737 Softwire Concentrator SPD-S 738 - IF local_address=IPv6-SC 739 remote_address=ANY (PFP=1) 740 proto=UDP 741 local_port=1701 742 remote_port=ANY (PFP=1) 743 Then use SA ESP transport mode 745 4. Mesh Security Guidelines 747 4.1. Deployment Scenario 749 In the softwire "Mesh" solution, it is required to establish 750 connectivity to access network islands of one address family type 751 across a transit core of a differing address family type [RFC4925]. 752 To provide reachability across the transit core, AFBRs are installed 753 between access network island and transit core network. These AFBRs 754 can perform as Provider Edge routers (PE) within an autonomous system 755 or perform peering across autonomous systems. The AFBRs establish 756 and encapsulate softwires in a mesh to the other islands across the 757 transit core network. The transit core network consists of one or 758 more service providers. 760 In the softwire "Mesh" solution, a pair of PE routers (AFBRs) use BGP 761 to exchange routing information. AFBR nodes in the transit network 762 are Internal BGP speakers and will peer with each other directly or 763 via a route reflector to exchange SW-encap sets, perform softwire 764 signaling, and advertise AF access island reachability information 765 and SW-NHOP information. If such information is advertised within an 766 autonomous system, the AFBR node receiving them from other AFBRs does 767 not forward them to other AFBR nodes. To exchange the information 768 among AFBRs, the full mesh connectivity will be established. 770 The connectivity between CE and PE routers includes dedicated 771 physical circuits, logical circuits (such as Frame Relay and ATM), 772 and shared medium access (such as Ethernet-based access). 774 When AFBRs are PE routers located at the edge of the provider core 775 networks, this is similar architecture of the L3VPN described in 776 [RFC4364]. The connectivity between a CE router in access island 777 network and a PE router in transit network is established by static 778 way. The access islands are enterprise networks accommodated through 779 PE routers in the provider's transit network. In this case, the 780 access island networks are administrated by the provider's autonomous 781 system. 783 The AFBRs may have the multiple connections to the core network, and 784 also may have the connections to the multiple client access networks. 785 The client access networks may connect each other through private 786 networks or through the Internet. When the client access networks 787 have their own AS number, a CE router located inside access islands 788 forms a private BGP peering with an AFBR. Further, an AFBR may need 789 to exchange a full Internet routing information with each network to 790 which it connects. 792 4.2. Trust Relationship 794 All AFBR nodes in the transit core MUST have a trust relationship or 795 an agreement with each other to establish softwires. When the 796 transit core consists of a single administrative domain, it is 797 assumed that all nodes (e.g. AFBR, PE or Route Reflector, if 798 applicable) are trusted with each other. 800 If the transit core consists of multiple administrative domains, 801 intermediate routers between AFBRs may not be trusted. 803 There MUST be a trust relationship between the PE in the transit core 804 and the CE in the corresponding island, although the link(s) between 805 the PE and the CE may not be protected. 807 4.3. Softwire Security Threat Scenarios 809 AS the architecture of softwire mesh solution is very similar to that 810 of the provider provisioned VPN (PPVPN). The security threats 811 considerations on the PPVPN operation are applicable to those in the 812 softwire mesh solution [RFC4111]. 814 Examples of attacks to data packets being transmitted on a softwire 815 tunnel include: 817 1. An adversary may try to discover confidential information by 818 sniffing softwire packets. 820 2. An adversary may try to modify the contents of softwire packets. 822 3. An adversary may try to spoof the softwire packets that do not 823 belong the authorized domains and to insert copies of once- 824 legitimate packets that have been recorded and replayed. 826 4. An adversary can launch Denial-of-Service (DoS) attack by 827 deleting softwire data traffic. DoS attacks of the resource 828 exhaustion type can be mounted against the data plane by spoofing 829 a large amount of non-authenticated data into the softwire from 830 the outside of the softwire tunnel. 832 5. An adversary may try to sniff softwire packets and to examine 833 aspects or meta-aspects of them that may be visible even when the 834 packets themselves are encrypted. An attacker might gain useful 835 information based on the amount and timing of traffic, packet 836 sizes, sources and destination addresses, etc. 838 The security attacks can be mounted on the control plane as well. In 839 softwire mesh solution, softwires encapsulation will be setup by 840 using BGP. As described in [RFC4272], BGP is vulnerable to various 841 security threats such as confidential violation, replay attacks, 842 insertion, deletion and modification of BGP messages, main-in-the- 843 middle, and denial-of-service. 845 4.4. Applicability of Security Protection Mechanism 847 Given that security is generally a compromise between expense and 848 risk, it is also useful to consider the likelihood of different 849 attacks. There is at least a perceived difference in the likelihood 850 of most types of attacks being successfully mounted in different 851 deployment. 853 The trust relationship among users in access networks, transit core 854 provider, and other parts of networks described in section 4.2 is a 855 key element in determining the applicability of security protection 856 mechanism for the specific softwire mesh deployment. 858 4.4.1. Security Protection Mechanism for Control Plane 860 The Softwire Problem Statement [RFC4925] states that the softwire 861 mesh setup mechanism to advertise the softwire encapsulation MUST 862 support authentication, but the transit core provider may decide to 863 turn it off in some circumstances. 865 The BGP authentication mechanism is specified in [RFC2385]. The 866 mechanism defined in [RFC2385] is based on a one-way hash function 867 (MD5) and use of a secret key. The key is shared between a pair of 868 peer routers and is used to generate 16-byte message authentication 869 code values that are not readily computed by an attacker who does not 870 have access to the key. 872 However the security mechanism for BGP transport (e.g. TCP-MD5) is 873 inadequate in some circumstances and also requires operator 874 interaction to maintain a respectable level of security. The current 875 deployments of TCP-MD5 exhibit some shortcomings with respect of key 876 management as described in [RFC3562]. 878 Key management can be especially cumbersome for operators. The 879 number of keys required and the maintenance of keys (issue/revoke/ 880 renew) has had an additive effect as a barrier to deployment. Thus 881 automated means of managing keys, to reduce operational burdens, is 882 available in BGP security system [I-D.rpsec-bgpsecrec], [RFC4107]. 884 Use of IPsec counters the message insertion, deletion, and 885 modification attacks, as well as man-in-the-middle attacks by 886 outsiders. If routing data confidentiality is desired, the use of 887 IPsec ESP could provide that service. If eavesdropping attack is 888 identified as a threat, ESP can be used to provide confidentiality 889 (encryption), integrity and authentication for the BGP session. 891 4.4.2. Security Protection Mechanism for Data Plane 893 To transport data packets across the transit core, the mesh solution 894 defines multiple encapsulations: L2TPv3, IP-in-IP, MPLS (LDP-based 895 and RSVP-TE based), and GRE. To securely transport such data packet, 896 the softwire must support IPsec tunnel. 898 IPsec can provide authentication and integrity. The implementation 899 MUST support ESP with null encryption RFC4303. If some part of the 900 transit core network is not trusted, ESP with encryption may be 901 applied. 903 The automated key distribution can be performed by IKE with the pre- 904 shared key management. But the implementation of IPsec with 905 automatic key management depends on the operational requirements, for 906 example, the scalability requirement, etc. 908 To provide replay protection, automated key management system using 909 IKEv2 can be used. IKEv2 can be applied using shared secrets for 910 authentication when the number of BGP peers is small. When the 911 number of BGP peers is large, managing the shared secrets on all 912 peers does not scale. In this scenario, public-key digital signature 913 or key encryption authentication in IKE should be used, assuming that 914 the peers have the necessary computation available. 916 If the link(s) between the user's site and the provider's PE is not 917 trusted, then encryption may be used on the PE-CE link(s). 919 Together with the cryptographic security protection, the access 920 control technique reduces the exposure to attacks from outside the 921 service provider networks (transit networks). The access control 922 technique includes packet-by-packet or packet flow-by-packet flow 923 access control by means of filters as well as by means of admitting a 924 session for a control/signaling/management protocol that is being 925 used to implement softwire mesh. 927 The access control technique is an important protection against 928 security attacks of DoS etc. and a necessary adjunct to cryptographic 929 strength in encapsulation. Packets that match the criteria 930 associated with a particular filter may be either discarded or given 931 special treatment to prevent an attack or to mitigate the effect of a 932 possible future attack. 934 5. Security Considerations 936 This document discusses various security threats for the softwire 937 control and data packets in "Hubs and Spokes" and "Mesh" time-to- 938 market solutions. With these discussions, the softwire security 939 protocol implementations are provided referencing to Softwire Problem 940 Statement [RFC4925], Securing L2TP using IPsec [RFC3193], Security 941 Framework for PPVPNs [RFC4111], and Guidelines for Mandating the Use 942 of IPsec [I-D.bellovin-useipsec]. The guidelines for the security 943 protocol employment are also given considering the specific 944 deployment context. 946 Note that this document discusses the softwire tunnel security 947 protection and does not address the end-to-end protection. 949 6. Acknowledgments 951 The authors would like to thank Tero Kivinen for reviewing the 952 document and Francis Dupont for substative suggestions and to 953 acknowledg Jordi Palet Martinez, Shin Miyakawa, Yasuhiro Shirasaki, 954 and Bruno Stevant for their feedback. 956 We would like also to thank the authors of Softwire Hub & Spoke 957 Deployment Framework document for providing the text concerning 958 security. 960 7. References 962 7.1. Normative References 964 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 965 Protocol (CHAP)", RFC 1994, August 1996. 967 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 968 Signature Option", RFC 2385, August 1998. 970 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 971 Internet Protocol", RFC 2401, November 1998. 973 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 974 (IKE)", RFC 2409, November 1998. 976 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 977 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 978 RFC 2661, August 1999. 980 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 981 "Securing L2TP using IPsec", RFC 3193, November 2001. 983 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 984 Signature Option", RFC 3562, July 2003. 986 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 987 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 988 January 2005. 990 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 991 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 992 RFC 3948, January 2005. 994 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 995 Key Management", BCP 107, RFC 4107, June 2005. 997 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 998 Internet Protocol", RFC 4301, December 2005. 1000 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1001 RFC 4303, December 2005. 1003 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1004 RFC 4306, December 2005. 1006 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1007 Routing Protocols", RFC 4593, October 2006. 1009 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 1010 Problem Statement", RFC 4925, July 2007. 1012 7.2. Informative References 1014 [I-D.bellovin-useipsec] 1015 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 1016 draft-bellovin-useipsec-04 (work in progress), 1017 September 2005. 1019 [I-D.ietf-softwire-hs-framework-l2tpv2] 1020 Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. 1022 Tremblay, "Softwires Hub & Spoke Deployment Framework with 1023 L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-07 (work 1024 in progress), September 2007. 1026 [I-D.ietf-softwire-mesh-framework] 1027 Wu, J., "Softwire Mesh Framework", 1028 draft-ietf-softwire-mesh-framework-02 (work in progress), 1029 July 2007. 1031 [I-D.rpsec-bgpsecrec] 1032 Christian, B. and T. Tauber, "BGP Security Requirements", 1033 draft-ietf-rpsec-bgpsecrec-06 (work in progress), 1034 April 2006. 1036 [I-D.v6ops-tunneling-requirements] 1037 Durand, A. and F. Parent, "Requirements for assisted 1038 tunneling", 1039 draft-durand-v6ops-assisted-tunneling-requirements-00 1040 (work in progress), September 2004. 1042 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1043 and Network Access (PANA) Threat Analysis and Security 1044 Requirements", RFC 4016, March 2005. 1046 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1047 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1049 [RFC4111] Fang, L., "Security Framework for Provider-Provisioned 1050 Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. 1052 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1053 RFC 4272, January 2006. 1055 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1056 Networks (VPNs)", RFC 4364, February 2006. 1058 [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. 1059 Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 1060 RFC 4891, May 2007. 1062 Appendix A. 1064 If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used, 1065 the SPD examples in [RFC3193] is applicable to "Hub & Spokes" model. 1066 In this model, the initiator is always the client (SI) and the 1067 responder is the SC. 1069 A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE 1071 IPv4 addresses of the softwire initiator and concentrator are denoted 1072 by IPv4-SI and IPv4-SC, respectively. If NAT traversal is used in 1073 IKE, UDP source and destination ports are 4500. In this SPD entry, 1074 IKE refers to UDP port 500. * denotes wildcard and indicates ANY port 1075 or address. 1077 Local Remote Protocol Action 1078 ----- ------ -------- ------ 1079 IPV4-SI IPV4-SC ESP BYPASS 1080 IPV4-SI IPV4-SC IKE BYPASS 1081 IPv4-SI IPV4-SC UDP, src 1701, dst 1701 PROTECT(ESP,transport) 1082 IPv4-SC IPv4-SI UDP, src * , dst 1701 PROTECT(ESP,transport) 1084 Softwire initiator SPD 1086 Remote Local Protocol Action 1087 ------ ------ -------- ------ 1088 * IPV4-SC ESP BYPASS 1089 * IPV4-SC IKE BYPASS 1090 * IPV4-SC UDP, src * , dst 1701 PROTECT(ESP,transport) 1092 Softwire concentrator SPD 1094 A.2. IPv4 over IPv6 Softwire with example for IKE 1096 IPv6 addresses of the softwire initiator and concentrator are denoted 1097 by IPv6-SI and IPv6-SC, respectively. If NAT traversal is used in 1098 IKE, UDP source and destination ports are 4500. In this SPD entry, 1099 IKE refers to UDP port 500. * denotes wildcard and indicates ANY port 1100 or address. 1102 Local Remote Protocol Action 1103 ----- ------ -------- ------ 1104 IPV6-SI IPV6-SC ESP BYPASS 1105 IPV6-SI IPV6-SC IKE BYPASS 1106 IPv6-SI IPV6-SC UDP, src 1701, dst 1701 PROTECT(ESP,transport) 1107 IPv6-SC IPv6-SI UDP, src * , dst 1701 PROTECT(ESP,transport) 1108 Softwire initiator SPD 1110 Remote Local Protocol Action 1111 ------ ------ -------- ------ 1112 * IPV6-SC ESP BYPASS 1113 * IPV6-SC IKE BYPASS 1114 * IPV6-SC UDP, src * , dst 1701 PROTECT(ESP,transport) 1116 Softwire concentrator SPD 1118 Authors' Addresses 1120 Shu Yamamoto 1121 KDDI R&D Labs 1122 2-1-15 Fujimino-shi 1123 Saitama, 356-8502 1124 Japan 1126 Phone: 81 (49) 278-7311 1127 Email: shu@kddilabs.jp 1129 Carl Williams 1130 KDDI R&D Labs 1131 Palo Alto, CA 94301 1132 USA 1134 Phone: +1.650.279.5903 1135 Email: carlw@mcsr-labs.org 1137 Florent Parent 1138 Beon Solutions 1139 Quebec, QC 1140 Canada 1142 Phone: +1 418 353 0857 1143 Email: Florent.Parent@beon.ca 1144 Hidetoshi Yokota 1145 KDDI R&D Labs 1146 2-1-15 Ohara 1147 Fujimino, Saitama 356-8502 1148 Japan 1150 Phone: 81 (49) 278-7894 1151 Email: yokota@kddilabs.jp 1153 Full Copyright Statement 1155 Copyright (C) The IETF Trust (2007). 1157 This document is subject to the rights, licenses and restrictions 1158 contained in BCP 78, and except as set forth therein, the authors 1159 retain all their rights. 1161 This document and the information contained herein are provided on an 1162 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1163 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1164 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1165 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1166 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1167 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1169 Intellectual Property 1171 The IETF takes no position regarding the validity or scope of any 1172 Intellectual Property Rights or other rights that might be claimed to 1173 pertain to the implementation or use of the technology described in 1174 this document or the extent to which any license under such rights 1175 might or might not be available; nor does it represent that it has 1176 made any independent effort to identify any such rights. Information 1177 on the procedures with respect to rights in RFC documents can be 1178 found in BCP 78 and BCP 79. 1180 Copies of IPR disclosures made to the IETF Secretariat and any 1181 assurances of licenses to be made available, or the result of an 1182 attempt made to obtain a general license or permission for the use of 1183 such proprietary rights by implementers or users of this 1184 specification can be obtained from the IETF on-line IPR repository at 1185 http://www.ietf.org/ipr. 1187 The IETF invites any interested party to bring to its attention any 1188 copyrights, patents or patent applications, or other proprietary 1189 rights that may cover technology that may be required to implement 1190 this standard. Please address the information to the IETF at 1191 ietf-ipr@ietf.org. 1193 Acknowledgment 1195 Funding for the RFC Editor function is provided by the IETF 1196 Administrative Support Activity (IASA).