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