Internet Engineering Task Force Wassim Haddad
Mobility Privacy Suresh Krishnan
Internet Draft Ericsson Research
Expires December 2005 Francis Dupont
Point6
Marcelo Bagnulo
UC3M
Hannes Tschofenig
Siemens
June 2005
Anonymity and Unlinkability Extension for CGA-OMIPv6
<draft-haddad-privacy-omipv6-anonymity-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.
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
This document is an Internet-Draft. 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.
Distribution of this memo is unlimited
Abstract
The "Optimized Mobile IPv6 with CGA" [CGA-OMIPv6] protocol
specifies a new route optimization (RO) technique. This document
describes a new extension to be added to the CGA-OMIPv6 protocol
in order to provide the anonymity and the unlinkability at the
IP layer.
Haddad, et al. Expires December 2005 [Page 1]
INTERNET-DRAFT OMIPv6 Privacy June 2005
Table of contents
1. Introduction................................................2
2. Terminology.................................................2
3. Glossary....................................................3
4. Problem Statement...........................................4
5. Proposed Solution...........................................6
6. Packet Format...............................................9
7. Privacy Considerations.....................................11
8. Security Considerations....................................12
9. Normative References.......................................13
10. Informative References....................................13
11. Authors' Addresses........................................14
Intellectual Property Statement...............................16
Disclaimer of Validity........................................16
Copyright Statement...........................................16
1. Introduction
CGA-OMIPv6 (called "OMIPv6" in the rest of the document for
simplicity) 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/pseudonymity and unlinkability. Supporting these
privacy aspects in OMIPv6 would allow a mobile user to move
outside its home network without disclosing its real IPv6 home
address, and thereby to prevent the ability to correlate
actions at this layer.
This document describes privacy extensions to the OMIPv6
protocol.
2. Terminology
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY"
in this document are to be interpreted as described in RFC 2219
[TERM].
Haddad, et al. Expires December 2005 [Page 2]
INTERNET-DRAFT OMIPv6 Privacy June 2005
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 December 2005 [Page 3]
INTERNET-DRAFT OMIPv6 Privacy June 2005
4. Problem Statement
OMIPv6 protocol introduces a new route optimization (RO) mode,
which 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 MN <-> CN 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 then 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
HoA and its new current topological location, i.e., disclosed in
its 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 under any circumstance(s), since data packets sent by the
CN are addressed to the MN's HoA. The BT mode is detailed in
[MIPv6].
But it should be noted that replacing the real MN's HoA with a
static (or even dynamic) pseudo-HoA can still allow the
eavesdropper to correlate between MN's movements across the
Internet, thus breaking the unlinkability feature. Such
correlation can be accomplished by simply tracing the BU
messages via the sequence number carried by each 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,
Haddad, et al. Expires December 2005 [Page 4]
INTERNET-DRAFT OMIPv6 Privacy June 2005
etc). In fact, such knowledge can reveal all MN's pseudo-HAs and
their 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 to
the same pseudo-HoA. Such correlation may reveal the exact time
of the MN's movement(s) regardless of the content of the BU
message. In addition, tracing the BU message may 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) 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:
- prevent disclosing the MN's HoA in any BU message.
- avoid using the same pseudo-HoA in more than one BU
message.
- prevent the possibility of tracing the BU messages via the
sequence number.
- prevent any correlation between data packets exchanged
with the current CoA and the next BU message sent after
performing an IP handover.
- prevent any correlation between data carried by the BU
message and data packets exchanged after receiving the BA
message.
Finally, it should be noted that any potential solution, which
addresses privacy as motivated above, should take the scenario
where a mobile node starts communicating end-to-end with a CN
from its home network before switching to a foreign network(s)
into consideration.
Haddad, et al. Expires December 2005 [Page 5]
INTERNET-DRAFT OMIPv6 Privacy June 2005
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:
a) 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 sequence number handling).
b) replacing the home address carried within the Home Address
Option (HAO) with an ephemeral identifier.
c) associating the interface identifier (iid) of the MN's home
address with the cryptographically-Based Identifiers (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 bidirectional tunneling mode (described in [MIPv6])
during the subsequent data exchange.
The MN MUST set the "P" bit in the PBU message, regardless of
the MN's location (also while staying at the 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 cryptographically generated and verifiable
identifier [CBID]. Note that using the CBID technology in Mobile
IPv6 for privacy purposes has been introduced in [MIPriv].
During the first exchange of signaling messages 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 in this case, the VHoA is the CBID,
thus the value is equal to SHA1(CBID) in the PBU message.
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 into the PBT message and returns
it to the MN. When the MN gets the PBT message, it sends a BU
message carrying the "P" bit, the challenge and inserts the real
CBID into the HAO. Note that the iid of the MN's CoA sent in the
Haddad, et al. Expires December 2005 [Page 6]
INTERNET-DRAFT OMIPv6 Privacy June 2005
PBU and the BU messages SHOULD be generated from hashing the
CBID in the following way:
iid(CoA) = First(64, SHA1(CBID))
Where:
- SHA1 is a hashing function
- CBID is a cryptographically generated identifier
- First(size,input) is a function used to indicate
truncation of the input data so that only the first
size bits remain to be used.
- iid is the interface identifier
Upon receiving the first BU message with the "P" bit set, the CN
starts by checking its validity. For this purpose, it will hash
the content of the HAO, i.e., the CBID, and compares 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 message. The third step after a successful validation would
be to create an entry in the BCE for the MN's VHoA and the CoA.
The CN computes also a long lifetime shared secret (i.e., SKbm)
and sends it back to the MN in the BA message as described in
[OMIPv6].
The presence of the "P" bit in the BU message is also used to
request the CN to replace the sequence number carried by the BU
message, in its BCE with the "next" value, i.e., 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
increment the sequence number. With the privacy extensions
introduced by this document, both endpoints MUST increment the
SQV with a constant value equal to the one obtained from hashing
the SKbm. Finally, the incremented 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(64, SHA1((pSQV) | Khbm))
Where:
Haddad, et al. Expires December 2005 [Page 7]
INTERNET-DRAFT OMIPv6 Privacy June 2005
- SKbm is a long lifetime binding management key
- Khbm is the hashed binding management key
- pSQV is the previous SQV, i.e., SQV sent in the last BU
message sent by the MN and already processed by the CN.
- nSQV is the hasht 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/updating
the MN's 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 a 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 address pair (CoA, VHoA) to be used in the data
packets exchange following the BCE creation/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:
- nCoA is the MN's care-of address sent in the BU message.
- 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]). Note that in such scenario, 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.
As mentioned above, 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, then the CN SHOULD
proceed to check the signature before updating the corresponding
entry with the eCoA, eVHoA and nSQV.
Haddad, et al. Expires December 2005 [Page 8]
INTERNET-DRAFT OMIPv6 Privacy June 2005
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 December 2005 [Page 9]
NTERNET-DRAFT OMIPv6 Privacy June 2005
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 December 2005 [Page 10]
INTERNET-DRAFT OMIPv6 Privacy June 2005
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 [MIP6-IKE] and [MIP6-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
strongly 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 December 2005 [Page 11]
INTERNET-DRAFT OMIPv6 Privacy June 2005
8. Security Considerations
The suggested solution does not introduce new attacks nor does
it amplify 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 December 2005 [Page 12]
INTERNET-DRAFT OMIPv6 Privacy June 2005
9. Normative References
[CGA-OMIPv6] W. Haddad, L. Madour, J. Arkko and F. Dupont,
"Applying Cryptographically Generated Addresses to
Optimize MIPv6 (CGA-OMIPv6)",
draft-haddad-mip6-cga-omipv6-04, May, 2005.
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[MIP6-IKE] J. Arkko, V. Devarapalli, F. Dupont, "Using IPsec
to Protect Mobile IPv6 Signaling Between Mobile
Nodes and Home Agents", RFC 3776, June 2004.
[MIP6-IKEv2] V. Devarapalli, "Mobile IPv6 Operation with IKEv2
and the revised IPsec Architecture",
draft-ietf-mip6-ikev2-ipsec-01, February 2005.
[TERM] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10. Informative References
[ANON] A. Pfitzmann et al. "Anonymity, Unobservability,
Pseudonymity, and Identity Management - A Proposal
for Terminology", Draft v0.21, September, 2004.
[CBID] G. Montenegro, C. Castelluccia, "Cryptographically-
Based Identifiers (CBID): Concepts and Applications",
ACM Transaction on Information and System Security
(TISSEC), February 2004.
[HBA] M. Bagnulo, "Hash Based Addresses (HBA)",
draft-ietf-multi6-hba-00, December 2004.
[MIPriv] C. Castelluccia, F. Dupont, G. Montenegro, "A Simple
Privacy Extension to Mobile IPv6", IEEE/IFIP
International Conference on Mobile and Wireless
Communication Networks (MWCN), Paris, France, October
Haddad, et al. Expires December 2005 [Page 13]
INTERNET-DRAFT OMIPv6 Privacy June 2005
2004.
[MOMIPRIV] W. Haddad, E. Nordmark, F. Dupont, M. Bagnulo, S.
Park and B. Patil, "Privacy for Mobile and
Multi-homed Nodes: MoMiPriv Problem Statement",
draft-haddad-momipriv-problem-statement-01,
February 2005.
[PRIVACY] T. Narten, R. Draves and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration
in IPv6", draft-ietf-ipv6-privacy-address-v2-04,
May 2005.
11. Authors' Addresses
Wassim Haddad
Ericsson Research
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2
Canada
Phone: +1 514 345 7900 (#2334)
E-Mail: Wassim.Haddad@ericsson.com
Suresh Krishnan
Ericsson Research
8400, Decarie Blvd
Town of Mount Royal
Quebec H4P 2N2
Canada
Phone: +1 514 345 7900 (#2871)
E-Mail: Suresh.Krishnan@ericsson.com
Francis Dupont
Point6
c/o GET/ENST Bretagne
Campus de Rennes
2, rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Haddad, et al. Expires December 2005 [Page 14]
INTERNET-DRAFT OMIPv6 Privacy June 2005
E-Mail: Francis.Dupont@enst-bretagne.fr
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
SPAIN
Phone: +34 91 6249500
E-Mail: 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 December 2005 [Page 15]
INTERNET-DRAFT OMIPv6 Privacy June 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 IETF's procedures
with respect to rights in IETF 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.
The IETF has been notified of intellectual property rights
claimed in regard to some or all of the specification contained
in this document. For more information consult the online list
of claimed rights.
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.
Haddad, et al. Expires December 2005 [Page 16]