Network Working Group S. Yamamoto
Internet-Draft NICT/KDDI R&D Labs
Intended status: Standards Track C. Williams
Expires: August 28, 2008 KDDI R&D Labs
F. Parent
Beon Solutions
H. Yokota
KDDI R&D Labs
February 25, 2008
Softwire Security Analysis and Requirements
draft-ietf-softwire-security-requirements-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 August 28, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
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
Yamamoto, et al. Expires August 28, 2008 [Page 1]
Internet-Draft Softwire security considerations February 2008
security attacks is analyzed to provide the security protection
mechanism such as authentication, integrity and confidentiality to
the softwire control and data packets.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Hubs and Spokes Security Guidelines . . . . . . . . . . . . . 5
3.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 5
3.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 7
3.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 7
3.4. Softwire Security Guidelines . . . . . . . . . . . . . . . 10
3.4.1. Authentication . . . . . . . . . . . . . . . . . . . . 11
3.4.2. Softwire Security Protocol . . . . . . . . . . . . . . 12
3.5. Guidelines for Usage of IPsec in Softwire . . . . . . . . 12
3.5.1. Authentication Issues . . . . . . . . . . . . . . . . 13
3.5.2. IPsec Pre-Shared Keys for Authentication . . . . . . . 13
3.5.3. Inter-Operability Guidelines . . . . . . . . . . . . . 13
3.5.4. IPsec Filtering Details . . . . . . . . . . . . . . . 14
4. Mesh Security Guidelines . . . . . . . . . . . . . . . . . . . 17
4.1. Deployment Scenario . . . . . . . . . . . . . . . . . . . 17
4.2. Trust Relationship . . . . . . . . . . . . . . . . . . . . 18
4.3. Softwire Security Threat Scenarios . . . . . . . . . . . . 19
4.4. Applicability of Security Protection Mechanism . . . . . . 19
4.4.1. Security Protection Mechanism for Control Plane . . . 20
4.4.2. Security Protection Mechanism for Data Plane . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 24
A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE . . . 24
A.2. IPv4 over IPv6 Softwire with example for IKE . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Yamamoto, et al. Expires August 28, 2008 [Page 2]
Internet-Draft Softwire security considerations February 2008
1. Introduction
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 exisiting
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] Section 2 and Section 3,
respectively. The protocols selected for softwire connectivity
require the security consideration on more specific deployment
scenarios for each solution.
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]. Note that other
adequate security mechanisms are applicable, the security protocol
for softwire is not necessarily mandated. 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 new implementation SHOULD use IKEv2
in the key management protocol for IPsec because of more reliable
protocol and integration of required protocols in a sigle platform.
The softwire "Mesh" solution should 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]. 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. As the security considerations for BGP is being discussed in
other working groups, this document provides general guidelines for
the deployment scenario being envisaged.
2. Terminology
Yamamoto, et al. Expires August 28, 2008 [Page 3]
Internet-Draft Softwire security considerations February 2008
2.1. Abbreviations
The terminology is based on the softwire problem statement document
[RFC4925].
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.
Yamamoto, et al. Expires August 28, 2008 [Page 4]
Internet-Draft Softwire security considerations February 2008
2.2. Requirements Language
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].
3. Hubs and Spokes Security Guidelines
3.1. Deployment Scenarios
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 models, the following three cases as shown
in Figure 1 should be considered. In these cases, the automated
discovery of the softwire concentrator (SC) may be used. But in this
document, the information on the SC such as the DNS name or IP
address is assumed to be configured by the user, or by the provider
of the SI in advance.
Case 1: The SI connects to the SC that belongs to the home network
service provider via the home access provider network. The IP
address of the host may be changed periodically due to the home
network service provider's policy.
Case 2: The SI connects to the SC that belongs to the home network
service provider via the visited access network. This is typical of
nomadic access use case. The host does not subscribe to the visited
access provider, but this provider has some roaming agreement with
the home network service provider of the host. The IP address of the
host 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 also
Yamamoto, et al. Expires August 28, 2008 [Page 5]
Internet-Draft Softwire security considerations February 2008
typical of nomadic access use case. The host does not subscribe to
the visited network service provider, but this provider has some
roaming agreement with the home network service provider of the host.
In this case, the IP address of the host is determined by the visited
network service provider's policy.
The trust relationship for these three cases will also be different.
The security consideration must take them into account. In
particular, to allow cases 2 and 3, the authentication infrastructure
between the SI and SC is needed to establish the trust relationship.
The softwire problem statement[RFC4925] states that the softwire
solution must be able to be integrated with commonly deployed AAA
solution. In these cases, AAA interactions between the home network
service provider and visited access/service provider should be
considered. The details of this scenario are given in Section 3.2.
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: Hubs and Spokes model
Yamamoto, et al. Expires August 28, 2008 [Page 6]
Internet-Draft Softwire security considerations February 2008
3.2. Trust Relationship
To perform authentication between the SC and SI, the AAA server needs
to be involved. One or more AAA servers should reside in the same
administrative domain as the SC to authenticate the SI. When the SI
is mobile, it may roam from the home ISP network to another, e.g. a
WiFi hot-spot network. In such a situation, the SI may not always
connect to the same SC. From the SI's viewpoint, the AAA server that
is in the same administrative domain is called the home AAA server
and those not in the same administrative domain are called visited
AAA servers. The trust relationships between those nodes are as
follows:
It can be assumed that the SC and the AAA in the same administrative
domain share a trust relationship. When the SC needs to authenticate
the SI, the SC communicates with the AAA server to request
authentication and/or to obtain security information. If the SI
roams into a network that is not in the same administrative domain,
the visited AAA server communicates with the home AAA server that has
the SI's security information. Therefore, the communication between
the SC and the AAA server must be protected. It can be usually
assumed that the home and visited AAA servers share a trust
relationship and the connection between them is protected.
It can be assumed that the SI and the home AAA server share a trust
relationship. The home AAA server provides security information on
the SI when it is requested by the visited AAA server. The SI and
the visited AAA server do not usually have a trust relationship;
however, if the SI can confirm that the home AAA server is involved
with the authentication of the SI and the visited AAA server does not
alter security information from the home AAA server, the visited AAA
server can be trusted by the SI. The communication between the SI,
the home and visited AAA servers must be protected.
The SI and the SC do not necessarily share a trust relationship
especially when the SI roams into a different administrative domain.
When they are mutually authenticated by means of e.g. AAA servers,
they can start trusting each other. Unless authentication is
successfully performed, the softwire protocol should not be
initiated.
3.3. Softwire Security Threat Scenarios
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
attack.
Yamamoto, et al. Expires August 28, 2008 [Page 7]
Internet-Draft Softwire security considerations February 2008
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], [I-D.ietf-softwire-hs-
framework-l2tpv2]. 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] is
applicable to softwire "Hubs and Spokes" deployment. The threat
analysis for other protocols such as PANA [RFC4016], NSIS [RFC4081],
and Routing Protocols [RFC4593] are applicable here as well and
should be used as reference.
First, the SI resided in the customer network sends Start-Control-
Connection-Request(SCCRQ) packet to the SC for the initiation of the
softwire. Optionally, L2TP exchanges Challenge and Response AVPs for
tunnel mutual authentication in L2TPv2 tunnel creation. For the CHAP
authentication key, L2TPv2 protocol does not provide the key
management facilities.
Once L2TPv2 process has been completed, 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, which can be interworked with the AAA server.
Other authentication of PAP authentication, MS-CHAP, and EAP MAY be
supported. But 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 access is granted to the SI, other protocols start for
network configuration and the node in the SI side will exchange data
with other nodes in the network connected through the SC.
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:
Yamamoto, et al. Expires August 28, 2008 [Page 8]
Internet-Draft Softwire security considerations February 2008
1. An adversary may try to discover identities by snooping data
packets.
2. An adversary may try to modify both control and data packets.
This type of attack involves integrity violations.
3. An adversary may try to eavesdrop and collect control messages.
By replaying these messages, an adversary may successfully hijack
the L2TP tunnel or the PPP connection inside the tunnel. An
adversary might mount MITM, DOS, and theft of service attacks.
4. An adversary can flood the softwire node with bogus signaling
messages to cause DoS attacks by terminating L2TP tunnels or PPP
connections.
5. An adversary may attempt to disrupt the softwire negotiation in
order to weaken or remove confidentiality protection.
6. An adversary may wish to disrupt the PPP LCP authentication
negotiation.
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.
To access the SC through the public networks, any node can pretend to
be a SC, if there is no prior trust relationship between the SI and
SC. In this case, an adversary may impersonate the SC to intercept
traffic (e.g. "rogue" softwire concentrator).
The rogue SC captures all of necessary information (including keys if
security is present) of a legitimate softwire node and remove the
message of the subgroup of the network. The rogue SC can introduce a
black hole attack in which the attacker sends out forged routing
packets and setup a route to some destination via itself and when the
actual data packets get in, they are simply dropped, forming a black
hole at the SC - where data enters but never leaves. Another
possibility is for an attacker to forge routes pointing into an area
where the destination node is not located. Everything will be routed
into this area but nothing will leave.
The deployment of ingress filtering is able to control the malicious
users' access. Without specific ingress filtering checks in the
decapsulator at the SC, it would be possible for an attacker to
inject a false packet. This causes DoS attack. The inner address
ingress filtering can reject invalid inner source address. Without
inner address ingress filtering, another kind of attack can happen.
Yamamoto, et al. Expires August 28, 2008 [Page 9]
Internet-Draft Softwire security considerations February 2008
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. To protect
address spoofing, authentication MUST be implemented in the tunnel
encapsulation.
3.4. Softwire Security Guidelines
Based on the security threat analysis in Section 3.3 in this
document, the softwire security protocol must support the following
protections.
1. Softwire control messages between the SI and SC MUST BE protected
against eavesdropping and spoofing attacks.
2. Softwire security protocol MUST be able to protect itself against
replay attacks.
3. Softwire security protocol MUST be able to protect the device
identifier against the impersonation when it is exchanged between
the SI and the SC.
4. Softwire security protocol MUST be able to securely bind the
authenticated session to the device identifier of the client, to
prevent service theft.
5. Softwire security protocol MUST be able to protect disconnect and
revocation messages.
The softwire security protocol requirement is comparable to RFC3193.
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 MUST be supported and confidentiality MAY be supported.
The softwire problem statement [RFC4925] provides some requirements
for "Hubs and Spoke" solution that are taken into account in defining
the security protection mechanisms.
1. Control and/or data plane must be able to provide full payload
security when desired.
2. Deployed technology must be very strongly considered
This additional security protection must be separable from the
Yamamoto, et al. Expires August 28, 2008 [Page 10]
Internet-Draft Softwire security considerations February 2008
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.
3.4.1. Authentication
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. The protocol SHOULD offer
mutual authentication in scenarios where the SI requires identity
proof from the SC, for example, the SI accesses to the SC across the
public network.
In some circumstances, the service provider may decide to allow non-
authenticated connection [I-D.ietf-softwire-hs-framework-l2tpv2].
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 it 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).
3.4.1.1. PPP Authentication
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. This means that there is no
reason to prohibit PPP CHAP authentication if appropriate protected
mechanism has been applied.
Optionally, other authentication methods such as PAP, MS-CHAP EAP MAY
be supported.
3.4.1.1.1. L2TPv2 Authentication
L2TPv2 provides an optional CHAP-like[RFC1994] tunnel authentication
Yamamoto, et al. Expires August 28, 2008 [Page 11]
Internet-Draft Softwire security considerations February 2008
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.
3.4.2. Softwire Security Protocol
To meet the above requirements, all softwire security compliant
implementations MUST implement the following security protocols.
IPsec ESP [RFC4303] in transport mode is used for securing softwire
control and data packets. Internet Key Exchange (IKE)
protocol[RFC4306] 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] and negotiation of NAT-
traversal in IKE[RFC3947] MUST be supported when IPsec is used.
3.5. Guidelines for Usage of IPsec in Softwire
[RFC3193] discusses how L2TP can use IPsec to provide tunnel
authentication, privacy protection, integrity checking and replay
protection. Since its publication, the revision to IPsec protocols
have been published (IKEv2 [RFC4306], ESP [RFC4303], NAT-traversal
for IKE [RFC3947] and ESP[RFC3948]).
Although [RFC3193] can be applied in the softwire "Hubs and Spokes"
solution, softwire requirements such as NAT-traversal, NAT-traversal
for IKE [RFC3947] and ESP [RFC3948] MUST be supported.
IKEv2 [RFC4306] integrates NAT-traversal. IKEv2 also supports EAP
authentication with the authentication using shared secrets and
public key signatures. IKEv2 is more reliable protocol than IKE
[RFC2409] in terms of the replay protection capability, DoS
protection enabled mechanism etc. Therefore, new implementations
SHOULD use IKEv2 over IKE.
IKEv2 [RFC4306] supports legacy authentication methods that may be
useful in environments where username and password based
authentication is already deployed.
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] is assumed.
Yamamoto, et al. Expires August 28, 2008 [Page 12]
Internet-Draft Softwire security considerations February 2008
3.5.1. Authentication Issues
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. Such a scenario
can be found in[I-D.eronen-ipsec-ikev2-eap-auth]. 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.
3.5.2. IPsec Pre-Shared Keys for Authentication
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).
3.5.3. Inter-Operability Guidelines
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).
Yamamoto, et al. Expires August 28, 2008 [Page 13]
Internet-Draft Softwire security considerations February 2008
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]), 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]).
3.5.4. IPsec Filtering Details
If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used,
the security policy database (SPD) examples in [RFC3193] 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] are also given in appendix A of this document.
The revised IPsec architecture [RFC4301] 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]. The following
sections provides the SPD examples for softwire to use the revised
IPsec architecture and IKEv2.
3.5.4.1. IPv6 over IPv4 Softwire L2TPv2 example for IKEv2
If IKEv2 is used as the key management protocol, RFC4301 provides the
guidance of the SPD etnries. 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.
Yamamoto, et al. Expires August 28, 2008 [Page 14]
Internet-Draft Softwire security considerations February 2008
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].
+----------------------------+------------------------------------+
| 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-SC
Yamamoto, et al. Expires August 28, 2008 [Page 15]
Internet-Draft Softwire security considerations February 2008
SPD 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
3.5.4.2. IPv4 over IPv6 Softwire L2TPv2 example for IKEv2
The PAD entries are only example configurations. The PAD entries
specify that the IP address in the traffic selector payload
(SC_address and SI_address) is used for matching against the SPD.
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 remote address SI_address
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].
Yamamoto, et al. Expires August 28, 2008 [Page 16]
Internet-Draft Softwire security considerations February 2008
+----------------------------+------------------------------------+
| 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 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
4. Mesh Security Guidelines
4.1. Deployment Scenario
In the softwire "Mesh" solution[RFC4925],
[I-D.ietf-softwire-mesh-framework], 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
Yamamoto, et al. Expires August 28, 2008 [Page 17]
Internet-Draft Softwire security considerations February 2008
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]. 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.
4.2. Trust Relationship
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.
Yamamoto, et al. Expires August 28, 2008 [Page 18]
Internet-Draft Softwire security considerations February 2008
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.
4.3. Softwire Security Threat Scenarios
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].
Examples of attacks to data packets being transmitted on a softwire
tunnel include:
1. An adversary may try to discover confidential information by
sniffing softwire packets.
2. An adversary may try to modify the contents of softwire packets.
3. An adversary may try to spoof the softwire packets that do not
belong the authorized domains and to insert copies of once-
legitimate packets that have been recorded and replayed.
4. An adversary can launch Denial-of-Service (DoS) attack by
deleting softwire data traffic. DoS attacks of the resource
exhaustion type can be mounted against the data plane by spoofing
a large amount of non-authenticated data into the softwire from
the outside of the softwire tunnel.
5. An adversary may try to sniff softwire packets and to examine
aspects or meta-aspects of them that may be visible even when the
packets themselves are encrypted. An attacker might gain useful
information based on the amount and timing of traffic, packet
sizes, sources and destination addresses, etc.
The security attacks can be mounted on the control plane as well. In
softwire mesh solution, softwires encapsulation will be setup by
using BGP. As described in [RFC4272], 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.
4.4. Applicability of Security Protection Mechanism
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
Yamamoto, et al. Expires August 28, 2008 [Page 19]
Internet-Draft Softwire security considerations February 2008
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.
4.4.1. Security Protection Mechanism for Control Plane
The Softwire Problem Statement [RFC4925] 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]. The
mechanism defined in [RFC2385] 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].
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],
[RFC4107].
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.
4.4.2. Security Protection Mechanism for Data Plane
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.
Yamamoto, et al. Expires August 28, 2008 [Page 20]
Internet-Draft Softwire security considerations February 2008
IPsec can provide authentication and integrity. The implementation
MUST support ESP with null encryption RFC4303. If some part of the
transit core network is not trusted, ESP with encryption may be
applied.
The automated key distribution can be performed by IKE with the pre-
shared key management. But the implementation of IPsec with
automatic key management depends on the operational requirements, for
example, the scalability requirement, etc.
To provide replay protection, automated key management system using
IKEv2 can be used. IKEv2 can be applied using shared secrets for
authentication when the number of BGP peers is small. When the
number of BGP peers is large, managing the shared secrets on all
peers does not scale. In this scenario, public-key digital signature
or key encryption authentication in IKE SHOULD be used.
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.
5. Security Considerations
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], Securing L2TP using IPsec [RFC3193], Security
Framework for PPVPNs [RFC4111], and Guidelines for Mandating the Use
of IPsec [I-D.bellovin-useipsec]. The guidelines for the security
protocol employment are also given considering the specific
deployment context.
Yamamoto, et al. Expires August 28, 2008 [Page 21]
Internet-Draft Softwire security considerations February 2008
Note that this document discusses the softwire tunnel security
protection and does not address the end-to-end protection.
6. IANA Considerations
This document creates no new requirements on IANA namespaces
[RFC2434].
7. Acknowledgments
The authors would like to thank Tero Kivinen for reviewing the
document and Francis Dupont for substative 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.
8. References
8.1. Normative References
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
Protocol (CHAP)", RFC 1994, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth,
"Securing L2TP using IPsec", RFC 3193, November 2001.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
Yamamoto, et al. Expires August 28, 2008 [Page 22]
Internet-Draft Softwire security considerations February 2008
January 2005.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
8.2. Informative References
[I-D.bellovin-useipsec]
Bellovin, S., "Guidelines for Mandating the Use of IPsec
Version 2", draft-bellovin-useipsec-07 (work in progress),
October 2007.
[I-D.eronen-ipsec-ikev2-eap-auth]
Tschofenig, H. and P. Eronen, "Extension for EAP
Authentication in IKEv2",
draft-eronen-ipsec-ikev2-eap-auth-05 (work in progress),
June 2006.
[I-D.ietf-rpsec-bgpsecrec]
Christian, B. and T. Tauber, "BGP Security Requirements",
draft-ietf-rpsec-bgpsecrec-09 (work in progress),
November 2007.
[I-D.ietf-softwire-hs-framework-l2tpv2]
Storer, B., Pignataro, C., Santos, M., Stevant, B., and J.
Tremblay, "Softwires Hub & Spoke Deployment Framework with
L2TPv2", draft-ietf-softwire-hs-framework-l2tpv2-07 (work
in progress), September 2007.
[I-D.ietf-softwire-mesh-framework]
Wu, J., "Softwire Mesh Framework",
draft-ietf-softwire-mesh-framework-02 (work in progress),
July 2007.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Yamamoto, et al. Expires August 28, 2008 [Page 23]
Internet-Draft Softwire security considerations February 2008
Internet Protocol", RFC 2401, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5
Signature Option", RFC 3562, July 2003.
[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication
and Network Access (PANA) Threat Analysis and Security
Requirements", RFC 4016, March 2005.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
Next Steps in Signaling (NSIS)", RFC 4081, June 2005.
[RFC4111] Fang, L., "Security Framework for Provider-Provisioned
Virtual Private Networks (PPVPNs)", RFC 4111, July 2005.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006.
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
RFC 4891, May 2007.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
Appendix A.
If the old IPsec architecture [RFC2401] and IKE [RFC2409] are used,
the SPD examples in [RFC3193] is applicable to "Hub & Spokes" model.
In this model, the initiator is always the client (SI) and the
responder is the SC.
A.1. IPv6 over IPv4 Softwire with L2TPv2 example for IKE
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
Yamamoto, et al. Expires August 28, 2008 [Page 24]
Internet-Draft Softwire security considerations February 2008
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
A.2. IPv4 over IPv6 Softwire with example for IKE
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)
Yamamoto, et al. Expires August 28, 2008 [Page 25]
Internet-Draft Softwire security considerations February 2008
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
Authors' Addresses
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
Phone: +1 418 353 0857
Email: Florent.Parent@beon.ca
Yamamoto, et al. Expires August 28, 2008 [Page 26]
Internet-Draft Softwire security considerations February 2008
Hidetoshi Yokota
KDDI R&D Labs
2-1-15 Ohara
Fujimino, Saitama 356-8502
Japan
Phone: 81 (49) 278-7894
Email: yokota@kddilabs.jp
Yamamoto, et al. Expires August 28, 2008 [Page 27]
Internet-Draft Softwire security considerations February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Yamamoto, et al. Expires August 28, 2008 [Page 28]
