idnits 2.17.1 draft-ietf-softwire-security-requirements-02.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 1138. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1162. 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 5 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 103: '... solution MUST use IPsec if the secu...' RFC 2119 keyword, line 107: '...cenarios. IKEv2 SHOULD be used in the...' RFC 2119 keyword, line 117: '... MUST be implemented in BGP. When t...' RFC 2119 keyword, line 120: '... mechanism MUST be used for BGP sign...' RFC 2119 keyword, line 121: '...d the secure encapsulation method MUST...' (32 more instances...) 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 (March 5, 2007) is 6255 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 472, but not defined == Missing Reference: 'I-D.draft-eronen-ipsec-ikev2-eap-auth-05' is mentioned on line 563, but not defined == Missing Reference: 'RFC 4111' is mentioned on line 741, but not defined == Unused Reference: 'I-D.ietf-softwire-hs-framework-l2tpv2' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'I-D.v6ops-tunneling-requirements' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'I-D.white-sobgp-architecture' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'I-D.wu-softwire-mesh-framework' is defined on line 1060, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-softwire-problem-statement-02 ** Downref: Normative reference to an Informational draft: draft-ietf-softwire-problem-statement (ref. 'I-D.ietf-softwire-problem-statement') ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2858 (Obsoleted by RFC 4760) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Downref: Normative reference to an Informational RFC: RFC 4593 == Outdated reference: A later version (-10) exists of draft-bellovin-useipsec-04 == Outdated reference: A later version (-13) exists of draft-ietf-softwire-hs-framework-l2tpv2-03 == Outdated reference: A later version (-10) exists of draft-ietf-rpsec-bgpsecrec-06 Summary: 9 errors (**), 0 flaws (~~), 13 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: September 6, 2007 KDDI R&D Labs 5 F. Parent 6 consultant 7 H. Yokota 8 KDDI R&D Labs 9 March 5, 2007 11 Softwire Security Analysis and Requirements 12 draft-ietf-softwire-security-requirements-02 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 September 13, 2007. 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . 13 68 3.5.5. IPsec SPD entries example . . . . . . . . . . . . . . 14 69 4. Mesh Security Guidelines . . . . . . . . . . . . . . . . . . . 15 70 4.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 15 71 4.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 16 72 4.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 17 73 4.3.1. Attacks on the Control Plane . . . . . . . . . . . . . 17 74 4.3.2. Attacks on the Data Plane . . . . . . . . . . . . . . 18 75 4.4. Applicability of Security Protection Mechanism . . . . . . 18 76 4.5. Guidelines for Usage of Security Protection Mechanism . . 19 77 4.5.1. Security Protection Mechanism for Control Plane . . . 19 78 4.5.2. Security Protection Mechanism for Data Plane . . . . . 21 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 6.1. Normative References . . . . . . . . . . . . . . . . . . . 22 82 6.2. Informative References . . . . . . . . . . . . . . . . . . 23 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 84 Intellectual Property and Copyright Statements . . . . . . . . . . 26 86 1. Introduction 88 TThe 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 in such two Softwire solution spaces such as 97 "Hubs and Spokes" and "Mesh" scenarios Section 3andSection 4described 98 in [I-D.ietf-softwire-problem-statement]. The protocols selected for 99 Softwire connectivity require the Security consideration on more 100 specific deployment scenarios for each solution. 102 Layer Two Tunneling Protocol (L2TPv2) selected for "Hubs and Spokes" 103 solution MUST use IPsec if the secure communication is 104 required[RFC3193]. This document provides the implementation 105 guidance (and proper usage) of IPsec as the security protection 106 mechanism by considering the various security vulnerabilities in 107 "Hubs and Spokes" scenarios. IKEv2 SHOULD be used in the key 108 management protocol for IPsec as the reason of the future proven 109 technology as opposed to IKEv1. 111 In the "Mesh" solution, Multi-Protocol Border Gateway Protocol (MP- 112 BGP) is used as the signaling protocol to establish the Softwire 113 connectivities among the access islands with same address families 114 across the transit core to exchange the reachability information and 115 softwire encapsulation attributes. As BGP is vulnerable to various 116 security attakcs[RFC4272], the adequate security protection mechanism 117 MUST be implemented in BGP. When the networks associated with 118 Softwire connectivity include untrusted devices or have possibility 119 of connections of those devices, the proper security protection 120 mechanism MUST be used for BGP signaling together with filering at 121 the Softwire end-point nodes and the secure encapsulation method MUST 122 be used for data traffic. This document provides the implementation 123 guidance of IPsec as the security protection mechanism for BGP by 124 referencing to the security framework for the Provider-Provisioned 125 Virtual Private Networks (PPVPNs) [RFC4111]. 127 2. Terminology 129 The terminology is based on the softwire problem statement document 130 [I-D.ietf-softwire-problem-statement]. 132 AF(i) - Address Family. IPv4 or IPv6. Notation used to indicate 133 that prefixes, a node or network only deal with a single IP AF. 135 AF(i,j) - Notation used to indicate that a node is dual-stack or that 136 a network is composed of dual-stack nodes. 138 Address Family Border Router (AFBR) -A dual-stack router that 139 interconnects two networks that use either the same or different 140 address families. An AFBR forms peering relationships with other 141 AFBRs, adjacent core routers and attached CE routers, perform 142 softwire discovery and signaling, advertises client ASF(i) 143 reachability information and encapsulates/decapsulates customer 144 packets in softwire transport headers. 146 Customer Edge (CE) - A router located inside AF access island that 147 peers with other CE routers within the access island network and with 148 one or more upstream AFBRs. 150 Customer Premise Equipment (CPE) - An equipment, host or router, 151 located at a subscriber's premises and connected with a carrier's 152 access network. 154 Provider Edge (PE) - A router located at the edge of transit core 155 network that interfaces with CE in access island. 157 Softwire Concentrator (SC) - The node terminating the softwire in the 158 service provider network. 160 Softwire Initiator (SI) - The node initiating the softwire within the 161 customer network. 163 Softwire Encapsulation Set (SW-Encap) - A softwire encapsulation set 164 contains tunnel header parameters, order of preference of the tunnel 165 header types and the expected payload types (e.g. IPv4) carried 166 inside the softwire. 168 Softwire Next_Hop (SW-NHOP) - This attribute accompanies client AF 169 reachability advertisements and is used to reference a softwire on 170 the ingress AFBR leading to the specific prefixes. It contains a 171 softwire identifier value and a softwire next_hop IP address denoted 172 as . Its existence in the presence of client 173 AF prefixes (in advertisements or entries in a routing table) infers 174 the use of softwire to reach that prefix. 176 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 If this is the case, the IP address of the host is determined by the 220 visited 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 PAP authentication, MS-CHAP, and EAP MAY be supported. 342 But PPP authentication does not provide per-packet authentication. 344 PPP encryption is defined but PPP Encryption Control Protocol (ECP) 345 negotiation does not provide for a protected cipher suite 346 negotiation. PPP encryption provides a weak security solution 347 [RFC3193]. PPP ECP implementation cannot be expected. PPP 348 authentication also does not provide the scalable key management. 350 Once the access is granted to the SI, other protocols start for 351 network configuration and the node in the SI side will exchange data 352 with other nodes in the network connected through SC. 354 These steps are vulnerable to man-in-the-middle (MITM), denial of 355 service (DoS), and Service theft attacks, which are caused as the 356 consequence of the following adversary actions. 358 Adversary attacks on softwire include: 360 1. An adversary may try to discover identities by snooping data 361 packets. 363 2. An adversary may try to modify both control and data packets. 364 This type of attack involves integrity violations. 366 3. An adversary may try to eavesdrop and collect control messages. 367 By replaying these messages, an adversary may successfully hijack 368 the L2TP tunnel or the PPP connection inside the tunnel. An 369 adversary might mount MITM, DOS, and theft of service attacks. 371 4. An adversary can flood the Softwire node with bogus signaling 372 messages to cause DoS attacks by terminating L2TP tunnels or PPP 373 connections. 375 5. An adversary may attempt to disrupt the softwire negotiation in 376 order to weaken or remove confidentiality protection. 378 6. An adversary may wish to disrupt the PPP LCP authentication 379 negotiation. 381 In environments where the link is shared without cryptographic 382 protections and the weak authentication or one-way authentication is 383 used, these security attacks can be mounted on softwire control and 384 data packets. 386 To access the SC through the public networks, any node can pretend to 387 be a SC, if there is no prior trust relationship between SI and SC. 388 In this case, an adversary may impersonate the SC to intercept 389 traffic ("rogue" softwire concentrator). 391 The rogue SC captures all of necessary information (including keys if 392 security is present) of a legitimate Softwire node and remove the 393 message of the subgroup of the network. The rogue SC can introduce a 394 black hole attack in which the attacker sends out forged routing 395 packets and setup a route to some destination via itself and when the 396 actual data packets get in they are simply dropped, forming a black 397 hole at the SC - where data enters but never leaves. Another 398 possibility is for the attacker to forge routes pointing into an area 399 where the destination node is not located. Everything will be routed 400 into this area but nothing will leave. 402 The deployment of ingress filtering is able to control the malicious 403 users' access. Without specific ingress filtering checks in the 404 decapsulator at SC, it would be possible for an attacker to inject a 405 false packet. This causes DoS attack. The inner address ingress 406 filtering can reject invalid inner source address. Without inner 407 address ingress filtering, another kind of attack can happen. The 408 malicious users from another ISP could start using its tunneling 409 infrastructure to get free inner address connectivity, transforming 410 effectively the ISP into an inner address transit provider. 412 While this does not provide the complete protection in the case an 413 address spoofing has been happened. To protect address spoofing, 414 authentication MUST be implemented in the tunnel encapsulation. 416 3.4. Softwire Security Guidelines 418 Based on the security threat analysis in Section 3.3 in this 419 document, Softwire security protocol must support the following 420 protections. 422 1. Softwire control messages between the SI and the SC MUST BE 423 protected against eavesdropping and spoofing attacks. 425 2. Softwire security protocol MUST be able to protect itself against 426 replay attacks. 428 3. Softwire security protocol MUST be able to protect the device 429 identifier against the impersonation when it is exchanged between 430 the SI and the SC. 432 4. Softwire security protocol MUST be able to securely bind the 433 authenticated session to the device identifier of the client, to 434 prevent service theft. 436 5. Softwire security protocol MUST be able to protect disconnect and 437 revocation messages. 439 The Softwire security protocol requirement is comparable to RFC3193. 440 For Softwire control packets, authentication, integrity and replay 441 protection MUST be supported and confidentiality SHOULD be supported. 442 For Softwire data packets, authentication, integrity and replay 443 protection MUST be supported and confidentiality MAY be supported. 445 The Softwire problem statement [I-D.ietf-softwire-problem-statement] 446 provides some requirements for "Hubs and Spoke" solution that are 447 taken into account in defining the security protection mechanisms. 449 1. control and/or data plane must be able to provide full payload 450 security when desired. 452 2. deployed technology must be very strongly considered 454 This additional security protection must be separable from the 455 Softwire tunneling mechanism. 457 Note that the scope of the security is on the L2TP tunnel between the 458 SI and SC. If end to end security is required, a security protocol 459 should be used in the payload packets. But this is out of scope of 460 this document. 462 3.4.1. Authentication 464 The softwire security protocol MUST support user authentication in 465 the control plane, in order to authorize access to the service, and 466 provide adequate logging of activity. The protocol SHOULD offer 467 mutual authentication in scenarios where the SI requires identity 468 proof from the SC, for example, SI accesses to SC across the public 469 network. 471 In some circumstances, the service provider may decide to allow non- 472 authenticated connection [I-D.softwire-hs-framework-l2tpv2]. For 473 example, when the customer is already authenticated by some other 474 means, such as closed networks, cellular networks at Layer 2, etc., 475 the service provider may decide to turn it off. If no authentication 476 is conducted on any layer, the SC acts as a gateway for anonymous 477 connections. Running such a service MUST be configurable by the SC 478 administrator and the SC SHOULD take some security measures such as 479 ingress filtering and adequate logging of activity. It should be 480 noted that anonymous connection service cannot provide the security 481 functionalities described in this document (e.g. integrity, replay 482 protection and confidentiality). 484 3.4.1.1. PPP Authentication 486 PPP can provide mutual authentication between the SI and SC using 487 CHAP [RFC1994] during the connection establishment phase (Link 488 Control Protocol, LCP). PPP CHAP authentication can be used when the 489 SI and SC are on a trusted, non-public IP network. 491 Since CHAP does not provide per-packet authentication, integrity, or 492 replay protection, PPP CHAP authentication MUST NOT be used 493 unprotected on a public IP network. 495 Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY 496 be supported. 498 3.4.1.1.1. L2TPv2 Authentication 500 L2TPv2 provides an optional CHAP-like[RFC1994] tunnel authentication 501 during the control connection establishment [RFC2661, 5.1.1]. The 502 same restrictions apply to L2TPv2 authentication and PPP CHAP. 504 3.4.2. Softwire Security Protocol 506 To meet the above requirements, all softwire security compliant 507 implementations MUST implement the following security protocols. 509 IPsec ESP[RFC4303]in transport mode for securing softwire control and 510 data packets. Internet Key Exchange (IKE) protocol[RFC3947] MUST be 511 supported for authentication, security association negotiation and 512 key management for IPsec. The applicability of different version of 513 IKE is discussed in Section 3.5 . 515 The softwire security protocol MUST support NAT traversal. UDP 516 encapsulation of IPsec ESP packets[RFC3948] and negotiation of NAT- 517 traversal in IKE[RFC3947] MUST be supported when IKEv1 is used. 519 3.5. Guidelines for Usage of IPsec in Softwire 521 [RFC3193] discusses how L2TP can use IPsec to provide tunnel 522 authentication, privacy protection, integrity checking and replay 523 protection [RFC4306]. Since it's publication, revision to IPsec 524 protocols have been published (IKEv2 [RFC4306], ESP [RFC4303], NAT- 525 traversal for IKE [RFC3947] and ESP[RFC3948]). 527 Although [RFC3193]can be applied in the softwire "Hubs and Spokes" 528 solution. To meet softwire requirements such as NAT-traversal, NAT- 529 traversal for IKE [RFC3947] and ESP[RFC3948] MUST be supported. 531 IKEv2 [RFC4306] offers NAT-traversal. IKEv2 also supports EAP 532 authentication with the authentication using shared secrets and 533 public key signatures. IKE is more reliable protocol than IKEv1 and 534 the future proof technology. New implementations SHOULD use IKEv2 535 over IKEv1. There are cases where IKEv1 may be needed, e.g. an 536 existing deployment of clients using L2TPv2 with IKEv1. 538 IKEv2 [RFC4306] supports legacy authentication methods that may be 539 useful in environments where username and password based 540 authentication is already deployed. 542 The following sections will discuss using IPsec to protect L2TPv2 as 543 applied in the softwire "Hubs and Spokes" model. Both IKEv1 (based 544 on [RFC3193]) and IKEv2 examples will be given. 546 3.5.1. Authentication Issues 548 IPsec implementation using IKEv1 only supports machine 549 authentication. There is no way to verify a user identity and to 550 segregate the tunnel traffic among users in the multi-user machine 551 environment. When the user identity is required, the extension of 552 IKE is required, for example, Xauth is commonly used but not 553 standardized. Whereas, the IKEv2 can support user authentication 554 with EAP payload by leveraging existing authentication infrastructure 555 and credential database. This enables the traffic segregation among 556 users when user authentication is used by combining the legacy 557 authentication. The user identity asserted within IKEv2 will be 558 verified on a per-packet basis. 560 If the AAA server is involved to establish a security association 561 between the SI and SC, a session key can be derived from the 562 authentication between the SI and the AAA server. Such a scenario 563 can be found in [I-D.draft-eronen-ipsec-ikev2-eap-auth-05]. 564 Successful EAP exchanges within IKEv2 runs between the SI and the AAA 565 server create a session key and it is securely transferred to the SC 566 from the AAA server. The trust relationship between the involved 567 entities follows Section 3.2 of this document. 569 3.5.2. IPsec Pre-Shared Keys for Authentication 571 With IPsec, when the identity asserted in IKE is authenticated, the 572 resulting derived keys are used to provide per-packet authentication, 573 integrity and replay protection. As a result, the identity verified 574 in the IKE is subsequently verified on reception of each packets. 575 [RFC3193, 5.1] 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 grow, 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. 582 ([RFC3193], 4.1). 584 If pre-shared keys are used, group pre-shared keys MUST NOT be used 585 because of its vulnerability to Man-In-The-Middle attacks ([RFC3193], 586 5.1.4). 588 3.5.3. Inter-operability guidelines 590 The L2TPv2/IPsec inter-operability concerning tunnel teardown, 591 fragmentation and per-packet security checks must be followed by 592 guidelines given in ([RFC3193] section 3). 594 3.5.4. IPsec filtering details 596 The IPsec filtering details from [RFC3193] section 4 are applicable 597 to softwire "Hubs and Spokes" model. 599 Although the L2TP specification allows the responder (SC in softwire) 600 to use a new IP address when sending the Start-Control-Connection- 601 Request-Reply (SCCRP), a softwire concentrator implementation SHOULD 602 NOT do this ([RFC3193] section 4). Note that this feature may be 603 needed for "load-balancing" between SCs. 605 3.5.5. IPsec SPD entries example 607 The SPD examples in [RFC3193] appendix A can be applied to softwire 608 model. In that case, the initiator is always the client (SI), and 609 responder is the SC. Note that the examples are IKEv1 specific. 611 3.5.5.1. IPv6 over IPv4 Softwire with L2TPv2 example 613 In this example, the softwire initiator and concentrator are denoted 614 with IPv4 addresses IPv4-SI and IPv4-SC respectively. 616 src dst Protocol Action 617 ----- ------ -------- ------ 618 IPV4-SI IPV4-SC ESP (ports 500,4500) BYPASS 619 IPV4-SI IPV4-SC IKE BYPASS 620 IPv4-SI IPV4-SC UDP, src 1701, dst 1701 PROTECT(ESP,transport) 621 IPv4-SC IPv4-SI UDP, src * , dst 1701 PROTECT(ESP,transport) 623 Softwire initiator SPD 625 src dst Protocol Action 626 ----- ------ -------- ------ 627 * IPV4-SC ESP (ports 500,4500) BYPASS 628 * IPV4-SC IKE BYPASS 629 * IPV4-SC UDP, src * , dst 1701 PROTECT(ESP,transport) 631 Softwire concentrator SPD 633 3.5.5.2. IPv4 over IPv6 Softwire with example 635 In this example, the softwire initiator and concentrator are denoted 636 with IPv6 addresses IPv6-SI and IPv6-SC respectively. 638 src dst Protocol Action 639 ----- ------ -------- ------ 640 IPV6-SI IPV6-SC ESP (ports 500,4500) BYPASS 641 IPV6-SI IPV6-SC IKE BYPASS 642 IPv6-SI IPV6-SC UDP, src 1701, dst 1701 PROTECT(ESP,transport) 643 IPv6-SC IPv6-SI UDP, src * , dst 1701 PROTECT(ESP,transport) 644 Softwire initiator SPD 646 src dst Protocol Action 647 ----- ------ -------- ------ 648 * IPV6-SC ESP (ports 500,4500) BYPASS 649 * IPV6-SC IKE BYPASS 650 * IPV6-SC UDP, src * , dst 1701 PROTECT(ESP,transport) 652 Softwire concentrator SPD 654 4. Mesh Security Guidelines 656 4.1. Deployment Scenario 658 In the softwire "Mesh" solution, it is required to establish 659 connectivity to access network islands of one address family type 660 across a transit core of a differing address family type. To provide 661 reachability across the transit core, AFBRs are installed between 662 access network island and transit core network. These AFBRs can 663 perform as Provider Edge routers (PE) within an autonomous system or 664 perform peering across autonomous systems. The AFBRs establish and 665 encapsulate softwires in a mesh to the other islands across the 666 transit core network. The transit core network consists of one or 667 more service providers. 669 In the softwire "Mesh" solution, point to multi-point connectivity 670 among AFBRs is dynamically established by announcing the reachability 671 and the encapsulation method using Multiprotocol Extensions for BGP-4 672 (MP-BGP) [RFC2858]. 674 AFBR nodes are Internal BGP speakers and will peer with each other 675 directly or via a route reflector to exchange SW-encap sets, perform 676 softwire signaling, and advertise AF access island reachability 677 information and SW-NHOP information. If such information is 678 advertised within an autonomous system, the AFBR node receiving them 679 from other AFBRs does not forward them to other AFBR nodes. To 680 exchange the information among AFBRs, the full mesh connectivity will 681 be established. 683 For the connectivity between CE and PE routers, the following two 684 cases should be considered. Note that the CE-PE connection includes 685 dedicated physical circuits, logical circuits (such as Frame Relay 686 and ATM), and shared medium access (such as Ethernet-based access). 688 Case 1: When AFBRs are PE routers located at the edge of the provider 689 core networks, this is similar architecture of Provider Provisioned 690 PE-based VPN. The connectivity between a CE router in access island 691 network and a PE router in transit network is established by static 692 way. The access islands are enterprise networks accommodated through 693 PE routers in the provider's transit network. In this case, the 694 access island networks are operated within the provider's autonomous 695 system. 697 When the access island networks have their own AS number, inter-AS 698 model can be applied for the connections among the access island 699 networks. CE routers located inside access islands form a peering 700 relationship with AFBRs in the transit network autonomous system to 701 exchange AF access island reachability information using eBGP. 703 Case 2: As alternative model, a single-stack AF(j) PE node is 704 applicable, the AFBR function of the dual-stack AF(i,j) processing is 705 moved to CE routers located at the edge of a customer site. This is 706 the dual-stack CE model. The CE device has the IP connectivity with 707 service provider's PE device over the access connection. The 708 customer's access network belongs to provider's autonomous system. 709 This model might evolve inter-CE BGP peering to exchange users' AF 710 prefixes/next-hops. 712 For this managed CE-based model, users in access networks have to 713 have a fairly high level of trust that the service provider will 714 properly provision and manage the CE devices. 716 4.2. Trust Relationship 718 In case 1, all AFBR nodes in the transit core MUST have a trust 719 relationship or an agreement with each other to establish softwires. 720 Within an autonomous system, it is assumed that all nodes (e.g. 721 AFBR, PE or Route Reflector, if applicable) are trusted with each 722 other. If the transit core consists of multiple autonomous systems, 723 intermediate routers between AFBRs may not be trusted when back-to- 724 back AFBRs are not available. There MUST be a trust relationship 725 between the PE in the transit core and the CE in the corresponding 726 island, although the link(s) between the PE and the CE may not be 727 protected. 729 For the dual-stack CE model in Case 2, CE nodes of iBGP speakers in 730 the access island network MUST have the trust relationship with each 731 other. In addition, users in the access island networks and the 732 transit core provider MUST have the trust relationship. The security 733 protection mechanism can be applied for CE-to-CE in either a 734 provider-provisioned or a user provisioned model. Note that the 735 user-provisioned CE-CE security protection mechanism is outside the 736 scope of this document. 738 4.3. Softwire Security Threat Scenarios 740 The architecture of softwire mesh solution is very similar to that of 741 the provider provisioned VPN (PPVPN) [RFC 4111]. The security 742 threats considerations on the PPVPN operation are applicable to those 743 in the softwire mesh solution. 745 The security attacks can be mounted on both the control plane and the 746 data plane. In softwire mesh solution, softwires encapsulation will 747 be setup by using MP-BGP. MP-BGP does not change the security issues 748 inherent in BGP. In terms of the control plane security, the general 749 BGP security vulnerabilities are applicable [RFC4272]. 751 4.3.1. Attacks on the Control Plane 753 BGP is subject to the following attacks [RFC4272]. 755 1. The routing data carried in BGP is carried in cleartext, so 756 eavesdropping is a possible attack against routing data 757 confidentiality. (confidentiality violations) 759 2. BGP does not provide for replay protection of its message. 760 (replay) 762 3. BGP does not provide protection against insertion of messages. 763 However, because BGP uses TCP, when the connection is fully 764 established, message insertion by an outsider would require 765 accurate sequence number prediction or session-stealing 766 attacks.(message insertion) 768 4. BGP does not provide protection against deletion messages. This 769 attack is more difficult against a mature TCP implementation, but 770 is not entirely out of question. (message deletion) 772 5. BGP does not provide protection against modification of messages. 773 A modification that was syntactically correct and did not change 774 the length of the TCP payload would in general not be detectable. 775 (message modification) 777 6. BGP does not provide protection against man-in-the-middle 778 attacks. As BGP does not perform peer entity authentication, it 779 is vulnerable to a man-in-the-middle attack. (man-in-the-middle) 781 7. While bogus routing data can present a DoS attack on the end 782 systems that are trying to transmit data through network and on 783 the network infrastructure itself, certain bogus information can 784 present a DoS on the BGP routing protocol. (denial-of-service) 786 4.3.2. Attacks on the Data Plane 788 Examples of attacks include: 790 1. An adversary may try to discover confidential information by 791 sniffing softwire packets. 793 2. An adversary may try to modify the contents of softwire packets. 795 3. An adversary may try to spoof the softwire packets that do not 796 belong there and to insert of copies of once-legitimate packets 797 that have been recorded and replayed. 799 4. An adversary can launch Denial-of-Service attack by deleting 800 softwire data traffic. DoS attacks of the resource exhaustion 801 type can be mounted against the data plane by spoofing a large 802 amount of non-authenticated data into the softwire from the 803 outside of the softwire tunnel. 805 5. An adversary may try to sniff softwire packets and to examine 806 aspects or meta-aspects of them that may be visible even when the 807 packets themselves are encrypted. An attacker might gain useful 808 information based on the amount and timing of traffic, packet 809 sizes, sources and destination addresses, etc. 811 4.4. Applicability of Security Protection Mechanism 813 Given that security is generally a compromise between expense and 814 risk, it is also useful to consider the likelihood of different 815 attacks. There is at least a perceived difference in the likelihood 816 of most types of attacks being successfully mounted in different 817 deployment. 819 The trust relationship among users in access networks, transit core 820 provider, and other parts of networks described in section 4.2 is a 821 key element in determining the applicability of security protection 822 mechanism for the specific softwire mesh deployment. 824 The Softwire Problem Statement [I-D.ietf-softwire-problem-statement] 825 states that the softwire mesh setup mechanism MUST support 826 authentication, but the transit core provider may decide to turn it 827 off in some circumstances. If a routing protocol is used to 828 advertise the softwire encapsulation, it must also support 829 authentication. 831 In the data plane, the softwire must support IPsec and a IPsec 832 profile must be defined. 834 In particular, it determines where encryption should be applied, as 835 follows [RFC4111] 837 - If the link(s) between the user's site and the provider's PE is not 838 trusted, then encryption may be used on the PE-CE link(s). 840 - If some part of the transit core network is not trusted, PE-PE path 841 may be encrypted. 843 The access control technique reduces the exposure to attacks from 844 outside the service provider networks. The access control technique 845 includes packet-by-packet or packet flow-by-packet flow access 846 control by means of filters as well as by means of admitting a 847 session for a control/signaling/management protocol that is being 848 used to implement softwire mesh. 850 The access control technique is an important protection against 851 security attacks of DoS etc. and a necessary adjunct to cryptographic 852 strength in encapsulation. Packets that match the criteria 853 associated with a particular filter may be either discarded or given 854 special treatment to prevent an attack or to mitigate the effect of a 855 possible future attack. 857 4.5. Guidelines for Usage of Security Protection Mechanism 859 4.5.1. Security Protection Mechanism for Control Plane 861 A BGP has the three fundamental vulnerabilities to the security 862 threats [RFC4272]. 864 1. BGP has no internal mechanism that provides strong protection of 865 the integrity, freshness, and peer authenticity of the message in 866 peer-peer BGP communications. 868 2. No mechanism has been specified within BGP to validate the 869 authority of a BGP peer to announce NLRI information. 871 3. No mechanism has been specified within BGP to ensure the 872 authenticity of the path attributes announced by a BGP peer. 874 The BGP specification requires that a BGP must support the 875 authentication mechanism specified in [RFC2385]. However the 876 security mechanism for BGP transport (e.g. TCP-MD5) is inadequate 877 and requires significant operator interaction to maintain a 878 respectable level of security. The current deployments of TCP-MD5 879 exhibit serious shortcomings with respect of key management as 880 described in [RFC3562] 882 The mechanism defined in RFC 2385 is based on a one-way hash function 883 (MD5) and use of a secret key. The key is shared between peer 884 routers and is used to generate 16-byte message authentication code 885 values that are not readily computed by an attacker who does not have 886 access to the key. 888 Key management can be especially cumbersome for operators. The 889 number of keys required and the maintenance of keys (issue/revoke/ 890 renew) has had an additive effect as a barrier to deployment. Thus 891 automated means of managing keys, to reduce operational burdens, MUST 892 be available in BGP security systems[I-D.rpsec-bgpsecrec], [RFC4107] 894 4.5.1.1. IKE/IPsec 896 Use of IPsec counters the message insertion, deletion, and 897 modification attacks, as well as man-in-the-middle attacks by 898 outsiders. If routing data confidentiality is desired, the use of 899 IPsec ESP could provide that service. If eavesdropping attack is 900 identified as a threat, ESP can be used to provide confidentiality 901 (encryption), integrity and authentication for the BGP session. 903 To provide replay protection, automated key management system using 904 IKEv2 must be used. IKEv2 can be applied using shared secrets for 905 authentication when the number of BGP peers is small. When the 906 number of BGP peers is large, managing the shared secrets on all 907 peers does not scale. In this scenario, public-key digital signature 908 or key encryption authentication in IKE should be used, assuming that 909 the peers have the necessary computation available. 911 4.5.1.2. Secure BGP 913 The deeper security issues raised by BGP are not addressed by IPsec 914 or any other transmission security mechanism. 916 As cryptographic-based mechanism, both TCP MD5 and IPsec assume that 917 the cryptographic algorithms are secure, that secrets used are 918 protected from exposure and are chosen well so as not to be 919 guessable, that the platforms are securely managed and operated to 920 prevent break-ins, etc. 922 These mechanisms do not prevent attacks that arise from a router's 923 legitimate BGP peers [RFC4272]. 925 The S-BGP countermeasures use IPsec, Public Key Infrastructure (PKI) 926 technology, and a new BGP path attribute ("attestations") to ensure 927 the authenticity and integrity of BGP communication on a point-to- 928 point basis, and to validate BGP routing UPDATE's on a source to 929 destination basis[I-D.clynn-s-bgp-protocol]. 931 To implement the secure BGP, Secure Origin BGP (soBGP) and Pretty 932 Secure BGP (psBGP) are also proposed. The detail comparison was made 933 in[Wan05]. 935 4.5.2. Security Protection Mechanism for Data Plane 937 The protection mechanisms discussed are intended to describe methods 938 by which some security threats can be mitigated. They are not 939 intended as requirements for all softwire mesh implementations. 941 The several of the attacks are outlined in 4.3.2. In order to 942 protect against such threats, the softwire SHOULD provide for replay 943 and integrity protection for softwire data packets and MAY protect 944 confidentiality of data packets. Automated key management in the 945 softwire mesh solution may be necessary per [RFC4107]. 947 IPsec can provide replay protection, integrity and confidentiality of 948 IP data packets, which would protect against most threats identified 949 in 4.3.2. 951 In softwire mesh solution, IPsec tunnels can be established on 952 selective basis using Tunnel SAFI announced by AFBRs. The softwire 953 mesh framework [wu-softwire-mesh-framework] currently supports many 954 tunnel encapsulation type using a "Softwire Mesh Encapsulation 955 Attribute" announced as a BGP Tunnel SAFI [nalawade-softwire-mesh- 956 encap-attribute], [nalawade-kapoor-tunnel-safi]. 958 To protect the data packets using IPsec, AFBRs must be configured 959 with the proper IPsec parameters: ESP ( encryption or NULL 960 encryption), transport or tunnel mode, key management (IKE SA 961 parameters), selectors and SPD. 963 [nalawade-kapoor-tunnel-safi] describes an IPsec Tunnel Information 964 TLV that contains an IKE Identifier. The SPD and selectors must also 965 be defined. These are directly related to the encapsulation type 966 used between the AFBRs (e.g., selectors for L2TP will be different 967 from IPv6-over-IPv4 tunnels). 969 5. Security Considerations 971 This document discusses various security threats for the softwire 972 control and data packets in "Hubs and Spokes" and "Mesh" time-to- 973 market solutions. With these discussions, the softwire security 974 protocol implementations are provided referencing to Softwire Problem 975 Statement [I-D.ietf-softwire-problem-statement], Securing L2TP using 976 IPsec[RFC3193], Security Framework for PPVPNs [RFC4111], and 977 Guidelines for Mandating the Use of IPsec [I-D.bellovin-useipsec].The 978 guidelines for the security protocol employment are also given 979 considering the specific deployment context. 981 Note that this document discusses the softwire tunnel security 982 protection and does not address the end-to-end protection. 984 6. References 986 6.1. Normative References 988 [I-D.ietf-softwire-problem-statement] 989 Li, X., "Softwire Problem Statement", 990 draft-ietf-softwire-problem-statement-02 (work in 991 progress), May 2006. 993 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 994 Protocol (CHAP)", RFC 1994, August 1996. 996 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 997 Signature Option", RFC 2385, August 1998. 999 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1000 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1001 RFC 2661, August 1999. 1003 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, 1004 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000. 1006 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1007 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1008 January 2005. 1010 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1011 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1012 RFC 3948, January 2005. 1014 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 1015 Key Management", BCP 107, RFC 4107, June 2005. 1017 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1018 RFC 4303, December 2005. 1020 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1021 RFC 4306, December 2005. 1023 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 1024 Routing Protocols", RFC 4593, October 2006. 1026 6.2. Informative References 1028 [I-D.bellovin-useipsec] 1029 Bellovin, S., "Guidelines for Mandating the Use of IPsec", 1030 draft-bellovin-useipsec-04 (work in progress), 1031 September 2005. 1033 [I-D.clynn-s-bgp-protocol] 1034 Lynn, C. and K. Seo, "Secure BGP (S-BGP)", 1035 draft-clynn-s-bgp-protocol-01 (work in progress), 1036 June 2003. 1038 [I-D.ietf-softwire-hs-framework-l2tpv2] 1039 Storer, B., "Softwires Hub & Spoke Deployment Framework 1040 with L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-03 1041 (work in progress), February 2007. 1043 [I-D.rpsec-bgpsecrec] 1044 Christian, B. and T. Tauber, "BGP Security Requirements", 1045 draft-ietf-rpsec-bgpsecrec-06 (work in progress), 1046 April 2006. 1048 [I-D.v6ops-tunneling-requirements] 1049 Durand, A. and F. Parent, "Requirements for assisted 1050 tunneling", 1051 draft-durand-v6ops-assisted-tunneling-requirements-00 1052 (work in progress), September 2004. 1054 [I-D.white-sobgp-architecture] 1055 White, R., "Architecture and Deployment Considerations for 1056 Secure Origin BGP (soBGP)", 1057 draft-white-sobgp-architecture-02 (work in progress), 1058 June 2006. 1060 [I-D.wu-softwire-mesh-framework] 1061 Wu, J., "Softwire Mesh Framework", 1062 draft-wu-softwire-mesh-framework-02 (work in progress), 1063 March 2007. 1065 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1066 "Securing L2TP using IPsec", RFC 3193, November 2001. 1068 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 1069 Signature Option", RFC 3562, July 2003. 1071 [RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication 1072 and Network Access (PANA) Threat Analysis and Security 1073 Requirements", RFC 4016, March 2005. 1075 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 1076 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 1078 [RFC4111] Fang, L., "Security Framework for Provider-Provisioned 1079 Virtual Private Networks (PPVPNs)", RFC 4111, July 2005. 1081 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 1082 RFC 4272, January 2006. 1084 [Wan05] Wan, T., Wan, P., and S. Kranakis, "A Selective 1085 Introduction to Border Gateway Protocol (BGP) Security 1086 Issues", URL http://www.scs.carleton.ca/research/ 1087 tech_reports/2005/TR-05-08.pdf, August 2005. 1089 Authors' Addresses 1091 Shu Yamamoto 1092 KDDI R&D Labs 1093 2-1-15 Fujimino-shi 1094 Saitama, 356-8502 1095 Japan 1097 Phone: 81 (49) 278-7311 1098 Email: shu@kddilabs.jp 1100 Carl Williams 1101 KDDI R&D Labs 1102 Palo Alto, CA 94301 1103 USA 1105 Phone: +1.650.279.5903 1106 Email: carlw@mcsr-labs.org 1108 Florent Parent 1109 consultant 1110 Quebec, QC 1111 Canada 1113 Phone: +1 418 265 7357 1114 Email: Florent.Parent@mac.com 1115 Hidetoshi Yokota 1116 KDDI R&D Labs 1117 2-1-15 Ohara 1118 Fujimino, Saitama 356-8502 1119 Japan 1121 Phone: 81 (49) 278-7894 1122 Email: yokota@kddilabs.jp 1124 Full Copyright Statement 1126 Copyright (C) The IETF Trust (2007). 1128 This document is subject to the rights, licenses and restrictions 1129 contained in BCP 78, and except as set forth therein, the authors 1130 retain all their rights. 1132 This document and the information contained herein are provided on an 1133 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1134 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1135 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1136 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1137 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1138 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1140 Intellectual Property 1142 The IETF takes no position regarding the validity or scope of any 1143 Intellectual Property Rights or other rights that might be claimed to 1144 pertain to the implementation or use of the technology described in 1145 this document or the extent to which any license under such rights 1146 might or might not be available; nor does it represent that it has 1147 made any independent effort to identify any such rights. Information 1148 on the procedures with respect to rights in RFC documents can be 1149 found in BCP 78 and BCP 79. 1151 Copies of IPR disclosures made to the IETF Secretariat and any 1152 assurances of licenses to be made available, or the result of an 1153 attempt made to obtain a general license or permission for the use of 1154 such proprietary rights by implementers or users of this 1155 specification can be obtained from the IETF on-line IPR repository at 1156 http://www.ietf.org/ipr. 1158 The IETF invites any interested party to bring to its attention any 1159 copyrights, patents or patent applications, or other proprietary 1160 rights that may cover technology that may be required to implement 1161 this standard. Please address the information to the IETF at 1162 ietf-ipr@ietf.org. 1164 Acknowledgment 1166 Funding for the RFC Editor function is provided by the IETF 1167 Administrative Support Activity (IASA).