idnits 2.17.1 draft-melen-hip-mr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 917: '...e moving network SHOULD use link-local...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 26, 2009) is 5442 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5206 (Obsoleted by RFC 8046) ** Obsolete normative reference: RFC 5204 (Obsoleted by RFC 8004) ** Obsolete normative reference: RFC 5203 (Obsoleted by RFC 8003) == Outdated reference: A later version (-02) exists of draft-vogt-rrg-six-one-01 Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Melen 3 Internet-Draft J. Ylitalo 4 Intended status: Experimental P. Salmela 5 Expires: November 27, 2009 Ericsson Research NomadicLab 6 T. Henderson 7 The Boeing Company 8 May 26, 2009 10 Host Identity Protocol-based Mobile Router (HIPMR) 11 draft-melen-hip-mr-02 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 27, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This drafts defines a moving network support for HIP enabled hosts. 50 The protocol uses asymmetric authentication and symmetric 51 authorization. The solution presented in this draft is based on 52 delegation of signalling rights between mobile nodes and mobile 53 routers that results in route optimization between end-hosts. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Background and Primary Use Case . . . . . . . . . . . . . . . 4 59 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Pre-Movement Phase . . . . . . . . . . . . . . . . . . . . 8 61 3.2. Node Movement Phase . . . . . . . . . . . . . . . . . . . 8 62 3.3. Delegation Phase . . . . . . . . . . . . . . . . . . . . . 8 63 3.4. Network Movement Phase . . . . . . . . . . . . . . . . . . 9 64 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10 65 4.1. Mobile Router Discovery . . . . . . . . . . . . . . . . . 10 66 4.2. HIP base/update exchange between the MN and its peers . . 10 67 4.3. Mobile Node Authorizes a Mobile Router . . . . . . . . . . 10 68 4.4. MR runs update exchange with the peer nodes . . . . . . . 12 69 4.5. Leaving a Moving Network; Revoking tickets . . . . . . . . 13 70 4.6. Kerberos vs. Ticket based Delegation of Signalling 71 Rights . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.7. Using the keying material . . . . . . . . . . . . . . . . 15 73 5. Packet processing . . . . . . . . . . . . . . . . . . . . . . 16 74 5.1. End-to-end Base Exchange . . . . . . . . . . . . . . . . . 18 75 5.2. End-to-end update exchange . . . . . . . . . . . . . . . . 20 76 5.3. Payload Packet Processing . . . . . . . . . . . . . . . . 21 77 6. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 22 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 26 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 26 84 Appendix A. Future work . . . . . . . . . . . . . . . . . . . . . 28 85 A.1. Static Signalling Proxies in the Fixed Network . . . . . . 28 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 88 1. Introduction 90 The Host Identity Protocol (HIP) [RFC5201] has been designed to allow 91 hosts to preserve existing security associations and higher-layer 92 protocol sessions by defining host mobility and multihoming 93 mechanisms [RFC5206]. Specifically, a mobile or multihomed host that 94 changes its IP address, or acquires new addresses, can securely 95 notify its corresponding peers of the new address(es). Similarly, a 96 mobile HIP-aware host can update information about its current IP 97 address(es) by updating records in HIP Rendezvous Servers [RFC5204] 98 or other name services. 100 However, in many situations, hosts do not move independently but as 101 part of an overall mobile network. Trains, buses, airplanes and 102 Personal Area Networks (PANs) are examples of where different mobile 103 network technologies can be applied. Herein, a mobile network is 104 defined as a cluster consisting of mobile nodes (MNs) and mobile 105 routers (MRs) [RFC3753], for which the IP addresses used to reach the 106 mobile network must change due to the local topology. A mobile 107 router connects the mobile network to the Internet or other larger 108 network, and at a minimum, the IP address of the link to which the 109 mobile router connects must be consistent with local addressing. 110 When the mobile nodes are moved along with the mobile network, they 111 change their topological location together with the mobile router. 112 On the other hand, when they move independently, they change their 113 topological location independent of the mobile router. 115 This draft describes HIP protocol extensions that allow a HIP-based 116 mobile network to use the services of a HIP-aware mobile router for 117 mobility management. Specifically, the HIP-aware hosts that are 118 clients of the HIP-aware mobile router delegate to the MR the 119 authority to signal mobility-related updates on their behalf. Two 120 approaches to perform the delegation are outlined herein. One 121 authorization system is architecturally similar to the well known 122 Kerberos [RFC4120] system, but differs in many details and in the 123 area of application. The second authorization system presented is a 124 public-key-based authorization. 126 2. Background and Primary Use Case 128 In general, there seems to be three fundamentally different 129 approaches to network mobility: 131 Approach-1: A simplistic approach is to forget that there is a 132 moving network and consider the moving nodes as separate mobile 133 nodes. Each of the mobile nodes takes care of mobility signalling 134 separately. The problem with this approach is that it leads to 135 high amounts of signalling and long hand-off reaction times. This 136 approach may require the mobile router to acquire a block of new 137 addresses (one for each mobile node) rather than just a single new 138 address. 140 Approach-2: A tunnelling approach is to create a tunnel from the 141 Mobile Router in the mobile network to some home router in the 142 fixed network side. All traffic is routed through this tunnel, 143 making the mobile network appear to be at a fixed location. The 144 problems with this approach are suboptimal routing (so called 145 triangular routing) and the larger packet size caused by 146 tunnelling overhead. A possible optimization is NEMO optimization 147 (cite the approaches). 149 Approach-3: A third approach is to make the mobile nodes delegate 150 the right to do mobility signalling to the mobile router, which 151 under certain conditions may delegate this right further to 152 another router in the fixed network side. However, the mobile 153 router presents itself to the visited network as a single node, 154 and performs network address translation on behalf of the mobile 155 nodes. This draft presents a variant of this approach. 157 One possible sequence of events is as follows. Mobile nodes on a 158 mobile platform register with the mobile router, using the HIP 159 registration extension [RFC5203]. The MN may discover the MR via a 160 router advertisement or preconfiguration. The mobile nodes next 161 perform a delegation to the mobile router; this delegation will 162 authorize the mobile node to generate and process some HIP-related 163 signaling messages upon mobility events. A possible first action for 164 the mobile router may be to notify the mobile host of its reachable 165 IP address if it differs from the one assigned to it on the local 166 network segment. Another possible first action is to allow the MR to 167 update the MN's record in DNS or the rendezvous server. 169 Some time later, the mobile host or a peer may initiate a HIP base 170 exchange with a peer located outside the mobile network. Since the 171 IP address used by the MN may not correspond to the publicly 172 reachable address, the MR inserts parameters into the HIP base 173 exchange that tell each party in the session about the presence of 174 the address mapping. These parameters may be authenticated by the 175 peer by virtue of the authorization tokens delegated to the MR by the 176 MN. Additionally, the MR establishes binding state and tracks that 177 there is an active session between a MN and a peer. In particular, a 178 SPINAT [I-D.melen-spinat] state for the association must be created 179 and maintained at the MR; the SPINAT maps the MN's IP address and SPI 180 value to public values. SPINAT can be thought of NAT-PT in which the 181 port translation is replaced by SPI translation. 183 Some time later, the mobile host or the peer may rekey their security 184 association or generate new keying material. The MR may translate 185 the IP address of such messages and optionally add NAT_ESP_INFO 186 parameter to the messages (see [I-D.melen-spinat]). Otherwise, the 187 MR does not participate in any keying-related exchanges; the end-to- 188 end encryption and authentication keys used by HIP are not known to 189 the MR or any other on-path observer. 191 Next, assume that the MR changes its attachment to the network and 192 obtains a new public-facing IP address. While packets sent from a MN 193 to a peer may still successfully reach the peer, packets from a peer 194 to the MN, or any new connection attempts to the MN, will fail. In 195 this scenario, the MR will generate an update message to the peer and 196 to any name services that the MN is connected to. 198 As a result of a mobile router hand-off, the mobile router sends an 199 update message to the peer nodes for which it holds binding state. 200 The mobile router uses its authorization token to digitally sign the 201 update messages that it sends to the peer nodes on behalf of the 202 mobile node. The peer node verifies received update messages using 203 the token. The MR should also notify the MN of the change of 204 address, although it is not strictly required. 206 A few variations of this scenario are possible. In the nested moving 207 network case, the mobile router may attach to and run registration 208 exchange with another mobile router. Once the two mobile routers 209 have a security association between them, the authorization token can 210 be sent over the protected channel to the new mobile router. The 211 approach described herein admits such a possibility, but we will not 212 describe it in any further detail for now. 214 Another variation is that the MN may not be HIP aware. In this case, 215 the MR may act as a "HIP proxy" for one or more MNs in the mobile 216 network. In such a case, the MR holds the HIP key for the MN and 217 participates in the full HIP signaling and encryption without the 218 participation of the MN. We do not consider this scenario further in 219 this draft. 221 Another variation is that a MN may initially create associations with 222 peers and subsequently move behind a HIP-aware mobile router. In 223 such a case, the MR can not participate in the base exchange but must 224 participate in the UPDATE exchange. Details of this case must be 225 worked out further; in particular, the MN must be able to discover 226 and register with the MR before initiating any UPDATEs to peers. HIP 227 may need to be extended to allow a HIP MR to ask a MN to register 228 with it, before allowing the UPDATE to proceed. 230 Two authorization and authentication frameworks for delegating rights 231 to a MR are proposed herein. The first is based on a Kerberos-like 232 ticket model. Here, the ticket is issued by the MN to the MR and 233 passed to the MR during the registration base exchange. This ticket 234 may be further passed onward to an upstream MR without participation 235 by the MN; i.e., any node that acquires the ticket is then 236 authorized. The ticket contains an HMAC key that is used by the MR 237 to sign its message parameters. The ticket has a lifetime, and may 238 be revoked. The security is based on that the new HMAC session key 239 is given only to trustworthy mobile routers. The lifetime of the 240 session key and the revoke mechanism also protects the mobile node 241 from the misuse of the given tickets. The second mode is based on 242 public-key delegation using certificates. Here, the MN gives each MR 243 a certificate (with lifetime) and the MR must sign its messages with 244 the key authorized in the certificate. This approach requires 245 asymmetric public-key verification by the peer node but has a benefit 246 over the Kerberos-like approach in that the MN can enforce that the 247 MR cannot further delegate its signalling rights upstream without the 248 participation of the mobile node. 250 3. Protocol Overview 252 The basic idea of the solution presented in this draft allow mobile 253 nodes (MN) to securely delegate to mobile routers (MR) the authority 254 to notify the peers of the MN whenever the MR moves with a resulting 255 addressing change. The security is based on the MN sharing with the 256 MR a portion of its symmetric key space (derived during the HIP base 257 exchange), with which the MR can compute HMACs on the mobility update 258 messages (MR). The overall approach of security delegation resembles 259 that of Kerberos [RFC4120]. The delegation of the signalling rights 260 is based on two trust relationships: 1) Trust relationship between a 261 mobile node and a peer node and 2) Trust relationship between a 262 mobile node and a mobile router. The peer node need not have any 263 pre-existing trust relationship with the MR. 265 In one typical use case, a MN may be semi-permanently located behind 266 a MR, such as a host connected to a mobile router on a mobile 267 platform. Typical operations for this use case, which we call the 268 "MN dedicated to a MR" case, can be considered to consist of these 269 phases: 271 o Pre-movement phase, where the MN creates HIP associations through 272 the MR with any number of its peers. 274 o Delegation phase, where the MN creates new keys and passes them 275 both to the MR and its peers. 277 o Network movement phase, where the MR changes its location and 278 informs all the peers of all of the MNs about the movement. 280 Another use case is when the MN is itself mobile and moves behind an 281 existing MR even though it has already established security 282 associations beforehand. We call this case the "roaming MN" case, 283 which can can consist of these phases: 285 o Pre-movement phase, where the MN creates HIP associations with any 286 number of its peers. 288 o Node movement phase, where the MN moves to a location that is 289 behind a MR and finds the MR. 291 o Delegation phase, where the MN creates new keys and passes them 292 both to the MR and its peers. 294 o Network movement phase, where the MR changes its location and 295 informs all the peers of all of the MNs about the movement. 297 3.1. Pre-Movement Phase 299 As in any typical use of HIP [RFC5201], this draft is based on an 300 assumption that the MN and its peer nodes create pieces common keying 301 material using the Diffie-Hellman method during the HIP base 302 exchange. This keying material is known only by the two hosts 303 participating to its creation. Keys drawn from the keying material 304 are used to protect the HIP signalling (e.g. location update 305 messages) [RFC5206] and data transmission between the nodes. 307 3.2. Node Movement Phase 309 When the MN moves behind a mobile router it will get information 310 about available mobile routers by monitoring incoming beacons that 311 the mobile routers use to advertise themselves. Once a suitable 312 router is found, the MN initiates a HIP base exchange with the mobile 313 router, and using the HIP registration extension [RFC5203], the MN 314 registers itself as a user of the mobile routing service, provided by 315 the mobile router. 317 The mobile sends runs update exchange with the peer nodes to updates 318 its HIP association. The mobile router transparently establishes a 319 SPINAT [I-D.melen-spinat] state per each end-to-end HIP session by 320 intercepting the end-the-end update exchange messages and forwarding 321 them between end-points. 323 3.3. Delegation Phase 325 The task of the mobile router is to act as a signalling proxy and 326 SPINAT node between the MN and its peer nodes. With this 327 arrangement, the amount of signalling is minimized when the mobile 328 router changes its location and location updates are sent to active 329 peer nodes. To be able to send HIP location update messages on 330 behalf of the mobile nodes inside the mobile network the mobile 331 router needs a so-called HMAC key from the MN. Knowing the mobile 332 node's HMAC key the mobile router can create HMAC protected messages 333 on the behalf of the MN, thereby being able to represent it by means 334 of symmetric cryptography. 336 To avoid aliasing and replay problems, the mobile node needs to 337 create a new HMAC key, for each of its peers, each time it wants to 338 use mobile routing service. The MN selects a new key for this 339 purpose from the keying material that it already has with its peer, 340 and prepares a ticket to be sent to the mobile router over the 341 negotiated ESP Security Association. The ticket contains the 342 following information: 344 o The new HMAC key to be used by the mobile router to calculate the 345 HMAC protected messages on the MN's behalf. 347 o Authentication information, which contains the same new HMAC key 348 (or key index information that the peer can use to get the same 349 key from its own keying material), integrity protected and 350 optionally encrypted with the HIP session key(s) that were 351 initially negotiated between the MN and its peer. The mobile 352 router cannot decrypt or modify this part of the message without 353 the peer noticing it. 355 3.4. Network Movement Phase 357 When the mobile router changes its location, it creates location 358 update packets for the mobile nodes behind the mobile router. 359 However, the update can be distinguished from an end-to-end update by 360 the use of a special "UPDATE-PROXY" message type. Each location 361 update contains the MN's HIT as the source HIT and includes location 362 update information as if it was sent by the MN itself. To 363 authenticate the packet, the Mobile Router inserts a new parameter 364 into the packet. The new parameter contains 1) the unmodified 365 authentication information from the ticket it received from the MN, 366 and 2) an HMAC calculated using the new HMAC key received from the 367 MN. This packet is delivered to the peer node. The peer can verify 368 the authentication information part of the packet and get the HMAC 369 key. Using this key, it can verify that the incoming update packet 370 was sent by a node authorized by the Mobile Node. 372 If the mobile router moves behind another mobile router (nested 373 mobile routers), it can deliver received tickets to the new mobile 374 router which in turn is capable of making location updates to peer 375 nodes based on the information received in these tickets. Because 376 there is no association between the peer and the mobile router, there 377 is no need to provide any additional information about the previous 378 mobile router and the same ticket can be used by the new mobile 379 router for location updates. 381 If the MN moves out of the mobile network, it needs to revoke the old 382 keys. It sends an update message to the peer containing information 383 about the keys that are no longer valid. After receiving this 384 information the peer node does not accept any new location updates 385 with that key. 387 4. Protocol Description 389 The mobile router consists of two integrated services: i) a 390 signalling proxy and ii) SPINAT services. The signalling proxy and 391 SPINAT services are presented in separate drafts. This draft defines 392 the signalling proxy service and defines some extensions to the HIP 393 base and update exchanges. The signalling proxy service is used to 394 establish, update and create SPINAT states for ESP packets. The 395 SPINAT service is presented in [I-D.melen-spinat]. 397 4.1. Mobile Router Discovery 399 The mobile node must discover the mobile router. For this purpose, 400 the HIP base exchange, combined with the registration extension 401 [RFC5203], can be used for the service registration procedure as 402 presented in draft [I-D.jokela-hip-service-discovery]. The mobile 403 node requests a mobile routing service from the mobile router using 404 the registration extension. 406 4.2. HIP base/update exchange between the MN and its peers 408 Either before or after the valid registration exchange, the mobile 409 node runs a HIP base-exchange or an update exchange with its peer 410 node as described in [RFC5201]. Typically, the base exchange is used 411 with new peers and updates are used with existing peers. As a result 412 of the base exchange, the mobile node and its peers posses mutual, 413 secret keying material that is used to generate various keys, 414 including those used to protect the HIP mobility management messages. 416 The end-to-end HIP base/update exchange creates a SPINAT state at the 417 mobile router (see [I-D.melen-spinat]). 419 4.3. Mobile Node Authorizes a Mobile Router 421 With the mutual keying material available with its peers, the mobile 422 node creates tickets (Figure 1), one for each of its active peers, to 423 authorize the mobile router to signal on behalf of the MN. A ticket 424 contains the end-to-end session key, for HMAC integrity protection 425 calculation, generated by the mobile node and to be generated or 426 received by the peer node. This new HMAC session key is later used 427 to protect the mobility management messages that the mobile router 428 sends to the peer node on behalf of the mobile node. 430 In addition to the new HMAC key, the mobile node includes other 431 relevant information in the ticket, like lifetime and what type of 432 authorization this is. This information is protected using HMAC with 433 the HIP session key agreed between the mobile node and the peer, and 434 it may be encrypted. The mobile router doesn't have the HIP session 435 key between the MN and its peer, and therefore the mobile router 436 cannot modify (or decrypt) the part of the ticket that is protected 437 with end-to-end keying material. The ticket has to contain, at 438 least, either the same HMAC key that is given to the mobile router or 439 a pointer to the place in the shared keying material from where the 440 key was drawn so that the peer can draw the same key. In addition to 441 the key information, the integrity protected part of the ticket can 442 contain also other information if needed. 444 Encrypted { 445 HI-MN; HI-PEER; 446 HI-issuer; HI-subject; 447 HMAC-key; 448 HMAC { 449 HMAC-key-index; 450 Action; 451 Lifetime; 452 } Key-MN-PEER 453 } Key-issuer-subject 455 Figure 1: Signalling proxy Ticket information 457 Figure 1 shows the ticket that is sent either from the MN (issuer) to 458 the MR (subject), or in case of nested mobile routers, from MR1 459 (issuer) to MR2 (subject). The key Key-MN-PEER is only known by the 460 MN and the peer. It is used to protect the integrity of the 461 authentication information from modifications. 463 If, instead of the HMAC-key-index, the whole HMAC-key is included in 464 the authentication information, the HMAC-key must be encrypted with 465 the key known only by the MN and the peer. 467 Note that the mobile node cannot deny the mobile router the 468 permission to give the tickets further to other mobile routers, as it 469 cannot prevent the mobile router from distributing the new HMAC-key 470 to other nodes. 472 { 473 HI-MN; HI-PEER; 474 HMAC { 475 HMAC-key-index; 476 Action; 477 Lifetime; 478 } Key-MN-PEER 479 } 481 Figure 2: Authentication ticket (Extracted from signalling proxy 482 ticket) 484 Figure 2 shows the authentication information, as extracted from the 485 ticket, that is sent from the MR to the peer when the MR updates 486 location information at the peer. 488 4.4. MR runs update exchange with the peer nodes 490 Once the mobile router changes the location, it creates location 491 update packets to be sent to peers based on the information about the 492 location change and the information that it had earlier received from 493 the mobile hosts. 495 The update packet contains the following information: 497 o The new IP address of the mobile node as seen by the peer node. 498 (Note: the mobile router implements the SPINAT functionality.) 500 o The authentication information as extracted from the received 501 ticket. 503 o A HMAC integrity code, calculated using the new HMAC key. 505 To avoid attacks related to the location update exchange, the peer 506 nodes must send challenges to the mobile node's claimed location 507 (i.e., reachability test). In practice, these challenge messages are 508 destined to the mobile router. The mobile router on the forwarding 509 path uses the new HMAC key to protect the reply message and sent the 510 message back to the peer nodes on behalf of the mobile nodes. 512 To distinguish the UPDATE from an end-to-end UPDATE exchange, a new 513 message type ("PROXY-UPDATE") is used. The peer node knows from this 514 message type that the HIP message was not generated by (and cannot be 515 signed by) the MN HIP host. From a message processing perspective, a 516 PROXY-UPDATE is handled similarly to a regular UPDATE. Notably, the 517 MN may simultaneously be in the process of a separate UPDATE exchange 518 with the peer for other reasons (e.g. rekeying). Therefore, both an 519 UPDATE exchange and PROXY-UPDATE exchange may be occurring 520 concurrently. 522 When a mobile router (MR1) moves into another mobile network, it 523 becomes the client for the next level mobile router (MR2). The MR1 524 sends the tickets it has received from its own network to the next 525 level mobile router (MR2) so that MR2 can send the location updates 526 also on behalf of the mobile nodes behind the MR1. Because there is 527 no association between the MR1 and the peer nodes, it doesn't need to 528 add any own information to the ticket, but it can deliver them 529 directly to the MR2. The MR2 gets all needed information from the 530 tickets. 532 Long ticket lifetimes allow the mobile router to signal on behalf of 533 the mobile node after the node has moved away from the mobile 534 router's link. Therefore, the lifetime of ticket is the estimated 535 locator lifetime at the mobile node's current location. The mobile 536 node generates a new ticket if it stays longer in the same link than 537 it initially expected. The mobile node stores also a ticket 538 revocation list. The list consists of hashes of active tickets that 539 were sent to the previous mobile routers. After the mobile node 540 leaves a moving network, it informs its active peers about the 541 revoked tickets using an enhanced location update exchange. 543 4.5. Leaving a Moving Network; Revoking tickets 545 Once a mobile node leaves a moving network it should revoke the 546 ticket both at the peer and at the mobile routers. The revoke 547 mechanism for tickets will be added for the draft version -03. 549 The rough idea is following. The revoke message must be sent to the 550 peer nodes and should be sent to the rendezvous of the mobile router. 551 The mobile node receives the rendezvous locator of the mobile router 552 during the registration exchange. 554 4.6. Kerberos vs. Ticket based Delegation of Signalling Rights 556 The signalling trust between the HIP enabled nodes is purely based on 557 the secret session key material that is generated during the initial 558 authenticated Diffie-Hellman (DH) key exchanges, i.e., the HIP base 559 exchanges. The generated session keying material is used to derive 560 new keys, which in turn are used to authenticate the proxied update 561 messages. 563 There is a clear analogy between this approach and the existing, well 564 known Kerberos [RFC4120] system. The mobile node acts like a 565 Kerberos-KDC, the mobile router works as a Kerberos-client, and the 566 peer node represents the Kerberos-service. However, there are also 567 differences due to which the legacy Kerberos system cannot be used as 568 such in this draft. 570 In Figure 3, the based relation to the Kerberos model is illustrated. 571 In the case of nested mobile routers, the Mobile Router 1 would 572 become a KDC and the Mobile Router 2 would become the client, when 573 the MR1 moves behind the MR2. 575 "Kerberos: client" 576 +--------+ +--------+ 577 | MR1 | | MR2 | 578 +--------+ +--------+ 579 ^ 580 "Kerberos: KDC" | "Kerberos: peer" 581 +--------+<-(SA)-+ +--------+ 582 | MN |<--Security Association (SA)----->| Peer | 583 +--------+ +--------+ 585 Figure 3: Relationship to Kerberos model 587 The difference between Kerberos and the solution presented in this 588 draft is that this draft relies only on the session keys, not on the 589 identifiers. In Kerberos, the ticket contains an encrypted 590 identifier of the principal that is allowed to access the service. 591 That encryption key is known only by the KDC and the service. In the 592 nested moving network case this causes scalability problems. As 593 earlier described, each nested mobile router acts as a client for the 594 next mobile router higher in the group hierarchy. Once the nested 595 mobile router approves a ticket to the other mobile router it also 596 becomes a KDC itself. However, the mobile router (middle-box) does 597 not have a security association with the peer node. As a result, the 598 nested mobile router (i.e. KDC) cannot encrypt the identifier of the 599 other mobile router to the ticket. 601 To overcome the problem, this solution approves only anonymous 602 tickets. In other words, the host (principal) that knows ("owns") 603 the secret session key, is allowed to signal on behalf of the mobile 604 node. Each mobile node (/nested mobile router) authenticates mobile 605 router in the architecture with the HIP base-exchange. Thus, the 606 mobile node (/nested mobile router) does not approve a ticket to the 607 mobile router if the authentication fails. 609 The situation with the ticket based delegation scheme is partially 610 similar to the public key based delegation scheme. Once using SPKI 611 [RFC2693] authorization certificates the issuer of the certificate 612 can only limit the length of the authorization chain. The issuer 613 cannot know how the principals in the chain act. In other words, the 614 mobile node trusts the link local mobile router to delegate the 615 signalling rights to another trustworthy mobile router. The same 616 kind of trust chain applies also to the ticket based authorization 617 scheme. Instead of expressing the trust with certificates this 618 solution uses symmetric key based tickets to authorize nodes in the 619 architecture. This solutions uses asymmetric cryptography to 620 authenticate client to the KDC and symmetric cryptography to 621 authorize the client. 623 4.7. Using the keying material 625 When the mobile host performs a HIP base exchange with the peer node, 626 they generate keying material using Diffie-Hellman method. From this 627 keying material (same for both hosts) they can retrieve keys 628 sequentially for HIP (encryption and authentication) as well as ESP 629 (encryption and authentication). During a session, hosts can re-key 630 the ESP association during which new keys for the ESP Security 631 Association are drawn from the keying material. HIP association keys 632 remain the same during the whole session. 634 This solution uses the same keying material for drawing keys for the 635 HMAC protected update messages from the mobile router to the peer 636 node. In normal case, the MN uses the HIP authentication key for 637 calculating the HMAC in update message. Because of the requirement 638 that the MN must be able to revocate the key that is sent to the MR, 639 the originally drawn HIP authentication key cannot be used. Thus, a 640 new key is retrieved from the keying material and sent to the mobile 641 router. 643 To be able to keep the mobile node's and peer node's keying material 644 pointers synchronized, the index value has to be transmitted between 645 the nodes. This is done in the authentication information that the 646 mobile node sends to the mobile router, which in turn delivers it to 647 the peer unmodified in location update messages. 649 The peer node can decrypt the received authentication information, if 650 all delegation information is properly delivered earlier, and it can 651 trust that the mobile router is acting on behalf of the correct 652 mobile node. 654 5. Packet processing 656 The following flow chart (Figure 4) illustrates the delegation of 657 signalling rights using tickets, for the "MN delegates to fixed MR" 658 case: 660 +--------+ +-------+ +--------+ 661 | MN | | MR1 | | Peer | 662 +--------+ +-------+ +--------+ 663 | | | 664 | 1. serv. disc. | | 665 |<-----------------| | 666 | | | 667 | | | 668 |2. registration exchange | 669 |<---------------->| | 670 | 3. base exchange: generate session keys | 671 |<------------------------------------------------------>| 672 | | 673 |4. provide ticket | | 674 |<---------------->| | 675 |5. update exchange | 676 |<------------------------------------------------------>| 677 | (hand-off) | 678 |6. hand-off NOTIFY | 679 |<-----------------| | 680 | |7. update exchange + peer ticket | 681 | |<----------------------------------->| 682 | | +--------+ | 683 | | | MR2 | | 684 | (hand-off) +--------+ | 685 |8. hand-off NOTIFY | | 686 |<-----------------| | | 687 | |9. registration exchange + ticket | 688 | |<------------------>| | 689 | | (hand-off) | 690 |11. |10. hand-off NOTIFY | 691 |<-----------------|<-------------------| | 692 | | |12. update exchange 693 | | | + peer ticket| 694 | | |<-------------->| 695 | | | | 697 Figure 4: Flow chart 699 Step-1 The mobile node MN discovers the mobile router MR1 through a 700 service discovery announcement or other configuration. The MN 701 autoconfigures an address on its interface, based on whichever 702 (DHCP, stateless autoconfiguration, or manual) technique is in 703 place. 705 Step-2 The MN performs a base exchange and registration with MR1, 706 registering for mobile router services. 708 Step-3 The mobile node and a peer node run a base exchange and 709 generate keying material from which session keys are drawn. 710 Subsequent to the base exchange, additional keys are drawn from 711 the material to be given to the mobile router and to be used to 712 protect the update messages with HMAC. Note that this base 713 exchange includes a modified I2 for SPINAT SPI remapping, as 714 described in [I-D.melen-spinat]. and SPINAT state is created. 715 This means, from the perspective of the peer host, the outbound 716 SPI and destination address to the MN may be different than the 717 inbound SPI and source address used by the MN, due to the SPINAT 718 translation. 720 Step-4 The mobile node uses the established security association 721 between it and the mobile router to encrypt a ticket. The ticket 722 allows the mobile router to later send update messages to the peer 723 node. The ticket also contains authorization rights information 724 and a lifetime field that is HMAC protected using the keys drawn 725 from the security association between mobile node and the peer 726 node. This end-to-end authentication keying material is not sent 727 to the mobile router, and it is only known by the end-hosts. 728 (Note: once the mobile node leaves the moving network, it revokes 729 the ticket from the mobile router.) 731 Step-5 The mobile node runs an update exchange with the peer node in 732 parallel with the registration exchange and provides it with a 733 signaling proxy ticket that authorizes one or more MR to signal on 734 its behalf. This update is also needed to notify the peer to 735 advance its keying material index, when the ticket uses a key 736 drawn from the end-to-end KEYMAT. 738 Step-6 The mobile router (MR1) makes a hand-off and sends a NOTIFY 739 message to the MN or a generic hand-off notification message to 740 the link local multicast/broadcast address on the private link. 741 The mobile node does not send acknowledgement back to the mobile 742 router, because it causes extra load for the mobile router during 743 hand-off. The notification message may be used at the mobile node 744 to inform layers above IP layer about hand-off. In addition, the 745 notify message contains the public locator of the mobile router. 747 Step-7 The mobile router runs (in parallel with step-6) an update 748 exchange with the peer node on behalf of the mobile node. It 749 informs the peer node that the mobile node has changed its 750 location. The mobile router presents the authorization 751 information to the peer node using the ticket. The peer node uses 752 the key information in the ticket to get a correct HMAC key from 753 the keying material to verify the received update message. (NOTE: 754 it is possible that the MN sent the HMAC key to the MR also 755 encrypted with a key that is known only by the peer, in which case 756 the MR sends this to the peer which can decrypt it and get the 757 HMAC key from that). The mobile router also updates its SPINAT 758 state. 760 Step-8 See step-6. 762 Step-9 The mobile router (MR1) attaches to another mobile router 763 (MR2). The situation is also called a nested mobile network case. 764 MR1 registers to the MR2 and gives the ticket to the MR2. The 765 session key is encrypted using the security association between 766 MR1 and MR2. The ticket contains also the encrypted end-to-end 767 part that cannot be decrypted by the mobile routers or other 768 intermediate nodes. 770 Step-10 See step-5. 772 Step-11 Once a mobile router receives a hand-off notification 773 message from the upper link it signs the messsage with its own HI 774 and multicasts the same message in its own private link (see 775 step-6). 777 Step-12 The MR2 sends a location update on behalf of the mobile node 778 to the peer node. The update message contains also the ticket 779 given in step-9. The peer node trusts that the update message 780 comes from an authentic sender, because the message was protected 781 with the correct HMAC, and the lifetime of the ticket is valid. 782 Note that the MR2 will also include a NAT_ESP_INFO parameter that 783 again changes the inbound SPI towards the MN. 785 5.1. End-to-end Base Exchange 787 The mobile router establishes a state during the end-to-end base 788 exchange between mobile host and peer hosts. This is illustrated in 789 Figure 5. 791 +--------+ +--------+ +--------+ 792 | MN | | MR | | Peer | 793 +--------+ +--------+ +--------+ 794 | | | 795 | registration exchange | 796 |<---------------->| | 797 | base/update exc. + SIGNED(locator TLV + ESP-INFO TLV) | 798 |<------------------------------------------------------>| 799 | | ticket exchange + 800 | | HMAC(locator TLV + ESP-INFO TLV) | 801 | |<----------------------------------->| 802 | | | 804 Figure 5: End-to-end base exchange through mobile router 806 The mobile host receives the rendezvous locator of the peer host from 807 the DNS and sends the I1 message to that location. The mobile router 808 establishes a soft NAT state for the MN before forwarding the I1 809 message to the rendezvous node ([RFC5204]). It also translates the 810 private source locator to the public multiplexed locator of the 811 mobile router. In addition, the mobile router adds an encrypted 812 'echo request' parameter to the I1 message that is echoed back by the 813 peer host in R1 message. 815 The I1 message may be forwarded via the rendezvous node to the peer 816 host. After receiving the I1 message, the peer host replies with the 817 R1 message. The peer host adds its locator set to the R1 message 818 according to [RFC5206]. The peer host sends the packet back to the 819 destination address that was used as the source address of the I1; 820 i.e. to the MR's public, multiplexed address. 822 Once the mobile router receives the R1 message it marks the initial 823 destination locator (used in I1) as verified. The peer host was 824 reachable behind the initial locator. The mobile router also 825 verifies that the received 'echo reply' parameter contains the same 826 secret that was included in the I1 message. The mobile router stores 827 the received locator set of the peer host, if it was included. The 828 mobile router translates the destination locator to the private 829 locator of the mobile host. 831 After receiving the R1 message, the mobile host sends back I2 message 832 to the rendezvous locator of the peer host. The mobile router node 833 does not forward the packet to the rendezvous node but reselects a 834 locator-pair between its public locator set and the earlier stored 835 peer host's locator set. (Note: Only the I1 message may be routed 836 via the rendezvous node and the rest of the messages of the base 837 exchange are sent directly between the mobile router and the peer 838 host.) In addition, the mobile router adds its signed LOCATOR TLV 839 and NAT_ESP_INFO TLV to the I2 message. The NAT_ESP_INFO TLV 840 contains the translated SPI values. 842 After receiving the I2 message the peer host creates a state for the 843 mobile host. From the peer host's point of view, the mobile host is 844 reachable at the mobile router's locator. The peer host replies with 845 an R2 message. The mobile router marks the destination locator of 846 the earlier sent I2 message as verified. Before forwarding the R2 847 message to mobile host, the mobile router node do the same locators 848 translation that took place with the R1 message. The soft state is 849 also changed to hard state and IPsec SAs are created at the mobile 850 router (see [I-D.melen-spinat]) 852 5.2. End-to-end update exchange 854 The mobile host runs the base exchange with the peer host only once. 855 After that the mobile host updates its location to the peer host by 856 running an update exchange. This is illustrated in Figure 5. From 857 the mobile router viewpoint, the state establishment using the update 858 exchange differs from the base exchange case. The update exchange is 859 only a three way handshake, while the base exchange consists of four 860 messages. (Note: The peer host must add it locator set to the 861 initial R1 message in the base exchange.) The end-to-end update 862 exchange is used both for updating a state at the peer host and for 863 creating state at the mobile routers. 865 The signed _peer_ host's locator set and the ticket are added to the 866 first update message. Once the mobile router receives the update 867 message, it creates a soft state. The mobile router selects a 868 locator pair between the peer's and mobile router's locator sets. 869 The mobile router also adds its own signed LOCATOR TLV and 870 NAT_ESP_INFO TLV to the update message before forwarding the message 871 to the peer host. The NAT_ESP_INFO TLV contains the translated SPI 872 values. In addition, the mobile router caches the first update 873 message to be able to retransmit the message later. 875 The peer host replies with the update (challenge) message and sends 876 it directly to the mobile router. The peer host should use one of 877 the locators of the LOCATOR TLV included in the first update message. 878 The mobile router verifies that the source locator in the update 879 (challenge) message sent by the peer host belongs to the locator set 880 that was carried in the first update message. In addition, the 881 mobile router compares locators in the earlier cached message and the 882 received challenge message. If the destination locator in the cached 883 packet and the source locator in the challenge packet differ from 884 each other the packet has been routed via a rendezvous node. In that 885 case, the mobile router cannot directly start using the received 886 source locator with the peer host. Instead, the mobile router node 887 silently drops the received challenge message and retransmits the 888 cached update message to the source locator of challenge message and 889 adds 'echo request' parameter to the message. In other words, the 890 mobile router uses the first round trip of the update exchange as a 891 reachability test. 893 If the peer host was reachable from its claimed location, the mobile 894 router receives the challenge message from the peer host containing 895 correct 'echo reply' parameter. The mobile router node marks the 896 peer host's location verified and forwards the packet to the mobile 897 host. The mobile host finalizes the update exchange by sending the 898 last update message to the peer host. The mobile router uses the 899 already verified destination locator towards the peer host. 901 5.3. Payload Packet Processing 903 The locator rewriting for payload packet headers is done in 904 alternative ways for IPv4 and IPv6 packets. In the IPv4 case, the 905 mobile router uses SPINAT mechanism for locator translation 906 [I-D.melen-spinat]. In the IPv6 case, the locator rewriting follows 907 the Six/One principles [I-D.vogt-rrg-six-one] as discussed in the 908 following. It is also good to notice that this draft does not rely 909 on the Six/One host context, but uses instead the HIP context at the 910 end hosts for locator-to-identifier bindings. 912 Basically, it is possible either to renumber the moving network 913 during mobile router hand-off or use rewriting mechanisms to rewrite 914 the prefixes in the packet headers at the mobile router. Without 915 prefix rewriting at mobile router, a mobile router hand-off would 916 result in renumbering in the moving network. Therefore, the hosts in 917 the moving network SHOULD use link-local subnet prefixes or unique 918 local subnetwork prefixes RFC4193 [RFC4193] that are replaced with 919 globally routable prefixes at the mobile router attached to the 920 Internet. Whenever a mobile router changes its attachment to the 921 network it gets a new prefix from the new access router. The mobile 922 router implements DAD for each address on behalf of the hosts 923 attached to the moving network. In other words, the host ID part of 924 the IPv6 address remains the same during prefix rewriting procedure 925 at the mobile router. 927 6. Payload Format 929 TBA for version -02. 931 7. Security Considerations 933 This draft defines an authorization and delegation mechanism that is 934 used for delegating update exchange rights between mobile nodes and 935 mobile routers. The security considerations are discussed in the 936 protocol context throughout the draft. 938 The authentication between nodes relies on the HIP base exchange. 939 The security considerations of the authentication procedure can be 940 found from the HIP based draft [RFC5201]. The single-hop delegation 941 between mobile hosts and mobile routers relies on the Kerberos 942 [RFC4120] security model. The multi-hop delegation between mobile 943 hosts and mobile routers relies on the SPKI [RFC2693] delegation 944 principles with certain restrictions. Using authorization 945 certificates it is possible to limit the length of the certificate 946 chain. However, the delegation mechanism in this draft does not 947 limit the length of the delegation chain. As earlier mentioned, the 948 mobile nodes(/mobile routers) should not delegate the signalling 949 rights to unauthenticated mobile routers. 951 When either the mobile node or the peer does not get incoming ESP 952 packets for a specific SA in KEEPALIVE seconds, it should revoke the 953 ticket bound to a corresponding SPI value, initiate a new 954 registration exchange and create a new ticket. A reason for the 955 communication break may be a re-direction attack that is made by a 956 malicious node. This requires that the malicious node has obtained 957 the session key in the ticket due to opportunistic HIP authentication 958 [RFC5201]. 960 8. IANA Considerations 961 9. Acknowledgments 963 A number of people have contributed to the text and ideas. The list 964 of these people include Pekka Nikander, Petri Jokela, Raimo 965 Vuopionpera, Yuri Ismailov, Jan Holler, Goran Selander, Goran Schultz 966 and Jari Arkko. Our apologies to anyone whose name is missing. 968 10. References 970 10.1. Normative References 972 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 973 "Host Identity Protocol", RFC 5201, April 2008. 975 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 976 Host Mobility and Multihoming with the Host Identity 977 Protocol", RFC 5206, April 2008. 979 [RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 980 Rendezvous Extension", RFC 5204, April 2008. 982 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 983 RFC 3753, June 2004. 985 [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity 986 Protocol (HIP) Registration Extension", RFC 5203, 987 April 2008. 989 [I-D.vogt-rrg-six-one] 990 Vogt, C., "Six/One: A Solution for Routing and Addressing 991 in IPv6", draft-vogt-rrg-six-one-01 (work in progress), 992 November 2007. 994 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 995 Addresses", RFC 4193, October 2005. 997 10.2. Informative References 999 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 1000 Kerberos Network Authentication Service (V5)", RFC 4120, 1001 July 2005. 1003 [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, 1004 B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, 1005 September 1999. 1007 [I-D.jokela-hip-service-discovery] 1008 Jokela, P., "HIP Service Discovery", 1009 draft-jokela-hip-service-discovery-00 (work in progress), 1010 June 2006. 1012 [I-D.melen-spinat] 1013 Melen, J., Ylitalo, J., and P. Salmela, "Security 1014 Parameter Index multiplexed Network Address Translation 1015 (SPINAT)", draft-melen-spinat-01 (work in progress), 1016 July 2008. 1018 Appendix A. Future work 1020 A.1. Static Signalling Proxies in the Fixed Network 1022 The mobile router may also optimize the over-the-air signalling 1023 between it and the Internet. The mobile router may register its 1024 clients and delegate the signalling rights to a static signalling 1025 proxy located in the fixed network. When the mobile router makes a 1026 hand-off, it runs a single location update exchange with the static 1027 signalling proxy. The mobile router's multiplexed IP address may 1028 represent the current location of all the clients belonging to the 1029 moving network behind it. 1031 The static signalling proxy in the fixed network can use the 1032 available high bandwidth to send the burst of location updates to the 1033 peer nodes on behalf of the mobile nodes. The peer nodes send the 1034 challenge messages to the multiplexed locator of the mobile router if 1035 the signalling proxy is not on the forwarding path. The peer nodes 1036 must verify that the mobile nodes are at the location where the 1037 static signalling proxy claims them to be. 1039 Authors' Addresses 1041 Jan Melen 1042 Ericsson Research NomadicLab 1043 JORVAS FIN-02420 1044 FINLAND 1046 Phone: +358 9 299 1 1047 Email: jan.melen@nomadiclab.com 1049 Jukka Ylitalo 1050 Ericsson Research NomadicLab 1051 JORVAS FIN-02420 1052 FINLAND 1054 Phone: +358 9 299 1 1055 Email: jukka.ylitalo@nomadiclab.com 1057 Patrik Salmela 1058 Ericsson Research NomadicLab 1059 JORVAS FIN-02420 1060 FINLAND 1062 Phone: +358 9 299 1 1063 Email: patrik.salmela@nomadiclab.com 1065 Tom Hendersson 1066 The Boeing Company 1067 Seattle, WA P.O. Box 3707 1068 USA 1070 Phone: 1071 Email: thomas.r.henderson@boeing.com