| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 14, 2009.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This document describes the security guidelines for the softwire "Hubs and Spokes" and "Mesh" solutions. Together with the discussion of the softwire deployment scenarios, the vulnerability to the security attacks is analyzed to provide the security protection mechanism such as authentication, integrity and confidentiality to the softwire control and data packets.
1.
Introduction
2.
Terminology
2.1.
Abbreviations
2.2.
Requirements Language
3.
Hubs and Spokes Security Guidelines
3.1.
Deployment Scenarios
3.2.
Trust Relationship
3.3.
Softwire Security Threat Scenarios
3.4.
Softwire Security Guidelines
3.4.1.
Authentication
3.4.2.
Softwire Security Protocol
3.5.
Guidelines for Usage of IPsec in Softwire
3.5.1.
Authentication Issues
3.5.2.
IPsec Pre-Shared Keys for Authentication
3.5.3.
Inter-Operability Guidelines
3.5.4.
IPsec Filtering Details
4.
Mesh Security Guidelines
4.1.
Deployment Scenario
4.2.
Trust Relationship
4.3.
Softwire Security Threat Scenarios
4.4.
Applicability of Security Protection Mechanism
4.4.1.
Security Protection Mechanism for Control Plane
4.4.2.
Security Protection Mechanism for Data Plane
5.
Security Considerations
6.
IANA Considerations
7.
Acknowledgments
8.
References
8.1.
Normative References
8.2.
Informative References
Appendix A.
A.1.
IPv6 over IPv4 Softwire with L2TPv2 example for IKE
A.2.
IPv4 over IPv6 Softwire with example for IKE
§
Authors' Addresses
| TOC |
The Softwire Working Group specifies the standardization of discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks. The softwire provides the connectivity to enable global reachability of both address families by reusing or extending existing technology. The Softwire Working Group is focusing on the two scenarios that emerged when discussing the traversal of networks composed of differing address families. This document provides the security guidelines for such two softwire solution spaces such as "Hubs and Spokes" and "Mesh" scenarios. "Hubs and Spokes" and "Mesh" problems are described in [RFC4925] (Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” July 2007.) Section 2 and Section 3, respectively. The protocols selected for softwire connectivity require the security considerations on more specific deployment scenarios for each solution. The scope of this document provides the analysis on the security vulnerabilities for the deployment scenarios and specifies the proper usage of the security mechanisms applied to the softwire deployment.
Layer Two Tunneling Protocol (L2TPv2) is selected as phase 1 protocol to be deployed in the "Hubs and Spokes" solution space. If L2TPv2 is used in the unprotected network, it will be vulnerable to various security attacks and MUST be protected by appropriate security protocol such as IPsec described in [RFC3193] (Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, “Securing L2TP using IPsec,” November 2001.). The new implementation SHOULD use IKEv2 in the key management protocol for IPsec because of more reliable protocol and integration of required protocols in a single platform. This document provides the implementation guidance and proper usage of IPsec as the security protection mechanism by considering the security vulnerabilities in "Hubs and Spokes" scenario. The document also addresses the cases where the security protocol is not necessarily mandated.
The softwire "Mesh" solution MUST support various levels of security mechanism to protect the data packets from an attacker being transmitted on a softwire tunnel from the access networks with one address family across the transit core operating with different address family [RFC4925] (Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” July 2007.). The security mechanism for the control plane is also required to be protected from control data modification, spoofing attack, etc. In the "Mesh" solution, BGP is used for distributing softwire routing information in the transit core while the security issues for BGP is being discussed in other working groups. This document provides the proper usage of the security mechanisms for the softwire mesh deployment scenarios.
| TOC |
| TOC |
The terminology is based on the softwire problem statement document [RFC4925] (Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” July 2007.).
AF(i) - Address Family. IPv4 or IPv6. Notation used to indicate that prefixes, a node or network only deal with a single IP AF.
AF(i,j) - Notation used to indicate that a node is dual-stack or that a network is composed of dual-stack nodes.
Address Family Border Router (AFBR) –A dual-stack router that interconnects two networks that use either the same or different address families. An AFBR forms peering relationships with other AFBRs, adjacent core routers and attached CE routers, perform softwire discovery and signaling, advertises client ASF(i) reachability information and encapsulates/decapsulates customer packets in softwire transport headers.
Customer Edge (CE) - A router located inside AF access island that peers with other CE routers within the access island network and with one or more upstream AFBRs.
Customer Premise Equipment (CPE) - An equipment, host or router, located at a subscriber’s premises and connected with a carrier’s access network.
Provider Edge (PE) - A router located at the edge of transit core network that interfaces with CE in access island.
Softwire Concentrator (SC) - The node terminating the softwire in the service provider network.
Softwire Initiator (SI) - The node initiating the softwire within the customer network.
Softwire Encapsulation Set (SW-Encap) - A softwire encapsulation set contains tunnel header parameters, order of preference of the tunnel header types and the expected payload types (e.g. IPv4) carried inside the softwire.
Softwire Next_Hop (SW-NHOP) - This attribute accompanies client AF reachability advertisements and is used to reference a softwire on the ingress AFBR leading to the specific prefixes. It contains a softwire identifier value and a softwire next_hop IP address denoted as <SW ID:SW-NHOP address>. Its existence in the presence of client AF prefixes (in advertisements or entries in a routing table) infers the use of softwire to reach that prefix.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
| TOC |
To provide the security guidelines, the discussion of the possible deployment scenario and the trust relationship in the network is important.
The softwire initiator (SI) always resides in the customer network. The node, in which the SI resides, can be the CPE access device, another dedicated CPE router behind the original CPE access device or any kind of host device such as PC, appliance, sensor etc.
However, the host device may not always have direct access to its home carrier network, to which the user has subscribed. For example, the SI in the laptop PC can access various access networks such as Wi-Fi hot-spots, visited office network. This is the nomadic case, which the softwire SHOULD support.
As the softwire deployment model, the following three cases as shown in Figure 1 (Authentication model for Hubs and Spokes) should be considered. Case 2 and 3 are typical for a nomadic node, but are also applicable to a stationary node. In order to securely connect legitimate SI and SC each other, the authentication process between SI and SC is performed normally using AAA servers.
visited network visited network
access provider service provider
+---------------------------------+
| |
+......v......+ +.....................|......+
. . . v .
+------+ . (case 3) . . +------+ +--------+ .
| |=====================.==| | | | .
| SI |__.________ . . | SC |<---->| AAAv | .
| |---------- \ . . | | | | .
+------+ . \\ . . +------+ +--------+ .
. \\ . . ^ .
^ +..........\\.+ +.....................|......+
| \\ |
| (case 2) \\ |
| \\ |
| \\ |
| +............+ \\ +.....................|......+
. . \\. v .
+------+ . . \\__+------+ +--------+ .
| | . (case 1) . ---| | | | .
| SI |=====================.==| SC |<---->| AAAh | .
| | . . . | | | | .
+------+ . . . +------+ +--------+ .
. . . .
+............+ +............................+
home network home network
access provider service provider
| Figure 1: Authentication model for Hubs and Spokes |
The AAA server shown in Figure 1 (Authentication model for Hubs and Spokes) interacts with the SC which acts as an AAA client. The AAA may consists of multiple AAA servers and the proxy AAA may be intermediate between the SC and the AAA servers. This document refers to the AAA server in the home network service provider as the home AAA server (AAAh) and that in the visited network service provider as the visited AAA server (AAAv).
The softwire problem statement [RFC4925] (Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” July 2007.) states that the softwire solution must be able to be integrated with common deployed AAA solution. L2TPv2 used in softwire supports PPP and L2TP authentications which can be integrated with common AAA servers.
When the softwire is used in an unprotected network, a stronger authentication process is required (e.g., IKEv2). The proper selection of the authentication processes is discussed in Section 3.4 with respect to the various security threats.
Case 1: The SI connects to the SC that belongs to the home network service provider via the home access provider network operating different address family. It is assumed that the home access network and the home network providing SC are under the same administrative system.
Note that the IP address of the host device, in which SI resides, is static or dynamic depending on the subscribed service. The discovery of the SC may be automatic. But in this document, the information on the SC, e.g. the DNS name or IP address, is assumed to be configured by the user or the provider of the SI in advance.
Case 2: The SI connects to the SC that belongs to the home network service provider network via the visited access network. For the nomadic case, the SI/user does not subscribe to the visited access provider. For the network access through the public network such as WiFi hot-spots, the home network service provider does not have the trust relationship with the access network.
Note that the IP address of the host device, in which SI resides, may be changed periodically due to the home network service provider's policy.
Case 3: The SI connects to the SC that belongs to the visited network service provider via the visited access network. This is typical of nomadic access case. When the SI is mobile, it may roam from the home ISP providing the home access network to the visited access network, e.g. WiFi hot-spot network provided by the different ISP. The SI does not connect to the SC in the home network, for example, due to the geographical reason. The SI/user does not subscribe to the visited network service provider, but the visited network service provider has some roaming agreement with the home network service provider.
Note that the IP address of the host, in which SI resides, is provided the visited network service provider's policy.
| TOC |
The establishment of the trust relationship between SI and SC is different for three cases. The security consideration must be taken into account for each case.
In Case 1, the SC and the home AAA server in the same network service provider MUST have a trust relationship and communications between them MUST be secured. When the SC authenticates the SI, the SC transmits the authentication request message to the home AAA server and obtains the accept message together with the Attribute Value Pair for the SI authentication. Since the SI in the service provider network, the provider can take measures to protect the entities (e.g., SC, AAA servers) against a number of security threats, including the communication between them.
In Case 2, when the SI is mobile, the access to the home network service provider through the visited access network provider is allowed. The trust relationship between SI and the SC in the home network MUST be established. When the visited access network is a public network, the various security attacks must be considered. Especially for SI to connect to the legitimate SC, the authentication from SI to SC MUST be performed together with that from SC to SI.
In Case3, if the SI roams into a different network service provider's administrative domain and the visited AAA server communicates with the home AAA server to obtain the information for SI authentication. The visited AAA server MUST have a trust relationship with the home AAA server and the communication between them MUST be secured in order to properly perform the roaming services that have been agreed upon under specified conditions.
Note that the path for the communications between the home AAA server and the visited AAA server may consist of several AAA proxies. In this case, AAA proxy threat model SHOULD be considered [RFC2607] (Aboba, B. and J. Vollbrecht, “Proxy Chaining and Policy Implementation in Roaming,” June 1999.). A malicious AAA proxy may launch passive or active security attacks. The trustworthiness of proxies in AAA proxy chains will be weaken when the hop counts of the proxy chain is longer. For example, the accounting information exchanged among AAA proxies is attractive for an adversary. The communication between a home AAA server and a visited AAA server MUST be protected.
| TOC |
Softwire can be used to connect IPv6 networks across public IPv4 networks and IPv4 networks across public IPv6 networks. The control and data packets used during the softwire session are vulnerable to the security attacks.
A complete threat analysis of softwire requires examination of the protocols used for the softwire setup, the encapsulation method used to transport the payload, and other protocols used for configuration (e.g., router advertisements, DHCP).
The softwire solution uses a subset of the Layer Two Tunneling Protocol (L2TPv2) functionality [RFC2661] (Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, “Layer Two Tunneling Protocol "L2TP",” August 1999.), [I‑D.ietf‑softwire‑hs‑framework‑l2tpv2] (Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. Tremblay, “Softwire Hub & Spoke Deployment Framework with L2TPv2,” March 2009.). In the softwire "Hubs and Spokes" model, L2TPv2 is used in a voluntary tunnel model only. The SI acts as a L2TP Access Concentrator (LAC) and PPP endpoint. The L2TPv2 tunnel is always initiated from the SI.,
Generic threat analysis done for L2TP using IPsec [RFC3193] (Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, “Securing L2TP using IPsec,” November 2001.) is applicable to softwire "Hubs and Spokes" deployment. The threat analysis for other protocols such as MIPv6 [RFC4225] (Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, “Mobile IP Version 6 Route Optimization Security Design Background,” December 2005.), PANA [RFC4016] (Parthasarathy, M., “Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements,” March 2005.), NSIS [RFC4081] (Tschofenig, H. and D. Kroeselberg, “Security Threats for Next Steps in Signaling (NSIS),” June 2005.), and Routing Protocols [RFC4593] (Barbir, A., Murphy, S., and Y. Yang, “Generic Threats to Routing Protocols,” October 2006.) are applicable here as well and should be used as references.
First, the SI resided in the customer network sends Start-Control-Connection-Request(SCCRQ) packet to the SC for the initiation of the softwire. L2TPv2 offers an optional CHAP-like tunnel authentication system during control connection establishment. This requires a shared secret between the SI and SC and no key management is offered for this L2TPv2.
When L2TPv2 control connection is established, the SI and SC optionally enter authentication phase after completing PPP Link Control Protocol (LCP) negotiation. PPP authentication supports one way or two way CHAP authentication, and can leverage existing AAA infrastructure. PPP authentication does not provide per-packet authentication.
PPP encryption is defined but PPP Encryption Control Protocol (ECP) negotiation does not provide for a protected cipher suite negotiation. PPP encryption provides a weak security solution [RFC3193]. PPP ECP implementation cannot be expected. PPP authentication also does not provide the scalable key management.
Once the L2TPv2 tunnel and PPP configuration are successfully established, the SI is connected and can start using the connection.
These steps are vulnerable to man-in-the-middle (MITM), denial of service (DoS), and service theft attacks, which are caused as the consequence of the following adversary actions.
Adversary attacks on softwire include:
When AAA servers are involved in softwire tunnel establishment, the security attacks can be mounted on the communication associated with AAA servers. Specifically for the case 3 stated in Section 3.2, an adversary may eavesdrop the packets between AAA servers in the home and visted network and compromise the authentication data. An adversary may also disrupt the communication between the AAA servers, causing a service denial. Security of AAA server communications is out of scope of this document.
In environments where the link is shared without the cryptographic protection and the weak authentication or one-way authentication is used, these security attacks can be mounted on softwire control and data packets.
When there is no prior trust relationship between the SI and SC, any node can pretend to be a SC. In this case, an adversary may impersonate the SC to intercept traffic (e.g. "rogue" softwire concentrator).
The rogue SC can introduce a denial of service attack by blackholing packets from the SI. The rogue SC can also eavesdrop on all packets sent from or to the SI. Security threats of a rogue SC are similar to a compromised router.
The deployment of ingress filtering is able to control the malicious users' access [RFC4213] (Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” October 2005.). Without specific ingress filtering checks in the decapsulator at the SC, it would be possible for an attacker to inject a false packet, leaving the system vulnerable to attacks such as DoS. The inner address ingress filtering can reject invalid inner source address. Without inner address ingress filtering, another kind of attack can happen. The malicious users from another ISP could start using its tunneling infrastructure to get free inner address connectivity, transforming effectively the ISP into an inner address transit provider.
While the ingress filtering does not provide the complete protection in the case an address spoofing has been happened. In order to provide better protection against address spoofing, authentication with binding between the legitimate address and the authenticated identity MUST be implemented. This can be implemented between the SC and the SI using IPsec.
| TOC |
Based on the security threat analysis in Section 3.3 in this document, the softwire security protocol MUST support the following protections.
The softwire security protocol requirement is comparable to [RFC3193] (Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, “Securing L2TP using IPsec,” November 2001.).
For softwire control packets, authentication, integrity and replay protection MUST be supported and confidentiality SHOULD be supported.
For softwire data packets, authentication, integrity and replay protection SHOULD be supported and confidentiality MAY be supported.
The softwire problem statement [RFC4925] (Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” July 2007.) provides some requirements for “Hubs and Spoke" solution that are taken into account in defining the security protection mechanisms.
This additional security protection must be separable from the softwire tunneling mechanism.
Note that the scope of the security is on the L2TP tunnel between the SI and SC. If end-to-end security is required, a security protocol SHOULD be used in the payload packets. But this is out of scope of this document.
| TOC |
The softwire security protocol MUST support user authentication in the control plane, in order to authorize access to the service, and provide adequate logging of activity. Although several authentication protocols are available, the security threats must be considered to choose the protocol.
For example, the SI/user using Password Authentication Protocol (PAP) access to the SC with the cleartext password. In many circumstances, this represents a large security risk. The adversary may spoof as a legitimate user by using the stolen password. Challenge Handshake Authentication Protocol (CHAP) [RFC1994] (Simpson, W., “PPP Challenge Handshake Authentication Protocol (CHAP),” August 1996.) encrypts a password with “challenge" sent from the SC. The theft of password can be mitigated. However, as CHAP only supports unidirectional authentication, the risk of a man-in-the-middle or rogue SC cannot be avoided. Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) [RFC5216] (Simon, D., Aboba, B., and R. Hurst, “The EAP-TLS Authentication Protocol,” March 2008.) mandates mutual authentication and avoid the rogue SC.
When the SI established a connection to the SC through a public network, the SI may want to a proof of the SC identity. Softwire MUST support mutual authentication to allow for such scenario.
In some circumstances, however, the service provider may decide to allow non-authenticated connection [I‑D.ietf‑softwire‑hs‑framework‑l2tpv2] (Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. Tremblay, “Softwire Hub & Spoke Deployment Framework with L2TPv2,” March 2009.). For example, when the customer is already authenticated by some other means, such as closed networks, cellular networks at Layer 2, etc., the service provider may decide to turn authentication off. If no authentication is conducted on any layer, the SC acts as a gateway for anonymous connections. Running such a service MUST be configurable by the SC administrator and the SC SHOULD take some security measures such as ingress filtering and adequate logging of activity. It should be noted that anonymous connection service cannot provide the security functionalities described in this document (e.g. integrity, replay protection and confidentiality).
L2TPv2 selected as Softwire phase 1 protocol supports PPP authentication and L2TPv2 authentication. PPP authentication and L2TPv2 have various security threats as stated in Section 3.3. They will be used in the limited condition as described in the next subsections.
| TOC |
PPP can provide mutual authentication between the SI and SC using CHAP [RFC1994] during the connection establishment phase (Link Control Protocol, LCP). PPP CHAP authentication can be used when the SI and SC are on a trusted, non-public IP network.
Since CHAP does not provide per-packet authentication, integrity, or replay protection, PPP CHAP authentication MUST NOT be used for unprotected on a public IP network. If other appropriate protected mechanism has been already applied, PPP CHAP authentication MAY be used.
Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY be supported.
| TOC |
L2TPv2 provides an optional CHAP-like tunnel authentication during the control connection establishment [RFC2661, 5.1.1]. L2TPv2 authentication MUST NOT be used for unprotected on a public IP network as the same restriction applied to PPP CHAP.
| TOC |
To meet the above requirements, all softwire security compliant implementations MUST implement the following security protocols.
IPsec ESP [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) in transport mode is used for securing softwire control and data packets. Internet Key Exchange (IKE) protocol[RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) MUST be supported for authentication, security association negotiation and key management for IPsec. The applicability of different version of IKE is discussed in Section 3.5.
The softwire security protocol MUST support NAT traversal. UDP encapsulation of IPsec ESP packets[RFC3948] (Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, “UDP Encapsulation of IPsec ESP Packets,” January 2005.) and negotiation of NAT-traversal in IKE[RFC3947] (Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, “Negotiation of NAT-Traversal in the IKE,” January 2005.) MUST be supported when IPsec is used.
| TOC |
When softwire "Hubs and Spokes" solution implemented by L2TPv2 is used in untrustworthy network, softwire MUST be protected by appropriate security protocol such as IPsec. This section provides guidelines for the usage of IPsec in L2TPv2 based softwire.
[RFC3193] (Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, “Securing L2TP using IPsec,” November 2001.) discusses how L2TP can use IKE [RFC2409] (Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” November 1998.) and IPsec [RFC2401] (Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.) to provide tunnel authentication, privacy protection, integrity checking and replay protection. Since its publication, the revision to IPsec protocols have been published (IKEv2 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.), ESP [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.), NAT-traversal for IKE [RFC3947] (Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, “Negotiation of NAT-Traversal in the IKE,” January 2005.) and ESP[RFC3948] (Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, “UDP Encapsulation of IPsec ESP Packets,” January 2005.)).
Given that deployed technology must be very strongly considered [RFC4925] (Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” July 2007.) for the 'time-to-market' solution, [RFC3193] (Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, “Securing L2TP using IPsec,” November 2001.) MUST be supported. However, the new implementation SHOULD use IKEv2 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) for IPsec because of the numerous advantages over IKE [RFC2409] (Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” November 1998.). In new deployments, IKEv2 SHOULD be used as well.
Although [RFC3193] (Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, “Securing L2TP using IPsec,” November 2001.) can be applied in the softwire "Hubs and Spokes" solution, softwire requirements such as NAT-traversal, NAT-traversal for IKE [RFC3947] (Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, “Negotiation of NAT-Traversal in the IKE,” January 2005.) and ESP [RFC3948] (Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, “UDP Encapsulation of IPsec ESP Packets,” January 2005.) MUST be supported.
Meanwhile, IKEv2 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) integrates NAT-traversal. IKEv2 also supports EAP authentication with the authentication using shared secrets (pre-shared key) or public key signature (certificate).
The selection of pre-shared key and certificate depends on the scale of the network for softwire to be deployed as described in Section 3.5.2. However, pre-shared key and certificates only support the machine authentication. When both machine and user authentications are required, for example, in the nomadic case, EAP SHOULD be used.
Together with EAP, IKEv2 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) supports legacy authentication methods that may be useful in environments where username and password based authentication is already deployed.
IKEv2 is more reliable protocol than IKE [RFC2409] (Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” November 1998.)in terms of the replay protection capability, DoS protection enabled mechanism etc. Therefore, new implementations SHOULD use IKEv2 over IKE.
The following sections will discuss using IPsec to protect L2TPv2 as applied in the softwire "Hubs and Spokes" model. Unless otherwise stated, IKEv2 and the new IPsec architecture [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) is assumed.
| TOC |
IPsec implementation using IKE only supports machine authentication. There is no way to verify a user identity and to segregate the tunnel traffic among users in the multi-user machine environment. IKEv2 can support user authentication with EAP payload by leveraging existing authentication infrastructure and credential database. This enables the traffic segregation among users when user authentication is used by combining the legacy authentication. The user identity asserted within IKEv2 will be verified on a per-packet basis.
If the AAA server is involved in security association establishment between the SI and SC, a session key can be derived from the authentication between the SI and the AAA server. Successful EAP exchanges within IKEv2 runs between the SI and the AAA server create a session key and it is securely transferred to the SC from the AAA server. The trust relationship between the involved entities follows Section 3.2 of this document.
| TOC |
With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity and replay protection. As a result, the identity verified in the IKE is subsequently verified on reception of each packet.
Authentication using pre-shared keys can be used when the number of SI and SC is small. As the number of SI and SC grows, pre-shared keys becomes increasingly difficult to manage. A softwire security protocol MUST provide a scalable approach to key management. Whenever possible, authentication with certificates is preferred.
When pre-shared keys are used, group pre-shared keys MUST NOT be used because of its vulnerability to Man-In-The-Middle attacks ([RFC3193], 5.1.4).
| TOC |
The L2TPv2/IPsec inter-operability concerning tunnel teardown, fragmentation and per-packet security checks given in ([RFC3193] section 3) must be taken into account.
Although the L2TP specification allows the responder (SC in softwire) to use a new IP address or to change the port number when sending the Start-Control-Connection-Request-Reply (SCCRP), a softwire concentrator implementation SHOULD NOT do this ([RFC3193] section 4).
However, with some reasons, for example, "load-balancing" between SCs, the IP address change is required. To signal an IP address change, the SC sends a StopCCN message to the SI using the Result and Error Code AVP in L2TPv2 message. A new IKE_SA and CHILD_SA MUST be established to the new IP address.
Since ESP transport mode is used, the UDP header carrying the L2TP packet will have an incorrect checksum due to the change of parts of the IP header during transit. [RFC3948] section 3.1.2 defines 3 procedures that can be used to fix the checksum. A softwire implementation MUST NOT use the "incremental update of checksum" (option 1 described in[RFC3948] (Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, “UDP Encapsulation of IPsec ESP Packets,” January 2005.)), because the IKEv2 does not have the information required (NAT-OA payload) to compute that checksum. Since ESP is already providing validation on the L2TP packet, a simple approach is to use the "do not check" approach (option 3 in [RFC3948] (Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, “UDP Encapsulation of IPsec ESP Packets,” January 2005.)).
| TOC |
If the old IPsec architecture [RFC2401] (Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.) and IKE [RFC2409] (Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” November 1998.) are used, the security policy database (SPD) examples in [RFC3193] (Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, “Securing L2TP using IPsec,” November 2001.) appendix A can be applied to softwire model. In that case, the initiator is always the client (SI), and responder is the SC. IPsec SPD examples for IKE [RFC2409] (Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” November 1998.) are also given in appendix A of this document.
The revised IPsec architecture [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) redefined the SPD entries to provide more flexibility (multiple selectors per entry, list of address range, peer authentication database (PAD), "populate from packet"(PFP) flag, etc.). The Internet Key Exchange (IKE) has also been revised and simplified in IKEv2 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.). The following sections provides the SPD examples for softwire to use the revised IPsec architecture and IKEv2.
| TOC |
If IKEv2 is used as the key management protocol, RFC4301 provides the guidance of the SPD entries. In IKEv2, we can use PFP flag to specify SA and the port number can be selected with Traffic Selector with TSr during CREATE_CHILD_SA. The following describes PAD entries on the SI and SC, respectively. The PAD entries are only example configurations. The PAD entry on the SC matches user identities to the L2TP SPD entry. This is done using a symbolic name type specified in [RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.).
SI PAD:
- IF remote_identity = SI_identity
Then authenticate (shared secret/certificate/)
and authorize CHILD_SA for remote address SC_address
SC PAD:
- IF remote_identity = user_1
Then authenticate (shared secret/certificate/EAP)
and authorize CHILD_SAs for symbolic name "l2tp_spd_entry"The following describes the SPD entries for the SI and SC, respectively. Note that IKEv2 and ESP traffic MUST be allowed (bypass). These include IP protocol 50 and UDP port 500 and 4500.
The IPv4 packet format of ESP protecting L2TPv2 carrying IPv6 packet is shown in Table 1 by using the similar Table in [RFC4891] (Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, “Using IPsec to Secure IPv6-in-IPv4 Tunnels,” May 2007.).
+----------------------------+------------------------------------+ | Components (first to last) | Contains | +----------------------------+------------------------------------+ | IPv4 header | (src = IPv4-SI, dst = IPv4-SC) | | ESP header | | | UDP header | (src port=1701, dst port=1701) | | L2TPv2 header | | | PPP header | | | IPv6 header | | | (payload) | | | ESP ICV | | +----------------------------+------------------------------------+ Table 1: Packet Format for L2TPv2 with ESP carrying IPv6 packet.
SPD for Softwire Initiator:
Softwire Initiator SPD-S
- IF local_address=IPv4-SI
remote_address=IPv4-SC
Next Layer Protocol=UDP
local_port=1701
remote_port=ANY (PFP=1)
Then use SA ESP transport mode
Initiate using IDi = user_1 to address IPv4-SCSPD for Softwire Concentrator:
Softwire Concentrator SPD-S
- IF name="l2tp_spd_entry"
local_address=IPv4-SC
remote_address=ANY (PFP=1)
Next Layer Protocol=UDP
local_port=1701
remote_port=ANY (PFP=1)
Then use SA ESP transport mode| TOC |
The PAD entries for SI and SC are shown as examples. These example configurations are similar to those in 3.3.4.1.[RFC4301] (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.)
SI PAD:
- IF remote_identity = SI_identity
Then authenticate (shared secret/certificate/)
and authorize CHILD_SA for remote address SC_address
SC PAD:
- IF remote_identity = user_2
Then authenticate (shared secret/certificate/EAP)
and authorize CHILD_SAs for symbolic name "l2tp_spd_entry"The following describes the SPD entries for the SI and SC, respectively. In this example, the SI and SC are denoted with IPv6 addresses IPv6-SI and IPv6-SC, respectively. Note that IKEv2 and ESP traffic MUST be allowed (bypass). These include IP protocol 50 and UDP port 500 and 4500.
The IPv6 packet format of ESP protecting L2TPv2 carrying IPv4 packet is shown in Table 2 by using similar one in [RFC4891] (Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, “Using IPsec to Secure IPv6-in-IPv4 Tunnels,” May 2007.).
+----------------------------+------------------------------------+ | Components (first to last) | Contains | +----------------------------+------------------------------------+ | IPv6 header | (src = IPv6-SI, dst = IPv6-SC) | | ESP header | | | UDP header | (src port=1701, dst port=1701) | | L2TPv2 header | | | PPP header | | | IPv4 header | | | (payload) | | | ESP ICV | | +----------------------------+------------------------------------+ Table 2: Packet Format for L2TPv2 with ESP carrying IPv4 packet.
SPD for Softwire Initiator:
Softwire Initiator SPD-S
- IF local_address=IPv6-SI
remote_address=IPv6-SC
Next Layer Protocol=UDP
local_port=1701
remote_port=ANY (PFP=1)
Then use SA ESP transport mode
Initiate using IDi = user_2 to address IPv6-SC
SPD for Softwire Concentrator:
Softwire Concentrator SPD-S
- IF name="l2tp_spd_entry"
local_address=IPv6-SC
remote_address=ANY (PFP=1)
Next Layer Protocol=UDP
local_port=1701
remote_port=ANY (PFP=1)
Then use SA ESP transport mode| TOC |
| TOC |
In the softwire “Mesh" solution[RFC4925] (Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” July 2007.), [RFC5565] (Wu, J., Cui, Y., Metz, C., and E. Rosen, “Softwire Mesh Framework,” June 2009.), it is required to establish connectivity to access network islands of one address family type across a transit core of a differing address family type. To provide reachability across the transit core, AFBRs are installed between access network island and transit core network. These AFBRs can perform as Provider Edge routers (PE) within an autonomous system or perform peering across autonomous systems. The AFBRs establish and encapsulate softwires in a mesh to the other islands across the transit core network. The transit core network consists of one or more service providers.
In the softwire “Mesh" solution, a pair of PE routers (AFBRs) use BGP to exchange routing information. AFBR nodes in the transit network are Internal BGP speakers and will peer with each other directly or via a route reflector to exchange SW-encap sets, perform softwire signaling, and advertise AF access island reachability information and SW-NHOP information. If such information is advertised within an autonomous system, the AFBR node receiving them from other AFBRs does not forward them to other AFBR nodes. To exchange the information among AFBRs, the full mesh connectivity will be established.
The connectivity between CE and PE routers includes dedicated physical circuits, logical circuits (such as Frame Relay and ATM), and shared medium access (such as Ethernet-based access).
When AFBRs are PE routers located at the edge of the provider core networks, this is similar architecture of the L3VPN described in [RFC4364] (Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006.). The connectivity between a CE router in access island network and a PE router in transit network is established by static way. The access islands are enterprise networks accommodated through PE routers in the provider's transit network. In this case, the access island networks are administrated by the provider's autonomous system.
The AFBRs may have the multiple connections to the core network, and also may have the connections to the multiple client access networks. The client access networks may connect each other through private networks or through the Internet. When the client access networks have their own AS number, a CE router located inside access islands forms a private BGP peering with an AFBR. Further, an AFBR may need to exchange a full Internet routing information with each network to which it connects.
| TOC |
All AFBR nodes in the transit core MUST have a trust relationship or an agreement with each other to establish softwires. When the transit core consists of a single administrative domain, it is assumed that all nodes (e.g. AFBR, PE or Route Reflector, if applicable) are trusted with each other.
If the transit core consists of multiple administrative domains, intermediate routers between AFBRs may not be trusted.
There MUST be a trust relationship between the PE in the transit core and the CE in the corresponding island, although the link(s) between the PE and the CE may not be protected.
| TOC |
As the architecture of softwire mesh solution is very similar to that of the provider provisioned VPN (PPVPN). The security threats considerations on the PPVPN operation are applicable to those in the softwire mesh solution [RFC4111] (Fang, L., “Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs),” July 2005.).
Examples of attacks to data packets being transmitted on a softwire tunnel include:
The security attacks can be mounted on the control plane as well. In softwire mesh solution, softwires encapsulation will be set up by using BGP. As described in [RFC4272] (Murphy, S., “BGP Security Vulnerabilities Analysis,” January 2006.), BGP is vulnerable to various security threats such as confidential violation, replay attacks, insertion, deletion and modification of BGP messages, main-in-the-middle, and denial-of-service.
| TOC |
Given that security is generally a compromise between expense and risk, it is also useful to consider the likelihood of different attacks. There is at least a perceived difference in the likelihood of most types of attacks being successfully mounted in different deployment.
The trust relationship among users in access networks, transit core provider, and other parts of networks described in section 4.2 is a key element in determining the applicability of security protection mechanism for the specific softwire mesh deployment.
| TOC |
The Softwire Problem Statement [RFC4925] (Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” July 2007.) states that the softwire mesh setup mechanism to advertise the softwire encapsulation MUST support authentication, but the transit core provider may decide to turn it off in some circumstances.
The BGP authentication mechanism is specified in [RFC2385] (Heffernan, A., “Protection of BGP Sessions via the TCP MD5 Signature Option,” August 1998.). The mechanism defined in [RFC2385] (Heffernan, A., “Protection of BGP Sessions via the TCP MD5 Signature Option,” August 1998.) is based on a one-way hash function (MD5) and use of a secret key. The key is shared between a pair of peer routers and is used to generate 16-byte message authentication code values that are not readily computed by an attacker who does not have access to the key.
However the security mechanism for BGP transport (e.g. TCP-MD5) is inadequate in some circumstances and also requires operator interaction to maintain a respectable level of security. The current deployments of TCP-MD5 exhibit some shortcomings with respect of key management as described in [RFC3562] (Leech, M., “Key Management Considerations for the TCP MD5 Signature Option,” July 2003.).
Key management can be especially cumbersome for operators. The number of keys required and the maintenance of keys (issue/revoke/ renew) has had an additive effect as a barrier to deployment. Thus automated means of managing keys, to reduce operational burdens, is available in BGP security system [I‑D.ietf‑rpsec‑bgpsecrec] (Christian, B. and T. Tauber, “BGP Security Requirements,” November 2008.), [RFC4107] (Bellovin, S. and R. Housley, “Guidelines for Cryptographic Key Management,” June 2005.).
Use of IPsec counters the message insertion, deletion, and modification attacks, as well as man-in-the-middle attacks by outsiders. If routing data confidentiality is desired, the use of IPsec ESP could provide that service. If eavesdropping attack is identified as a threat, ESP can be used to provide confidentiality (encryption), integrity and authentication for the BGP session.
| TOC |
To transport data packets across the transit core, the mesh solution defines multiple encapsulations: L2TPv3, IP-in-IP, MPLS (LDP-based and RSVP-TE based), and GRE. To securely transport such data packet, the softwire MUST support IPsec tunnel.
IPsec can provide authentication and integrity. The implementation MUST support ESP with null encryption [RFC4303] (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) or else AH (IP Authentication Header) [RFC4302] (Kent, S., “IP Authentication Header,” December 2005.). If some part of the transit core network is not trusted, ESP with encryption MAY be applied.
Since the softwires are created dynamically by BGP, the automated key distribution MUST be performed by IKEv2 [RFC4306] (Kaufman, C., “Internet Key Exchange (IKEv2) Protocol,” December 2005.) with either pre-shared key or public key management. For the dynamic softwire IPsec tunnel creation, pre-shared key will be same in all routers. Namely pre-shared key indicates here group key instead of pairwise shared key.
If security policy requires a stronger key management, the public key SHOULD be used. If a public key infrastructure is not available, the IPsec Tunnel Authentication sub-TLV specified in [RFC5566] (Berger, L., White, R., and E. Rosen, “BGP IPsec Tunnel Encapsulation Attribute,” June 2009.) MUST be used before SA is established.
If the link(s) between the user's site and the provider's PE is not trusted, then encryption MAY be used on the PE-CE link(s).
Together with the cryptographic security protection, the access control technique reduces the exposure to attacks from outside the service provider networks (transit networks). The access control technique includes packet-by-packet or packet flow-by-packet flow access control by means of filters as well as by means of admitting a session for a control/signaling/management protocol that is being used to implement softwire mesh.
The access control technique is an important protection against security attacks of DoS etc. and a necessary adjunct to cryptographic strength in encapsulation. Packets that match the criteria associated with a particular filter may be either discarded or given special treatment to prevent an attack or to mitigate the effect of a possible future attack.
| TOC |
This document discusses various security threats for the softwire control and data packets in “Hubs and Spokes" and “Mesh" time-to-market solutions. With these discussions, the softwire security protocol implementations are provided referencing to Softwire Problem Statement [RFC4925] (Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” July 2007.), Securing L2TP using IPsec [RFC3193] (Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, “Securing L2TP using IPsec,” November 2001.), Security Framework for PPVPNs [RFC4111] (Fang, L., “Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs),” July 2005.), and Guidelines for Mandating the Use of IPsec [RFC5406] (Bellovin, S., “Guidelines for Specifying the Use of IPsec Version 2,” February 2009.). The guidelines for the security protocol employment are also given considering the specific deployment context.
Note that this document discusses the softwire tunnel security protection and does not address the end-to-end protection.
| TOC |
This document creates no new requirements on IANA namespaces [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.).
| TOC |
The authors would like to thank Tero Kivinen for reviewing the document and Francis Dupont for substantive suggestions. Acknowledgments to Jordi Palet Martinez, Shin Miyakawa, Yasuhiro Shirasaki, and Bruno Stevant for their feedback.
We would like also to thank the authors of Softwire Hub & Spoke Deployment Framework document for providing the text concerning security.
| TOC |
| TOC |
| TOC |
| [I-D.ietf-rpsec-bgpsecrec] | Christian, B. and T. Tauber, “BGP Security Requirements,” draft-ietf-rpsec-bgpsecrec-10 (work in progress), November 2008 (TXT). |
| [I-D.ietf-softwire-hs-framework-l2tpv2] | Storer, B., Pignataro, C., Santos, M., Stevant, B., and J. Tremblay, “Softwire Hub & Spoke Deployment Framework with L2TPv2,” draft-ietf-softwire-hs-framework-l2tpv2-12 (work in progress), March 2009 (TXT). |
| [RFC2401] | Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” RFC 2401, November 1998 (TXT, HTML, XML). |
| [RFC2409] | Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” RFC 2409, November 1998 (TXT, HTML, XML). |
| [RFC2607] | Aboba, B. and J. Vollbrecht, “Proxy Chaining and Policy Implementation in Roaming,” RFC 2607, June 1999 (TXT). |
| [RFC3562] | Leech, M., “Key Management Considerations for the TCP MD5 Signature Option,” RFC 3562, July 2003 (TXT). |
| [RFC4016] | Parthasarathy, M., “Protocol for Carrying Authentication and Network Access (PANA) Threat Analysis and Security Requirements,” RFC 4016, March 2005 (TXT). |
| [RFC4081] | Tschofenig, H. and D. Kroeselberg, “Security Threats for Next Steps in Signaling (NSIS),” RFC 4081, June 2005 (TXT). |
| [RFC4111] | Fang, L., “Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs),” RFC 4111, July 2005 (TXT). |
| [RFC4213] | Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” RFC 4213, October 2005 (TXT). |
| [RFC4225] | Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, “Mobile IP Version 6 Route Optimization Security Design Background,” RFC 4225, December 2005 (TXT). |
| [RFC4272] | Murphy, S., “BGP Security Vulnerabilities Analysis,” RFC 4272, January 2006 (TXT). |
| [RFC4364] | Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” RFC 4364, February 2006 (TXT). |
| [RFC4593] | Barbir, A., Murphy, S., and Y. Yang, “Generic Threats to Routing Protocols,” RFC 4593, October 2006 (TXT). |
| [RFC4891] | Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, “Using IPsec to Secure IPv6-in-IPv4 Tunnels,” RFC 4891, May 2007 (TXT). |
| [RFC4925] | Li, X., Dawkins, S., Ward, D., and A. Durand, “Softwire Problem Statement,” RFC 4925, July 2007 (TXT). |
| [RFC5216] | Simon, D., Aboba, B., and R. Hurst, “The EAP-TLS Authentication Protocol,” RFC 5216, March 2008 (TXT). |
| [RFC5406] | Bellovin, S., “Guidelines for Specifying the Use of IPsec Version 2,” BCP 146, RFC 5406, February 2009 (TXT). |
| [RFC5565] | Wu, J., Cui, Y., Metz, C., and E. Rosen, “Softwire Mesh Framework,” RFC 5565, June 2009 (TXT). |
| [RFC5566] | Berger, L., White, R., and E. Rosen, “BGP IPsec Tunnel Encapsulation Attribute,” RFC 5566, June 2009 (TXT). |
| TOC |
If the old IPsec architecture [RFC2401] (Kent, S. and R. Atkinson, “Security Architecture for the Internet Protocol,” November 1998.) and IKE [RFC2409] (Harkins, D. and D. Carrel, “The Internet Key Exchange (IKE),” November 1998.) are used, the SPD examples in [RFC3193] (Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, “Securing L2TP using IPsec,” November 2001.) is applicable to "Hub & Spokes" model. In this model, the initiator is always the client (SI) and the responder is the SC.
| TOC |
IPv4 addresses of the softwire initiator and concentrator are denoted by IPv4-SI and IPv4-SC, respectively. If NAT traversal is used in IKE, UDP source and destination ports are 4500. In this SPD entry, IKE refers to UDP port 500. * denotes wildcard and indicates ANY port or address.
Local Remote Protocol Action
----- ------ -------- ------
IPV4-SI IPV4-SC ESP BYPASS
IPV4-SI IPV4-SC IKE BYPASS
IPv4-SI IPV4-SC UDP, src 1701, dst 1701 PROTECT(ESP,
transport)
IPv4-SC IPv4-SI UDP, src * , dst 1701 PROTECT(ESP,
transport)
| Softwire initiator SPD |
Remote Local Protocol Action
------ ------ -------- ------
* IPV4-SC ESP BYPASS
* IPV4-SC IKE BYPASS
* IPV4-SC UDP, src * , dst 1701 PROTECT(ESP,
transport)
| Softwire concentrator SPD |
| TOC |
IPv6 addresses of the softwire initiator and concentrator are denoted by IPv6-SI and IPv6-SC, respectively. If NAT traversal is used in IKE, UDP source and destination ports are 4500. In this SPD entry, IKE refers to UDP port 500. * denotes wildcard and indicates ANY port or address.
Local Remote Protocol Action
----- ------ -------- ------
IPV6-SI IPV6-SC ESP BYPASS
IPV6-SI IPV6-SC IKE BYPASS
IPv6-SI IPV6-SC UDP, src 1701, dst 1701 PROTECT(ESP,
transport)
IPv6-SC IPv6-SI UDP, src * , dst 1701 PROTECT(ESP,
transport)
| Softwire initiator SPD |
Remote Local Protocol Action
------ ------ -------- ------
* IPV6-SC ESP BYPASS
* IPV6-SC IKE BYPASS
* IPV6-SC UDP, src * , dst 1701 PROTECT(ESP,
transport)
| Softwire concentrator SPD |
| TOC |
| Shu Yamamoto | |
| NICT/KDDI R&D Labs | |
| 1-13-16 Hakusan, Bunkyo-ku | |
| Tokyo, 113-0001 | |
| Japan | |
| Phone: | +81-3-3868-6913 |
| Email: | shu@nict.go.jp |
| Carl Williams | |
| KDDI R&D Labs | |
| Palo Alto, CA 94301 | |
| USA | |
| Phone: | +1-650-279-5903 |
| Email: | carlw@mcsr-labs.org |
| Florent Parent | |
| Beon Solutions | |
| Quebec, QC | |
| Canada | |
| Email: | Florent.Parent@beon.ca |
| Hidetoshi Yokota | |
| KDDI R&D Labs | |
| 2-1-15 Ohara | |
| Fujimino, Saitama 356-8502 | |
| Japan | |
| Phone: | +81-49-278-7894 |
| Email: | yokota@kddilabs.jp |