One document matched: draft-matos-hip-privacy-extensions-00.txt
Host Identity Protocol Working A. Matos
Group J. Santos
Internet-Draft IT Aveiro
Expires: December 2005 J. Girao
M. Liebsch
NEC Europe Ltd
R. Aguiar
IT Aveiro
June 2005
Host Identity Protocol Location Privacy Extensions
draft-matos-hip-privacy-extensions-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo describes a framework for the Host Identity Protocol that
provides location privacy and mobility to end hosts.
Matos, et al. Expires December 2005 [Page 1]
Internet-Draft HIP Privacy Extensions June 2005
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 . . . . . . . . . . . . . . . . . . . . . . 8
4. Location Privacy Considerations . . . . . . . . . . . . . . . 9
5. Overview of the Location Privacy Architecture . . . . . . . . 10
5.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1.1 HIP Mobile Node . . . . . . . . . . . . . . . . . . . 11
5.1.2 Access Router . . . . . . . . . . . . . . . . . . . . 11
5.1.3 Rendezvous Agent . . . . . . . . . . . . . . . . . . . 12
5.1.4 Rendezvous Server . . . . . . . . . . . . . . . . . . 12
5.2 RVA Protected Areas . . . . . . . . . . . . . . . . . . . 12
5.2.1 Mechanisms for Location Privacy . . . . . . . . . . . 12
5.2.2 Communication Interfaces . . . . . . . . . . . . . . . 13
5.2.2.1 HMN to AR Communication . . . . . . . . . . . . . 13
5.2.2.2 AR to RVA Communication . . . . . . . . . . . . . 13
5.2.2.3 RVA to RVA Communication . . . . . . . . . . . . . 13
6. Message and Parameter Requirements . . . . . . . . . . . . . . 14
6.1 Advertisement Message . . . . . . . . . . . . . . . . . . 14
6.2 RVA Parameter . . . . . . . . . . . . . . . . . . . . . . 14
6.3 FROM_ID Parameter . . . . . . . . . . . . . . . . . . . . 14
7. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15
7.1 Base Exchange with RVA . . . . . . . . . . . . . . . . . . 15
7.2 Base Exchange with RVS . . . . . . . . . . . . . . . . . . 16
7.3 Base Exchange with HCN . . . . . . . . . . . . . . . . . . 17
7.4 Intra-RVA Handover . . . . . . . . . . . . . . . . . . . . 19
7.5 Inter-RVA Handover . . . . . . . . . . . . . . . . . . . . 19
7.6 RVA to RVA Update . . . . . . . . . . . . . . . . . . . . 21
7.7 Packet Forwarding . . . . . . . . . . . . . . . . . . . . 22
8. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 24
8.1 HIP Mobile Node . . . . . . . . . . . . . . . . . . . . . 24
8.2 Access Router . . . . . . . . . . . . . . . . . . . . . . 24
8.3 Rendezvous Agent . . . . . . . . . . . . . . . . . . . . . 24
9. Compatibility Mode . . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . 27
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1 RVA Certification . . . . . . . . . . . . . . . . . . . . 28
11.2 Levels of Responsibility Assignment . . . . . . . . . . . 28
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
Matos, et al. Expires December 2005 [Page 2]
Internet-Draft HIP Privacy Extensions June 2005
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1 Normative References . . . . . . . . . . . . . . . . . . . 32
15.2 Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 33
A. Protocol Operation Example over IPv6 . . . . . . . . . . . . . 35
A.1 Base Exchange with RVA . . . . . . . . . . . . . . . . . . 35
A.2 Base Exchange with RVS . . . . . . . . . . . . . . . . . . 35
A.3 Base Exchange . . . . . . . . . . . . . . . . . . . . . . 38
A.4 Intra-RVA Handover . . . . . . . . . . . . . . . . . . . . 40
A.5 Inter-RVA Handover . . . . . . . . . . . . . . . . . . . . 41
A.6 RVA to RVA Update . . . . . . . . . . . . . . . . . . . . 45
A.7 Packet Forwarding . . . . . . . . . . . . . . . . . . . . 45
B. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 47
B.1 Packet Processing . . . . . . . . . . . . . . . . . . . . 47
B.1.1 Processing Beacons . . . . . . . . . . . . . . . . . . 47
B.1.2 Base Exchange . . . . . . . . . . . . . . . . . . . . 47
B.1.3 Movement Detection . . . . . . . . . . . . . . . . . . 47
B.1.4 Intra-RVA Handover . . . . . . . . . . . . . . . . . . 47
B.1.5 Inter-RVA Handover . . . . . . . . . . . . . . . . . . 47
C. Access Router Operation . . . . . . . . . . . . . . . . . . . 49
C.1 Packet Processing . . . . . . . . . . . . . . . . . . . . 49
D. Rendezvous Agent Operation . . . . . . . . . . . . . . . . . . 50
D.1 Packet Processing . . . . . . . . . . . . . . . . . . . . 50
D.1.1 Base Exchange with the RVS . . . . . . . . . . . . . . 50
D.1.2 Intra-RVA Handover . . . . . . . . . . . . . . . . . . 50
D.1.3 Inter-RVA Handover . . . . . . . . . . . . . . . . . . 50
D.1.4 Packet Forwarding . . . . . . . . . . . . . . . . . . 50
E. Rendezvous Server Operation . . . . . . . . . . . . . . . . . 51
E.1 Packet Processing . . . . . . . . . . . . . . . . . . . . 51
E.1.1 Base Exchange . . . . . . . . . . . . . . . . . . . . 51
E.1.2 Inter-RVA Handover . . . . . . . . . . . . . . . . . . 51
E.1.3 I1 Packet Forwarding . . . . . . . . . . . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . . 52
Matos, et al. Expires December 2005 [Page 3]
Internet-Draft HIP Privacy Extensions June 2005
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.jokela-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-threat-model], location privacy is
the capability of preventing other parties from learning one's past
or current location. Here location pertains to the topological and
Matos, et al. Expires December 2005 [Page 4]
Internet-Draft HIP Privacy Extensions June 2005
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 December 2005 [Page 5]
Internet-Draft HIP Privacy Extensions June 2005
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 December 2005 [Page 6]
Internet-Draft HIP Privacy Extensions June 2005
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 December 2005 [Page 7]
Internet-Draft HIP Privacy Extensions June 2005
3. Problem Statement
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 7.3.
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 [I-D.eggert-hip-rendezvous-01] some considerations and network
elements are introduced that shield a HIP node's location.
Matos, et al. Expires December 2005 [Page 8]
Internet-Draft HIP Privacy Extensions June 2005
4. Location Privacy Considerations
The architecture described in this document addresses key issues
defined in [I-D.haddad-momipriv-threat-model]. In this section, we
summarize the key aspects covered by this new architecture:
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
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 December 2005 [Page 9]
Internet-Draft HIP Privacy Extensions June 2005
5. Overview of the Location Privacy Architecture
As suggested in [I-D.eggert-hip-rendezvous-01] 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 RVA
protected areas. An RVA protected area is a section of the network
where locators are concealed or not used at all. Instead, HITs are
used to identity the traffic path. RVAs are also responsible for
local mobility under their RVA protected areas.
We do not assume any transport layer, as long as it can support HIP.
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.
5.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 December 2005 [Page 10]
Internet-Draft HIP Privacy Extensions June 2005
+---+ +---+
|RVS| |DNS|
+-+-+ +-+-+
| +--------+ |
+--------|INTERNET+-----+
+---+--+-+
| |
+--------+ +---------+
| |
+-+--+ +-+--+
|RVA1| |RVA2|
++--++ ++--++
| | | |
+--+ +--+ +--+ +--+
| | | |
+-+-+ +-+-+ +-+-+ +-+-+
|AR1| |AR2| |AR3| |AR4|
+---+ +---+ +---+ +-+-+
| |
+--+-+ +-+--+
|HMN1| |HMN2|
+----+ +----+
Figure 1: Basic architecture topology example
5.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. The detailed operation of the HMN is
described in Appendix B.
5.1.2 Access Router
The AR is responsible for forwarding the packets to and from the RVA
or the AN edge router. It keeps a HIT based neighbor list of all the
HMNs under it. Each entry of the HIT neighbor list contains a HIT
based route to forward the packets from the RVA to the MN and vice-
versa.
The AR sustains the advertisement protocol by broadcasting RVA
advertisement messages (defined in Section 6.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 December 2005 [Page 11]
Internet-Draft HIP Privacy Extensions June 2005
5.1.3 Rendezvous Agent
As described in [I-D.eggert-hip-rendezvous-01], 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.
5.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.
5.2 RVA Protected Areas
5.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
Matos, et al. Expires December 2005 [Page 12]
Internet-Draft HIP Privacy Extensions June 2005
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 sent 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.
5.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
possible. For example, if a tunnel mechanism is used between RVAs,
there is no need for a global locator attribution per HMN.
5.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.
5.2.2.2 AR to RVA Communication
The communication between a AR and RVA is done through a
bidirectional point-to-point connection.
5.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 December 2005 [Page 13]
Internet-Draft HIP Privacy Extensions June 2005
6. Message and Parameter Requirements
6.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.
6.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.
6.3 FROM_ID Parameter
The FROM_ID Parameter is used by RVAs to inform other RVAs of a
registered HMN location's change. This parameter announces the HMN's
HIT and is always used together with a LOCATOR parameter.
Matos, et al. Expires December 2005 [Page 14]
Internet-Draft HIP Privacy Extensions June 2005
7. Protocol Operation
In order 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.
7.1 Base Exchange with RVA
Matos, et al. Expires December 2005 [Page 15]
Internet-Draft HIP Privacy Extensions June 2005
+---+ +--+ +---+
|HMN| |AR| |RVA|
+-+-+ ++-+ +-+-+
| 1.I1() | |
|---------------+-------------->|
| 2.R1() | |
|<--------------+---------------|
| 3.I2() | |
|---------------+-------------->|
| 4.R2() | |4a. RVA learns
|<--------------+---------------| HIT-AR
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.koponen-hip-
registration].
Note that no packet forwarding for the HMN is done until the BE is
completed to avoid DoS attacks. After the BE is completed, the RVA
learns the HIT-AR mapping for further packet forwarding.
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 11.
7.2 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 3, 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 6.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
Matos, et al. Expires December 2005 [Page 16]
Internet-Draft HIP Privacy Extensions June 2005
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.
+---+ +--+ +---+ +---+
|HMN| |AR| |RVA| |RVS|
+-+-+ ++-+ +-+-+ +-+-+
| 1.I1() | | |
|---------------+-------------->| 2.I1() |
| | |--------------->|
| | | 3.R1() |
| 4.R1() | |<---------------|
|<--------------+---------------| |
| 5.I2() | | |
|---------------+-------------->| 6.I2() |
| | |--------------->|
| | | |
| | | 7.R2() |
| 8.R2() | |<---------------|
|<--------------+---------------| |
| | | 8a. Assign IPg |
| | | for HMN |
| | | |
Figure 3: Base Exchange with RVS
7.3 Base Exchange with HCN
The HIP base exchange between an Initiator and a Responder, depicted
in Figure 4, 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
Matos, et al. Expires December 2005 [Page 17]
Internet-Draft HIP Privacy Extensions June 2005
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.
+---+ +----+ +---+ +---+ +----+ +---+
| 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 4: Base Exchange
Matos, et al. Expires December 2005 [Page 18]
Internet-Draft HIP Privacy Extensions June 2005
7.4 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.
+---+ +---+ +---+ +---+
|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 5: Intra-RVA Handover
7.5 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 6 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 7.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 7.2. The RVS updates the HMN entry
Matos, et al. Expires December 2005 [Page 19]
Internet-Draft HIP Privacy Extensions June 2005
according to this parameter, changing the responsible entity for the
HMN to the new announced RVA.
+---+ +--------+ +----+ +--------+ +----+ +---+
|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 6: 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 7, 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 December 2005 [Page 20]
Internet-Draft HIP Privacy Extensions June 2005
+---+ +--------+ +----+ +--------+ +----+
|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 7: 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.
7.6 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 December 2005 [Page 21]
Internet-Draft HIP Privacy Extensions June 2005
decide when mobility updates are needed or not. The procedure is
depicted in Figure 8.
+----+ +-------+ +-------+ +----+ +----+
|HMN1| |RVA_new| |RVA_old| |RVA1| |HMN2|
+-+--+ +---+---+ +---+---+ +--+-+ +-+--+
| | | | 1.DATA()|
| | | |<--------|
| | | 2.DATA() | |
| | |<-----------+ |
| | 3.DATA() | | |
| |<-------------| | |
| 4.DATA() | | | |
|<-------------| | | |
| | 5.UPDATE() | | |
| |--------------+----------->| |
| | | | |
| | | 6.UPDATE() | |
| |<-------------+------------| |
| | | | |
| | 7.UPDATE() | | |
| |--------------+----------->| |
| | | | |
Figure 8: HCN's RVA update after handover
7.7 Packet Forwarding
For packet forwarding, the RVAs use the same mechanisms already
described for base exchange and update packets. The RVAs perform the
required readdressing, concealing the globally routable IP addresses
assigned to the HIP nodes from RVA protected areas. In the RVA
protected areas, the transport mechanism defined, based on HITs, is
used to deliver the packets to the destination.
Matos, et al. Expires December 2005 [Page 22]
Internet-Draft HIP Privacy Extensions June 2005
+---+ +---+ +---+ +---+
| I | |RVA| | |RVA| | R |
+-+-+ +-+-+ +-+-+ +-+-+
| | | | |
| 1.DATA() | | |
|---------->| 2.DATA() | | |
| |------------------------>| 3.DATA()
| | | |------->|
| | | 4.DATA()
| | | 5.DATA() |<-------|
| |<------------------------| |
| 6.DATA() | | | |
|<----------| | |
| | | | |
Figure 9: Packet Forwarding
Matos, et al. Expires December 2005 [Page 23]
Internet-Draft HIP Privacy Extensions June 2005
8. Conceptual Data Structures
8.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
8.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
8.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.
Matos, et al. Expires December 2005 [Page 24]
Internet-Draft HIP Privacy Extensions June 2005
+-------------------------------------------------------------+
| Host Identity Tag |AR MAC Address | Lifetime | IPg Assigned |
+-------------------+---------------+----------+--------------+
| ... | ... | ... | ... |
+-------------------+---------------+----------+--------------+
Figure 12: RVA data structure
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 December 2005 [Page 25]
Internet-Draft HIP Privacy Extensions June 2005
9. 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 December 2005 [Page 26]
Internet-Draft HIP Privacy Extensions June 2005
10. 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 December 2005 [Page 27]
Internet-Draft HIP Privacy Extensions June 2005
11. Open Issues
11.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.
11.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.
Matos, et al. Expires December 2005 [Page 28]
Internet-Draft HIP Privacy Extensions June 2005
12. Contributors
Contributors to the document
Matos, et al. Expires December 2005 [Page 29]
Internet-Draft HIP Privacy Extensions June 2005
13. IANA Considerations
This document makes no request of IANA.
Matos, et al. Expires December 2005 [Page 30]
Internet-Draft HIP Privacy Extensions June 2005
14. Acknowledgements
We would like to thank Bernd Lamparter, Andreas Festag and Lars
Eggert for their comments and suggestions on this work.
Matos, et al. Expires December 2005 [Page 31]
Internet-Draft HIP Privacy Extensions June 2005
15. References
15.1 Normative References
[I-D.ietf-hip-arch]
Moskowitz, R., "Host Identity Protocol Architecture",
draft-ietf-hip-arch-02 (work in progress), January 2005.
[I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-02 (work in progress), February 2005.
[I-D.ietf-hip-dns]
Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions",
draft-ietf-hip-dns-01 (work in progress), February 2005.
[I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multi-Homing with
Host Identity Protocol", draft-ietf-hip-mm-01 (work in
progress), February 2005.
[I-D.ietf-hip-rvs]
Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extensions", draft-ietf-hip-rvs-01 (work in
progress), February 2005.
[I-D.jokela-hip-esp]
Jokela, P., "Using ESP transport format with HIP",
draft-jokela-hip-esp-00 (work in progress), February 2005.
[I-D.koponen-hip-registration]
Koponen, T. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-koponen-hip-registration-00
(work in progress), February 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2 Informative References
[I-D.eggert-hip-rendezvous-01]
Eggert, L. and M. Liebsch, "Host Identity Protocol (HIP)
Rendezvous Mechanisms", draft-eggert-hip-rendezvous-01
(work in progress), July 2004.
[I-D.haddad-momipriv-problem-statement]
Haddad, W., "Privacy for Mobile and Multi-homed Nodes:
Matos, et al. Expires December 2005 [Page 32]
Internet-Draft HIP Privacy Extensions June 2005
MoMiPriv Problem Statement",
draft-haddad-momipriv-problem-statement-01 (work in
progress), February 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-00 (work in progress),
February 2005.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Authors' Addresses
Alfredo Matos
IT Aveiro
Campus Universitario de Santiago
Aveiro P-3810-193
Portugal
Phone: +351 234 377900
Fax: +351 234 377901
Email: a23622@alunos.det.ua.pt
Justino Santos
IT Aveiro
Campus Universitario de Santiago
Aveiro P-3810-193
Portugal
Phone: +351 234 377900
Fax: +351 234 377901
Email: a20257@alunos.det.ua.pt
Matos, et al. Expires December 2005 [Page 33]
Internet-Draft HIP Privacy Extensions June 2005
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
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 December 2005 [Page 34]
Internet-Draft HIP Privacy Extensions June 2005
Appendix A. Protocol Operation Example over IPv6
In this section we define an example of how the architecture should
behave with a HIT forwarding mechanism in the HIP protected area,
over IPv6.
A.1 Base Exchange with RVA
When a HMN notices an AR it will discover the HIT of the RVA
controlling the area through the ICMP RVA Advertisement message
provided by the AR. If the HMN is not yet registered in the
announced RVA, it performs the registration process. This
registration procedure consists in a normal base exchange using
registration extensions. Packets are sent as it follows:
I1():
IP Header: src: HIT HMN, dst: HIT RVA
HIP Header: src: HIT HMN, dst: HIT RVA
Parameters: none
R1():
IP Header: src: HIT RVA, dst: HIT HMN
HIP Header: src: HIT RVA, dst: HIT HMN
Parameters: PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, HOST_ID :
HI_RVA, REG_INFO, HIP_SIGNATURE_2
I2():
IP Header: src: HIT HMN, dst: HIT RVA
HIP Header: src: HIT HMN, dst: HIT RVA
Parameters: SOLUTION, DIFFIE_HELLMAN, HIP_TRANSFORM, ENCRYPTED
{ HOST_ID : HI_HMN }, REG_REQ, HMAC, HIP_SIGNATURE
R2():
IP Header: src: HIT RVA, dst: HIT HMN
HIP Header: src: HIT RVA, dst: HIT HMN
Parameters: REG_RESP, HMAC_2, HIP_SIGNATURE
A.2 Base Exchange with RVS
Figure 15 depicts the registration procedure with a RVS for global
reachability. When a HMN notices an AR it will discover the HIT of
the RVA controlling the area through the ICMP RVA Advertisement
message provided by the AR, as shown in step 1. If the HMN is not
Matos, et al. Expires December 2005 [Page 35]
Internet-Draft HIP Privacy Extensions June 2005
yet registered in a RVS, it begins the registration process. This
registration procedure consists in an enhanced base exchange which
contains the identifier of the designated RVA for the node.
On HIP layer the I1, R1 and R2 packets are the same as described in
the base architecture. The I2 packet contains an extra HIP parameter
which carries the newly discovered RVA identifier. This parameter -
RVA Parameter (see Section 6.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.
On the IP layer the RVA needs to translate all HITs to IPs in all the
packets coming from RVA protected area and IPs to HITs all the
packets arriving from the outside network. For packets I1 and I2 the
RVA translates both source and destination fields to the IP
equivalents as described in steps 2, 3 (I1) and 6, 7 (I2). Finally,
for packets R1 and R2 the RVA does the inverse translation as
described in steps 4, 5 (R1) and 8, 9 (R2). Note that for HIP
packets concerning signalling to a RVS, the HIT to IP translation of
a HMN HIT is always RVA's IP. Therefore, the reply packets will come
with RVA's IP as destination. In order to forward HIP packets coming
from the outside network, the RVA needs to inspect the HIP header to
map the correct HIT translation.
The RVA also needs to learn the HIT-AR mapping from the I1 packet for
further packet forwarding, as seen in step 2a. Upon detecting the
end of the base exchange the RVA assigns a globally routable IPv6
address to the HMN that will be used in further HIP sessions with
correspondent nodes.
Matos, et al. Expires December 2005 [Page 36]
Internet-Draft HIP Privacy Extensions June 2005
Base Exchange with RVS
+---+ +--+ +---+ +---+
|HMN| |AR| |RVA| |RVS|
+-+-+ ++-+ +-+-+ +-+-+
| | | |
|1.ICMP_RVA_ADV(HIT_RVA) | |
|<--------------| | 2a. Store map |
| 2.I1(HIT_HMN,HIT_RVA) | HMN <-> AR |
|---------------+-------------->| |
| | |3.I1(IP_RVA,IP_RVS)
| | |--------------->|
| | | |
| | |4.R1(IP_RVS,IP_RVA)
| | |<---------------|
| 5.R1(HIT_RVS,HIT_HMN) | |
|<--------------+---------------| |
| 6.I2(HIT_HMN,HIT_RVS) | |
|---------------+-------------->|7.I2(IP_RVA,IP_RVS)
| | |--------------->|
| | | |
| | |8.R2(IP_RVS,IP_RVA)
| 9.R2(HIT_RVS,HIT_HMN) |<---------------|
|<--------------+---------------| |
| | | 9a. Assign IPg |
| | | for HMN |
| | | |
Figure 15
HIP Layer:
I1():
HIP Header: src: HIT HMN, dst: HIT RVS
Parameters: none
R1():
HIP Header: src: HIT RVS, dst: HIT HMN
Parameters: PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, HOST_ID :
HI_RVS, HIP_SIGNATURE_2
I2():
HIP Header: src: HIT HMN, dst: HIT RVS
Parameters: SOLUTION, DIFFIE_HELLMAN, HIP_TRANSFORM, ENCRYPTED
{ HOST_ID : HI_HMN }, RVA, HMAC, HIP_SIGNATURE
Matos, et al. Expires December 2005 [Page 37]
Internet-Draft HIP Privacy Extensions June 2005
R2():
HIP Header: src: HIT RVS, dst: HIT HMN
Parameters: HMAC_2, HIP_SIGNATURE
A.3 Base Exchange
The HIP base exchange between an Initiator and a Responder, depicted
in Figure 16, remains unchanged from HIP base protocol at the HIP
layer. The noteworthy differences are at the IP layer. In the
Initiator's RVA, the HITs get translated to 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
discussed in Appendix E.1.3. Basically, 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].
In the end of step 5, the Responder's RVA does the following
translations: IP RVA2 is translated in the Responder's HIT and the
Initiator's globally assigned IP in the Initiator's HIT. The RVA
also needs to store the newly learnt HIT-IPg mapping for further
packet forwarding. Then, the RVA forwards the packet.
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, translating the HITs to IP addresses based on the
learnt mapping. In the base exchange's remaining packets (I2 and R2)
the globally assigned IP addresses of both I and R are used between
RVAs. Accordingly, the RVAs translate globally assigned IP addresses
to HITs on incoming packets in steps 8, 11 and 14 and from HITs to
globally assigned IP addresses in steps 7, 10 and 13.
Matos, et al. Expires December 2005 [Page 38]
Internet-Draft HIP Privacy Extensions June 2005
Base Exchange
+---+ +----+ +---+ +---+ +----+ +---+
| R | |RVA1| |RVS| |DNS| |RVA2| | I |
+---+ +-+--+ +---+ +-+-+ +-+--+ +-+-+
| | | | | | |1.I1(HIT_I,HIT_R)
| | | | |<-------|
| | | | 2.query(HIT_R) |
| | | |<--------| |
| | | | | | | |
| | | 3.reply(IP_RVS) |
| | | | |-------->| |
| | | 4.I1(IPg I,IP RVS) | |
| | | |<----------+---------| |
| | 5.I1(IPg I,IP RVA1) | | | |
| |<----------| | | |
6.I1(HIT_I,HIT_R) | | | |
|<----------| | | | | | |
| | | | | |
7.R1(HIT_R,HIT_I) | | | | | |
|---------->|8.R1(IPg_R,IPg_I) | | |
| |-----------+-----------+-------->|9.R1(HIT_R,HIT_I)
| | | | | | |------->|
| | | | |10.I2(HIT_I,HIT_R)
| | | | 11.I2(IPg_I,IPg_R) |<-------|
| |<----------+-----------+---------| |
12.I2(HIT_I,HIT_R) | | | |
|<----------| | | | | | |
| | | | | |
|13.I2(HIT_R,HIT_I) | | | | |
|---------->|14.R2(IPg_R,IPg_I) | | |
| |-----------+-----------+-------->|15.R2(HIT_R,HIT_I)
| | | | | | |------->|
| | | | | |
Figure 16
HIP Layer:
1.I1():
HIP Header: src: HIT I, dst: HIT R
Parameters: none
4.I1():
HIP Header: src: HIT I, dst: HIT R
Parameters: FROM : IPg R, VIA : IP RVA2
Matos, et al. Expires December 2005 [Page 39]
Internet-Draft HIP Privacy Extensions June 2005
R1():
HIP Header: src: HIT R, dst: HIT I
Parameters: PUZZLE, DIFFIE_HELLMAN, HIP_TRANSFORM, HOST_ID :
HI_R , HIP_SIGNATURE_2
I2():
HIP Header: src: HIT I, dst: HIT R
Parameters: SOLUTION, DIFFIE_HELLMAN, HIP_TRANSFORM, ENCRYPTED
{ HOST_ID : HI_I }, HMAC, HIP_SIGNATURE
R2():
HIP Header: src: HIT R, dst: HIT I
Parameters: HMAC_2, HIP_SIGNATURE
A.4 Intra-RVA Handover
When a HMN detects that it has changed AR, though, without changing
RVA protected area, it performs an intra RVA handover (see 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 RVS since the HMN remains in the
same area. It is also transparent to other RVAs because the global
assigned IP for that node does not change.
Matos, et al. Expires December 2005 [Page 40]
Internet-Draft HIP Privacy Extensions June 2005
Intra-RVA Handover
+---+ +---+ +---+ +---+
|HMN| |AR1| |AR2| |RVA|
+-+-+ +-+-+ +-+-+ +-+-+
|1.ICMP_RVA_ADV(HIT_RVA) | |
|<-----x-----| | |
| | | |
| 2.ICMP_RVA_ADV(HIT_RVA) | |3a.HMN<->AR
|<-----------+------------| | mapping
| | | | updated
| 3.UPDATE(HIT_HMN,HIT_RVA) |
|------------+------------+---------->|
| | | |
| 4.UPDATE(HIT_RVA,HIT_HMN) |
|<-----------+------------+-----------|
| | | |
| 5.UPDATE(HIT_HMN,HIT_RVA) |
|------------+------------+---------->|
| | | |
Figure 17
HIP Layer:
3.UPDATE():
HIP Header: src: HIT HMN, dst: HIT RVA
Parameters: SEQ
4.UPDATE():
HIP Header: src: HIT RVA, dst: HIT HMN
Parameters: SPI, SEQ, ACK, ECHOREQ
5.UPDATE():
HIP Header: src: HIT HMN, dst: HIT RVA
Parameters: ACK, ECHO REPLY
A.5 Inter-RVA Handover
The inter-RVA handover occurs when a HMN detects it has changed RVA
protected area after receiving a ICMP RVA Advertisement message.
This is described in Figure 18 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 Appendix A.1. Then the HMN
Matos, et al. Expires December 2005 [Page 41]
Internet-Draft HIP Privacy Extensions June 2005
performs a normal Update to the RVS and to the old RVA. A base
exchange with the new RVA is also required.
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 Appendix A.2. The RVS updates the HMN entry
according to this parameter, changing the responsible entity for the
HMN to the new announced RVA. The RVA learns the AR-HMN mapping in
step 3, and later assigns a globally routable IPv6 address to the HMN
upon completion of step 7.
Inter-RVA Handover - RVS Update
+---+ +--------+ +----+ +--------+ +----+ +---+
|HMN| |AR(RVA1)| |RVA1| |AR(RVA2)| |RVA2| |RVS|
+-+-+ +----+---+ +-+--+ +----+---+ +-+--+ +-+-+
| | | | | |
|1.ICMP_RVA_ADV(HIT_RVA1) | | |
|<----x----| | | | |
| | | | | |
| 2.ICMP_RVA_ADV(HIT_RVA2) | | |
|<---------+------------+------------| | |
| | | | | |
| -- BASE EXCHANGE (HMN <-> RVA) --- | | |
| | | | | |
| |3.UPDATE(HIT_HMN,HIT_RVS)| | |
|----------+------------+------------+--------->| |
| | | | 4.UPDATE(IP_RVA2,IP_RVS)
| | | | |------->|
| | | | 5.UPDATE(IP_RVS,IP_RVA2)
| | | | |<-------|
| |6.UPDATE(HIT_RVS,HIT_HMN)| | |
|<---------+------------+-----------------------| |
| | | | | |
| |7.UPDATE(HIT_HMN,HIT_RVS)| | |
|----------+------------+------------+--------->+ |
| | | | 8.UPDATE(IP_RVA2,IP_RVS)
| | | | |------->|
Figure 18
HIP Layer:
UPDATE():
HIP Header: src: HIT HMN, dst: HIT RVS
Parameters: RVA : HIT_RVA2, SEQ
Matos, et al. Expires December 2005 [Page 42]
Internet-Draft HIP Privacy Extensions June 2005
UPDATE():
HIP Header: src: HIT RVS, dst: HIT HMN
Parameters: SPI, SEQ, ACK, ECHOREQ
UPDATE():
HIP Header: src: HIT HMN, dst: HIT RVS
Parameters: ACK, ECHO REPLY
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 19, the old RVA needs to forward the data packets destined
to the HMN to the new RVA. When the new RVA receives the forwarded
packets, it updates the location to the HCNs RVA's.
It is possible to perform an inter-RVA handover without signalling
the RVS. This would require the RVAs to act as RVSs for every
registered HMN. This matter requires further study.
Matos, et al. Expires December 2005 [Page 43]
Internet-Draft HIP Privacy Extensions June 2005
Inter-RVA Handover - old RVA Update
+---+ +--------+ +----+ +--------+ +----+
|HMN| |AR(RVA1)| |RVA1| |AR(RVA2)| |RVA2|
+-+-+ +----+---+ +-+--+ +----+---+ +-+--+
| | | | |
|1.ICMP_RVA_ADV(HIT_RVA1) | |
|<----x----| | | |
| | | | |
| 2.ICMP_RVA_ADV(HIT_RVA2) | |
|<---------+------------+------------| |
| | | | |
| |3.UPDATE(HIT_HMN,HIT_RVA1) |
|----------+------------+------------+--------->|
| | |4.UPDATE(IP_RVA2,IP_RVA1)
| | |<-----------+----------|
| | | | |
| | |5.UPDATE(IP_RVA1,IP_RVA2)
| | |------------+--------->|
| |6.UPDATE(HIT_RVA1,HIT_HMN) |
|<---------+------------+------------+----------|
| | | | |
| |7.UPDATE(HIT_HMN,HIT_RVA1) |
|----------+------------+------------+--------->|
| | | | |
| | 8.UPDATE(IP_RVA2,IP_RVA1) 8a. old RVA
| | |<----------------------| forwards packets
to new RVA
Figure 19
HIP Layer:
UPDATE():
HIP Header: src: HIT HMN, dst: HIT RVA1
Parameters: RVA : HIT_RVA2, SEQ
UPDATE():
HIP Header: src: HIT RVA1, dst: HIT HMN
Parameters: SPI, SEQ, ACK, ECHOREQ
UPDATE():
HIP Header: src: HIT HMN, dst: HIT RVA1
Parameters: ACK, ECHO REPLY
Matos, et al. Expires December 2005 [Page 44]
Internet-Draft HIP Privacy Extensions June 2005
A.6 RVA to RVA Update
HCN's RVA update after handover
+----+ +-------+ +-------+ +----+ +----+
|HMN1| |RVA_new| |RVA_old| |RVA1| |HMN2|
+-+--+ +---+---+ +---+---+ +--+-+ +-+--+
| | | 1.DATA(HIT_HMN2,HIT_HMN1)
| | | |---------|
| | | 2.DATA(IPg HMN2,IPg HMN1)
| | |<-----------+ |
| | 3.DATA(IP_RVA_old,IP_RVA_new) |
| |<-------------| | |
| 4.DATA(HIT_HMN2,HIT_HMN1) | | |
|<-------------| | | |
| | 5.UPDATE(IP_RVA_new,IP_RVA1) |
| |--------------+----------->| |
| | | | |
| | 6.UPDATE(IP_RVA1,IP_RVA_new) |
| |<-------------+------------| |
| | | | |
| | 7.UPDATE(IP_RVA_new,IP_RVA1) |
| |--------------+----------->| |
| | | | |
Figure 20
HIP Layer:
UPDATE():
HIP Header: src: HIT_RVA_new, dst: HIT_RVA1
Parameters: LOC : IPg HMN1, FROM_ID : HIT_HMN1, SEQ
UPDATE():
HIP Header: src: HIT RVA1, dst: HIT HMN
Parameters: SPI, SEQ, ACK, ECHOREQ
UPDATE():
HIP Header: src: HIT HMN, dst: HIT RVA1
Parameters: ACK, ECHO REPLY
A.7 Packet Forwarding
The IPv6 packet forwarding at the RVAs imply the same mechanisms used
Matos, et al. Expires December 2005 [Page 45]
Internet-Draft HIP Privacy Extensions June 2005
for base exchange and update packets. The IP header of data packets
coming from the outside network (in Figure 21 steps 2, 3 and 5, 6)
are translated from IPs to HITs according to the mappings learned on
the base exchange explained in Appendix A.3. In the opposite
direction, from a RVA protected area to the outside network, the IP
header is translated from HITs to the global IPs (steps 1, 2 and 5,
6).
Packet Forwarding
+---+ +---+ +---+ +---+
| I | |RVA| | |RVA| | R |
+---+ +-+-+ +-+-+ +-+-+
| | | | |
1.DATA(HIT I,HIT R) | |
|---------->|2.DATA(IPg I,IPg R) | |
| |------------------------>|3.DATA(HIT I,HIT R)
| | | |------->|
| | |4.DATA(HIT R,HIT I)
| | 5.DATA(IPg R,IPg I) |<-------|
| |<------------------------| |
6.DATA(HIT R,HIT I) | | |
|<----------| | |
| | | | |
Figure 21
Matos, et al. Expires December 2005 [Page 46]
Internet-Draft HIP Privacy Extensions June 2005
Appendix B. Mobile Node Operation
The HMN MUST perform the initial registration with the RVS and
movement detection, based on the advers system. Distinguishing
between intra and inter RVA movement is required, to perform
different update procedures, to the RVA and to the RVS, respectively.
B.1 Packet Processing
B.1.1 Processing Beacons
When the HMN receives a ICMP RVA Advertisement message Section 6.1 it
MUST check if it had a previous connection to an AR. If no
connection previously existed it MUST trigger a HIP base exchange
with its RVS described in Appendix B.1.2 . If the HMN already has a
connection it MUST perform movement detection as described in
Appendix B.1.3 .If the node detects that the source address and RVA
parameter is the same as previously received it SHOULD update the
lifetime of the association with the AR.
B.1.2 Base Exchange
The Base Exchange defined in [I-D.ietf-hip-base] is extended. In
packet I2 the RVA option has to be included. The RVA option
announces the RVA responsible by the registering HMN in the RVS.
B.1.3 Movement Detection
The HMN performs movement detection based on ICMP RVA Advertisement
messages (see Section 6.1) it receives. If the source HIT of the
beacon message differs from the previous message but the RVA option
announces the same RVA then the HMN has moved to a different AR in
the same zone. This event triggers an Intra-RVA handover defined in
Appendix B.1.4 .If the source HIT and the RVA option are both
different then the HMN has moved to a different AR under a new RVA,
which triggers and Inter-RVA Handover defined in Appendix B.1.5 .
B.1.4 Intra-RVA Handover
An Intra RVA handover consists of an Update to the RVA responsible
for the HMN. This update can be done according to the Update defined
in [I-D.ietf-hip-rvs] .
B.1.5 Inter-RVA Handover
An Inter RVA handover consists of an Update to the RVS as defined in
[I-D.ietf-hip-rvs] but with the inclusion of a RVA option in the
Update message. This signals the RVS of HMN responsibility change to
Matos, et al. Expires December 2005 [Page 47]
Internet-Draft HIP Privacy Extensions June 2005
the announced RVA.
Matos, et al. Expires December 2005 [Page 48]
Internet-Draft HIP Privacy Extensions June 2005
Appendix C. Access Router Operation
The AR should learn by undefined static means its designated RVA and
announce it to the HMN using ICMP RVA Advertisement messages (see
Section 6.1). The HIT of the AR MUST be in the source of an ICMP RVA
Advertisement, and MUST also contain an RVA Option announcing the
zone responsible RVA.
Paging scenarios may be defined if the AR and the RVA share a query/
response mechanism. With query and response messages the HMN can be
allowed to enter a dormant state be paged when needed.
C.1 Packet Processing
The AR MUST forward packets based on the HIT contained in the
destination field of the IPv6 header, from and to the HMN's that are
associated with the AR.
Matos, et al. Expires December 2005 [Page 49]
Internet-Draft HIP Privacy Extensions June 2005
Appendix D. Rendezvous Agent Operation
D.1 Packet Processing
D.1.1 Base Exchange with the RVS
I1
The RVA MUST upon reception of an I1 packet verify if the node is
already registered. If not, assume that this is a Base Exchange with
a RVS, so the RVA must create an entry in the neighbor table for the
sender of the I1 packet to forward packets correctly. It must also
replace the HIT existing on source field in the IPv6 Header by it's
on IPv6 address if assumed to be a BE with an RVS. If the HMN is
registered then replace the source address with the HMN's IPv6
address.
NOTE: THE RVA MUST CREATE BINDINGS FOR ALL INCOMING HIT/IPv6 MAPPING,
IF NOT, THE INITIATOR HOST BECOMES UN-MAPPABLE
R1
Upon reception of an R1 packet the
The R1 packet is from the RVS, so we do not know the HI of the HMN,
so how do we verify the packets?
I2
R2
D.1.2 Intra-RVA Handover
In case that a handover occurs under the same RVA (between AR's) the
MN will send update messages to the RVA. The RVA then updates the
binding between HIT of MN and AR.
D.1.3 Inter-RVA Handover
The previous RVA (PRVA) will simply let the HIT entry expire. The
new RVA (NRVA) will track the update messages sent to the RVS and
assign a globally routable IP upon successful completion of the
update process between MN and RVS.
D.1.4 Packet Forwarding
Post inter-RVA movement is the most important case to describe, the
others are straightforward.
Matos, et al. Expires December 2005 [Page 50]
Internet-Draft HIP Privacy Extensions June 2005
Appendix E. Rendezvous Server Operation
E.1 Packet Processing
E.1.1 Base Exchange
The RVS must handle the base exchange as described in [I-D.ietf-hip-
rvs] and must parse the RVA Option in the I2 packet from the HMN.
The RVS must then create the mapping of the registering HIT to the
announced RVA in the RVA option. From the base exchange the RVS
should create the mapping between the RVA HIT and the IPv6 address
present in the Base Exchange packets received. This is done because
if the HMN is registering with the RVA option then it is behind an
RVA and therefore the source IPv6 address present in the I1 and I2
packets must be the one of the RVA.
E.1.2 Inter-RVA Handover
The update packets also contain the RVA option Section 6.2, which
means the HMN updates his position with another RVA HIT. The RVS can
again automatically create the entry of the RVA IPv6 address in the
same manner described in Appendix E.1.1 .
E.1.3 I1 Packet Forwarding
When the RVS receives a I1 packet for one of it's registered HMN it
must perform a two step translation. This is because the RVS should
translate the HIT of the Responder into the HIT of the RVA, and later
translate the HIT of RVA into the address of the RVA. This two step
conversion must be done transparently to the Initiator of the HIP
base exchange.
Matos, et al. Expires December 2005 [Page 51]
Internet-Draft HIP Privacy Extensions 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 procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Matos, et al. Expires December 2005 [Page 52]
| PAFTECH AB 2003-2026 | 2026-04-24 10:25:54 |