Network Working Group J. Melen Internet-Draft J. Ylitalo Expires: September 29, 2008 P. Salmela Ericsson Research NomadicLab March 28, 2008 Host Identity Protocol based Mobile Router (HIPMR) draft-melen-hip-mr-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 September 29, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Melen, et al. Expires September 29, 2008 [Page 1] Internet-Draft HIPMR March 2008 Abstract This drafts defines a moving network support for HIP enabled hosts. The protocol uses asymmetric authentication and symmetric authorization. The solution presented in this draft is based on delegation of signalling rights between mobile nodes and mobile routers that results in route optimization between end-hosts. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background: Alternative Moving Network Approaches . . . . . . 4 3. Basic concept . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Pre-Movement Phase . . . . . . . . . . . . . . . . . . . . 5 3.2. Node Movement Phase . . . . . . . . . . . . . . . . . . . 5 3.3. Delegation Phase . . . . . . . . . . . . . . . . . . . . . 6 3.4. Network Movement Phase . . . . . . . . . . . . . . . . . . 6 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 4.1. Mobile Router Discovery . . . . . . . . . . . . . . . . . 8 4.2. HIP base/update exchange between the MN and its peers . . 8 4.3. Mobile Node Authorizes a Mobile Router . . . . . . . . . . 8 4.4. MR runs update exhchange with the peer nodes . . . . . . . 10 4.5. Leaving a Moving Network; Revoking tickets . . . . . . . . 11 4.6. Kerberos vs. Ticket based Delegation of Signalling Rights . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Using the keying material . . . . . . . . . . . . . . . . 12 5. Packet processing . . . . . . . . . . . . . . . . . . . . . . 14 5.1. End-to-end Base Exchange . . . . . . . . . . . . . . . . . 16 5.2. End-to-end update exchange . . . . . . . . . . . . . . . . 18 6. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. Future work . . . . . . . . . . . . . . . . . . . . . 25 A.1. Static Signalling Proxies in the Fixed Network . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Melen, et al. Expires September 29, 2008 [Page 2] Internet-Draft HIPMR March 2008 1. Introduction Trains, busses, airplanes and Personal Area Networks (PANs) are examples of where different moving network technologies can be applied. In general, a moving network is a cluster consisting of mobile nodes (MNs) and mobile routers (MRs). A mobile router connects the moving network to the Internet or other larger network. When the mobile nodes are moved along the moving network, they change their topological location together with the mobile router. On the other hand, when they move independently, they change their topological location independent of the mobile router. This draft describes a HIP [I-D.ietf-hip-base] based moving network solution that is based on public-key based authentication and symmetric key based authorization. The presented authorization system is architecturally similar to the well know Kerberos [RFC4120] system, but differs in many details and in the area of application. The network mobility operations can be considered to consists of subsequent phases. Initially, a mobile node and a peer node create security association and a session key during end-to-end HIP base exchange. The session key is used to protect the location update messages. Once the mobile node attaches to mobile router, it creates a security association with the mobile router using the HIP base exchange [I-D.ietf-hip-base] with registration extension [I-D.ietf-hip-registration]. The mobile node generates a new HMAC session key and sends it to the mobile router using the protected channel created during the mobile router attachment phase. This key is generated with the specific purpose of allowing the mobile router to use it to represent movements on the behalf of the mobile node. In the nested moving network case, the mobile router may attach to and run registration exchange with another mobile router. Once the two mobile routers has security association between them, the session key can be send over the protected channel to the new mobile router. As a result of a mobile router hand-off, the mobile router sends an update message to the peer node. The mobile router uses the given new HMAC session key to protect the update messages that it sends to the peer nodes on behalf of the mobile node. The peer node verifies received update messages using the new HMAC key and the initially generated session key. The lifetime of the session key is send in the ticket. The security is based on that the new HMAC session key is given only to trustworthy mobile routers. The lifetime of the session key and the revoke mechanism also protects the mobile node from the misuse of the given tickets. Melen, et al. Expires September 29, 2008 [Page 3] Internet-Draft HIPMR March 2008 2. Background: Alternative Moving Network Approaches In general, there seems to be three fundamentally different approaches to network mobility: Approach-1: A simplistic approach is to forget that there is a moving network and consider the moving nodes as separate mobile nodes. Each of the mobile nodes takes care of mobility signalling separately. The problem with this approach is that it leads to high amounts of signalling and long hand-off reaction times. Approach-2: A tunnelling approach is to create a tunnel from the Mobile Router in the mobile network to some home router in the fixed network side. All traffic is routed through this tunnel, making the mobile network to appear at a fixed location. The problems with this approach are suboptimal routing (so called triangular routing) and the larger packet size caused by tunnelling overhead. Approach-3: A third approach is to make the mobile nodes to delegate the right to do mobility signalling to the mobility router, which under certain conditions may delegate this right further into some node in the fixed network side. This draft presents a variant of this approach. Melen, et al. Expires September 29, 2008 [Page 4] Internet-Draft HIPMR March 2008 3. Basic concept The basic idea of the solution presented in this draft is to represent delegation of signalling rights using symmetric keys and HMAC based computation. This is made possibly by utilizing existing security associations between the MN and its peers, and by creating new symmetric keys in a Kerberos [RFC4120]-like fashion. The delegation of the signalling rights is based on two trust relationships: 1) Trust relationship between a mobile node and a peer node and 2) Trust relationship between a mobile node and a mobile router. Typical operations can be considered to consist of four phases: o Pre-movement phase, where the MN creates HIP associations with any number of its peers. o Node movement phase, where the MN moves to a location that is behind a MR and finds the MR. o Delegation phase, where the MN creates new keys and passes them both to the MR and its peers. o Network movement phase, where the MR changes its location and informs all the peers of all of the MNs about the movement. 3.1. Pre-Movement Phase As typically in any setting using HIP [I-D.ietf-hip-base], this draft is based on an assumption that the MN and its peer nodes create pieces common keying material using Diffie-Hellman method during the HIP base exchange. This keying material is known only by the two hosts participating to its creation. Keys drawn from the keying material are used to protect the HIP signalling (e.g. location update messages) [I-D.ietf-hip-mm] and data transmission between the nodes. 3.2. Node Movement Phase When the MN moves behind a mobile router it will get information about available mobile routers by monitoring incoming beacons that the mobile routers use to advertise themselves. Once a suitable router is found, the MN initiates a HIP base exchange with the mobile router, and using the HIP registration extension [I-D.ietf-hip-registration], the MN registers itself as a user of the mobile routing service, provided by the mobile router. The mobile sends runs update exchange with the peer nodes to updates its HIP association. The mobile router transparently establishes a Melen, et al. Expires September 29, 2008 [Page 5] Internet-Draft HIPMR March 2008 SPINAT state per each end-to-end HIP session by intercepting the end- the-end update exchange messages and forwarding them between end- points. 3.3. Delegation Phase The task of the mobile router is to act as a signalling proxy and SPINAT node between the MN and its peer nodes. With this arrangement, the amount of signalling is minimized when the mobile router changes its location and location updates are sent to active peer nodes. To be able to send HIP location update messages on behalf of the mobile nodes inside the mobile network the mobile router needs a so called HMAC key from the MN. Knowing the mobile node's HMAC key the mobile router can create HMAC protected messages on the behalf of the MN, thereby being able to represent it by means of symmetric cryptography. To avoid aliasing and replay problems, the mobile node needs to create a new HMAC key, for each of its peers, each time it wants to use mobile routing service. The MN selects a new key for this purpose from the keying material that it already has with its peer, and prepares a ticket to be sent to the mobile router over the negotiated ESP Security Association. The ticket contains the following information: o The new HMAC key to be used by the mobile router to calculate the HMAC protected messages on the MN's behalf. o Authentication information, which contains the same new HMAC key (or key index information that the peer can use to get the same key from its own keying material), integrity protected and optionally encrypted with the HIP session key(s) that were initially negotiated between the MN and its peer. The mobile router cannot decrypt or modify this part of the message without the peer noticing it. 3.4. Network Movement Phase When the mobile router changes its location, it creates location update packets that look as if it were created by the mobile nodes behind the mobile router. Each location update contains the MN's HIT as the source HIT and includes location update information as if it was sent by the MN itself. To authenticate the packet, the Mobile Router inserts a new parameter into the packet. The new parameter contains 1) the unmodified authentication information from the ticket it received from the MN, and 2) an HMAC calculated using the new HMAC key received from the MN. This packet is delivered to the peer node. The peer can verify the authentication information part of the packet Melen, et al. Expires September 29, 2008 [Page 6] Internet-Draft HIPMR March 2008 and get the HMAC key. Using this key, it can verify that the incoming update packet was sent by a node authorized by the Mobile Node. If the mobile router moves behind another mobile router (nested mobile routers), it can deliver received tickets to the new mobile router which in turn is capable of making location updates to peer nodes based on the information received in these tickets. Because there is no association between the peer and the mobile router, there is no need to provide any additional information about the previous mobile router and the same ticket can be used by the new mobile router for location updates. If the MN moves out of the mobile network, it needs to revoke the old keys. It sends an update message to the peer containing information about the keys that are no longer valid. After receiving this information the peer node doesn't accept any new location updates with that key. Melen, et al. Expires September 29, 2008 [Page 7] Internet-Draft HIPMR March 2008 4. Protocol Description The mobile router consists of two integrated services that are signalling proxy and a SPINAT services. The signalling proxy and SPINAT services are presented in separate drafts. This draft defines the signalling proxy service and defines some extensions to the HIP base and update exchanges. The signalling proxy service is used to establish, update and create SPINAT states for ESP packets. The SPINAT service is presented in [I-D.melen-spinat]. 4.1. Mobile Router Discovery The mobile node must discover the mobile router. For this purpose, the HIP base exchange, combined with the registration extension [I-D.ietf-hip-registration], can be used for the service registration procedure like presented in draft [I-D.jokela-hip-service-discovery]. The mobile node requests a mobile routing service from the mobile router using the registration extension. 4.2. HIP base/update exchange between the MN and its peers Either before or after the valid registration exchange, the mobile node runs a HIP base-exchange or an update exchange with its peer node as desribed in [I-D.ietf-hip-base]. Typically, the base exchange is used with new peers and updates are used with existing peers. As a result of the base exchange, the mobile node and its peers posses mutual, secret keying material that is used to generate various keys, including those used protect the HIP mobility management messages. the end-to-end HIP base/update exchange creates a SPINAT state at the mobile router (see draft xxx). 4.3. Mobile Node Authorizes a Mobile Router With the mutual keying material available with its peers, the mobile node creates tickets (Figure 1), one for each of its active peers, for the mobile router to signal on behalf of it. A ticket contains the end-to-end session key, for HMAC integrity protection calculation, generated by the mobile node and to be generated or received by the peer node. This new HMAC session key is later used to protect the mobility management messages that the mobile router sends to the peer node on behalf of the mobile node. In addition to the new HMAC key, the mobile node includes other relevant information in the ticket, like lifetime and what type of authorization this is. This information is protected using HMAC with the HIP session key agreed between the mobile node and the peer, and Melen, et al. Expires September 29, 2008 [Page 8] Internet-Draft HIPMR March 2008 it may be encrypted. The mobile router doesn't have the HIP session key between the MN and its peer, and therefore the mobile router cannot modify (or decrypt) the part of the ticket that is protected with end-to-end keying material. The ticket has to contain, at least, either the same HMAC key that is given to the mobile router or a pointer to the place in the shared keying material from where the key was drawn so that the peer can draw the same key. In addition to the key information, the integrity protected part of the ticket can contain also other information if needed. Encrypted { HI-MN; HI-PEER; HI-issuer; HI-subject; HMAC-key; HMAC { HMAC-key-index; Action; Lifetime; } Key-MN-PEER } Key-issuer-subject Figure 1: Signalling proxy Ticket information Figure 1 shows the ticket that is sent either from the MN (issuer) to the MR (subject), or in case of nested mobile routers, from MR1 (issuer) to MR2 (subject). The key Key-MN-PEER is only known by the MN and the peer. It is used to protect the integrity of the authentication information from modifications. If, instead of the HMAC-key-index, the whole HMAC-key is included in the authentication information, the HMAC-key there must be encrypted with the key known only by the MN and the peer. It is good to notice that the mobile node cannot deny the mobile router the permission to give the tickets further to other mobile routers, as it cannot prevent the mobile router from distributing the new HMAC-key to other nodes. { HI-MN; HI-PEER; HMAC { HMAC-key-index; Action; Lifetime; } Key-MN-PEER } Figure 2: Authentication ticket (Extracted from signalling proxy Melen, et al. Expires September 29, 2008 [Page 9] Internet-Draft HIPMR March 2008 ticket) Figure 2 shows the authentication information, as extracted from the ticket, that is sent from the MR to the peer when the MR updates location information at the peer. 4.4. MR runs update exhchange with the peer nodes Once the mobile router changes the location, it creates location update packets to be sent to peers based on the information about the location change and the information that it had earlier received from the mobile hosts. The update packet contains the following information: o The new IP address of the mobile router. (Note: the mobile router implements the SPINAT functionality.) o The authentication information as extracted from the received ticket. o A HMAC integrity code, calculated using the new HMAC key. To avoid attacks related to the location update exchange, the peer nodes must send challenges to the mobile node's claimed location (i.e., reachability test). In practice, these challenge messages are destined to the mobile router. The mobile router on the forwarding path uses the new HMAC key to protect the reply message and sent the message back to the peer nodes on behalf of the mobile nodes. When a mobile router (MR1) moves into another mobile network, it becomes the client for the next level mobile router (MR2). The MR1 sends the tickets it has received from its own network to the next level mobile router (MR2) so that MR2 can send the location updates also on behalf of the mobile nodes behind the MR1. Because there is no association between the MR1 and the peer nodes, it doesn't need to add any own information to the ticket, but it can deliver them directly to the MR2. The MR2 gets all needed information from the tickets. Long ticket lifetimes let the mobile router to signal on behalf of the mobile node after the node has moved away from the mobile router's link. Therefore, the lifetime of ticket is the estimated locator lifetime at the mobile node's current location. The mobile node generates a new ticket if it stays longer in the same link than it initially expected. The mobile node stores also a ticket revocation list. The list consists of hashes of active tickets that were sent to the previous mobile routers. After the mobile node Melen, et al. Expires September 29, 2008 [Page 10] Internet-Draft HIPMR March 2008 leaves a moving network, it informs its active peers about the revoked tickets using an enhanced location update exchange. 4.5. Leaving a Moving Network; Revoking tickets Once a mobile node leaves a moving network it should revoke the ticket both at the peer and at the mobile routers. The revoke mechanism for tickets will be added for the draft version -01. The rough idea is following. The revoke messahe must be sent to the peer nodes and should be sent to the rendezvous of the mobile router. The mobile node reveices the rendezvous locator of the mobile router during the registration exchange. 4.6. Kerberos vs. Ticket based Delegation of Signalling Rights The signalling trust between the HIP enabled nodes is purely based on the secret session key material that is generated during the initial authenticated Diffie-Hellman (DH) key exchanges, i.e., the HIP base- exchanges. The generated session keying material is used to derive new keys, which in turn are used to authenticate the proxied update messages. There is a clear analogy between this approach and the existing, well known Kerberos [RFC4120] system. The mobile node acts like a Kerberos-KDC, the mobile router works as a Kerberos-client, and the peer node represents the Kerberos-service. However, there are also differences due to which the legacy Kerberos system cannot be used as such in this draft. In Figure 3, the based relation to the Kerberos model is illustrated. In the case of nested mobile routers, the Mobile Router 1 would become a KDC and the Mobile Router 2 would become the client, when the MR1 moves behind the MR2. "Kerberos: client" +--------+ +--------+ | MR1 | | MR2 | +--------+ +--------+ ^ "Kerberos: KDC" | "Kerberos: peer" +--------+<-(SA)-+ +--------+ | MN |<--Security Association (SA)----->| Peer | +--------+ +--------+ Figure 3: Relationship to Kerberos model Melen, et al. Expires September 29, 2008 [Page 11] Internet-Draft HIPMR March 2008 The difference between Kerberos and the solution presented in this draft is that this draft relies only on the session keys, not on the identifiers. In Kerberos, the ticket contains an encrypted identifier of the principal that is allowed to access the service. That encryption key is known only by the KDC and the service. In the nested moving network case this causes scalability problems. As earlier described, each nested mobile router acts as a client for the next mobile router higher in the group hierarchy. Once the nested mobile router approves a ticket to the other mobile router it also becomes a KDC itself. However, the mobile router (middle-box) does not have a security association with the peer node. As a result, the nested mobile router (i.e. KDC) cannot encrypt the identifier of the other mobile router to the ticket. To overcome the problem, this solution approves only anonymous tickets. In other words, the host (principal) that knows ("owns") the secret session key, is allowed to signal on behalf of the mobile node. Each mobile node (/nested mobile router) authenticates mobile router in the architecture with the HIP base-exchange. Thus, the mobile node (/nested mobile router) does not approve a ticket to the mobile router if the authentication fails. The situation with the ticket based delegation scheme is partially similar to the public key based delegation scheme. Once using SPKI [RFC2693] authorization certificates the issuer of the certificate can only limit the length of the authorization chain. The issuer cannot know how the principals in the chain act. In other words, the mobile node trusts the link local mobile router to delegate the signalling rights to another trustworthy mobile router. The same kind of trust chain applies also to the ticket based authorization scheme. Instead of expressing the trust with certificates this solution uses symmetric key based tickets to authorize nodes in the architecture. This solutions uses asymmetric cryptography to authenticate client to the KDC and symmetric cryptography to authorize the client. 4.7. Using the keying material When the mobile host performs a HIP base exchange with the peer node, they generate keying material using Diffie-Hellman method. From this keying material (same for both hosts) they can retrieve keys sequentially for HIP (encryption and authentication) as well as ESP (encryption and authentication). During a session, hosts can re-key the ESP association during which new keys for the ESP Security Association are drawn from the keying material. HIP association keys remain the same during the whole session. This solution uses the same keying material for drawing keys for the Melen, et al. Expires September 29, 2008 [Page 12] Internet-Draft HIPMR March 2008 HMAC protected update messages from the mobile router to the peer node. In normal case, the MN uses the HIP authentication key for calculating the HMAC in update message. Because of the requirement that the MN must be able to revocate the key that is sent to the MR, the originally drawn HIP authentication key cannot be used. Thus, a new key is retrieved from the keying material and sent to the mobile router. To be able to keep the mobile node's and peer node's keying material pointers synchronized, the index value has to be transmitted between the nodes. This is done in the authentication information that the mobile node sends to the mobile router, which in turn delivers it to the peer unmodified in location update messages. The peer node can decrypt the received authentication information, if all delegation information is properly delivered earlier, and it can trust that the mobile router is acting on behalf of the correct mobile node. Melen, et al. Expires September 29, 2008 [Page 13] Internet-Draft HIPMR March 2008 5. Packet processing The following flow chart (Figure 4) illustrates the delegation of signalling rights using tickets: +--------+ +--------+ | MN | | Peer | +--------+ +--------+ | 1. base-exchange: generate session key | |<------------------------------------------------------>| | | | +--------+ | | | MR1 | | (hand-off) +--------+ | |2. registration exchange + ticket | |<---------------->| | |3. update exchange | |<------------------------------------------------------>| | |4. ticket exchange | | |<----------------------------------->| | (hand-off) | |5. hand-off NOTIFY | |<-----------------| | | |6. update exchange + peer ticket | | |<----------------------------------->| | | +--------+ | | | | MR2 | | | (hand-off) +--------+ | |7. hand-off NOTIFY | | |<-----------------| | | | |8. registration exchange + ticket | | |<------------------>| | | |9. update exchange + peer ticket | | |<----------------------------------->| | | |10. ticket exchange | | |<-------------->| | | (hand-off) | |12. |11. hand-off NOTIFY | |<-----------------|<-------------------| | | | |13. update exchange | | | + peer ticket| | | |<-------------->| | | | | Figure 4: Flow chart Melen, et al. Expires September 29, 2008 [Page 14] Internet-Draft HIPMR March 2008 Step-1 The mobile node and the peer node run base-exchange and generate keying material from where session keys are drawn. Later on, new keys are drawn from the material to be given to the mobile router and to be used to protect the update messages with HMAC. Step-2 The mobile node makes hand-off and moves behind a mobile router (MR1). It runs registration exchange with the mobile router and request a mobile router service from the mobile router. The mobile node uses the established security association between it and the mobile router to encrypt a ticket. The mobile hosts approves the ticket to the mobile router. The ticket allows the mobile router to send update messages to the peer node. The ticket also contains authorization right information and lifetime that is HMAC protected using the security association between mobile node and the peer node. This end-to-end encryption keying material is not sent to the mobile router, and it is only known by the end-hosts. During the registration exchange the mobile node also receives the locators leased from the mobile router's rendezvous node. (Note: once the mobile node leaves the moving network, it revokes the ticket from the mobile router.) Step-3 The mobile node runs update exchange with the peer node in parallel with the registration exchange. The update exchange creates a SPINAT state for the end-to-end ESP traffic at the mobile router. Step-4 The mobile router (MR1) runs 1-round-trip ticket exchange with the peer node. The exchange contains ticket received in step-2. In addition to the ticket, the MR1 sends HMAC protected LOCATOR and ESP_INFO TLVs to the peer node. The HMAC is computed using the key received in the ticket. Step-5 The mobile router (MR1) makes a hand-off and sends a hand-off notification message to the link local multi-cast/broadcast address at the private link. The mobile node does not send acknowledgement back to mobile router, because it causes extra load for the mobile router during hand-off. If the notification message doesn't reach the mobile node, it is better to let mobile router run update exchnage in step-5, instead of slowing down the hand-off procedure. The notification message may be used at the mobile node to inform layers above IP layer about hand-off. In addition, the notify message contains the public locator of the mobile router. Step-6 The mobile router runs (in parallel with step-5) an update exchange with the peer node on behalf of the mobile node. It informs the peer node that the mobile node has changed its location. The mobile router presents the authorization Melen, et al. Expires September 29, 2008 [Page 15] Internet-Draft HIPMR March 2008 information to the peer node using the ticket. The peer node uses the key information in the ticket to get a correct HMAC key from the keying material to verify the received update message. (NOTE: it is possible that the MN sent the HMAC key to the MR also encrypted with a key that is known only by the peer, in which case the MR sends this to the peer which can decrypt it and get the HMAC key from that). The mobile router also updates its SPINAT state. Step-7 See step-5. Step-8 The mobile router (MR1) attaches to another mobile router (MR2). The situation is also called a nested mobile network case. MR1 registers to the MR2 and gives the ticket to the MR2. The session key is encrypted using the security association between MR1 and MR2. The ticket contains also the encrypted end-to-end part that cannot be decrypted by the mobile routers or other intermediate nodes. Step-9 The same as step-6. Step-10 The same as step-4. Step-11 See step-5. Step-12 Once a mobile router receives a hand-off notification message from the upper link it signs the messsage with its own HI and multicasts the same message in its own private link (see step-4). Step-13 The MR2 sends location update on behalf of the mobile node to the peer node. The update message contains also the ticket given in step-7. The peer node trusts that the update message comes from an authentic sender, because the message was protected with the correct HMAC, and the lifetime of the ticket is valid. 5.1. End-to-end Base Exchange The mobile router establishes a state during the end-to-end base exchange between mobile host and peer hosts. This is illustrated in Figure 5. Melen, et al. Expires September 29, 2008 [Page 16] Internet-Draft HIPMR March 2008 +--------+ +--------+ +--------+ | MN | | MR | | Peer | +--------+ +--------+ +--------+ | | | | registration exchange | |<---------------->| | | base/update exc. + SIGNED(locator TLV + ESP-INFO TVL) | |<------------------------------------------------------>| | | ticket exchange + | | HMAC(locator TLV + ESP-INFO TVL) | | |<----------------------------------->| | | | Figure 5: End-to-end base exchange through mobile router the mobile host receives the rendezvous locator of the peer host from the DNS and sends the I1 message to that location. The mobile router establishes a soft state for the HIT-pair before forwarding the I1 message to the rendezvous node ([I-D.ietf-hip-rvs]). It also translates the private source locator to the public multiplexed locator of the mobile router. The mobile router adds its self-signed locator set information to the end of the I1 message before forwarding the I1 message. In addition, the mobile router adds an encrypted 'echo request' parameter to the I1 message that is echoed back by the peer host in R1 message. The I1 message may be forwarded via the rendezvous node to the peer host. After receiving the I1 message, the peer host replies with the R1 message. The peer host adds its locator set to the R1 message according to [I-D.ietf-hip-mm]. the peer host uses one of the received mobile router's locators. The packet is sent directly, i.e. using optimized routing, to one of the mobile router's locators. Once the mobile router receives the R1 message it marks the initial destination locator (used in I1) as verified. The peer host was reachable behind the initial locator. The mobile router also verifies that the received 'echo reply' parameter contains the same secret that was included in the I1 message. The mobile router stores the received locator set of the peer host. The mobile router translates the locators according to [I-D.melen-spinat]. The mobile router translates the source locator to point to the destinaton locator of the earlier I1 message before forwarding the R1 message to the mobile host. In other words, the source locator is translated to the same locator as to where the I1 message was sent, and the destination locator is translated to the private locator of the mobile host. After receiving the R1 message, the mobile host sends back I2 message Melen, et al. Expires September 29, 2008 [Page 17] Internet-Draft HIPMR March 2008 to the rendezvous locator of the peer host. The mobile router node does not forward the packet to the rendezvous node but reselects a locator-pair between its public locator set and the earlier stored peer host's locator set. (Note: Only the I1 message may be routed via the rendezvous node and the rest of the messages of the base exchange are sent directly between the mobile router and the peer host.) In addition, the mobile router adds its signed LOCATOR TLV and ESP_INFO TLV to the I2 message. The ESP_INFO TLV contains the translated SPI values. After receiving the I2 message the peer host creates a state for the mobile host. From the peer host's point of view, the mobile host is reachable at the mobile router's locator. The peer host replies with an R2 message. The mobile router marks the destination locator of the earlier sent I2 message as verified. Before forwarding the R2 message to mobile host, the mobile router node do the same locators translation that took place with the R1 message. The soft state is also changed to hard state and IPsec SAs are created at the mobile router (see xxxdraftspinat) 5.2. End-to-end update exchange The mobile host runs the base exchange with the peer host only once. After that the mobile host updates its location to the peer host by running an update exchange. This is illustrated in Figure 5. From the moible router viewpoint, the state establishment using the update exchange differs from the base exchange case. The update exchange is only a three way hand shake, while the base exchange consists of four messages. (Note: The peer host must add it locator set to the intial R1 message in the base exchange.) The end-to-end update exchange is used both for updating a state at the peer host and for creating states at the mobile routers. The signed _peer_ host's locator set and the ticket are added to the first update message. Once the mobile router receives the update message, it creates a soft state. The mobile router selects a locator pair between the peer's and mobile router's locator sets. The mobile router also adds its own signed LOCATOR TLV and ESP_INFO TLV to the update message before forwarding the message to the peer host. The ESP_INFO TLV contains the translated SPI values. In addition, the mobile router caches the first update message to be able to retransmit the message later. The peer host replies with the update (challenge) message and sends it directly to the mobile router. The peer host should use one of the locators of the LOCATOR TLV included in the first update message. The mobile router verifies that the source locator in the update (challenge) message sent by the peer host belongs to the locator set Melen, et al. Expires September 29, 2008 [Page 18] Internet-Draft HIPMR March 2008 that was carried in the first update message. In addition, the mobile router compares locators in the earlier cached message and the received challenge message. If the destination locator in the cached packet and the source locator in the challenge packet differ from each other the packet has been routed via a rendezvous node. In that case, the mobile router cannot directly start using the received source locator with the peer host. Instead, the mobile router node silently drops the received challenge message and retransmits the cached update message to the source locator of challenge message and adds 'echo request' parameter to the message. In other words, the mobile router uses the first round trip of the update exchange as a reachability test. If the peer host was reachable from its claimed location, the mobile router receives the challenge message from the peer host containing correct 'echo reply' parameter. The mobile router node marks the peer host's location verified and forwards the packet to the mobile host. The mobile host finalizes the update exchange by sending the last update message to the peer host. The mobile router uses the already verified destination locator towards the peer host. Melen, et al. Expires September 29, 2008 [Page 19] Internet-Draft HIPMR March 2008 6. Payload Format TBA for version -01. Melen, et al. Expires September 29, 2008 [Page 20] Internet-Draft HIPMR March 2008 7. Security Considerations This draft defines an authorization and delegation mechanism that is used for delegating update exchange rights between mobile nodes and mobile routers. The security considerations are discussed in the protocol context throughout the draft. The authentication between nodes relies on the HIP base exchange. The security considerations of the authentication procedure can be found from the HIP based draft [I-D.ietf-hip-base]. The single-hop delegation between mobile hosts and mobile routers relies on the Kerberos [RFC4120] security model. The multi-hop delegation between mobile hosts and mobile routers relies on the SPKI [RFC2693] delegation principles with certain restrictions. Using authorization certificates it is possible to limit the length of the certificate chain. However, the delegation mechanism in this draft does not limit the length of the delegation chain. As earlier mentioned, the mobile nodes(/mobile routers) should not delegate the signalling rights to unauthenticated mobile routers. When either the mobile node or the peer does not get incoming ESP packets for a specific SA in KEEPALIVE seconds, it should revoke the ticket bound to a corresponding SPI value, initiate a new registration exchange and create a new ticket. A reason for the communication break may be a re-direction attack that is made by a malicious node. This requires that the malicious node has obtained the session key in the ticket due to opportunistic HIP authentication [I-D.ietf-hip-base]. Melen, et al. Expires September 29, 2008 [Page 21] Internet-Draft HIPMR March 2008 8. IANA Considerations Melen, et al. Expires September 29, 2008 [Page 22] Internet-Draft HIPMR March 2008 9. Acknowledgments A number of people have contributed to the text and ideas. The list of these people include Pekka Nikander, Petri Jokela, Raimo Vuopionpera, Yuri Ismailov, Jan Holler, Goran Selander, Goran Schultz and Jari Arkko. Our apologies to anyone whose name is missing. Melen, et al. Expires September 29, 2008 [Page 23] Internet-Draft HIPMR March 2008 10. References 10.1. Normative References [I-D.ietf-hip-base] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", draft-ietf-hip-base-10 (work in progress), October 2007. [I-D.ietf-hip-mm] Henderson, T., "End-Host Mobility and Multihoming with the Host Identity Protocol", draft-ietf-hip-mm-05 (work in progress), March 2007. [I-D.ietf-hip-registration] Laganier, J., "Host Identity Protocol (HIP) Registration Extension", draft-ietf-hip-registration-02 (work in progress), June 2006. 10.2. Informative References [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999. [I-D.ietf-hip-rvs] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) Rendezvous Extension", draft-ietf-hip-rvs-05 (work in progress), June 2006. [I-D.jokela-hip-service-discovery] Jokela, P., "HIP Service Discovery", draft-jokela-hip-service-discovery-00 (work in progress), June 2006. [I-D.melen-spinat] Melen, J., Ylitalo, J., and P. Salmela, "Security Parameter Index multiplexed Network Address Translation (SPINAT)", draft-melen-spinat-00 (work in progress), March 2008. Melen, et al. Expires September 29, 2008 [Page 24] Internet-Draft HIPMR March 2008 Appendix A. Future work A.1. Static Signalling Proxies in the Fixed Network The mobile router may also optimize the over-the-air signalling between it and the Internet. The mobile router may register its clients and delegate the signalling rights to a static signalling proxy located in the fixed network. When the mobile router makes a hand-off, it runs a single location update exchange with the static signalling proxy. The mobile router's multiplexed IP address may represent the current location of all the clients belonging to the moving network behind it. The static signalling proxy in the fixed network can use the available high bandwidth to send the burst of location updates to the peer nodes on behalf of the mobile nodes. The peer nodes send the challenge messages to the multiplexed locator of the mobile router if the signalling proxy is not on the forwarding path. The peer nodes must verify that the mobile nodes are at the location where the static signalling proxy claims them to be. Melen, et al. Expires September 29, 2008 [Page 25] Internet-Draft HIPMR March 2008 Authors' Addresses Jan Melen Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: jan.melen@nomadiclab.com Jukka Ylitalo Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: jukka.ylitalo@nomadiclab.com Patrik Salmela Ericsson Research NomadicLab JORVAS FIN-02420 FINLAND Phone: +358 9 299 1 Email: patrik.salmela@nomadiclab.com Melen, et al. Expires September 29, 2008 [Page 26] Internet-Draft HIPMR March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Melen, et al. Expires September 29, 2008 [Page 27]