Host Identity Protocol Working A. Matos
Group J. Santos
Internet-Draft IT Aveiro
Expires: September 7, 2006 J. Girao
M. Liebsch
NEC Europe Ltd
R. Aguiar
IT Aveiro
March 6, 2006
Host Identity Protocol Location Privacy Extensions
draft-matos-hip-privacy-extensions-01
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 September 7, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo describes a framework for the Host Identity Protocol that
provides location privacy and mobility to end hosts. It discusses
the introduction of a new functional entity that prevents HIP enabled
Matos, et al. Expires September 7, 2006 [Page 1]
Internet-Draft HIP Privacy Extensions March 2006
nodes from revealing their location.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119] .
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Problem Statement and Location Privacy Considerations . . . . 8
4. Location Privacy Framework Overview . . . . . . . . . . . . . 10
4.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. HIP Mobile Node . . . . . . . . . . . . . . . . . . . 11
4.1.2. Access Router . . . . . . . . . . . . . . . . . . . . 11
4.1.3. Rendezvous Agent . . . . . . . . . . . . . . . . . . . 12
4.1.3.1. Rendezvous Agent Location . . . . . . . . . . . . 12
4.1.4. Rendezvous Server . . . . . . . . . . . . . . . . . . 12
4.2. RVA Protected Areas . . . . . . . . . . . . . . . . . . . 12
4.2.1. Mechanisms for Location Privacy . . . . . . . . . . . 13
4.2.2. Communication Interfaces . . . . . . . . . . . . . . . 13
4.2.2.1. HMN to AR Communication . . . . . . . . . . . . . 14
4.2.2.2. AR to RVA Communication . . . . . . . . . . . . . 14
4.2.2.3. RVA to RVA Communication . . . . . . . . . . . . . 14
5. Message and Parameter Requirements . . . . . . . . . . . . . . 15
5.1. Advertisement Message . . . . . . . . . . . . . . . . . . 15
5.2. RVA Parameter . . . . . . . . . . . . . . . . . . . . . . 15
5.3. HOST_ID Parameter . . . . . . . . . . . . . . . . . . . . 15
5.4. RENDEZVOUS_AGENT Registration Type . . . . . . . . . . . . 15
5.5. FROM_ID Parameter . . . . . . . . . . . . . . . . . . . . 15
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Base Exchange with RVA . . . . . . . . . . . . . . . . . . 16
6.1.1. Certification . . . . . . . . . . . . . . . . . . . . 17
6.2. Packet Translation at RVA . . . . . . . . . . . . . . . . 17
6.3. Base Exchange with RVS . . . . . . . . . . . . . . . . . . 18
6.4. Base Exchange with HCN . . . . . . . . . . . . . . . . . . 19
6.5. Intra-RVA Handover . . . . . . . . . . . . . . . . . . . . 20
6.6. Inter-RVA Handover . . . . . . . . . . . . . . . . . . . . 21
6.7. RVA to RVA Update . . . . . . . . . . . . . . . . . . . . 23
7. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 25
7.1. HIP Mobile Node . . . . . . . . . . . . . . . . . . . . . 25
7.2. Access Router . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Rendezvous Agent . . . . . . . . . . . . . . . . . . . . . 25
8. Compatibility Mode . . . . . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
Matos, et al. Expires September 7, 2006 [Page 2]
Internet-Draft HIP Privacy Extensions March 2006
10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. RVA Certification . . . . . . . . . . . . . . . . . . . . 29
10.2. Levels of Responsibility Assignment . . . . . . . . . . . 29
10.3. Credit Based Authorization . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
13.1. Normative References . . . . . . . . . . . . . . . . . . . 32
13.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Matos, et al. Expires September 7, 2006 [Page 3]
Internet-Draft HIP Privacy Extensions March 2006
1. Introduction
The current Internet architecture has two important global
namespaces: Internet Protocol (IP) addresses and fully qualified
domain names (FQDN). The Domain Name System (DNS) provides services
for domain name to IP resolution.
IP addresses have two different roles. They are used simultaneously
as locators and identifiers for a host. At the network layer an IP
address is used for routing and network-layer mechanisms thus acting
as a locator. Transport layer mechanisms bind IP addresses as names
that identify communication endpoints.
Using IP addresses for location and identification limits the current
Internet architecture. Mobility scenarios rely on constant re-
addressing, which breaks the existing transport layer communications.
The Host Identity Protocol (HIP) architecture [I-D.ietf-hip-arch]
proposes a new namespace (Host Identity) to eliminate the dual role
of IP addresses. Instead of translating directly FQDNs to IP
addresses a HIP enabled DNS [I-D.ietf-hip-dns] translates FQDNs to
Host Identities (HI), and Host Identities to IP addresses. HIs are
now used by the transport layer as endpoint names. The network layer
continues to use IP addresses as pure locators.
The HIP base protocol [I-D.ietf-hip-base] further defines a simple
mechanism for rapid authentication between two hosts and allows the
creation of cryptographic material for subsequent IPsec Encapsulated
Security payload (ESP) communication [I-D.ietf-hip-esp].
The HIP mobility and multihoming extensions [I-D.ietf-hip-mm] defines
a generic Locator Parameter that allows a HIP node to dynamically
change its set of underlying IP addresses without breaking transport
layer sessions.
Mobility management relying on dynamic DNS has been widely discussed.
This approach has two drawbacks. Dynamic DNS updates have a big
performance impact when security is considered, and propagating
updated DNS entries requires excessive time for many mobility
scenarios. The HIP architecture tries to reduce the DNS updates by
introducing Rendezvous Server (RVS) [I-D.ietf-hip-rvs]. A HIP node
registers his RVS's IP address in the DNS and then registers its IP
addresses with the RVS, maintaining global reachability without
relying on dynamic DNS updates.
As defined in [I-D.haddad-momipriv-problem-statement], location
privacy is the capability of preventing other parties from learning
one's past or current location. Here location pertains to the
Matos, et al. Expires September 7, 2006 [Page 4]
Internet-Draft HIP Privacy Extensions March 2006
topological and not geographical position of a node, although
frequently the topological location can give a very accurate
geographical position. For a node to obtain location privacy, there
must be no relation between its Host Identifier and its location.
The location privacy problem is not limited to a single layer. In
fact it is related to the identifiers associated with a node, i.e.,
the MAC and IP addresses. Another related problem is their
interdependency.
The MAC Layer uses a MAC address which is unique for each device.
When a mobile device attaches to a link, it is always identified by
that address. Also, the frame header of the MAC Layer contains a
sequence number, which can be used to uniquely identify a node, even
if the node changes MAC Address or uses pseudo-identifiers. The
location privacy problems concerning the MAC Layer are out of scope
for this document.
At the IP Layer, several issues result in loss of location privacy.
In the IPv6 context, a Mobile Node (MN) performing address auto-
configuration is implicitly disclosing its MAC address, allowing a
direct mapping between MAC address and IPv6 address, therefore making
itself easy to track.
Another problem in the IP layer relates to mobility. Moving across
networks using different local addresses reveals the actual location
of MN.
Currently, the base HIP architecture does not support location
privacy. In the current HIP architecture, the resolution of a remote
Host Identifier to its current locator is done by the host. With
HIP, the Locator Parameter usage on the base exchange and mobility
update procedures discloses the current set of IP addresses
(locators) used by the communicating HIP nodes.
The proposed extensions to the HIP architecture attempts to resolve
the problems at the network level.
Matos, et al. Expires September 7, 2006 [Page 5]
Internet-Draft HIP Privacy Extensions March 2006
2. Terminology
o Host Identity Protocol (HIP) - protocol that proposes a new
namespace between the IP and DNS namespaces. Decouples the dual
locator/identifier role of an IP address.
o Host Identifier (HI) - public key used as name for a Host.
o Host Identity Tag (HIT) - 128 bit hash over the HI.
o HIP Mobile Node (HMN) - HIP enabled node capable of changing its
point of attachment to the network.
o HIP Correspondent Node (HCN) - HIP enabled node on the other end
point of a HIP communication with a HMN.
o HIP Base Exchange (BE) - HIP packets that manage the establishment
of state between an Initiator (I) and a Responder (R) using a
4-way handshake with a standard authenticated Diffie-Hellman key
exchange for session key generation. It allows the establishment
of a Security Association between the hosts.
o Rendezvous Service - consists of relaying the first packet of the
BE sent by the I to the R. It may also serve as a location
registration point for HMNs. This service is provided by
RendezVous Servers (RVS)s and, in the case the HMN is registered
with the RVS, it is also denominated as a RendezVous Client (RVC).
o Rendezvous Agent (RVA) - entity responsible for providing location
privacy to its attendants in HIP. The RVA is responsible for
HIP-IP resolution and, at the same time, conceal the locators of
HMN for outgoing packets and of its communication peer in
incomming packets.
o Access Router (AR) - entity responsible for managing the last hop
packet communication in the Access Network (rout).
o Locator - a name by which a packet can be routed through the
network. Normally an IP address.
o RVA protected area - area under a delegated RVA that provides
location privacy. No locators are used inside this area.
o Intra-RVA Mobility - mobility between access routers (AR), within
the same RVA protected area.
o Inter-RVA Mobility - mobility between different RVA protected
areas.
Matos, et al. Expires September 7, 2006 [Page 6]
Internet-Draft HIP Privacy Extensions March 2006
o IPg - a globally routable IP address used in the core network
attributed to a HMN under an RVA protected area.
o AN - Access Network
Matos, et al. Expires September 7, 2006 [Page 7]
Internet-Draft HIP Privacy Extensions March 2006
3. Problem Statement and Location Privacy Considerations
The current HIP architecture does not take into account location
privacy issues. HIP is an end-to-end protocol. This means that when
an Initiator and a Responder perform a base exchange, they learn the
location of the each other immediately from the I1 and R1 packets as
described in Section 6.4.
If we consider the presence of an RVS, the Initiator does not
immediately learn the current locator of the Responder. However,
that information is disclosed in the R1 packet.
In both approaches an end-to-end addressing mechanism is used. This
means that both I and R will always learn each other's current IP
address once the BE is completed.
Furthermore, capturing the HIP base exchange enables an eavesdropper
to learn the HITs and IPv6 addresses of both participants,
consequently forfeiting the location privacy of the peers.
In the current HIP mobility draft , [I-D.ietf-hip-mm] a HMN is
required to update its locator for every HCN by sending explicit
update messages in case a handover occurs. These update messages
contain the new locator of the node. This is comparable to the
Binding Update messages exchanged between MIPv6 [RFC3775] enabled
Mobile Nodes (MN) and Correspondent Nodes (CN) when performing route
optimization. HIP ultimately suffers from the same location privacy
issues as MIPv6, described in [I-D.haddad-momipriv-threat-model].
If the target HIP node of a DNS query is not registered in an RVS
then the DNS resolves to the current IPv6 address of the node. In an
architecture that supports location privacy, the HIP nodes should
never be able to map the identifier to the real locator of the node.
In older versions of [I-D.ietf-hip-rvs] some considerations and
network elements were introduced that shield a HIP node's location,
although there was no followup on this matters.
The framework presented in this document addresses key issues before
mentioned. The solution limits as much as possible any disclosure,
voluntary or involuntary, of location information from the nodes.
Relying on the concept of a protected area, which can be though of as
a network under an anchor point as in Hierarchical Mobile IP
[RFC4140], privacy is assured by the suppression of locators on these
networks, making the nodes unaware of their locations. We can
summarize some key aspects gained with this solution:
The HCN never learns the IP address of a HMN, nor vice-versa, if
both are under RVA protected areas. The communication in the AN
Matos, et al. Expires September 7, 2006 [Page 8]
Internet-Draft HIP Privacy Extensions March 2006
is based on HITs and therefore no locators are necessary. In case
the transport in the AN requires locators for routing, the scope
of these names are deemed as local and are never leaked outside
the AN.
The attacker is only able to learn a HMN's location if it is in
the same AN. In this case, the attacker can track HITs, MACs and
possibly other AN transport information by simply eavesdropping on
the physical medium. We believe that this architecture can be
extended or combined with other mechanisms to also cover this
case.
The globally assigned IPv6 addresses limits the amount of location
information an eavesdropper in the core network obtains from
mapping HITs to global addresses used in the routing process.
This factor can even be reduced if an encrypted tunnel is used
between the different RVAs. If the eavesdropper is on the path
and able to intercept all messages received by the HCN outside the
HCN's protected area, it does not learn of local mobility and can
only track movement between different RVA protected areas. The
size of RVA protected areas determines how much geographical
location information an attacker can obtain by using this method.
An attacker tracking the base exchange can learn the SPIs of IPsec
SAs and afterwards map the SPIs to the assigned IPv6 addresses.
Once again, the attacker is limited to the location of the RVAs
information and the SPIs used.
Matos, et al. Expires September 7, 2006 [Page 9]
Internet-Draft HIP Privacy Extensions March 2006
4. Location Privacy Framework Overview
Location privacy is provided by delegating the HIT to IP resolution
into a network entity called the RVA.
Moving the resolution upwards in the network topology (from the HMNs
to the RVA) has the benefit that locators are not used within the RVA
protected area.
The core feature of the proposed solution is the concept of an RVA
protected area. It is a section of the network where locators are
either concealed or not used at all. Instead, HITs are used to
identify the traffic path. Moreover, RVAs are responsible locating
HMNs within the protected area, thus handling local mobility.
We do not assume any type of transport at the network layer. As long
as it can support some type of identity based routing, any protocol
can be used. Currently, HIP is defined only for IPv4 and IPv6. In
this document, for the sake of simplicity, we provide examples
assuming the presence of IPv6.
4.1. Topology
An example of the proposed topology has been illustrated in Figure 1.
The scenario consists of two RVA protected areas connected to the
Internet. An RVA protected area is composed by multiple ARs which
are directly connected to an RVA. There are no assumptions on the
number of RVA protected areas, although it is reasonable to think
that an RVA covers a large number of ARs. A wider coverage of area,
geographical or topological, limits the amount of location
information revealed to an external eavesdropper. The RVSs and DNSs
are located in the Internet, natively or, possibly, under different
RVA protected areas. Note that several RVSs may exist in this
architecture.
The AR and the RVA are functional entities, thus they can be
collocated in the same machine. As stated in location privacy
considerations, due to the area coverage of such an RVA, this option
has consequences in the quality of the location privacy provided to
the HMNs in that RVA protected area.
Matos, et al. Expires September 7, 2006 [Page 10]
Internet-Draft HIP Privacy Extensions March 2006
+---+ +---+
|RVS| |DNS|
+-+-+ +-+-+
| +--------+ |
+--------|INTERNET+-----+
+---+--+-+
| |
+--------+ +---------+
| |
+-+--+ +-+--+
|RVA1| |RVA2|
++--++ ++--++
| | | |
+--+ +--+ +--+ +--+
| | | |
+-+-+ +-+-+ +-+-+ +-+-+
|AR1| |AR2| |AR3| |AR4|
+---+ +---+ +---+ +-+-+
| |
+--+-+ +-+--+
|HMN1| |HMN2|
+----+ +----+
Figure 1: Basic architecture topology example
4.1.1. HIP Mobile Node
The HMN is meant to deal with intra and inter RVA mobility,
signalling the RVA and RVS respectively. The HMN has to perform
movement detection, based on the advertisements it receives from the
ARs. The HMN does not need to implement auto-configuration
mechanisms, unless required by the AN, but it is required to maintain
a communication path to the AR.
4.1.2. Access Router
The AR is responsible for forwarding packets to and from the RVA or
the AN edge router. It keeps a HIT based neighbor list of all the
HMNs under it. Note that each entry of the HIT neighbor list
contains an HIT based route for packet forwarding.
The AR sustains the advertisement protocol by broadcasting RVA
advertisement messages (defined in Section 5.1). This enables the
HMN to learn the HIT of the local RVA and to perform movement intra
and inter RVA area handover.
Matos, et al. Expires September 7, 2006 [Page 11]
Internet-Draft HIP Privacy Extensions March 2006
4.1.3. Rendezvous Agent
The RVA is an enhanced RVS that performs the IP-HI address resolution
function. This functionality splitting provides location privacy to
the MNs behind it. This is done by readdressing the packets flowing
between an RVA area and the outside network. To forward packets to a
destination HIT outside a RVA protected area, the RVA addresses a
globally routable IPv6 address previously assigned by another RVA to
the destination host. When an RVA receives packets from the outside
network to a host belonging to its RVA protected area, it re-
addresses them to HITs and forwards the packet to the destination.
Note that the RVA is the entity which assigns globally routable IP
addresses to the hosts under it, and the only one to map between HITs
and global IP addresses.
The RVA is capable of forwarding packets based on HITs because it
maintains a table mapping for every HMN in the protected area to its
point of attachment, which is the AR.
The RVA is responsible for handling mobility for the HMNs in the
protected area. This means that the RVA might have to signal other
RVAs or HCNs on behalf of the HMNs for location updates.
4.1.3.1. Rendezvous Agent Location
The RVA does not need to be the AR of a protected area. The
acumulation of functionality could lead to scalability problems.
Therefore the RVA needs only to be within the protected area. The
area router then queries the RVA for routing decisions.
4.1.4. Rendezvous Server
The RVS is a network entity which serves as the initial contact point
for HIP nodes registered in it, the RVCs. The RVS provides a
relaying service of incoming I1 packets to an RVC IP address. An RVC
should use the registration mechanisms defined in [I-D.ietf-hip-rvs].
After this procedure is finished, all communication typically occur
directly without the assistance of the RVS.
The proposed architecture implies that instead of registering
locators, the HIP nodes register the HIT of their designated RVA.
When an incoming I1 packet arrives at an RVS intended to one of its
RVCs, the RVS resolves HIT HMN to HIT of the HMN's RVA, then HIT RVA
to IP address of the RVA where the packet is sent to.
4.2. RVA Protected Areas
Matos, et al. Expires September 7, 2006 [Page 12]
Internet-Draft HIP Privacy Extensions March 2006
4.2.1. Mechanisms for Location Privacy
Once the architecture described in this document is deployed, issues
such as mobility have to be addressed. To this purpose we believe
that the use of an advertisement system based on identifiers, rather
than locators, is sufficient. The mechanism should be sufficient so
that the node detects movement but shall not give out any additional
information, especially in what concerns location.
Inline with the aforementioned, the transport mechanism in the AN is
also required to keep location information concealed. Packets that
are exchanged between RVAs, ARs and HMNs should not reveal global
location information.
One simple way of instantiating such a transport is to consider point
to point connections between ARs and RVAs, not disclose any locator
information, even if local, and use a switching method based on the
peers of the different point to point connections.
IPv6 can also be used within the protected area, given that the RVA
performs the necessary address translations for the exchanged
packets. This allows better scalability with current tecnologies
without limiting the size of the protected area. Since the the
routers in the protected area do not need to be HIP aware, nor
maintain separte routes for each hip node, normal IP routing can be
performed. But, this has implications on the amount of information
revealed within the protected area:
The Initiator is aware of his local address, and possibly of the
global IP of the Responder.
An eavesdropper on path between RVA and HMN is able to map the hip
node's position.
There is a clear tradeoff between location privacy and scalabity
within the protected area.
4.2.2. Communication Interfaces
Rather than defining a specific transport layer for this approach, we
base ourselves in some basic assumptions that allow the mechanisms to
work. The architecture itself should be independent of the HIP
transport layer. We propose some instantiations based on direct IPv6
address translations, tunnels and semantical adaptations (replacing
IPv6 addresses with HITs).
In principle all approaches are valid and one should just keep in
mind that, when a specific approach is chosen, optimizations might be
Matos, et al. Expires September 7, 2006 [Page 13]
Internet-Draft HIP Privacy Extensions March 2006
possible. For example, if a tunnel mechanism is used between RVAs,
there is no need for a global locator attribution per HMN.
4.2.2.1. HMN to AR Communication
The basic assumption on the communication medium between HMN and AR
is that packets can be transmitted based on HITs. This can either be
a bidirectional point-to-point connection or a broadcast shared
medium.
4.2.2.2. AR to RVA Communication
The communication between a AR and RVA is done through a
bidirectional point-to-point connection.
4.2.2.3. RVA to RVA Communication
The communication between RVAs is also done through a bidirectional
point-to-point medium. Typically this is over the Internet or a core
network.
Matos, et al. Expires September 7, 2006 [Page 14]
Internet-Draft HIP Privacy Extensions March 2006
5. Message and Parameter Requirements
5.1. Advertisement Message
The advertisement message is sent by the ARs and contains the RVA HIT
responsible for the RVA protected area of the AR sending the message.
The HMN learns the RVA HIT from this message.
5.2. RVA Parameter
The RVA parameter announces the RVA responsible for the HMN sending
the packet. This parameter is sent from the HMN to the RVS.
5.3. HOST_ID Parameter
The HOST_ID Parameter to inform RVAs of which host (or HMN) the
sending RVA is acting on behalf of. This parameter announces the
HMN's HIT and is always used together with a LOCATOR parameter.
5.4. RENDEZVOUS_AGENT Registration Type
This specification defines an additional registration for the HIP
registration protocol [I-D.ietf-hip-registration] that allows
registering with a rendezvous server for rendezvous service.
Number Registration Type
------ -----------------
TBD RENDEZVOUS_AGENT_SERVICE
5.5. FROM_ID Parameter
The FROM_ID parameter carries a HIT. It is used when RVA to RVA
packet forwarding occurs, so that the receiving node can validate the
sending RVA and that it should perform update to the source of the
packet.
Matos, et al. Expires September 7, 2006 [Page 15]
Internet-Draft HIP Privacy Extensions March 2006
6. Protocol Operation
For the privacy location scenario to work it is necessary to slightly
alter the basic HIP mechanisms. This includes minor changes in the
following mechanisms:
Base Exchange with RVA: The MN performs a base exchange with the
RVA, allowing a RVA to deal with HMN intra mobility, packet
forwarding and RVA to RVA signaling.
Base Exchange with RVS: The BE with the RVS is performed through
the RVA. The RVA must monitor the exchange in order to create
entries for the HMN's current point of attachment and assign a
globally routable IPv6 address.
Normal Base exchange (between I and R): The RVAs must perform
network layer readdressing. HIP session tracking must be
performed in order to perform mobility signalling on behalf of the
HMN.
Handover: The normal update to the RVS requires RVA monitoring for
entry creation and IPv6 assignment as in the base exchange to the
RVS. Local handover is also defined for intra-RVA mobility
because there is no need to update the RVS, only the RVA.
RVA to RVA update: After a HMN handover, a HCN's RVA still sends
data packets to the old RVA until it is updated with the HMN's new
location. When an old RVA receives packets to a HMN no longer
registered, it redirects them to the new RVA. The new RVA then
performs signalling on behalf of the HMN to update the location in
the HCN's RVA.
Normal Packet forwarding: this operation requires readdressing on
the involved RVAs.
6.1. Base Exchange with RVA
+-----+ +-----+
| | 1.I1 | |
| |--------------------------->| |1a. RVA learns
| | 2.R1(REG_INFO) | | HIT-AR map
| HMN |<---------------------------| RVA |
| | 3.I2(REG_REQ) | |
| |--------------------------->| |
| | 4.R2(REG_RES) | |
| |<---------------------------| |4a. RVA assigns
+-----+ +-----+ IPg for HMN
Matos, et al. Expires September 7, 2006 [Page 16]
Internet-Draft HIP Privacy Extensions March 2006
Figure 2: Base Exchange with RVA
When a HMN first arrives on a protected area is has to register with
the responsible RVA. The RVA HIT is learnt from the Advertisement
messages sent by the AR. Upon receiving an advertisement message,
the HMN register with the announced RVA by means of a base exchange
using the registration extensions defined in [I-D.ietf-hip-
registration].
The RVA learns HIT-AR mapping from I1, for identity based routing.
Note that no packet forwarding on the behalf of the HMN is done until
the BE is completed, avoiding DoS attacks. After the BE is
completed, the RVA assings an IPg for the registering HMN.
The HMN can use the BE described above to cross-certify his assigned
RVA. This procedure can later be explored for mobility delegation
and other explicit signaling from the RVA to the RVS on behalf of the
HMN. Further details are discussed in Section 10.
6.1.1. Certification
In I2 the HMN should give out a CER Parameter, in order to certify
the RVA. This certificate can later be used for secure mobility
updates, between RVAs
6.2. Packet Translation at RVA
After the BE, when communicating with nodes that are after the RVA,
it is required that the RVA performs readressing. On packets going
outwars to the core network, the RVA hides the endpoints HIT's, and
inserts the corresponding IP's (steps and 2 in figure Figure 3). For
packets arriving from the core network the RVA performs the required
readdressing, concealing the globally routable IP addresses assigned
to the HIP nodes, and inserts the corresponding HIT's, that are
delivered according to the defined HIT based transport mechanism that
conveys packets to the correct destination (steps 3 and 4 in figure
Figure 3.
Matos, et al. Expires September 7, 2006 [Page 17]
Internet-Draft HIP Privacy Extensions March 2006
+-----+ +-----+ +-----+
| | 1.Data(HMN_HIT,R_HIT) | | | |
| |---------------------->| | | |
| | | | 2.Data(IPg,R_IP) | |
| I | | RVA |------------------>| R |
| | | | 3.Data(IPg,R_IP) | |
| | | |<------------------| |
| | 4.Data(HMN_HIT,R_HIT) | | | |
| |<----------------------| | | |
+-----+ +-----+ +-----+
Figure 3: Packet Header Translation
6.3. Base Exchange with RVS
After arriving on a new RVA protected area and performing the BE with
the RVA described above, the HMN has to register with his RVS or
update it. If the HMN is not yet registered in an RVS, it begins the
registration process. This registration procedure consists in an
enhanced base exchange, depicted in Figure 4, which contains the
identifier of the designated RVA for the node.
The I1, R1 and R2 packets are the same as described for a standard
base exchange with an RVS in [I-D.ietf-hip-rvs]. The I2 packet
contains an extra HIP parameter which carries the newly discovered
RVA identifier. This parameter - RVA Parameter (see Section 5.2) -
is used to inform the RVS of the RVA identifier this HMN is currently
using. This enables the HMN to register with the RVS not with a
locator but with an identity.
In a RVA protected area, packets are routed using a transport
mechanism (eg. point-to-point IPsec) that does not use the locators
in the core network. For this reason, packets coming from a RVA
protected area are processed and given the correct locators for
routing in the core network. Packets arriving from the outside
network need to be forwarded correctly to the current assigned AR for
destination HIT. Until the base exchange is completed, no globally
routable address is assigned to the HMN. Therefore, in the outside
network, packets concerning signalling to a RVS use the locator of
the HMN's assigned RVA.
Matos, et al. Expires September 7, 2006 [Page 18]
Internet-Draft HIP Privacy Extensions March 2006
+-----+ +-----+
| | 1.I1 | |
| |--------------------------->| |
| | 2.R1(REG_INFO) | |
| HMN |<---------------------------| RVS |
| | 3.I2(REG_REQ,RVA_HIT) | |
| |--------------------------->| |
| | 4.R2(REG_RES) | |
| |<---------------------------| |
+-----+ +-----+
Figure 4: Base Exchange with RVS
6.4. Base Exchange with HCN
The HIP base exchange between an Initiator and a Responder, depicted
in Figure 5, remains unchanged from HIP base protocol at the HIP
layer. Key differences are at the network layer. The Initiator's
RVA performs readdressing of outgoing packets to globally routable IP
addresses. If the RVA does not know the Responder's HIT, it queries
the DNS for its IP address as shown in step 2. The DNS server then
returns the IP address of the Responder's RVS in step 3.
In step 4 and 5, the RVS relays I1 packet to the IP address of the
Responder's RVA. This is done based on the two step mapping
previously discussed where the Responder's HIT is translated to the
RVA HIT, and then RVA HIT is finally translated to the RVA IP
address. Also, the FROM and VIA Parameters are included as described
in [I-D.ietf-hip-rvs].
Upon receiving the I1 in step 5, the Responder's RVA forwards the
packet to the destination HIT's currently. The RVA also needs to
store the newly learnt HIT I - IPg I mapping for further packet
forwarding as shown in step 5a.
In step 6, the HMN receives the packet and replies in step 7 with a
R1 packet. The R1 packet is then relayed in RVA, which performs its
normal operation, readdressing the packet based on the on the learnt
mapping. In the base exchanges remaining packets (I2 and R2) the
globally assigned IP addresses of both I and R are used between RVAs.
Matos, et al. Expires September 7, 2006 [Page 19]
Internet-Draft HIP Privacy Extensions March 2006
+---+ +----+ +---+ +---+ +----+ +---+
| R | |RVA1| |RVS| |DNS| |RVA2| | I |
+---+ +-+--+ +---+ +-+-+ +-+--+ +-+-+
| | | | | | |1.I1() |
| | | | |<-------|
| | | | |2.query()| |
| | | |<--------| |
| | | | | | | |
| | | |3.reply()| |
| | | | |-------->| |
| | | |4.I1() | |
| | | |<----------+---------| |
| | 5.I1() | | | | |
| |<----------| | | |
| 6.I1() | 5a. HIT I <-> IPg I | | |
|<----------| mapping learnt | | | |
| | | | | |
| 7.R1() | | | | | | |
|---------->| 8.R1() | | | |
| |-----------+-----------+-------->| 9.R1() |
| | | | | | |------->|
| | | | |10.I2() |
| | | | 11.I2() |<-------|
| |<----------+-----------+---------| |
| 12.I2() | | | | |
|<----------| | | | | | |
| | | | | |
| 13.I2() | | | | | | |
|---------->| 14.R2() | | | |
| |-----------+-----------+-------->|15.R2() |
| | | | | | |------->|
| | | | | |
Figure 5: Base Exchange
6.5. Intra-RVA Handover
When a HMN detects that it has changed AR, though, without changing
RVA protected area, it performs an intra RVA handover (steps 1 and
2). Since the AR is in the same RVA protected area there is no need
to update the RVS. The HMN updates its binding to the RVA directly,
performing a normal HIP update procedure without a locator as
depicted in steps 3 to 5. This update message is used by the RVA to
learn the new HMN - AR mapping. Note that the globally assigned IP
for the node performing the handover remains the same. This location
change is transparent to the RVS since the HMN remains in the same
area. It is also transparent to other RVAs because the global
assigned IP address for that node does not change.
Matos, et al. Expires September 7, 2006 [Page 20]
Internet-Draft HIP Privacy Extensions March 2006
+---+ +---+ +---+ +---+
|HMN| |AR1| |AR2| |RVA|
+-+-+ +-+-+ +-+-+ +-+-+
| 1.RVA_ADV()| | |
|<-----x-----| | |
| | | |
| 2.RVA_ADV()| | |3a.HMN<->AR
|<-----------+------------| | mapping
| | | | updated
| 3.UPDATE() | | |
|------------+------------+---------->|
| | | |
| | 4.UPDATE(AC) |
|<-----------+------------+-----------|
| | | |
| 5.UPDATE(ACR) | |
|------------+------------+---------->|
| | | |
Figure 6: Intra-RVA Handover
6.6. Inter-RVA Handover
The inter-RVA handover occurs when a HMN detects it has changed RVA
protected area after receiving a RVA Advertisement message. This is
described in Figure 7 where the ARs in step 1 and 2 announce
different RVA HITs. At this point the HMN registers with the RVA by
means of a base exchange as defined in Section 6.1. Then the HMN
performs a normal Update to the RVS and to the old RVA.
To the RVS, the HMN sends a HIP Update packet including the RVA HIT
on a RVA parameter (step 3), in the same way it is done for the I2
packet mentioned in Section 6.3. The RVS updates the HMN entry
according to this parameter, changing the responsible entity for the
HMN to the new announced RVA.
Matos, et al. Expires September 7, 2006 [Page 21]
Internet-Draft HIP Privacy Extensions March 2006
+---+ +--------+ +----+ +--------+ +----+ +---+
|HMN| |AR(RVA1)| |RVA1| |AR(RVA2)| |RVA2| |RVS|
+-+-+ +----+---+ +-+--+ +----+---+ +-+--+ +-+-+
| | | | | |
| 1.RVA_ADV() | | | |
|<----x----| | | | |
| | | | | |
| | 2.RVA_ADV() | | |
|<---------+------------+------------| | |
| | | | | |
| -- BASE EXCHANGE (HMN <-> RVA) --- | | |
| | | | | |
| 3.UPDATE(HIT_RVA2) | | | |
|----------+------------+------------+--------->| |
| | | | UPDATE(HIT_RVA2)
| | | | |------->|
| | | | | 5.UPDATE(AC)
| | | | |<-------|
| | | 6.UPDATE(AC)| |
|<---------+------------+------------+----------| |
| | | | | |
| 7.UPDATE(ACR) | | | |
|----------+------------+------------+--------->+ |
| | | | | 8.UPDATE(ACR)
| | | | |------->|
Figure 7: Inter-RVA Handover - RVS Update
To the old RVA, the HMN sends an update packet with an RVA parameter.
This packet is used to inform the old RVA that HMN as changed RVA
protected area. After the update procedure is completed as depicted
in Figure 8, the old RVA needs to forward the data packets destined
to the HMN to the new RVA (step 8a). When the new RVA receives the
forwarded packets, it updates the location to the HCNs RVA's.
Matos, et al. Expires September 7, 2006 [Page 22]
Internet-Draft HIP Privacy Extensions March 2006
+---+ +--------+ +----+ +--------+ +----+
|HMN| |AR(RVA1)| |RVA1| |AR(RVA2)| |RVA2|
+-+-+ +----+---+ +-+--+ +----+---+ +-+--+
| | | | |
| 1.RVA_ADV() | | |
|<----x----| | | |
| | | | |
| | 2.RVA_ADV() | |
|<---------+------------+------------| |
| | | | |
| 3.UPDATE(HIT_RVA2) | | |
|----------+------------+------------+--------->|
| | | 4.UPDATE(HIT_RVA2) |
| | |<-----------+----------|
| | | | |
| | | 5.UPDATE(AC) |
| | |------------+--------->|
| | | 6.UPDATE(AC) |
|<---------+------------+------------+----------|
| | | | |
| 7.UPDATE(ACR) | | |
|----------+------------+------------+--------->|
| | | | |
| | | 8.UPDATE(ACR) | 8a. old RVA
| | |<----------------------| forwards packets
to new RVA
Figure 8: Inter-RVA Handover - old RVA Update
It is possible to perform an inter-RVA handover without signalling
the RVS. The advantage of this approach is the reduced overhead of
the handover, but it requires the RVAs to act as RVSs (forwarding de
I1 packet) for every registered HMN. This forms a cascading chain of
RVSs that could be desirable if the geographical area covered by one
RVA is considerably big. This matter requires further study.
For fast mobility a preparation phase is required. The HMN needs to
inform the current RVA that it is changing and to perform a BE with
the new RVA. The current RVA starts forwarding packets to the new
RVA. After the move, the HMN explicitly signals the new RVA which
performs performs location updates to other RVA's or HCN's. Further
investigation is required on this matter.
6.7. RVA to RVA Update
When the new RVA receives the forwarded packets from another RVA, it
updates the location to the HCNs RVA's. The forwarded packets need
to be differentiated from the normal traffic, allowing a RVA to
Matos, et al. Expires September 7, 2006 [Page 23]
Internet-Draft HIP Privacy Extensions March 2006
decide when mobility updates are needed or not. This is acomplished
by using the HIP FROM_ID PARAMETER in a new HIP Header inserted at
the old RVA. This allows increased security, authentication and
triggers updates from the new RVA. The procedure is depicted in
Figure 9.
+----+ +-------+ +-------+ +-----+ +----+
|HMN1| |new_RVA| |old_RVA| | RVA | |HMN2|
+-+--+ +---+---+ +---+---+ +--+--+ +-+--+
| | | | 1.DATA() |
| | | |<---------|
| | | 2.DATA() | |
| | |<-----------+ |
| | 3.HIP(DATA()) | | |
| |<--------------| | |
| 4.DATA() | | | |
|<-------------| | | |
| | 5.UPDATE() | | |
| |---------------+----------->| |
| | | | |
| | | 6.UPDATE() | |
| |<--------------+------------| |
| | | | |
| | 7.UPDATE() | | |
| |---------------+----------->| |
| | | | |
Figure 9: HCN's RVA update after handover
Matos, et al. Expires September 7, 2006 [Page 24]
Internet-Draft HIP Privacy Extensions March 2006
7. Conceptual Data Structures
7.1. HIP Mobile Node
The HMN MUST have a path to the AR currently being used. The table
of all reachable ARs MAY be maintained. This table should contain
the RVA HIT, AR's MAC address and association lifetime. Note that a
AR may belong to two or more different RVA protected areas.
+---------------------------------------------------+
| RVA Host Identity Tag | AR MAC Address | Lifetime |
+-----------------------+----------------+----------+
| ... | ... | ... |
+-----------------------+----------------+----------+
Figure 10: HMN data structure
7.2. Access Router
The AR must maintain a HIT based neighbor table so that packet
forwarding is possible, since there are no locators in RVA protected
areas.
+--------------------------------------------+
| Host Identity Tag | MAC Address | Lifetime |
+-------------------+-------------+----------+
| ... | ... | ... |
+-------------------+-------------+----------+
Figure 11: AR data structure
7.3. Rendezvous Agent
The RVA MUST maintain a HMN HIT based table for downlink packet
handling. This entry keeps track of which AR the HMN is currently
attached.
The table MUST also contain location information (i.e. the globally
assigned IPv6 address) for each registered HMN for packet routing in
the core network.
+-------------------------------------------------------------+
| Host Identity Tag |AR MAC Address | Lifetime | IPg Assigned |
+-------------------+---------------+----------+--------------+
| ... | ... | ... | ... |
+-------------------+---------------+----------+--------------+
Figure 12: RVA data structure
Matos, et al. Expires September 7, 2006 [Page 25]
Internet-Draft HIP Privacy Extensions March 2006
The RVA maintains also a table containing information for each
established session between nodes in the RVA protected area and CNs
for proper data packet processing.
+----------------------------------------------------+
| HMN registered | HCN | HCN/RVA |
| Host Identity Tag | Host Identity Tag | IP |
+-------------------+-------------------+------------+
| ... | ... | ... |
+-------------------+-------------------+------------+
Figure 13: Registered HMNs session data structure
Matos, et al. Expires September 7, 2006 [Page 26]
Internet-Draft HIP Privacy Extensions March 2006
8. Compatibility Mode
In a scenario where an HMN in a RVA domain is able to initiate a HIP
session with a HCN not in RVA domain (directly connected to core
network), the HMN's RVA location is revealed to the HCN.
+---+
+---+ |HCN| +---+
|RVS| +-+-+ |DNS|
+-+-+ | +-+-+
| +-+------+ |
+--------|INTERNET+-----+
+---+--+-+
| |
+--------+ +---------+
| |
+-+--+ +-+--+
|RVA1| |RVA2|
++--++ ++--++
| | | |
+--+ +--+ +--+ +--+
| | | |
+-+-+ +-+-+ +-+-+ +-+-+
|AR1| |AR2| |AR3| |AR4|
+---+ +---+ +---+ +-+-+
|
+--+-+
|HMN |
+----+
Figure 14: Compatibility topology
This scenario has obvious implications in location privacy. A HCN is
able to track the RVAs a HMN is using by inspecting the Update
messages. The HCN's location is still protected from the HCN.
This issue can be solved by a full RVA deployment.
Matos, et al. Expires September 7, 2006 [Page 27]
Internet-Draft HIP Privacy Extensions March 2006
9. Security Considerations
It is suggested that the nodes use IPsec in tunnel node. If IPsec
transport mode is used, a simple traceroute from one end to another
might disclose the corresponding node's RVA, even if both exist
behind an RVA protected area. Using IPsec tunnel, only one hop
exists between communicating nodes, providing more location privacy
against this kind of attacks. The drawback of using tunnel mode is
the encapsulation overhead.
Further security considerations are currently being investigated and
will be added in future revisions of this memo.
Matos, et al. Expires September 7, 2006 [Page 28]
Internet-Draft HIP Privacy Extensions March 2006
10. Open Issues
10.1. RVA Certification
When the HMN performs the BE with the RVA it should send its
certificate, so that afterwards the RVA can perform mobility updates
to other RVAs in a secure manner. The [I-D.ietf-hip-base] a CER
parameter is defined and can be used to deliver mobility handling
delegation to a RVA. For now it is assumed that trust between the
RVAs is implicit and that the communication between two RVAs is done
via a HIP association.
10.2. Levels of Responsibility Assignment
The proposed architecture can be hierarchical and provide several
levels of responsibility assignment. Basically, a RVA attaching down
in other RVA may delegate to the top most RVA responsibility for it.
This scenario may provide an environment for network mobility
support. This matter requires further study.
10.3. Credit Based Authorization
Credit Based Authorization [I-D.vogt-hip-credit-based-authorization]
is a potentical item for itegration, due to the fact that prior to an
update, the node is required to perform a Base Exchange with the RVA
of the new network. The framework would gain in terms of overall
performance, reducing the time between association and updates and
data packets flowing through the network.
Matos, et al. Expires September 7, 2006 [Page 29]
Internet-Draft HIP Privacy Extensions March 2006
11. IANA Considerations
This document makes no request of IANA.
Matos, et al. Expires September 7, 2006 [Page 30]
Internet-Draft HIP Privacy Extensions March 2006
12. Acknowledgements
We would like to thank Bernd Lamparter, Andreas Festag and Lars
Eggert for their comments and suggestions on this document.
Matos, et al. Expires September 7, 2006 [Page 31]
Internet-Draft HIP Privacy Extensions March 2006
13. References
13.1. Normative References
[I-D.ietf-hip-arch]
Moskowitz, R. and P. Nikander, "Host Identity Protocol
Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005.
[I-D.ietf-hip-base]
Moskowitz, R., Nikander, P., Jokella, P., and T.
Henderson, "Host Identity Protocol",
draft-ietf-hip-base-05 (work in progress), March 2006.
[I-D.ietf-hip-dns]
Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions",
draft-ietf-hip-dns-06 (work in progress), February 2006.
[I-D.ietf-hip-esp]
Jokela, P. and R. Moskowitz, "Using ESP transport format
with HIP", draft-ietf-hip-esp-02 (work in progress),
March 2006.
[I-D.ietf-hip-mm]
Henderson, T., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-03 (work in
progress), March 2006.
[I-D.ietf-hip-registration]
Laganier, J., "Host Identity Protocol (HIP) Registration
Extension", draft-ietf-hip-registration-01 (work in
progress), December 2005.
[I-D.ietf-hip-rvs]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", draft-ietf-hip-rvs-04 (work in
progress), October 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
13.2. Informative References
[I-D.haddad-momipriv-problem-statement]
Haddad, W., "Privacy for Mobile and Multi-homed Nodes:
MoMiPriv Problem Statement",
draft-haddad-momipriv-problem-statement-02 (work in
Matos, et al. Expires September 7, 2006 [Page 32]
Internet-Draft HIP Privacy Extensions March 2006
progress), October 2005.
[I-D.haddad-momipriv-threat-model]
Haddad, W., "Privacy for Mobile and Multi-homed Nodes
(MoMiPriv): Formalizing the Threat Model",
draft-haddad-momipriv-threat-model-01 (work in progress),
October 2005.
[I-D.vogt-hip-credit-based-authorization]
Vogt, C., "Credit-Based Authorization for HIP Mobility
with Concurrent IP-Address Tests",
draft-vogt-hip-credit-based-authorization-00 (work in
progress), February 2005.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
Matos, et al. Expires September 7, 2006 [Page 33]
Internet-Draft HIP Privacy Extensions March 2006
Authors' Addresses
Alfredo Matos
IT Aveiro
Campus Universitario de Santiago
Aveiro P-3810-193
Portugal
Phone: +351 234 377900
Fax: +351 234 377901
Email: alfredo.matos@av.it.pt
Justino Santos
IT Aveiro
Campus Universitario de Santiago
Aveiro P-3810-193
Portugal
Phone: +351 234 377900
Fax: +351 234 377901
Email: jsantos@av.it.pt
Joao Girao
NEC Europe Ltd
Kurfuersten Anlage 36
Heidelberg D-69115
Germany
Phone: +49 (0)6221 905 11 17
Fax: +49 (0)6221 905 11 55
Email: joao.girao@netlab.nec.de
Marco Liebsch
NEC Europe Ltd
Kurfuersten Anlage 36
Heidelberg D-69115
Germany
Phone: +49 (0)6221 905 11 46
Fax: +49 (0)6221 905 11 55
Email: marco.liebsch@netlab.nec.de
Matos, et al. Expires September 7, 2006 [Page 34]
Internet-Draft HIP Privacy Extensions March 2006
Rui Aguiar
IT Aveiro
Campus Universitario de Santiago
Aveiro P-3810-193
Portugal
Phone: +351 234 377900
Fax: +351 234 377901
Email: ruilaa@det.ua.pt
Matos, et al. Expires September 7, 2006 [Page 35]
Internet-Draft HIP Privacy Extensions March 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.
Matos, et al. Expires September 7, 2006 [Page 36]