Network Working Group W. Haddad
Internet-Draft S. Krishnan
Expires: April 26, 2007 Ericsson Research
F. Dupont
CELAR
M. Bagnulo
UC3M
H. Tschofenig
Siemens AG
October 23, 2006
An Anonymity and Unlinkability Extension for OMIPv6
draft-haddad-privacy-omipv6-anonymity-02
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 April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The "Optimized Mobile IPv6 with CBA" (OMIPv6) protocol specifies a
new route optimization (RO) mechanism, which offers better security,
Haddad, et al. Expires April 26, 2007 [Page 1]
Internet-Draft OMIPv6 Anonymity October 2006
less signaling messages and reduces the handoff latency. This
document describes a new extension to be added to the OMIPv6 protocol
in order to provide the anonymity and the unlinkability aspects at
the IP layer.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
5. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 8
6. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Haddad, et al. Expires April 26, 2007 [Page 2]
Internet-Draft OMIPv6 Anonymity October 2006
1. Introduction
Optimized Mobile IPv6 [OMIPv6] protocol specifies a new route
optimization (RO), which reduces the amount of signaling messages,
the handover latency and improves the overall security.
However, OMIPv6 protocol lacks privacy support, namely anonymity or
pseudonymity, and unlinkability aspects. Supporting these privacy
aspects in OMIPv6 would allow a mobile user to move outside its home
network without disclosing its real IPv6 home address nor linking its
different moves together, and thereby preventing eavesdroppers from
the ability to correlate its actions at the IP layer.
This document describes privacy extensions to the OMIPv6 protocol.
Haddad, et al. Expires April 26, 2007 [Page 3]
Internet-Draft OMIPv6 Anonymity October 2006
2. Conventions used in this document
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 [TERM].
Haddad, et al. Expires April 26, 2007 [Page 4]
Internet-Draft OMIPv6 Anonymity October 2006
3. Glossary
Anonymity
Anonymity ensures that a user may use a resource or service
without disclosing the user's identity.
Anonymity in wireless networks means that neither the mobile node
nor its system software shall by default expose any information,
that allows any conclusions on the owner or current use of the
node.
Consequently, in scenarios where a device and/or network
identifiers are used (e.g., MAC address, IP address), neither the
communication partner nor any outside attacker should be able to
disclose the relationship between the respective identifier and
the user's identity.
Pseudonymity
Pseudonymity is a weaker property related to anonymity. It means
that one cannot identify an entity, but it may be possible to
prove that two pseudonymous acts were performed by the same
entity.
Unlinkability
Two events are unlinkable if they are no more and no less related
than they are related concerning the a-priori knowledge.
Unlinkability ensures that a user may make use of resources or
services without others being able to link the use of these
services together.
In hiding the mobile node's current location, unlinkability
feature removes any possible correlation between two successive IP
handovers performed by the same mobile node.
For more information about privacy aspects and location privacy
please refer to [MOMIPRIV].
Haddad, et al. Expires April 26, 2007 [Page 5]
Internet-Draft OMIPv6 Anonymity October 2006
4. Problem Statement
OMIPv6 protocol introduces a new route optimization (RO) mode, which
significantly reduces the load of signaling messages, i.e., mainly by
eliminating the HoTI/HoT messages, offers a semi-permanent security
association (SA) between the mobile node (MN) and the correspondent
node (CN) and improves the overall security of the communication.
However, OMIPv6 allows the CN and any potential eavesdropper located
on the path between the MN and the CN to first identify the mobile
node via its IPv6 Home Address (HoA) and to trace its movements in
real time across the Internet, thus seriously violating its privacy.
Such scenario is feasible by simply looking into the Binding Update
(BU) message(s) sent by the MN to the CN, which carries among other
parameters, the MN's IPv6 Home Address (HoA) and its new current
topological location, i.e., disclosed in its IPv6 care-of address
(CoA).
In addition to the BU message(s), the eavesdropper can learn and
trace the MN's movements by looking into the data packets exchanged
with the CN. In fact, the main RO mode (detailed in [MIPv6]) defined
two mobility extension headers, which carry the MN's home address.
The first one is the Home Address Option (HAO) and is inserted in
each data packet sent by the MN to the CN on the direct path. The
second one is a Routing Header (RH) and is inserted in each data
packet sent by the CN to the MN on the direct path.
Based on the above, it appears that in order to keep the exchange of
data packets between the two endpoints flowing on the direct path,
only the home address can be hidden from both the CN and any
potential eavesdropper(s) located on the direct path.
Consequently, any solution for the privacy problem in OMIPv6 MUST
prevent the CN from falling back to the bidirectional (BT) mode
(detailed in [MIPv6]) under any circumstance(s), since data packets
sent by the CN are addressed to the MN's HoA.
However, replacing the real MN's HoA with a static/dynamic pseudo-HoA
does not solve the entire privacy problem as described above. In
fact, using static/dynamic pseudo-HoA(s) can still allow the
eavesdropper to correlate between MN's movements across the Internet,
thus easily breaking the unlinkability feature. Such correlation can
be accomplished by simply tracing the sequence number carried by each
BU message. The seriousness of such correlation is tightly related
to how difficult is for the eavesdropper to discover the MN's real
HoA (e.g., based on prior knowledge and/or other identifier(s), which
are already known or can be discovered at a further stage, etc). In
fact, learning the MN's HoA can reveal all its pseudo-HoAs and their
Haddad, et al. Expires April 26, 2007 [Page 6]
Internet-Draft OMIPv6 Anonymity October 2006
corresponding CoAs as well as the exact time of each movement.
The unlinkability feature can also be broken if an eavesdropper is
able to correlate between two data packets exchanged between the MN
and the CN and carrying different CoAs, but associated with the same
pseudo-HoA. In this case, the correlation may also reveal the exact
time of the MN's movement(s), regardless of the BU message content.
In addition to the correlation based on tracing data packets only,
which provides the possibility to correlate between different
movements, another correlation becomes possible between the signaling
messages and the data packets. In fact, tracing the BU messages in
addition to the data packets can also help the eavesdropper correlate
between the MIPv6 signaling messages and the data packets (namely the
pseudo-HoA and/or CoA carried by the BU message with the address(es)
and/or pseudo-address(es) carried by the data packet).
Consequently, we argue that any solution for privacy related to the
network layer mobility only should also offer the unlinkability
feature by fulfilling the following requirements:
o prevent disclosing the MN's HoA in any BU message.
o prevent any correlation between BU messages by avoiding using the
same pseudo-HoA in more than one BU message.
o prevent any correlation between the BU messages via the sequence
number.
o prevent any correlation between data packets exchanged with the
current CoA and the next BU message sent after performing an IP
handover.
o prevent any correlation between data carried by the BU message and
data packets exchanged directly after sending/receiving BU/BA
message(s).
Finally, it should be noted that any potential solution, which
addresses privacy as motivated above, should take into consideration
the scenario where a mobile node starts communicating with a CN from
its home network before switching to a foreign network(s).
Haddad, et al. Expires April 26, 2007 [Page 7]
Internet-Draft OMIPv6 Anonymity October 2006
5. Proposed Solution
Our suggested solution can be used regardless of whether the MN is
establishing its session from its home network or from a visited
network. It consists of three components:
1. the "P" bit that is carried in the Pre-Binding Update (PBU), the
Pre-Binding Test (PBT) and the Binding Update (BU) message; this
bit demands additional processing guidelines (including special
sequence number handling).
2. replacing the home address inserted in the HAO with an ephemeral
identifier.
3. associating the interface identifier (iid) of the MN's home
address with the statistically unique cryptographically-Based
Identifiers (described in [CBID]).
As a first step, a Pre-Binding Update (PBU) message is sent directly
from the MN to the CN. The PBU message carried a newly introduced
Privacy (P) bit set and thereby asks the CN to skip any home address
test, and also to avoid any possible fallback to the BT mode during
the subsequent data packets exchange.
The MN MUST set the "P" bit in the PBU message, regardless of the
MN's location (i.e., also if located in its home network), and in the
BU message sent after receiving the Pre-Binding Test (PBT) message
from the CN.
Additionally, the MN MUST replace the home address inserted in the
Home Address Option (HAO) with a "Virtual Home Address" (VHoA). The
VHoA sent in the first BU message MUST be a statistically unique
crypto-based identifier (CBID). Note that using the CBID technology
in Mobile IPv6 for privacy purposes has been introduced in [MIPriv].
During the initial signaling messages exchange between the two
endpoints, and in order to enable the CN to check if it is still
talking to the same MN when receiving the first BU message, the MN
MUST insert in the PBU message the value obtained from hashing the
VHoA (note that for the initial case, the VHoA is the CBID, thus the
value sent in the PBU message is equal to SHA1(CBID)).
After receiving the PBU message, the CN computes a challenge from the
MN's CoA, the content of the HAO and a local secret. Then it inserts
the challenge in the PBT message and sends it to the MN. When the MN
gets the PBT message, it sends a BU message carrying the "P" bit, the
challenge and the real CBID (i.e., the CBID is inserted in the HAO).
Note that the iid of the MN's CoA sent in the PBU and the BU messages
Haddad, et al. Expires April 26, 2007 [Page 8]
Internet-Draft OMIPv6 Anonymity October 2006
SHOULD be generated from hashing the CBID in the following way:
iid(CoA) = First(64, SHA1(CBID))
Where:
o SHA1 is a hashing function
o CBID is a crypto-based identifier
o First(size,input) is a function used to indicate truncation of the
input data so that only the first bits remain to be used.
o iid is the interface identifier
Upon receiving the first BU message with the "P" bit set, the CN
starts by checking its validity, which is done by hashing the content
of the HAO, i.e., the CBID, and comparing the first 64 bits of the
resulting hash with the CoA's iid. After that, it will re-compute
the challenge and compare it to the one sent in the BU message. The
third step after a successful validation would be to create an entry
in the BCE for the MN's VHoA and CoA. The CN MUST also generate a
long lifetime shared secret (i.e., SKbm) and sends it to the MN in
the BA message as described in [OMIPv6].
The presence of the "P" bit in the BU message serves another purpose,
which is to request the CN to replace the sequence number carried by
the BU message, in its BCE with the "next" value, i.e., the value
expected in the next BU message sent by the MN. Such value is called
the "Sequence Value" SQV and is used to prevent replay attacks and to
allow the CN to identify the MN's corresponding entry in its BCEs
when processing a BU message carrying the "P" bit.
In OMIPv6, each time the MN sends a BU message, it MUST increase the
32-bit sequence number value. When the privacy extensions introduced
in this document are used, then both endpoints MUST increment the SQV
with a constant value equal to the one obtained from hashing the
SKbm. Finally, the increased SQV is hashed, inserted by the MN into
the BU message and sent it to the CN.
The two entities MUST compute the next SQV (nSQV) in the following
way:
Khbm = SHA1(SKbm)
nSQV = First(32, SHA1((pSQV) | Khbm))
Where:
Haddad, et al. Expires April 26, 2007 [Page 9]
Internet-Draft OMIPv6 Anonymity October 2006
o SKbm is a long lifetime binding management key
o Khbm is the hashed binding management key
o pSQV is the previous SQV, i.e., SQV sent in the last BU message
sent bythe MN and already processed by the CN.
o nSQV is the hash value of the next SQV computed during updating
the BCE with the BU message carrying the pSQV.
The CN MUST compute and store the nSQV during creating or updating
the MN's corresponding entry in its BCE, and the MN MUST compute and
send a new SQV in all subsequent BU messages sent to the CN.
In addition, all subsequent BU messages sent after the first one
SHOULD carry each a different VHoA, which is generated from hashing
the nCoA, i.e., nVHoA is equal to SHA1(nCoA), sent in the message.
However, it should be noted that the CN SHOULD NOT store in the MN's
corresponding entry the new CoA (nCoA) and new VHoA (nVHoA) carried
in the BU message. In fact, besides computing the nSQV and storing
it in the corresponding entry, the CN SHOULD also compute another
pair of addresses (CoA, VHoA) to be used in the data packets exchange
following the BCE creation or update. These two addresses are called
"expected CoA" (eCoA) and "expected VHoA" (eVHoA).
The two expected addresses are computed in the following way:
iid(eCoA) = First(64, SHA1(Khbm | nCoA Subnet Prefix))
eVHoA = SHA1(eCoA)
Where:
o nCoA is the MN's care-of address sent in the BU message.
o eVHoA is the pseudo-home address carried in the HAO and RH headers
in all data packets.
The subnet prefix of the nCoA MUST be the same as the one sent by the
MN in the BU message (note that this technique is similar to the one
defined in [HBA]). As mentioned above, the CN MUST update the MN's
entry in its BCE with the eCoA and eVHoA. However, the BA message
sent to the MN MUST carry the nCoA and nVHoA.
When the MN sends a BU message carrying the "P" bit, the SQV MUST be
used alone by the CN to detect the presence of an entry corresponding
to the MN in its BCE. If an entry containing the same SQV is found,
Haddad, et al. Expires April 26, 2007 [Page 10]
Internet-Draft OMIPv6 Anonymity October 2006
then the CN SHOULD proceed to check the signature before updating the
corresponding entry with the eCoA, eVHoA and nSQV.
Haddad, et al. Expires April 26, 2007 [Page 11]
Internet-Draft OMIPv6 Anonymity October 2006
6. Packet Format
This proposal defines a new bit called the Privacy (P) bit to be
added to the Pre-BU and BU messages. The MN MUST set the "P" bit in
both messages and in all subsequent BU messages as long as it needs
to keep its real home IP address undisclosed.
When used in the Pre-BU message, the "P" bit indicates to the CN to
limit the address test to the CoA only and also to include the VHoA
in computing the nonce value sent in the Pre-Binding Test (PBT)
message.
When used in the BU message, the "P" bit is used for three different
purposes. The first one is to ask the CN to use the sequence number
to locate the MN's corresponding BCE. The second one is to notify
the CN to NOT send any data packet carrying the MN's home pseudo-
address, i.e., VHAO, as destination address.
The third purpose is to ask the CN to compute the eCoA, the eVHoA,
the new SQV and store them in the MN's corresponding BCE.
When used in the Pre-BU message, the structure of the message will be
as it follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Care-of Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Pre-Binding Update Cookie +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Haddad, et al. Expires April 26, 2007 [Page 12]
Internet-Draft OMIPv6 Anonymity October 2006
The different fields carried in the Pre-BU message are detailed in
[OMIPv6].
When used in the BU message, the structure of the message will be as
it follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The different fields carried in the BU message are detailed in
[MIPv6].
Haddad, et al. Expires April 26, 2007 [Page 13]
Internet-Draft OMIPv6 Anonymity October 2006
7. Privacy Considerations
This memo describes an extension, which makes the MN's real identity
anonymous for both the CN and any malicious eavesdropper(s) located
on the path between the MN and the CN.
Our solution aims to present the MN's HoA as any other CoA that the
MN may use during its movements across the Internet. However, our
solution is based on the assumption that the BU messages exchanged
between the MN and its HA are protected with an ESP tunnel according
to [MIPv6-IKE] and [MIPv6-IKEv2].
The suggested solution provides the anonymity feature to the MN
during exchanging data packets and signaling messages with the CN.
It also provides the unlinkability feature during and after
performing IP handovers, by making it difficult for an eavesdropper
to correlate between two successive IP handoffs performed by the same
MN. The unlinkability between these events aims to enhance the
anonymity feature.
However, it should be noted that the unlinkability protection is
limited against eavesdroppers located on the path between the MN and
the CN and does not prevent the CN to trace the MN's movements in
real time.
The suggested solution allows the MN to select when and where the
anonymity feature should be activated. But it should be noted that
it works only when the MN initiates the session. Actually, when the
CN initiates the session, it uses the MN's home address (HoA). In
such scenario, the MN can hide its current location from the CN by
switching to the bidirectional tunneling mode.
It is worth mentioning that the anonymity concept is very much
context dependent. In order to quantify anonymity with concrete
situations, one would have to describe the system context, which is
practically not always possible for large open systems [ANON].
Consequently, the efficiency of the suggested solution is tightly
related to two key factors: the diversity and load of the traffic
circulating in parallel with the MN's traffic, on the same portion(s)
of the direct path, which is monitored by an eavesdropper(s).
Finally, the suggested solution strongly recommends using the Privacy
Extension proposal [PRIVACY], in configuring the care-of address(es)
sent by the MN in all BU messages except for the BU message sent
after receiving a PBT message, i.e., in which the CoA is derived from
the CBID.
Haddad, et al. Expires April 26, 2007 [Page 14]
Internet-Draft OMIPv6 Anonymity October 2006
8. Security Considerations
The suggested solution does not introduce new attacks nor does it
amplify existing threats. However, it is important to mention that
it makes the switch to the MIPv6 BT mode impossible.
The suggested solution aims to hide the mobile user's real identity
when moving outside its home network or from its home network to
foreign networks. Making the MN anonymous (with regard to the used
home address) to potential eavesdroppers may help to prevent attacks,
thus improves the overall security.
Haddad, et al. Expires April 26, 2007 [Page 15]
Internet-Draft OMIPv6 Anonymity October 2006
9. References
9.1. Normative References
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[MIPv6-IKE]
Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[MIPv6-IKEv2]
Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture", Internet
Draft, draft-ietf-mip6-ikev2-ipsec-06.txt, April 2006.
[OMIPv6] Arkko, J., Vogt, C., and W. Haddad, "Applying
Cryptographically Generated Addresses and Credit-Based
Authorization to Optimize Mobile IPv6 (OMIPv6)", Internet
Draft, draft-ietf-mipshop-omipv6-cga-cba-01,
September 2006.
[TERM] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP , March 1997.
9.2. Informative References
[ANON] Pfitzmann et al., A., "Anonymity, Unobservability,
Pseudonymity and Identity Management - A Consolidated
Proposal for Terminology", Anon Terminology Draft v0.28,
May 2006.
[CBID] Montenegro, G. and C. Castelluccia, "Cryptographically-
Based Identifiers (CBID): Concepts and Applications", ACM
Transactions on Information and System Security TISSEC,
February 2004.
[HBA] Bagnulo, M., "Hash Based Addresses (HBA)", Internet
Draft, draft-ietf-shim6-hba-02.txt, October 2006.
[MIPriv] Castelluccia, C., Dupont, F., and G. Montenegro, "A Simple
Privacy Extension for Mobile IPv6", Internet
Draft, draft-dupont-mip6-privacyext-04.txt, July 2006.
[MOMIPRIV]
Haddad, W., Nordmark, E., Dupont, F., Bagnulo, M., Park,
S., and B. Patil, "Privacy for Mobile and Multi-homed
Haddad, et al. Expires April 26, 2007 [Page 16]
Internet-Draft OMIPv6 Anonymity October 2006
Nodes: MoMiPriv Problem Statement", Internet-Draft, draft-
haddad-momipriv-problem-statement-03.txt, June 2006.
[PRIVACY] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6",
Internet-Draft, draft-ietf-ipv6-privacy-address-v2-05.txt,
August 2006.
Haddad, et al. Expires April 26, 2007 [Page 17]
Internet-Draft OMIPv6 Anonymity October 2006
Authors' Addresses
Wassim Haddad
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
Phone: +46 8 4044079
Email: Wassim.Haddad@ericsson.com
Suresh Krishnan
Ericsson Research
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900
Email: Suresh.Krishnan@ericsson.com
Francis Dupont
CELAR
Email: Francis.Dupont@point6.net
Marcelo Bagnulo
UC3M
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: +31 91 6249500
Email: Marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Hannes Tschofenig
Siemens AG
Otto-Hahn-Ring 6
81739 Munich
Germany
Email: Hannes.Tschofenig@siemens.com
Haddad, et al. Expires April 26, 2007 [Page 18]
Internet-Draft OMIPv6 Anonymity October 2006
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 (2006). 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.
Haddad, et al. Expires April 26, 2007 [Page 19]