idnits 2.17.1 draft-dietz-hip-operator-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 745. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 729. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 735. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 17, 2005) is 6765 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-matos-hip-privacy-extensions-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Dietz 3 Internet-Draft M. Brunner 4 Expires: April 20, 2006 NEC 5 N. Papadoglou 6 V. Raptis 7 K. Kypris 8 Vodafone 9 October 17, 2005 11 Issues of HIP in an Operators Networks 12 draft-dietz-hip-operator-issues-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 20, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document discuss the potential issues that arise when the Host 46 Identity Protocol (HIP) will be introduced in a operator network, 47 especially in the IP Multimedia Subsystem (IMS) of the 3GPP systems. 48 It discusses mobile network specific issues like charging, lawful 49 interception as well as common issues like where to associate the HIP 50 ID or privacy issues. The document tries to make the HIP community 51 aware of those issues and wants to stimulate discussion on those 52 topics. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Charging Issues . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Lawful Interception . . . . . . . . . . . . . . . . . . . . . 5 59 4. How HIP could improve SIP . . . . . . . . . . . . . . . . . . 5 60 5. How SIP could improve HIP . . . . . . . . . . . . . . . . . . 7 61 6. HIT creation, bootstrapping and distribution . . . . . . . . . 8 62 7. HIP Associations . . . . . . . . . . . . . . . . . . . . . . . 8 63 8. HIP ID and HIT mappings . . . . . . . . . . . . . . . . . . . 10 64 9. Privacy implications with HIP . . . . . . . . . . . . . . . . 11 65 10. Problem of using DNS in the HIP architecture . . . . . . . . . 12 66 11. Free Choice of Access Technology . . . . . . . . . . . . . . . 12 67 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 14. Informative References . . . . . . . . . . . . . . . . . . . . 15 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 71 Intellectual Property and Copyright Statements . . . . . . . . . . 17 73 1. Introduction 75 This document presents some of the issues arising when the Host 76 Identity Protocol (HIP) infrastructure is introduced in an operator 77 networks architecture such as a 3GPP one. In those mobile networks 78 and especially in the IP Multimedia Subsystem (IMS), HIP has to be 79 integrated with systems used for charging, application proxies and 80 registrars (SIP based) and may have to fulfill rules for lawful 81 interception and the like. 83 Further on the structure of mobile networks and its authentication 84 methods are different from fixed networks. Thus the association of 85 the HIP ID to e.g. a SIM card could make sense in this mobile 86 environment. Also the privacy issues become more important in those 87 networks than in fixed networks and the Internet. 89 The document also tries to identify possible solutions in some of the 90 areas and wants to stimulate discussion on the topics picked out in 91 this document. 93 Most of the sections present independent issues, but overall the 94 document tries to cover all the different issues within an operator 95 network the authors are aware of. 97 2. Charging Issues 99 One of the most important aspects in the design of a network 100 architecture for network operators as well as for service providers 101 is the functions related to charging and tariffing. There are a 102 number of models that need to be supported such as: 104 o Volume based charging 106 o Time based charging 108 o Volume and time based charging 110 o No charging 112 Some of the functions/mechanism that the above charging models need 113 to support are: 115 o Pre-paid and post-paid 117 o On line and Off line charging 119 Most of the above models and mechanisms need to be supported by the 120 network architecture in order to allow the operator to design and 121 apply flexible charging plans and differentiated tariffs. With the 122 introduction of the TCP/IP suite in the wireless communications arena 123 for transporting most of the data that services and applications 124 generate means that a number of changes needed to take place in the 125 systems and methods used so far in the circuit switched world. A new 126 concept was introduced, known as IP flow based charging [1], which 127 enables operators to maintain the current charging models even over 128 IP. The idea is to have flexible mechanisms for creating new tariffs 129 based on the different IP based services. For example, a network 130 operator might want to be able to charge with different tariffs voice 131 and video in a rich video call. In order to promote the service he 132 might want to offer video for free and charge only the voice traffic. 133 Hence, the video traffic is zero rated when it traverses the specific 134 charging functions of the network based on a flow identifier. In 135 order to be able to do this the operator needs mechanisms such as 136 those introduced with IP based flow charging in 3GPP and other 137 standardization bodies. 139 The introduction of cryptographic Host Identifiers and in particular 140 with the employment of the Host Identity Protocol (HIP) in an 141 operator's network may raise issues with the current charging models 142 and mechanisms. This is due to the fact that HIP is a P2P protocol 143 enabling the negotiation and establishment of an encrypted tunnel 144 between 2 hosts. Although this is a good way of establishing an end- 145 to-end and secure communication channel (encrypted channel) end-to- 146 end, it posses a number of issues with the existing charging model 147 and mechanisms. When the traffic passing the charging function of a 148 network is encrypted, then it is very difficult to apply different 149 charging rules based on the type of the traffic, i.e. differentiate 150 between voice and media traffic. Since the packets traversing the 151 charging function are encrypted it not possible to look at the upper 152 layers and apply different policies based on the media type, unless 153 it possesses the keys in order to de-crypt the traffic. This 154 restricts the charging plans that a network operator might want to 155 deploy in the future based on the different service propositions 156 available. The only available model from those outlined above that 157 can be applied is volume based charging which offers no flexibility 158 or differentiation of the service used. 160 For this reason, there are three options foreseen solving this 161 drawback. The first is to break the e2e security association and 162 terminate it at a network sub-element where the charging function may 163 be applied, and from there establish another one from this node to 164 the end terminal/device. The second option is for the charging 165 function to possess the keys of the sessions to be established and 166 thus being able to decrypt the traffic and apply the different 167 charging policies. The deficiency with this solution is that it 168 would probably not scale in a large scale network (e.g. an operator 169 network) and that in some cases (e.g. anonymity) the keys will not be 170 available to the charging function. Finally, the third and less 171 desirable option is to accept this as a de-facto standard and apply 172 only volume based charging although having a negative effect both to 173 the customers and the operators business. 175 3. Lawful Interception 177 Even though wire tapping has not been standardized or will be 178 standardized in the IETF [2], we need to bring up the issue here. 179 Countries around the world are drafting and enacting laws to regulate 180 lawful interception procedures. National laws define local intercept 181 requirements; the means and authority of conducting Lawful Intercept 182 is often recorded in government legislation or regulatory mandates. 183 Naturally, the base requirement would be that the interceptor is on 184 path of the HIP base exchange as well as on the path of the data 185 communication. Furthermore, in order to decrypt the data traffic the 186 interceptor needs to have at least one of the private keys of the 187 communicating end-points for extracting the IPSec session key for 188 decrypting the data communication. 190 Lawful Interception could use the first two solutions presented in 191 the previous section with the charging issues. This assumes that the 192 private keys are known by the operator or at least that the customers 193 accept the breakage of end-to-end security. 195 If the keys are generated by the user (device), it implies that 196 lawful interception is not possible. In many European countries, 197 this also means that the ISP is not liable for the voice 198 communication. 200 4. How HIP could improve SIP 202 SIP is an emerging signaling protocol that operates over the standard 203 TCP/IP protocol stack. As such it should benefit from the use of HIP 204 in the same way as the rest applications. Mobility support and 205 improved security are the main advantages of using HIP. The scope of 206 this section is to discuss whether and in what way HIP actually 207 affects SIP. 209 SIP uses URIs in order to identify hosts in the application layer. 210 It uses additional infrastructure such as registrars, redirection and 211 proxy servers. Security in SIP is handled by various techniques, 212 e.g. IPsec, TLS. Additionally, a draft is under development in 213 order for SIP to support session mobility. Therefore, with the 214 existence of these features, it is an issue worth of investigation 215 whether HIP actually improves the operation of SIP with the 216 decoupling of the network and transport layers. The main difference 217 between the two proposed solutions is that SIP attempts to solve the 218 problems in a higher layer than HIP does. 220 With the current SIP architecture, the SIP URI is registered to an IP 221 address (dynamic or static) in order to route the messages to the 222 appropriate SIP agent. If HIP is present in the network, the mapping 223 from the URI to HI should be supported as well as the mapping of HI 224 to the IP address of the host. The mapping is usually accomplished 225 through DNS servers. The one-level mapping between URIs and IP 226 addresses is straightforward. On the other hand, the mapping in the 227 case of HIP could be performed: 229 Either through a two-level mapping (one DNS search for the mapping 230 between URI and HI and an additional search for the HIT-IP 231 mapping). This requires 2 DNS servers in the network and 232 introduces additional delay for the delivery of the response. 234 Or through a one-level mapping where the DNS search returns both 235 the HI and the IP address. This technique requires additional 236 storage space in the DNS server in order to be able to store the 237 naming and addressing information in the same infrastructure. The 238 work in IETF is focusing on this solution. 240 It is clear that the use of HIP increases the needed time for DNS 241 resolution and modifies the requirements for the DNS infrastructure. 243 In regards to security, HIP could be used to setup the IPsec security 244 associations. SIP security is accomplished through IPsec or higher 245 (application) layer protocols. IPsec is open in man-in-the-middle 246 threats when HIP is not used in a communication stream. As such the 247 use of HIP shields the communication from similar vulnerabilities, 248 but the response time increases due to the processing for the HIP 249 base exchange. 251 SIP can offer terminal mobility through the reregistration with the 252 home registrar prior to a call. For mobility support in the middle 253 of a call, the moving terminal sends a re-INVITE message directly to 254 the correspondent host or via the SIP proxies. In order to shield 255 the handover from security threats, SIP uses authentication or public 256 key cryptography. The main constraint of SIP mobility is the 257 inability of TCP to support session mobility. Even if a mechanism 258 like M-TCP is used in order for mobility to be supported, the 259 required time for the handover to be performed is considered high. 260 On the other hand, HIP inherently provides mobility support to the 261 higher layers without requiring optional SIP features. Even though 262 HIP does not offer any specific advantages to SIP session mobility, 263 it provides mobility support to all higher layer protocols (SIP, HIP, 264 HTTP, etc.) through a unified environment and doesn't leave this 265 issue to be handled at higher layers which usually results in slower 266 custom solutions. 268 SIP extensions have been released to enable SIP connectivity between 269 hosts behind NATs and firewalls. HIP is considered to be a better 270 solution concerning NAT traversal for TCP connections since it 271 decouples the transport from the network layer. 273 Upon investigation of the previous issues, it is evident that HIP 274 does not offer clear benefits since most of its features are 275 supported through SIP extensions. On the other hand, HIP provides 276 solutions to all these issues not only to the SIP protocol but to all 277 higher layer protocols with slightly improved security. 279 5. How SIP could improve HIP 281 There are various possible ways, where SIP could help with some 282 problems of the current HIP and its deployment. 284 The problem of trustfully getting the HIT of the other communication 285 end-point is one of the problems. In most experiments today, 286 opportunistic HIP is used for initiating the communication. The 287 usage of the HIT DNS extension is quite some time ahead and not 288 really securely deployed today. So in environments with walled 289 gardens or relatively secure handling of SIP message exchanges, SIP 290 could be used for getting the HIT from one end to the other. The HIT 291 could be included in a SIP message, for example the INVITE, and 292 securely sent to the host of the callee. This then would allow for a 293 normal HIP base exchange and running the voice communication over a 294 secured channel. 296 A problem of deploying HIP is the missing HIP infrastructure. 297 Specifically, infrastructure for NAT and firewall traversal and for 298 mobility solutions using the rendez-vous server. Since the 299 functionality of the rendez-vous server and a SIP registrar looks 300 quite similar, a SIP registrar and SIP proxy could be used instead of 301 the a rendez-vous server to lookup the current location (IP address) 302 of a HIT, which has been registered using a SIP REGISTER message. So 303 basically, the I1 packet is somehow encoded into a SIP message and 304 the HIT would show-up in the SIP URI. In a more extreme case one 305 would completely replace the HIP base exchange with a SIP based 306 message exchange, containing the similar semantic as the HIP base 307 exchange. 309 These ideas are just a first sketch where SIP could help to deploy 310 HIP in a first stage. Further investigation should be made on this 311 topic. There may be other issues where SIP could improve HIP at 312 least in a first stage. 314 6. HIT creation, bootstrapping and distribution 316 The HIP naming scheme is based on cryptographic techniques. IP 317 addresses are decoupled from higher layer applications, while 318 providing simultaneously security and the end hosts' authentication. 319 The host identity in HIP is a public key which identifies a 320 particular network stack and thus authentication is automatically 321 enabled and the robustness to man-in-the-middle attacks is increased. 323 Host identities can be either 325 stored in public directories thus enabling the authentication of 326 the hosts 328 or can be anonymous in which case HIP can not provide 329 authentication of the end host but only the encryption of the 330 session with the given host. On the other hand, anonymous HIs 331 offer improved privacy to the users, since the HI is only valid 332 for the current connection and cannot be correlated to a specific 333 user or host. 335 Multiple distribution methods for host identities can be identified 336 and used in practice. The method of distribution implies a specific 337 association of the identity. 339 o One HI per network interface 341 o One HI per user terminal/device 343 o One HI per person/user. 345 The HIP Associations are discussed in greater detail in the following 346 section. 348 7. HIP Associations 350 There are several possibilities to associate a HIP ID to an entity. 351 The HIP ID can be bound to a device or user terminal (PC, Server, 352 etc.) which can include several network interfaces, to a network 353 interface, to a person/user, to a session or to a SIM card (or 354 something similar). The list could be continued but contains the 355 most common and most important cases. The association might depend 356 also on other non technical arguments. These depend for example on 357 whether charging is based on the HIP ID or not, whether a HIP ID 358 locks a customer/device into one ISPs network or similar things. 360 In the following section we will discuss the advantages and 361 disadvantages of binding the HIP ID to one of those entities. It 362 will conclude with a recommendation where such an ID should be 363 associated to. The rest of the document will assume that the HIP ID 364 is associated as recommended here if not stated otherwise. 366 Binding to a Device/User Terminal: The most natural way of a HIP ID 367 association would be to bind it to a device or user terminal. The 368 goal of HIP is to separate identity and location. With binding 369 the HIP ID to the device we would identify the device no matter 370 where it currently is located. The identity would be independent 371 of the interface on which the device is reached. This method 372 provides mobility support since upon handover to a different 373 access network or merely a change in IP address the TCP session is 374 not terminated. The HI could either be static (built in by the 375 manufacturer or assigned statically by the network operator) or 376 dynamically created upon creation of the TCP session. Only 377 through the static HI approach can the HIP-enabled nodes be 378 globally identified (naming feature of HIP). The dynamic HI 379 offers anonymity to the hosts even if the HI is globally unique. 381 Binding to an Network Interface: If we bind the HIP ID to a network 382 interface we would give a device that is multi-homed or 383 incorporates several access technologies that could be used 384 alternatively (e.g. a mobile phone with integrated WLAN) multiple 385 identities. The idea of HIP was, besides separating identity from 386 location, to make multi-homing transparent to the other 387 communication partners. So binding a HIP ID to an interface would 388 be contradictory to that goal and ongoing TCP sessions would be 389 terminated if the host changes the used network. The only benefit 390 from using HIP with this distribution method is the improved 391 security over the existing TCP/IP approach. 393 Binding to a Person/User: We could also bind the HIP ID to a person. 394 But HIP IDs should resolve to a location and should also be used 395 to connect to things like web servers, mail servers or other 396 services. Also people usually use more than one device. This 397 technique offers increased flexibility but on the same time the 398 technical and business complexity increases, since it requires the 399 system to be able to select which device the connection should be 400 directed to. Also a method should be developed so as to correlate 401 the multiple devices to the given user. Basically, this technique 402 assumes that the user should be authenticated in any device based 403 on a username and password method in order to be able to use the 404 various devices and dynamically direct the traffic to them. So 405 binding to a person is not really helpful either. 407 Binding to a Session: For completeness, we also mention the binding 408 to a session. If we would bind the HIP ID to a session we would 409 ease the migration of sessions between devices. But it would also 410 mean that we would change the location and the device. That would 411 also mean that a device could have multiple identities. That 412 approach would only make sense in extreme cases like moving a 413 service transparently from one device to another. 415 Binding to a SIM Card: Binding the HIP ID to a SIM Card (or to 416 something comparable) is the alternative to binding the ID to a 417 device, especially in the world of mobile communication. Since 418 all mobile devices that are used today are rather similar in their 419 functionality the SIM Card could be used as a substitute of the 420 mobile device of the SIM Card owner. 422 So the recommended bindings for a HIP ID are binding it to a device 423 or if we are in the mobile world binding it to a SIM Card. Both 424 methods are valid and match the goals of the HIP architecture. On 425 the other hand restricting the association of HIP ID to physical 426 devices would introduce new problems and inconveniences. Changing 427 the hardware would thus imply changing the identity. Especially if 428 the device is e.g. a mobile phone changing the phone should not 429 naturally mean changing the identity. People tend to be lazy and 430 want to keep information as static as possible. So we would like to 431 introduce a new association that combines the device and SIM card 432 approaches. 434 We propose to bind the HIP ID to a kind of Virtual Device that would 435 represent a special entity like the web server of Vodafone, the mail 436 server of NEC, the mobile phone of user X or the home PC of user W. 437 We think that association would give the closest match with the 438 intention of the HIP goals. It would give the possibility to change 439 broken hardware (or move to a more powerful device) without changing 440 the identity. It would make multi-homing transparent and it would 441 also match the current usage of identities in the mobile 442 communication world. 444 8. HIP ID and HIT mappings 446 Since the HIP ID or its short form the HIT is only an identifier it 447 is useless without mapping it to a location. On the other hand the 448 HIP ID and its HIT are numbers and are as such only hard to remember. 449 Thus several lookup services are needed. 451 HIP IDs, and even HITs, are hard to remember since they are only 452 digits after digits, so you need a lookup service to resolve a 453 readable name like www.somewhere.com to a HIP ID or HIT. You could 454 use the good old Domain Name System (DNS) for this. Since this 455 information is rather static the current DNS is suitable for such a 456 kind of translation. 458 But with the HIP ID/HIT you only get the identity bound to that name. 459 The location of the identity is still unknown. Thus a second lookup 460 service is needed that resolves the identity to a location. That 461 location can be defined by several different means. The location can 462 be defined by an IP address, an IMSI signal in a mobile phone network 463 or any other means. 465 In the case of IP addresses the DNS could be used again to map the 466 identity to a location. But if you want to support mobile nodes that 467 move rather frequently then the DNS could get to slow and inflexible 468 to support such a mapping. Even if you allow dynamic DNS where 469 clients can update their location the propagation delay is too high. 470 If mobility is important new technologies like Distributed Hash 471 Tables (DHT) are the better choice. 473 That is also true for mobile phone networks. In mobile phone 474 networks services like DHT or other existing services could be used 475 to map the HIP ID/HIT to the current location of the mobile device. 476 Note, however, that some first implementation experiences show some 477 performance problems with DHTs. 479 To summarize we must state that the mapping of HIP IDs/HITs is two- 480 fold. To be used and memorized by humans you need a name to HIP ID/ 481 HIT mapping that could be well performed by the existing DNS. But to 482 map the HIP ID/HIT to the current location of the Virtual Device a 483 new system is needed in order to support all the features HIP is 484 offering. DHT could be such a service in the IP world, but other new 485 mechanisms are studied in the research arena. Some existing services 486 may be used in the mobile phone world. 488 9. Privacy implications with HIP 490 Currently, the base HIP architecture does not support location 491 privacy. Location privacy is the capability of preventing other 492 parties from learning one's past or current location. In the current 493 HIP architecture, the resolution of a remote Host Identifier to its 494 current locater can be done in various ways. With HIP, the locater 495 parameter usage on the base exchange and mobility update procedures 496 discloses the current set of IP addresses (locater) used by the 497 communicating HIP nodes [3]. 499 Since in many large scale operator deployments, the IP address 500 basically tells you something about what operator or ISP you are 501 with, but you are not able to derive the geographic location. For 502 smaller scale deployment this does not hold. 504 Since the HIT of the other communication party is known, any entity 505 the Host Identifier is associated with (see above), will be known. 506 For VoIP deployment that is actually useful in many cases. 508 In summary there are no specific HIP related privacy issues, but the 509 typical ones know from the Internet. Additionally, using a rendez- 510 vous server not only for mobility purposes, but also for hiding its 511 current location. This would mean, that the rendez-vous server needs 512 to be improved towards running the complete communication over that 513 rendez-vous server. 515 On issues that arises and that is new with HIP is the traceability of 516 the HIT. Since the HIT (if not used in opportunistic mode) never 517 changes an attacker could try to follow the HIT and record all the 518 places the user visits. Thus an attacker would at least be able to 519 evolve a kind of profile of the user. 521 10. Problem of using DNS in the HIP architecture 523 If HIP should support mobility the current DNS system is not capable 524 to keep up with the speed of change needed for such an application. 525 The propagation of the DNS entries is to slow for frequent location 526 updates. Another issue with DNS is still the security problem. How 527 can I trust my DNS server if all users are allowed to change data on 528 it? 530 EDITOR NOTE: This section must be elaborated further. 532 11. Free Choice of Access Technology 534 A device like a mobile phone may have more than one network 535 interface, each one connected to the same or to a different service 536 provider network or Autonomous System (AS) via different access 537 technology bearers (e.g. UMTS, WiMax, WLAN or even a fixed access). 538 In that case the device is termed as a multi-homed-host. 540 In the IP world, every AS has its own IP addressing plan (public and 541 private) and consequently the device's interfaces can have multiple 542 and different IP addresses. Since an IP address defines the location 543 of an end-system (host) in the Internet, in that case the device 544 seems to be located in different locations within the network. 546 On the other hand, HIP provides a decoupling between the inter- 547 working and transport layers. The IP address does not longer define 548 both the location and the host identity, but only the location of the 549 host in the network. In case of multi-homing, the HI (Host Identity) 550 is used as the end-point (device) identity, while at the same time 551 the IP address represents the topological location of the device 552 within the network. This is the normal approach, since IP will be 553 used only for the purpose that it was initially designed: the routing 554 of data to their destinations. 556 A simple scenario is presented in the following figure. 558 Person Equipment Number IP Service Service 559 of i/fs addr Provider 561 User ----> UE1 ---> i/f1 ----> IP addr1 -> SP1 (e.g. Voice) 562 | 563 +-> UE2 +--> i/f1 ----> IP addr1 -> SP2 (e.g. Surveillance) 564 | +--> i/f2 ----> IP addr2 -> SP2 (e.g. Emergency) 565 | 566 +-> UE3 +--> i/f1 ----> IP addr1 -> SP1 (e.g. Voice) 567 | +--> i/f2 ----> IP addr2 -> SP1 (e.g. WWW) 568 | +--> i/f3 ----> IP addr3 -> SP1 (e.g. Intranet) 569 | 570 +-> UE4 +--> i/f1 ----> IP addr1 -> SP3 (e.g. Gaming) 571 +--> i/f2 ----> IP addr2 -> SP4 (e.g. TV/Video) 573 Figure 1: User ordinary scenario. 575 A user has multiple devices (UEs) each one having a number of 576 interfaces. In every interface an IP address is assigned (public or 577 private) defining in that way the service provider (SP) offering the 578 bearer and/or the service. This is a very possible scenario since 579 most of the people today hold a number of devices. One can easily 580 determine that the HI can be used to easily define the user equipment 581 identity in case the UE has more than one i/fs (e.g. in UE2, UE3 and 582 UE4). In this case one HI is used per UE. 584 With HIP support, a Network Operator or a Service Provider in order 585 to provide services to the user of the end-point, needs first to know 586 his/her identity in order to authenticate the host and finally the 587 user. The storage of the private keys and HITs in a network element 588 (e.g. HLR/AuC in mobile world) is an issue for further study. 590 The associations are now being established at a higher layer (the HIP 591 layer). Even in case of an IP address change, the association (and 592 of course the communication session) is kept alive because the 593 transport layer (e.g. TCP) is intact from the change. The socket 594 call is now in the following form: 596 {tcp, source HIT, source port, dest HIT, dest port} 598 No IP address is used anymore and in turn the transport layer is 599 becoming independent from the IP layer. 601 Moreover, due to the possibility of different access technology 602 support, the applications shall have different QoS guarantees than 603 device's interfaces can provide in accordance to the Operators 604 offered user services. For instance, from a 3G interface the user 605 can make rich voice and video calls, while from the WiFi interface 606 the user can have wireless access to a corporate LAN via an access 607 point and from there to a Web/Email/FTP Server. All of these 608 services can occur simultaneously with no QoS degradation, a usual 609 phenomenon occurred in ordinary communication bearers because the 610 bearers are now independent and optimized for the service that they 611 intend to support. The device has now the possibility to 612 simultaneously use multiple access technologies, to reach different 613 contents. Each access technology is used to transport the traffic 614 for which it is most suitable. 616 The access technology selection procedure could be done by a control 617 function located in an operator network element or the device logic 618 itself, based on different criteria or a combination of them (e.g. 619 decrease in the communication session quality, session content, 620 charging tariffs etc.) 622 With the assistance of HIP, another option is that an operator can 623 reroute the content transfer session, already established via a 624 certain interface over the most appropriate access technology and 625 consequently to another interface, depending on quality measurements 626 performed by a control function installed on the operator network 627 and/or the device can be able to initiate the session handover over 628 another access bearer. 630 In case that the bearers supported by the device are provided by 631 different operators (as depicted in Figure 1), then a session 632 handover between two different AS is occurred. In that case, HITs 633 storage and transport, security and QoS issues shall be carefully 634 examined. 636 What is happening in a case where the session transfer shall be moved 637 towards a new UE (e.g. due to battery outage in a mobile phone)? One 638 possible solution is that the HLR/AuC shall keep in its database all 639 the mappings between the user UEs, HIs and private keys. In a case 640 of a session transfer towards the new UE a session transfer mechanism 641 (located in the device and/or the network) shall trigger the session 642 transfer procedure. 644 In case that the new UE i/f IP address is belonging to a different 645 network operator, then inter-AS and inter-UE session handover shall 646 be performed simultaneously. 648 The session transfer is for further study. 650 12. IANA Considerations 652 This memo includes no request to IANA. 654 13. Security Considerations 656 Currently there are no Security Considerations within this document. 658 14. Informative References 660 [1] 3GPP, "Overall high level functionality and architecture impacts 661 of flow based charging; Stage 2", 3GPP TS 23.125 6.6.0, 662 October 2005. 664 [2] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. 666 [3] Matos, A., "Host Identity Protocol Location Privacy Extensions", 667 draft-matos-hip-privacy-extensions-00 (work in progress), 668 July 2005. 670 Authors' Addresses 672 Thomas Dietz 673 NEC Network Laboratories 674 Kurfuersten-Anlage 36 675 69115 Heidelberg 676 Germany 678 Email: dietz@netlab.nec.de 680 Marcus Brunner 681 NEC Network Laboratories 682 Kurfuersten-Anlage 36 683 69115 Heidelberg 684 Germany 686 Email: brunner@netlab.nec.de 688 Nick Papadoglou 689 Vodafone Group Services Limited 690 Voafone House 691 The Connection 692 Newbury, Berkshire RG142FN 693 Great Britain 695 Email: Nick.Papadoglou@vodafone.com 697 Vasilios Raptis 698 Vodafone Panafon 699 1-3 Tzavella Str. Chalandri 700 15231 Athens 701 Greece 703 Email: Vasilios.Raptis@vodafone.com 705 Kostas Kypris 706 Vodafone Panafon 707 1-3 Tzavella Str. Chalandri 708 15231 Athens 709 Greece 711 Email: Kostas.Kypris@vodafone.com 713 Intellectual Property Statement 715 The IETF takes no position regarding the validity or scope of any 716 Intellectual Property Rights or other rights that might be claimed to 717 pertain to the implementation or use of the technology described in 718 this document or the extent to which any license under such rights 719 might or might not be available; nor does it represent that it has 720 made any independent effort to identify any such rights. Information 721 on the procedures with respect to rights in RFC documents can be 722 found in BCP 78 and BCP 79. 724 Copies of IPR disclosures made to the IETF Secretariat and any 725 assurances of licenses to be made available, or the result of an 726 attempt made to obtain a general license or permission for the use of 727 such proprietary rights by implementers or users of this 728 specification can be obtained from the IETF on-line IPR repository at 729 http://www.ietf.org/ipr. 731 The IETF invites any interested party to bring to its attention any 732 copyrights, patents or patent applications, or other proprietary 733 rights that may cover technology that may be required to implement 734 this standard. Please address the information to the IETF at 735 ietf-ipr@ietf.org. 737 Disclaimer of Validity 739 This document and the information contained herein are provided on an 740 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 741 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 742 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 743 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 744 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 745 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 747 Copyright Statement 749 Copyright (C) The Internet Society (2005). This document is subject 750 to the rights, licenses and restrictions contained in BCP 78, and 751 except as set forth therein, the authors retain all their rights. 753 Acknowledgment 755 Funding for the RFC Editor function is currently provided by the 756 Internet Society.