Network Working Group M. Qi
Internet-Draft H. Li
Intended status: Standards Track Tsinghua Univ.
Expires: January 3, 2008 P. Yang
H. Deng
Y. Ma
Hitachi (China) R&D Corporation
K. Xu
Tsinghua Univ.
July 2, 2007
Interfacing between IKEv2/IPsec & MIPv6 by simple PF_KEY extensions
draft-qi-mip6-ikev2-interfacing-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 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Qi, et al. Expires January 3, 2008 [Page 1]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
Abstract
This draft discusses the issues associated with interfacing between
IKEv2/IPsec and MIPv6. When mobile nodes bootstrap in foreign
network or handover to a new network, IKEv2/IPsec can not probe the
changing of care-of-address, which is related security associations.
One simple extension to the SADB_ACQUIRE in PF_KEY framework is
proposed to support this interfacing. And the operation modification
of IKEv2 and MIPv6 are described in this proposal based on the
SADB_ACQUIRE extension. A new mobility security reference database
is created to store the temporary mobility parameters.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements on IKEv2 and MIPv6 integration . . . . . . . . . 5
3. Mobile Security Reference Database (MSRD) . . . . . . . . . . 6
3.1. the structure of MSRD . . . . . . . . . . . . . . . . . . 6
3.2. MSRD APIs . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of the extension to PF_KEY interface . . . . . . . . 7
5. Applicability to Mobile IPv6 scenarios . . . . . . . . . . . . 9
5.1. Treatment of transport SA for BU/BA during bootstrap . . . 9
5.2. Update tunnel mode SAs during handover . . . . . . . . . . 10
5.3. How to do Re-key of IPsec/IKE security associations
(SA) . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Summary on the modification of related softwares . . . . . . . 13
6.1. The modification of IKEv2 software . . . . . . . . . . . . 13
6.2. The modification of MIPv6 software . . . . . . . . . . . . 13
6.3. The modification of OS kernel . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Normative References . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Qi, et al. Expires January 3, 2008 [Page 2]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
1. Introduction
IP security (IPsec) [RFC4301] framework could provide security
services for traffic at IP layer. Internet Key Exchange v2 (IKEv2)
[RFC4306] protocol is designed to negotiate IPsec security
association (SA) between two end-to-end nodes, which are also called
initiator and responder.
IKEv2 protocol is a protocol which consists of two exchanges:
(1) An authentication and key exchange protocol to establish IKE-SA.
This is also called IKEv2 INIT procedure
(2) The protocol with some payloads for negotiation IPsec security
associations (i.e., Child-SAs). These payloads contain security
algorithm parameters and traffic selector fields. This is the IKEv2
AUTH procedure, which is protected by IKE-SA
In addition to the above-mentioned parts IKEv2 also includes some
payloads and messages which allow configuration parameters to be
exchanged primarily for remote access scenarios.
Mobile IPv6 (MIPv6)[RFC3775] allows the mobile nodes(MN) to maintain
the reachability while moving in the IPv6 network. After
registration to home agent(HA), the packets destined to MN could be
routed correctly by using the end-to-end tunnel, while MN is away
from the home network. According the specification in [RFC3775], the
MIPv6 signaling messages and optinally data packets should be
protected by IPsec in transport mode or tunnel mode. While MN
changes its IP point of attachment, the survival of related IPsec SAs
must be maintained.
IPsec has two related databases: Security Policy Database (SPD) is
the place to store the requirements of IP security; Security
Association Database (SAD) is the warehouse for all the SAs. PF_KEY
interface is a socket protocol used by key management entities (such
as IKEv2) to communicate with OS kernels for internal security
management. MIPv6 entity could use PF_KEY interface to populate its
security requirements in SPD and get the SA parameters in SAD.
[RFC2367].
This document describes the seamless interfacing solution between
IKEv2/IPsec and MIPv6. A new simple PF_KEY extension is proposed to
support the smooth MIPv6 operation with the IPsec framework and
IKEv2. We extended the SADB_ACQUIRE message in PF_KEY framework. A
new mobility security reference database is created to store the
temporary mobility parameters. It's a key reference database for
IKEv2 entity to update the SAs in SAD and IKE internal parameters,
Qi, et al. Expires January 3, 2008 [Page 3]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
while MN moves to another network.
While this solution could support the seamless interworking between
IKEv2/IPsec and MIPv6, it is easy to be applied to IKEv1/IPsec
[RFC2409] framework.
Qi, et al. Expires January 3, 2008 [Page 4]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
2. Requirements on IKEv2 and MIPv6 integration
The MN and the HA must use an IPsec SA to protect the integrity and
authenticity of the Binding Updates and Acknowledgements. [RFC4877]
specifies the dynamic keying requirements which applies to
IKEv2[RFC4306] for BU/BA between MNs and HAs. The transport SA
between MN and HA should base on Home Address (HoA) of MN for survial
of SA after the Care-of Address (CoA) is changed. This is because
the Home Address (HoA) is unrecheable before registration during the
bootstrapping phase in foreign network.
Tunnel mode ESP is needed for Home Test Init (HoTi), Home Test (HoT)
messages and optionally payload packets. Since the MN may change its
attachment point to the Internet, it is necessary to update its
endpoint address of the IPsec SAs using tunnel mode. The IKEv2
entities should dynamically update these SAs when the MN moves. In
order to realize this, IKEv2 entity should be notified by Mobile IPv6
daemon with necessary information to modify the related SAs.
As time goes by, the IPsec SA and IKE SA may expire and need to
rekey. But MN would have some new CoAs, if it roams to other
networks. So it is required to make IPsec SA rekey process by using
MN's current address.
This document proposes the new mobility security reference database
(MSRD) and extension to PF_KEY socket to support the following
functions for IKEv2/IPsec and MIPv6 interfacing:
(1) Provision of related MIPv6 parameters for IKEv2 during
bootstrapping phase in foreign network.
(2) Interfacing between MIPv6 and IKEv2 to update the related SAs
when MN does handover to another network.
(3) Provision of related MIPv6 parameters for rekey of IKEv2/IPsec.
This proposal only requires very simple extension (SADB_ACQUIRE
extension) to the existing PF_KEY API. It could support the seamless
interfacing between MIPv6 and IKEv2/IPsec with minimum modification
of related softwares.
Qi, et al. Expires January 3, 2008 [Page 5]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
3. Mobile Security Reference Database (MSRD)
3.1. the structure of MSRD
MSRD is the database for mobility security reference. MIPv6 deamon
will store the mobility related paramters in this database. The
information in this database should only be accessible for OS kernel
and related key management deamons (such as IKEv2, etc.).
Considering the structure, MSRD could be disigned as a table indexed
by mobile protocol index (MPI).
Every table entry should include at least the current CoA, HoA, HA
address and lifetime. Some other information could also be included
to support other interworking functions (such as redundant SA
negotiation) between IKEv2/IPsec and MIPv6.
3.2. MSRD APIs
MSRD should support some basic APIs, but not limited to for table
operation,
uint64 MSRD_ADD(HoA, HA, CoA, lifetime, ...)
the return value is the MPI for the added MSRD entry
uint64 MSRD_DELETE(HoA, HA, CoA, lifetime, ...)
the return value is the MPI for the deleted MSRD entry
uint64 MSRD_GETMPI(HoA, HA, CoA, lifetime, ...)
the return value is the MPI of MSRD entry whose parameters match
the API arguments
uint8 MSRD_QUERY(MPI, *HoA, *HA, *CoA, *lifetime, ...)
Get the mobility related information from MSRD indexed by MPI.
The return values are defined as below:
0 - success, 1 - entry not found by MPI, 2 - table unaccessible
uint8 MSRD_UPDATE(MPI, HoA, HA, CoA, lifetime, ...)
update the mobility related information in MSRD indexed by MPI.
The return values are defined as below:
0 - success, 1 - entry not found by MPI, 2 - table unaccessible
Qi, et al. Expires January 3, 2008 [Page 6]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
4. Overview of the extension to PF_KEY interface
The definition of SADB_ACQUIRE message in is shown below
< base, address(SD), address(P)*, identity(SD)*, sensitivity*
proposal >
* means optional payload
The SADB_ACQUIRE message is typically sent by the kernel to key
socket listeners who have registered their key socket (Such as the
IKEv2 deamon). SADB_ACQUIRE messages also can be sent by
application-level consumers of security associations. In this
document, MIPv6 can send this message to kernal for security services
of MIPv6 signaling and payload traffic.
In the proposal, the SADB_ACQUIRE message is extended as below:
< base, address(SD), address(P)*, identity(SD)*, sensitivity*,
proposal, ref* >
* means optional payload
The definition of SADB_X_REF for 'ref' in the message is described
below:
struct sadb_x_ref {
uint8_t sadb_ref_ver; //version
uint8_t sadb_ref_type; //type
uint16_t sadb_ref_type_ext; //sub type
uint16_t sadb_ref_len; //length
uint16_t sadb_ref_reserved; //length
uint64_t sadb_ref_mpi; //index in MSRD
}; /* SADB_X_REF header */
/* sizeof(struct sadb_x_ref) == 32 */
sadb_ref_type
Type of this extension,
0 means originated from APP,
1 means originated from kernel
sadb_ref_sub_type
Sub-type of this extension,
0 is reserved for MIPv6 usage
sadb_ref_mpi
Qi, et al. Expires January 3, 2008 [Page 7]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
64bit Reference index to MSRD
The illustration of message layout for SADB_X_REF extension is shown
below:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------+---------------+---------------+---------------+
| sadb_ref_ver | sadb_ref_type | sadb_ref_sub_type |
+---------------+---------------+---------------+---------------+
| sadb_ref_len | sadb_ref_reserved |
+---------------+---------------+---------------+---------------+
| sadb_ref_mpi |
| (64 bits) |
+---------------+---------------+---------------+---------------+
Mobility related information is needed for IKEv2 deamon to negotiate
the IPsec SAs. MIPv6 deamon stores all the required mobility
parameters in the MSRD, which is indexed by mobile protocol index
(MPI). This MPI must be included in the SADB_X_REF extension of
SADB_ACQUIRE message from MIPv6 deamon to the kernel. This message
will be delivered to registered key management deamon (IKEv2). then,
IKEv2 deamon could get the mobility related parameters (such as CoA,
redundent HA, etc) from MSRD by using the sadb_ref_mpi field in the
SADB_ACQUIRE message from kernel.
Qi, et al. Expires January 3, 2008 [Page 8]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
5. Applicability to Mobile IPv6 scenarios
5.1. Treatment of transport SA for BU/BA during bootstrap
The Figure below shows the framework and internal procedure of
interfacing between MIPv6 and IKEv2/IPsec to set up the trnasport
mode SA for BU/BA protection during bootstrap.
6.Query 1. Modify
+------------+ MSRD by MPI MSRD +-----------+
| |< ----------+ +-----------| |
| IKEv2 | | V | MIPv6 |
| | +------+ | |
+------------+ | MSRD | +-----------+
| A +------+ | |
7. Update| | A 3. send| |2. Modify
SAD | |5. PF_KEY | BU/BA| | SPD
| | SADB_ACQUIRE | | |
| | |4.GetMPI | |
| | | by MSRD API | |
User Space | | | | |
==========[ | | **PF_KEY Interface** | |]===========
Kernel | | +------+-----+ | |
| +----------| IPsec |< -------+ |
V | sub-system | V
+-------+ +------------+ +-------+
| SAD | | SPD |
+-------+ +-------+
The brief procedure is described as below:
1. MIPv6 deamon add or update the MSRD entries when it is needed
to set up SAs to protect BU and BA;
2. MIPv6 deamon add or update the related SPD entries based on
the related mobility parameters;
3. MIPv6 deamon sends BU or BA to the IPsec sub-system in kernel;
4. Kernel will query MSRD based on the content of BU to get the
MPI by using MSRD API;
5. Kernel puts the MPI in SADB_X_REF extension, builds and sents
the SADB_ACQUIRE message to IKEv2 deamon;
6. Upon receiving this SADB_ACQUIRE message from kernel, IKEv2
deamon will query the MSRD by MPI to get the mobility related
Qi, et al. Expires January 3, 2008 [Page 9]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
parameters (such as CoA, etc);
7. IKEv2 deamon will negotiate the transport SA for BU/BA and
update the SAD according to the specification in [RFC4877];
5.2. Update tunnel mode SAs during handover
The Figure below shows the framework and internal procedure of
interfacing between MIPv6 and IKEv2/IPsec to update the tunnel mode
SA between MN and HA during handover.
4.Query 1. Modify
+------------+ MSRD by MPI MSRD +-----------+
| |< ----------+ +-----------| |
| IKEv2 | | V | MIPv6 |
| | +------+ | |
+------------+ | MSRD | +-----------+
| A +------+ | |
5. Update| | | |2. Modify
SAD | |3. PF_KEY | | SPD
| | SADB_ACQUIRE | |
| | | |
| | | |
User Space | | | |
==========[ | | **PF_KEY Interface** | |]===========
Kernel | | | |
| +---------------------------------+ |
V V
+-------+ +-------+
| SAD | | SPD |
+-------+ +-------+
The brief procedure is described as below:
1. MIPv6 deamon add or update the MSRD entries when it handover
to a new network;
2. MIPv6 deamon update the related SPD entries based on the
related mobility parameters;
3. MIPv6 deamon sends SADB_ACQUIRE message with SADB_X_REF
extension to the IPsec sub-system in kernel. Inside this message,
the MPI should be included. The kernal will check its integrity
and deliver it to IKEv2 deamon;
6. Upon receiving this SADB_ACQUIRE message from kernel, IKEv2
deamon will query the MSRD by MPI to get the mobility related
Qi, et al. Expires January 3, 2008 [Page 10]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
parameters (such as CoA, etc);
7. IKEv2 deamon will update the tunnel mode SAs in the SAD based
on the information in MSRD and SPD. It will also update the
related parameters inside IKEv2 deamon (such as IKE SA, etc);
The BU/BA re-registration in same network will not trigger MIPv6
deamon to send the SADB_ACQUIRE messages
5.3. How to do Re-key of IPsec/IKE security associations (SA)
When the MIPv6-related IPsec SAs in SAD expire, IPsec sub-system in
kernel will send SADB_EXPIRE message to IKEv2 deamon. In this case,
IKEv2 should know the mobility related information in MSRD. The
straightforward way is to store the related MPI in IKEv2 deamon. So
upon receiving the SADB_EXPIRE message from kernel, IKEv2 could get
information MSRD by MPI directly and update the related SAD. This
procedure is depicted in the picture below.
2.Query
+------------+ MSRD by MPI +-----------+
| |< ----------+ +-----------| |
| IKEv2 | | V | MIPv6 |
| | +------+ | |
+------------+ | MSRD | +-----------+
| A +------+ |
3. Update| | |
SAD | |1. PF_KEY |
| | SADB_EXPIRE |
| | |
| | |
User Space | | |
==========[ | | **PF_KEY Interface** |]===========
Kernel | | +------------+ |
| +----------| IPsec | |
V | sub-system | V
+-------+ +------------+ +-------+
| SAD | | SPD |
+-------+ +-------+
If IKEv2 deamon does not store the MPI for mobility SAs, the OS
kernal need to query the MSRD based on the information in SAs. After
it gets the MPI, kernel could encapsulate it in SADB_X_REF extension
of SADB_EXPIRE to IKEv2 deamon. In this case, the SADB_EXPIRE should
be extended to support the SADB_X_REF extension. This could follow
the same way of SADB_ACQUIRE extension in this documents. The
picture below describes this case.
Qi, et al. Expires January 3, 2008 [Page 11]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
3.Query
+------------+ MSRD by MPI +-----------+
| |< ----------+ +-----------| |
| IKEv2 | | V | MIPv6 |
| | +------+ | |
+------------+ | MSRD | +-----------+
| A +------+ |
4. Update| | A |
SAD | |2. PF_KEY | |
| | SADB_EXPIRE | |
| | |1.GetMPI |
| | | by MSRD API |
User Space | | | |
==========[ | | **PF_KEY Interface** |]===========
Kernel | | +------+-----+ |
| +----------| IPsec | |
V | sub-system | V
+-------+ +------------+ +-------+
| SAD | | SPD |
+-------+ +-------+
The brief procedure is described as below:
1. while the mobility-related SAs IPsec sub-system Kernel will
query MSRD based on the content of BU to get the MPI;
2. Kernel puts the MPI in SADB_X_REF extension, builds and sents
the SADB_EXPIRE message to IKEv2 deamon;
3. Upon receiving this SADB_EXPIRE message from kernel, IKEv2
deamon will query the MSRD by MPI to get the mobility related
parameters (such as CoA, etc);
4. IKEv2 deamon will rekey the related SA in SAD;
Qi, et al. Expires January 3, 2008 [Page 12]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
6. Summary on the modification of related softwares
6.1. The modification of IKEv2 software
IKEv2 daemon should be able to extract MPI from SADB_X_REF payload.
It should be able to retrieve the mobility related parameters from
MSRD by MPI or SA parameters. It should support the capability to
set up the specific IPsec SAs in mobile environment or to modify
IPsec SAs when receiving extended SADB_ACQUIRE message in this
documents. It should be able to rekey the specific IPsec SAs in
mobile environment when receiving extended SADB_EXPIRE message in
this docuemtn.
6.2. The modification of MIPv6 software
Mobile Ipv6 should be able to write and index the mobility
information in the MSRD that can be read by OS kernel, IKEv2 daemon
or any other related key management deamons. Mobile Ipv6 should send
extended PF_KEY SADB_ACQUIRE message with SADB_X_REF to kernel. This
is the notification of MN's roaming to new network.
6.3. The modification of OS kernel
Kernel should be able to recognize SADB_X_REF payload and to deal
with it. It should be able to add this payload in SADB_ACQUIRE
message and optionally SADB_EXPIRE message. In some cases, OS kernel
should support the MSRD query API for IPsec SA rekey.
Qi, et al. Expires January 3, 2008 [Page 13]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
7. Security Considerations
The MSRD should be only accessible for MIPv6 deamon, OS kernel and
related key management deamons (such as IKEv2). Only MIPv6 deamons
could have the full manipulation right on MSRD. MSRD is read-only
for all the other softwares. Besides this point, there is no other
security issues for consideration introduced by this documents.
Qi, et al. Expires January 3, 2008 [Page 14]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
8. Conclusion
In this documents, the simple PF_KEY extension is proposed to support
the full seamless interworking between IKEv2/IPsec and MIPv6. A new
SADB_X_REF extension is created for SADB_ACQUIRE message and
optionally SADB_EXPIRE message in PF_KEY framework. The basic target
for this extension is to provide the mobility related information in
the cases of bootstrap in Foreign network, handover to a new network
and IPsec SA rekey. The proposal in this document incurs small
modification on the softwares of IKEv2, MIPv6 and OS kernel.
Qi, et al. Expires January 3, 2008 [Page 15]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
9. Normative References
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877,
April 2007.
Qi, et al. Expires January 3, 2008 [Page 16]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
Authors' Addresses
Minpeng Qi
Tsinghua Univ.
Network Institute
Department of Computer Science and Technology
Tsinghua University
Haidian District
Beijing, 100084
P.R. China
Phone: +861062785818(ext.)6864
Email: qiminpeng@csnet1.cs.tsinghua.edu.cn
Haitao Li
Tsinghua Univ.
Network Institute
Department of Computer Science and Technology
Tsinghua University
Haidian District
Beijing, 100084
P.R. China
Phone: +861062785818(ext.)6864
Email: lihaitao@csnet1.cs.tsinghua.edu.cn
Peng Yang
Hitachi (China) R&D Corporation
N301, Tower C Raycom Infotech Park
2 kexueyuan Nanlu
Haidian District
Beijing, 100080
P.R. China
Phone: +861082862918(ext.)328
Email: pyang@hitachi.cn
Qi, et al. Expires January 3, 2008 [Page 17]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
Hui Deng
Hitachi (China) R&D Corporation
N301, Tower C Raycom Infotech Park
2 kexueyuan Nanlu
Haidian District
Beijing, 100080
P.R. China
Phone: +861082862918(ext.)332
Email: hdeng@hitachi.cn
Yuanchen Ma
Hitachi (China) R&D Corporation
N301, Tower C Raycom Infotech Park
2 kexueyuan Nanlu
Haidian District
Beijing, 100080
P.R. China
Phone: +861082862918(ext.)327
Email: ycma@hitachi.cn
Ke Xu
Tsinghua Univ.
Network Institute
Department of Computer Science and Technology
Tsinghua University
Haidian District
Beijing, 100084
P.R. China
Phone: +861062785818(ext.)6864
Email: xuke@csnet1.cs.tsinghua.edu.cn
Qi, et al. Expires January 3, 2008 [Page 18]
Internet-Draft Integration of IKEv2 & MIPv6 July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Qi, et al. Expires January 3, 2008 [Page 19]