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