MIP4 Working Group V. Devarapalli
Internet-Draft P. Eronen
Expires: January 11, 2006 Nokia
July 10, 2005
Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE
draft-devarapalli-mip4-mobike-connectivity-00
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 January 11, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Enterprise users require mobility and secure connectivity when they
roam and connect to the services offered in the enterprise. Secure
connectivity is required when the user connects to the enterprise
from an untrusted network. Mobility is beneficial when the user
moves, either inside or outside the enterprise network, and acquires
a new IP address. This document describes a solution using Mobile
IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure
connectivity and mobility.
Devarapalli & Eronen Expires January 11, 2006 [Page 1]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Access modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 Access mode: 'c' . . . . . . . . . . . . . . . . . . . 6
3.1.2 Access mode: 'f' . . . . . . . . . . . . . . . . . . . 6
3.1.3 Access mode: 'mc' . . . . . . . . . . . . . . . . . . 7
3.2 Mobility within the enterprise . . . . . . . . . . . . . . 7
3.3 Mobility when outside the enterprise . . . . . . . . . . . 7
3.4 Crossing Security Boundaries . . . . . . . . . . . . . . . 8
3.4.1 Operation when moving from an untrusted network . . . 8
3.4.2 Operation when moving from a trusted network . . . . . 9
4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1 Normative References . . . . . . . . . . . . . . . . . . . 10
8.2 Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Mobility Extensions for IKEv1 . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 14
Devarapalli & Eronen Expires January 11, 2006 [Page 2]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
1. Introduction
A typical enterprise network consists of users connecting to the
services from a trusted network (intranet), and from an untrusted
network (Internet). The trusted and untrusted networks are,
typically, separated by a DMZ. Access to the intranet is controlled
by a firewall and a VPN gateway in the DMZ.
Enterprise users, when roaming on untrusted networks, most often have
to authenticate themselves to the VPN gateway and setup a secure
tunnel in order to access the intranet. The use of IPsec VPNs is
very common to enable such secure connectivity to the intranet. When
the user is on the trusted network, VPNs are not used. However, the
users benefit tremendously when session mobility between subnets,
through the use of Mobile IPv4, is available.
There has been some work done on using Mobile IPv4 and IPsec VPNs to
provide roaming and secure connectivity to an enterprise [10]. The
solution described in [10] was designed with certain restrictions,
including requiring no modifications to the VPN gateways and involves
the use of two layers of MIPv4, with one Home Agent inside the
intranet and one in the Internet or in the DMZ before the VPN
gateway. The per-packet overhead is very high in this solution. It
is also challenging to implement and have two instances of MIPv4
active at the same time on a mobile node.
This document describes an alternate solution that does not require
two layers of MIPv4. The solution described in this document uses
Mobile IPv4 when the mobile node is on the trusted network and MOBIKE
capable IPsec VPNs when mobile node is on the untrusted network. The
mobile node uses the tunnel inner address (TIA) given out by the
IPsec VPN gateway as the co-located CoA for MIP registration. This
eliminates the need for using an external mobile IP Home Agent and
the need for encapsulating the VPN tunnel inside a MIP tunnel.
The following assumptions are made for the solution described in this
document.
o IKEv2 [4] and IPsec [5] are used to setup the VPN tunnels between
the mobile node and the VPN gateway.
o The VPN gateway and the mobile node support MOBIKE extensions as
defined in [3].
o When the mobile node is on the trusted network, traffic should not
go through the DMZ. Current deployments of firewalls and DMZs
consider the scenario where only a small amount of the total
enterprise traffic goes through the DMZ. Routing through the DMZ,
typically, involves stateful inspection of each packet by the
firewalls in the DMZ.
Devarapalli & Eronen Expires January 11, 2006 [Page 3]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
o When the mobile node is on the trusted network and uses a wireless
access technology, confidentiality protection of the data traffic
is provided by the particular access technology. In some
networks, confidentiality protection MAY be available between the
mobile node and the first hop access router, in which case, it is
not required at layer 2.
Mobility extensions are IKEv2 are being standardized. There is no
similar effort for IKEv1 [6].
This document also presents a solution for the mobile node to detect
when it is on a trusted network, so that the IPsec tunnel can be
dropped and the mobile node can use Mobile IP in the intranet.
2. Terminology
Many of the following terms are defined in [10], but are repeated
here to make this document self-contained.
FA: Mobile IPv4 foreign agent
co-CoA: co-located Care-of address
FA-CoA: Foreign Agent Care-of address
FW: Firewall
i-FA: Mobile IPv4 foreign agent residing in the trusted (intranet)
network
i-HA: Mobile IPv4 home agent residing in the trusted (intranet)
network
i-MIP: The mobile node uses the home agent in the internal network
VPN-TIA: VPN tunnel inner address. This address is given out by the
VPN gateway during IKE negotiation and is routable in the trusted
network
mVPN: VPN with MOBIKE functionality
The following access modes are used in explaining the protocol. The
access modes are explained in more detail in [10].
f: i-MIP with FA-CoA
c: i-MIP with co-CoA
mc: mobile enhanced VPN, i-MIP with VPN_TIA has co-CoA
Devarapalli & Eronen Expires January 11, 2006 [Page 4]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
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 [1].
3. Solution Overview
The mobile node is configured with a home address that remains the
same irrespective of whether the mobile node is outside or inside the
enterprise network. The mobile node is also reachable at the same
home address irrespective of its current point of attachment. When
the mobile node is connected to the intranet directly, it uses Mobile
IP for internal mobility. When it roams and connects to an untrusted
network outside the enterprise, it sets up a VPN tunnel to the VPN
gateway. However, it still maintains a valid binding cache entry at
the i-HA. It uses the VPN TIA, allocated by the VPN gateway, as the
co-located CoA for registration with the i-HA. If the VPN TIA
changes or if the mobile node moves and connects to another VPN
gateway, then it sends a Registration Request to the i-HA using the
new co-located CoA. If the mobile node moves while outside the
enterprise and its access network changes, it uses the MOBIKE
protocol to update the VPN gateway of its current address. The
internal home agent is not aware of the mobile node's movement as
long as the mobile node is attached to the same VPN gateway and the
TIA remains the same.
The following figure depicts the network topology assumed for the
solution. It also shows the possible MN locations and access modes.
Devarapalli & Eronen Expires January 11, 2006 [Page 5]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
(MN) {mc} {home} (MN) [i-HA]
! \ /
.--+---. .-+---+-.
( ) ( )
`--+---' [MVPN] `--+----'
\ ! !
[R/FA] .--+--. [R]
\ ( DMZ ) !
.-+-------+--. `--+--' .-----+------.
( ) ! ( )
( external net +---[R]----[FW]----[R]--+ internal net )
( ) ( )
`--+---------' `---+---+----'
/ / \
[DHCP] [R] [DHCP] [R] [R] [i-FA]
\ / \ / \ /
.+--+---. .-+-+--. .--+--+-.
( ) ( ) ( )
`---+---' `--+---' `---+---'
! ! !
(MN) {mc} (MN) {c} (MN) {f}
This results in a Mobile IP tunnel inside an IPsec tunnel. The
Mobile IP tunnel is between the MN and the Home Agent and the IPsec
tunnel is between the MN and the mVPN gateway. The Mobile IP tunnel
uses reverse tunneling through the Home Agent [12].
3.1 Access modes
The following access modes are used in the solution described in this
document.
3.1.1 Access mode: 'c'
This access mode is standard Mobile IPv4 [2] with a co-located
care-of address. The mobile node MUST be able to detect that it is
connected to an internal trusted network before using this mode. The
co-located care-of address is configured form the access network to
which the mobile node is attached to.
3.1.2 Access mode: 'f'
This access mode is standard Mobile IPv4 [2] with a FA-located
care-of address. The mobile node can use this mode only when it is
able to detect that it is connected to an internal trusted network
and detects a foreign agent on the access network.
Devarapalli & Eronen Expires January 11, 2006 [Page 6]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
3.1.3 Access mode: 'mc'
This access mode involves using both Mobile IPv4 and MOBIKE enabled
IPsec VPN gateway, resulting in a Mobile IP tunnel inside an IPsec
tunnel. The mobile node uses the IPsec TIA as the co-located CoA for
registering with the Home Agent. This mode is used only when the
mobile node is attached to an untrusted network and is required to
setup an IPsec tunnel with a VPN gateway to gain access to the
trusted network.
3.2 Mobility within the enterprise
When the mobile node is inside the enterprise network and attached to
the intranet, it uses Mobile IPv4 [2] for subnet mobility. The
mobile node uses Foreign Agent co-located care-of address, if a
foreign agent is available. Otherwise it acquires an address through
DHCP on the access link and uses it as the care-of address (CoA) for
Mobile IP. The mobile node attempts Foreign Agent discovery and CoA
address acquisition through DHCP simultaneously in order to avoid the
delay in discovering a foreign agent when there is no foreign agent
available. The mobile node at any time maintains a valid binding
cache entry that maps the home address to the current CoA, at the
Home Agent. Whenever the mobile node moves, it sends a Registration
Request to update the binding cache entry.
The Mobile IP signaling messages between the mobile node and the Home
Agent are authenticated as described in [2].
When the mobile node moves outside the enterprise and attaches to an
untrusted network, it sets up a VPN tunnel with the VPN gateway. It
also maintains a valid binding cache entry at the Home Agent. The
VPN TIA given out by the VPN gateway is used as care-of address for
Mobile IP registration. If the mobile node attaches to another VPN
gateway or it re-connects to the same VPN gateway after a while, it
might get allocated a new TIA. In such a case, the mobile node sends
a Registration Request to its Home Agent to update the binding cache
with its current TIA.
3.3 Mobility when outside the enterprise
When the mobile node is attached to an untrusted network, it sets up
a VPN tunnel with the VPN gateway to gain access to the enterprise
network. IKEv2 [4] and IPsec [5] are used to setup the VPN tunnel.
If the mobile node moves and its IP address changes, it initiates the
MOBIKE protocol [3] to update the address on the VPN gateway. If the
TIA changes or the mobile node attaches to another VPN gateway, while
outside the enterprise, the mobile node should send a Registration
Devarapalli & Eronen Expires January 11, 2006 [Page 7]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
Request to its Home Agent using the new TIA as the co-located care-of
address.
3.4 Crossing Security Boundaries
Security boundary detection is based on the reachability of the i-HA
from the mobile node's current point of attachment. Whenever the
mobile node detects that it has moved to a new IP subnet [13] and its
IP address changes, it sends a registration request to the i-HA
without any VPN encapsulation. If the mobile node receives a
Registration Reply, then it is assumes that it is on a trusted
network. This is based on the mechanism described in [10] to detect
attachment to the internal trusted network. The mobile node should
re-transmit the Registration Request, if it does not receive the
Registration Reply within a timeout period. The number of times the
mobile node should re-transmit the Registration Request and the
timeout period for receiving the Registration Reply are configurable
on the mobile node.
If the mobile node has an existing VPN tunnel to its VPN gateway, it
MUST send a IKE MOBIKE message at the same time as the registration
request to the i-HA, whenever the IP address changes. If the mobile
node receives a response from the VPN gateway, but not from the i-HA,
it assumes it is outside the enterprise network. If it receives a
response from the i-HA, then it assumes it is inside the enterprise
network.
There could also be some out-of-band mechanisms that involve
configuring the wireless access points with some information which
the mobile node can recognize as access points that belong to the
trusted network in an enterprise network. Such mechanisms are beyond
the scope of this document.
3.4.1 Operation when moving from an untrusted network
When the mobile node is outside the enterprise network and attached
to an untrusted network, it has an IPsec VPN tunnel with its mobility
aware VPN gateway, and a valid registration with a Home Agent on the
intranet with the VPN TIA as the care-of address.
If the mobile nodes moves and its IP address changes, it performs the
following steps:
1. Initiate IKE mobility exchange to update the current address with
the VPN gateway. If the new network is also untrusted, this will
be enough for setting up the connectivity. If the new network is
trusted, and if the VPN gateway is reachable, this exchange will
allow the mobile node to keep the VPN state alive while in the
Devarapalli & Eronen Expires January 11, 2006 [Page 8]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
trusted side. If the VPN gateway is not reachable from inside,
then this exchange will fail.
2. At the same time as step 1, send a Mobile IPv4 Registration
Request to the internal Home Agent without VPN encapsulation.
3. If the mobile node receives a Registration Response to the
request sent in step 2, then the current subnet is a trusted
subnet, and the mobile node can communicate without VPN
tunneling. The mobile node MAY tear down the VPN tunnel.
3.4.2 Operation when moving from a trusted network
When the mobile node is inside the enterprise and attached to the
intranet, it does not use a VPN tunnel for data traffic. It has a
valid binding cache entry at its home agent. If the VPN gateway is
reachable from the trusted network, the mobile node MAY have valid
IKEv2 security associations with its VPN gateway. The IPsec security
associations can be created when required. The mobile node may have
to re-negotiate the IKEv2 security associations to prevent them from
expiring.
If the mobile node moves and its IP address changes, it performs the
following steps:
1. Initiate IKE mobility exchange to update the current address with
the VPN gateway, or if there is no VPN connection, then establish
a VPN tunnel with the gateway from the new local IP address. If
the new network is trusted, and if the VPN gateway is reachable,
this exchange will allow the mobile node to keep the VPN state
alive, while in the trusted side. If the new network is trusted
and if the VPN gateway is not reachable from inside, then this
exchange will fail.
2. At the same time as step 1, send a Mobile IPv4 Registration
Request to the internal Home Agent without VPN encapsulation.
3. If the mobile node receives a Registration Response to the
request sent in step 2, then the current subnet is a trusted
subnet, and the mobile node can communicate without VPN
tunneling, using only Mobile IP with the new care-of address.
4. If the mobile node didn't receive the response in step 3, and if
the VPN tunnel is successfully established and registered in step
1, then the mobile node sends a Registration Request over the VPN
tunnel to the internal Home Agent. After receiving a
Registration Response from the Home Agent, the mobile node can
start communicating over the VPN tunnel with the Mobile IP home
address.
4. NAT Traversal
There could be a NAT device between the mobile node and the home
Devarapalli & Eronen Expires January 11, 2006 [Page 9]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
agent in any of the access modes, 'c', 'f' and 'mc', and between the
mobile node and the VPN gateway in the access mode 'mc'. Mobile IPv4
NAT traversal, as described in [7] MUST be supported by the mobile
node and the home agent when the mobile node is using access modes
'c' or 'f'. When using access mode, 'mc', IPsec NAT traversal [8]
[9] MUST be supported by the mobile node and the VPN gateway.
Typically, the TIA would be a routable address inside the enterprise
network. But in some cases, the TIA could be from a private address
space associated with the VPN gateway. In such a case, Mobile IPv4
NAT traversal should be used in addition to IPsec NAT traversal in
the 'mc' mode.
5. Security Considerations
Enterprise connectivity, typically requires very strong security and
the solution described in this document was designed keeping this in
mind.
Security concerns related to the mobile node detecting that is on a
trusted network and thereafter dropping the VPN tunnel are described
in [10].
Please see [3] for MOBIKE-related security considerations, and [7],
[8] for security concerns related to the use of NAT traversal
mechanisms for Mobile IPv4 and IPsec.
6. IANA Considerations
This document requires no action from IANA.
7. Acknowledgments
The authors would like to thank Henry Haverinen, Sandro Grech, Dhaval
Shah and John Cruz for their participation in developing this
solution.
8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[3] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
draft-ietf-mobike-protocol-00 (work in progress), June 2005.
Devarapalli & Eronen Expires January 11, 2006 [Page 10]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
[5] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", draft-ietf-ipsec-rfc2401bis-06 (work in progress),
April 2005.
[6] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[7] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network
Address Translation (NAT) Devices", RFC 3519, May 2003.
[8] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[9] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948,
January 2005.
[10] Vaarala, S., "Mobile IPv4 Traversal Across IPsec-based VPN
Gateways", draft-ietf-mip4-vpn-problem-solution-01 (work in
progress), January 2005.
8.2 Informative References
[11] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4
Traversal of VPN Gateways",
draft-ietf-mip4-vpn-problem-statement-03 (work in progress),
October 2004.
[12] Montenegro, G., "Reverse Tunneling for Mobile IP, revised",
RFC 3024, January 2001.
[13] Aboba, B., "Detecting Network Attachment (DNA) in IPv4",
draft-ietf-dhc-dna-ipv4-12 (work in progress), June 2005.
Devarapalli & Eronen Expires January 11, 2006 [Page 11]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
Authors' Addresses
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: vijay.devarapalli@nokia.com
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
Email: pasi.eronen@nokia.com
Appendix A. Mobility Extensions for IKEv1
Note: It is not decided yet if we should have this section in this
document. It might be removed or moved to a separate document.
There is no standards effort currently to develop mobility extensions
for IKEv1. The current IPsec VPN deployments predominantly use
IKEv1. In this section, we describe mobility extensions for IKEv1.
The mobile node must not use these extensions before it has confirmed
that the VPN gateway supports this. The VPN gateway signals support
by including a Vendor ID payload in the first phase 1 message it
sends. The value for this payload is the following 15 bytes {0xB5,
0xC8, 0xDF, 0x2B, 0xD4, 0xC3, 0xC6, 0x89, 0x9F, 0xB8, 0x19, 0xA3,
0x4A, 0x81, 0x1F}, followed by one byte corresponding to the highest
version of this extension supported (0x01 for this document).
The messages used by this extension are shown below.
Mobile node VPN gateway
----------- -----------
HDR*, HASH,
N(ADDRESS-UPDATE-REQUEST), -->
NAT-D, NAT-D
<-- HDR*, HASH, NAT-D, NAT-D
When the mobile node wishes to change its address, it constructs a
message with the following contents:
Devarapalli & Eronen Expires January 11, 2006 [Page 12]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
o The IP source address is the new address.
o ISAKMP Exchange Type is Transaction Exchange (defined in
draft-dukes-ike-mode-cfg-02). All payloads following the header
are encrypted, so the Encryption bit is set to 1, and a new
Message ID is selected.
o The HASH payload authenticates the message, and is calculated as
described in draft-dukes-ike-mode-cfg-02.
o The ADDRESS-UPDATE-REQUEST Notify payload is constructed as
follows:
* Domain of Interpretation is set to 1 (IPSEC) and Protocol-Id is
set to 1 (ISAKMP)
* Notify Message Type is set to 35389 (randomly selected from the
32768-40959 range).
* SPI Size is set to 16; the SPI is set to the ISAKMP cookies.
* Notification Data contains a four-octet sequence number. This
sequence number is initialized to 0 when the ISAKMP SA is set
up, and incremented for each ADDRESS-UPDATE-REQUEST sent.
o The NAT-D payloads as described in draft-ietf-ipsec-nat-t-ike-08.
Note that more than two NAT-D payloads may be present in some
circumstances.
When the VPN gateway receives this message, it
o Looks up the correct ISAKMP SA, decrypts the message, and verifies
the HASH payload.
o Compares the sequence number in the ADDRESS-UPDATE-REQUEST payload
with its stored value, and rejects the message if the sequence
number in the packet is smaller than the stored value. The stored
value is updated after the message has been processed.
o Determines which ESP SAs are associated with the mobile node
(typically only a single ESP SA).
o Calculates the expected value for the NAT-D payloads based on IP
address and port number from the IP/UDP headers.
o If the mobile node is behind a NAT (none of the mobile node's
NAT-D payloads match the expected value), updates encapsulation
mode of the ESP SAs to UDP-Encapsulated-Tunnel, and updates the IP
address and port number based on the IP/UDP header.
o If the mobile node is not behind a NAT, updates the encapsulation
mode of the ESP SAs to Tunnel, and updates the IP address based on
the IP header.
o Constructs a reply containing a HASH and NAT-D payloads.
When the mobile node receives the reply, it verifies the HASH
payload, and changes encapsulation mode if it detects that it is
behind a NAT.
Devarapalli & Eronen Expires January 11, 2006 [Page 13]
Internet-Draft MIPv4 and MOBIKE interworking July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Devarapalli & Eronen Expires January 11, 2006 [Page 14]