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]