Internet Engineering Task Force T. Dietz Internet-Draft M. Brunner Expires: April 20, 2006 NEC N. Papadoglou V. Raptis K. Kypris Vodafone October 17, 2005 Issues of HIP in an Operators Networks draft-dietz-hip-operator-issues-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document discuss the potential issues that arise when the Host Identity Protocol (HIP) will be introduced in a operator network, especially in the IP Multimedia Subsystem (IMS) of the 3GPP systems. It discusses mobile network specific issues like charging, lawful Dietz, et al. Expires April 20, 2006 [Page 1] Internet-Draft Operator Issues October 2005 interception as well as common issues like where to associate the HIP ID or privacy issues. The document tries to make the HIP community aware of those issues and wants to stimulate discussion on those topics. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Charging Issues . . . . . . . . . . . . . . . . . . . . . . . 3 3. Lawful Interception . . . . . . . . . . . . . . . . . . . . . 5 4. How HIP could improve SIP . . . . . . . . . . . . . . . . . . 5 5. How SIP could improve HIP . . . . . . . . . . . . . . . . . . 7 6. HIT creation, bootstrapping and distribution . . . . . . . . . 8 7. HIP Associations . . . . . . . . . . . . . . . . . . . . . . . 8 8. HIP ID and HIT mappings . . . . . . . . . . . . . . . . . . . 10 9. Privacy implications with HIP . . . . . . . . . . . . . . . . 11 10. Problem of using DNS in the HIP architecture . . . . . . . . . 12 11. Free Choice of Access Technology . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 14. Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Dietz, et al. Expires April 20, 2006 [Page 2] Internet-Draft Operator Issues October 2005 1. Introduction This document presents some of the issues arising when the Host Identity Protocol (HIP) infrastructure is introduced in an operator networks architecture such as a 3GPP one. In those mobile networks and especially in the IP Multimedia Subsystem (IMS), HIP has to be integrated with systems used for charging, application proxies and registrars (SIP based) and may have to fulfill rules for lawful interception and the like. Further on the structure of mobile networks and its authentication methods are different from fixed networks. Thus the association of the HIP ID to e.g. a SIM card could make sense in this mobile environment. Also the privacy issues become more important in those networks than in fixed networks and the Internet. The document also tries to identify possible solutions in some of the areas and wants to stimulate discussion on the topics picked out in this document. Most of the sections present independent issues, but overall the document tries to cover all the different issues within an operator network the authors are aware of. 2. Charging Issues One of the most important aspects in the design of a network architecture for network operators as well as for service providers is the functions related to charging and tariffing. There are a number of models that need to be supported such as: o Volume based charging o Time based charging o Volume and time based charging o No charging Some of the functions/mechanism that the above charging models need to support are: o Pre-paid and post-paid o On line and Off line charging Most of the above models and mechanisms need to be supported by the Dietz, et al. Expires April 20, 2006 [Page 3] Internet-Draft Operator Issues October 2005 network architecture in order to allow the operator to design and apply flexible charging plans and differentiated tariffs. With the introduction of the TCP/IP suite in the wireless communications arena for transporting most of the data that services and applications generate means that a number of changes needed to take place in the systems and methods used so far in the circuit switched world. A new concept was introduced, known as IP flow based charging [1], which enables operators to maintain the current charging models even over IP. The idea is to have flexible mechanisms for creating new tariffs based on the different IP based services. For example, a network operator might want to be able to charge with different tariffs voice and video in a rich video call. In order to promote the service he might want to offer video for free and charge only the voice traffic. Hence, the video traffic is zero rated when it traverses the specific charging functions of the network based on a flow identifier. In order to be able to do this the operator needs mechanisms such as those introduced with IP based flow charging in 3GPP and other standardization bodies. The introduction of cryptographic Host Identifiers and in particular with the employment of the Host Identity Protocol (HIP) in an operator's network may raise issues with the current charging models and mechanisms. This is due to the fact that HIP is a P2P protocol enabling the negotiation and establishment of an encrypted tunnel between 2 hosts. Although this is a good way of establishing an end- to-end and secure communication channel (encrypted channel) end-to- end, it posses a number of issues with the existing charging model and mechanisms. When the traffic passing the charging function of a network is encrypted, then it is very difficult to apply different charging rules based on the type of the traffic, i.e. differentiate between voice and media traffic. Since the packets traversing the charging function are encrypted it not possible to look at the upper layers and apply different policies based on the media type, unless it possesses the keys in order to de-crypt the traffic. This restricts the charging plans that a network operator might want to deploy in the future based on the different service propositions available. The only available model from those outlined above that can be applied is volume based charging which offers no flexibility or differentiation of the service used. For this reason, there are three options foreseen solving this drawback. The first is to break the e2e security association and terminate it at a network sub-element where the charging function may be applied, and from there establish another one from this node to the end terminal/device. The second option is for the charging function to possess the keys of the sessions to be established and thus being able to decrypt the traffic and apply the different charging policies. The deficiency with this solution is that it Dietz, et al. Expires April 20, 2006 [Page 4] Internet-Draft Operator Issues October 2005 would probably not scale in a large scale network (e.g. an operator network) and that in some cases (e.g. anonymity) the keys will not be available to the charging function. Finally, the third and less desirable option is to accept this as a de-facto standard and apply only volume based charging although having a negative effect both to the customers and the operators business. 3. Lawful Interception Even though wire tapping has not been standardized or will be standardized in the IETF [2], we need to bring up the issue here. Countries around the world are drafting and enacting laws to regulate lawful interception procedures. National laws define local intercept requirements; the means and authority of conducting Lawful Intercept is often recorded in government legislation or regulatory mandates. Naturally, the base requirement would be that the interceptor is on path of the HIP base exchange as well as on the path of the data communication. Furthermore, in order to decrypt the data traffic the interceptor needs to have at least one of the private keys of the communicating end-points for extracting the IPSec session key for decrypting the data communication. Lawful Interception could use the first two solutions presented in the previous section with the charging issues. This assumes that the private keys are known by the operator or at least that the customers accept the breakage of end-to-end security. If the keys are generated by the user (device), it implies that lawful interception is not possible. In many European countries, this also means that the ISP is not liable for the voice communication. 4. How HIP could improve SIP SIP is an emerging signaling protocol that operates over the standard TCP/IP protocol stack. As such it should benefit from the use of HIP in the same way as the rest applications. Mobility support and improved security are the main advantages of using HIP. The scope of this section is to discuss whether and in what way HIP actually affects SIP. SIP uses URIs in order to identify hosts in the application layer. It uses additional infrastructure such as registrars, redirection and proxy servers. Security in SIP is handled by various techniques, e.g. IPsec, TLS. Additionally, a draft is under development in order for SIP to support session mobility. Therefore, with the Dietz, et al. Expires April 20, 2006 [Page 5] Internet-Draft Operator Issues October 2005 existence of these features, it is an issue worth of investigation whether HIP actually improves the operation of SIP with the decoupling of the network and transport layers. The main difference between the two proposed solutions is that SIP attempts to solve the problems in a higher layer than HIP does. With the current SIP architecture, the SIP URI is registered to an IP address (dynamic or static) in order to route the messages to the appropriate SIP agent. If HIP is present in the network, the mapping from the URI to HI should be supported as well as the mapping of HI to the IP address of the host. The mapping is usually accomplished through DNS servers. The one-level mapping between URIs and IP addresses is straightforward. On the other hand, the mapping in the case of HIP could be performed: Either through a two-level mapping (one DNS search for the mapping between URI and HI and an additional search for the HIT-IP mapping). This requires 2 DNS servers in the network and introduces additional delay for the delivery of the response. Or through a one-level mapping where the DNS search returns both the HI and the IP address. This technique requires additional storage space in the DNS server in order to be able to store the naming and addressing information in the same infrastructure. The work in IETF is focusing on this solution. It is clear that the use of HIP increases the needed time for DNS resolution and modifies the requirements for the DNS infrastructure. In regards to security, HIP could be used to setup the IPsec security associations. SIP security is accomplished through IPsec or higher (application) layer protocols. IPsec is open in man-in-the-middle threats when HIP is not used in a communication stream. As such the use of HIP shields the communication from similar vulnerabilities, but the response time increases due to the processing for the HIP base exchange. SIP can offer terminal mobility through the reregistration with the home registrar prior to a call. For mobility support in the middle of a call, the moving terminal sends a re-INVITE message directly to the correspondent host or via the SIP proxies. In order to shield the handover from security threats, SIP uses authentication or public key cryptography. The main constraint of SIP mobility is the inability of TCP to support session mobility. Even if a mechanism like M-TCP is used in order for mobility to be supported, the required time for the handover to be performed is considered high. On the other hand, HIP inherently provides mobility support to the higher layers without requiring optional SIP features. Even though Dietz, et al. Expires April 20, 2006 [Page 6] Internet-Draft Operator Issues October 2005 HIP does not offer any specific advantages to SIP session mobility, it provides mobility support to all higher layer protocols (SIP, HIP, HTTP, etc.) through a unified environment and doesn't leave this issue to be handled at higher layers which usually results in slower custom solutions. SIP extensions have been released to enable SIP connectivity between hosts behind NATs and firewalls. HIP is considered to be a better solution concerning NAT traversal for TCP connections since it decouples the transport from the network layer. Upon investigation of the previous issues, it is evident that HIP does not offer clear benefits since most of its features are supported through SIP extensions. On the other hand, HIP provides solutions to all these issues not only to the SIP protocol but to all higher layer protocols with slightly improved security. 5. How SIP could improve HIP There are various possible ways, where SIP could help with some problems of the current HIP and its deployment. The problem of trustfully getting the HIT of the other communication end-point is one of the problems. In most experiments today, opportunistic HIP is used for initiating the communication. The usage of the HIT DNS extension is quite some time ahead and not really securely deployed today. So in environments with walled gardens or relatively secure handling of SIP message exchanges, SIP could be used for getting the HIT from one end to the other. The HIT could be included in a SIP message, for example the INVITE, and securely sent to the host of the callee. This then would allow for a normal HIP base exchange and running the voice communication over a secured channel. A problem of deploying HIP is the missing HIP infrastructure. Specifically, infrastructure for NAT and firewall traversal and for mobility solutions using the rendez-vous server. Since the functionality of the rendez-vous server and a SIP registrar looks quite similar, a SIP registrar and SIP proxy could be used instead of the a rendez-vous server to lookup the current location (IP address) of a HIT, which has been registered using a SIP REGISTER message. So basically, the I1 packet is somehow encoded into a SIP message and the HIT would show-up in the SIP URI. In a more extreme case one would completely replace the HIP base exchange with a SIP based message exchange, containing the similar semantic as the HIP base exchange. Dietz, et al. Expires April 20, 2006 [Page 7] Internet-Draft Operator Issues October 2005 These ideas are just a first sketch where SIP could help to deploy HIP in a first stage. Further investigation should be made on this topic. There may be other issues where SIP could improve HIP at least in a first stage. 6. HIT creation, bootstrapping and distribution The HIP naming scheme is based on cryptographic techniques. IP addresses are decoupled from higher layer applications, while providing simultaneously security and the end hosts' authentication. The host identity in HIP is a public key which identifies a particular network stack and thus authentication is automatically enabled and the robustness to man-in-the-middle attacks is increased. Host identities can be either stored in public directories thus enabling the authentication of the hosts or can be anonymous in which case HIP can not provide authentication of the end host but only the encryption of the session with the given host. On the other hand, anonymous HIs offer improved privacy to the users, since the HI is only valid for the current connection and cannot be correlated to a specific user or host. Multiple distribution methods for host identities can be identified and used in practice. The method of distribution implies a specific association of the identity. o One HI per network interface o One HI per user terminal/device o One HI per person/user. The HIP Associations are discussed in greater detail in the following section. 7. HIP Associations There are several possibilities to associate a HIP ID to an entity. The HIP ID can be bound to a device or user terminal (PC, Server, etc.) which can include several network interfaces, to a network interface, to a person/user, to a session or to a SIM card (or something similar). The list could be continued but contains the Dietz, et al. Expires April 20, 2006 [Page 8] Internet-Draft Operator Issues October 2005 most common and most important cases. The association might depend also on other non technical arguments. These depend for example on whether charging is based on the HIP ID or not, whether a HIP ID locks a customer/device into one ISPs network or similar things. In the following section we will discuss the advantages and disadvantages of binding the HIP ID to one of those entities. It will conclude with a recommendation where such an ID should be associated to. The rest of the document will assume that the HIP ID is associated as recommended here if not stated otherwise. Binding to a Device/User Terminal: The most natural way of a HIP ID association would be to bind it to a device or user terminal. The goal of HIP is to separate identity and location. With binding the HIP ID to the device we would identify the device no matter where it currently is located. The identity would be independent of the interface on which the device is reached. This method provides mobility support since upon handover to a different access network or merely a change in IP address the TCP session is not terminated. The HI could either be static (built in by the manufacturer or assigned statically by the network operator) or dynamically created upon creation of the TCP session. Only through the static HI approach can the HIP-enabled nodes be globally identified (naming feature of HIP). The dynamic HI offers anonymity to the hosts even if the HI is globally unique. Binding to an Network Interface: If we bind the HIP ID to a network interface we would give a device that is multi-homed or incorporates several access technologies that could be used alternatively (e.g. a mobile phone with integrated WLAN) multiple identities. The idea of HIP was, besides separating identity from location, to make multi-homing transparent to the other communication partners. So binding a HIP ID to an interface would be contradictory to that goal and ongoing TCP sessions would be terminated if the host changes the used network. The only benefit from using HIP with this distribution method is the improved security over the existing TCP/IP approach. Binding to a Person/User: We could also bind the HIP ID to a person. But HIP IDs should resolve to a location and should also be used to connect to things like web servers, mail servers or other services. Also people usually use more than one device. This technique offers increased flexibility but on the same time the technical and business complexity increases, since it requires the system to be able to select which device the connection should be directed to. Also a method should be developed so as to correlate the multiple devices to the given user. Basically, this technique assumes that the user should be authenticated in any device based Dietz, et al. Expires April 20, 2006 [Page 9] Internet-Draft Operator Issues October 2005 on a username and password method in order to be able to use the various devices and dynamically direct the traffic to them. So binding to a person is not really helpful either. Binding to a Session: For completeness, we also mention the binding to a session. If we would bind the HIP ID to a session we would ease the migration of sessions between devices. But it would also mean that we would change the location and the device. That would also mean that a device could have multiple identities. That approach would only make sense in extreme cases like moving a service transparently from one device to another. Binding to a SIM Card: Binding the HIP ID to a SIM Card (or to something comparable) is the alternative to binding the ID to a device, especially in the world of mobile communication. Since all mobile devices that are used today are rather similar in their functionality the SIM Card could be used as a substitute of the mobile device of the SIM Card owner. So the recommended bindings for a HIP ID are binding it to a device or if we are in the mobile world binding it to a SIM Card. Both methods are valid and match the goals of the HIP architecture. On the other hand restricting the association of HIP ID to physical devices would introduce new problems and inconveniences. Changing the hardware would thus imply changing the identity. Especially if the device is e.g. a mobile phone changing the phone should not naturally mean changing the identity. People tend to be lazy and want to keep information as static as possible. So we would like to introduce a new association that combines the device and SIM card approaches. We propose to bind the HIP ID to a kind of Virtual Device that would represent a special entity like the web server of Vodafone, the mail server of NEC, the mobile phone of user X or the home PC of user W. We think that association would give the closest match with the intention of the HIP goals. It would give the possibility to change broken hardware (or move to a more powerful device) without changing the identity. It would make multi-homing transparent and it would also match the current usage of identities in the mobile communication world. 8. HIP ID and HIT mappings Since the HIP ID or its short form the HIT is only an identifier it is useless without mapping it to a location. On the other hand the HIP ID and its HIT are numbers and are as such only hard to remember. Thus several lookup services are needed. Dietz, et al. Expires April 20, 2006 [Page 10] Internet-Draft Operator Issues October 2005 HIP IDs, and even HITs, are hard to remember since they are only digits after digits, so you need a lookup service to resolve a readable name like www.somewhere.com to a HIP ID or HIT. You could use the good old Domain Name System (DNS) for this. Since this information is rather static the current DNS is suitable for such a kind of translation. But with the HIP ID/HIT you only get the identity bound to that name. The location of the identity is still unknown. Thus a second lookup service is needed that resolves the identity to a location. That location can be defined by several different means. The location can be defined by an IP address, an IMSI signal in a mobile phone network or any other means. In the case of IP addresses the DNS could be used again to map the identity to a location. But if you want to support mobile nodes that move rather frequently then the DNS could get to slow and inflexible to support such a mapping. Even if you allow dynamic DNS where clients can update their location the propagation delay is too high. If mobility is important new technologies like Distributed Hash Tables (DHT) are the better choice. That is also true for mobile phone networks. In mobile phone networks services like DHT or other existing services could be used to map the HIP ID/HIT to the current location of the mobile device. Note, however, that some first implementation experiences show some performance problems with DHTs. To summarize we must state that the mapping of HIP IDs/HITs is two- fold. To be used and memorized by humans you need a name to HIP ID/ HIT mapping that could be well performed by the existing DNS. But to map the HIP ID/HIT to the current location of the Virtual Device a new system is needed in order to support all the features HIP is offering. DHT could be such a service in the IP world, but other new mechanisms are studied in the research arena. Some existing services may be used in the mobile phone world. 9. Privacy implications with HIP Currently, the base HIP architecture does not support location privacy. Location privacy is the capability of preventing other parties from learning one's past or current location. In the current HIP architecture, the resolution of a remote Host Identifier to its current locater can be done in various ways. With HIP, the locater parameter usage on the base exchange and mobility update procedures discloses the current set of IP addresses (locater) used by the communicating HIP nodes [3]. Dietz, et al. Expires April 20, 2006 [Page 11] Internet-Draft Operator Issues October 2005 Since in many large scale operator deployments, the IP address basically tells you something about what operator or ISP you are with, but you are not able to derive the geographic location. For smaller scale deployment this does not hold. Since the HIT of the other communication party is known, any entity the Host Identifier is associated with (see above), will be known. For VoIP deployment that is actually useful in many cases. In summary there are no specific HIP related privacy issues, but the typical ones know from the Internet. Additionally, using a rendez- vous server not only for mobility purposes, but also for hiding its current location. This would mean, that the rendez-vous server needs to be improved towards running the complete communication over that rendez-vous server. On issues that arises and that is new with HIP is the traceability of the HIT. Since the HIT (if not used in opportunistic mode) never changes an attacker could try to follow the HIT and record all the places the user visits. Thus an attacker would at least be able to evolve a kind of profile of the user. 10. Problem of using DNS in the HIP architecture If HIP should support mobility the current DNS system is not capable to keep up with the speed of change needed for such an application. The propagation of the DNS entries is to slow for frequent location updates. Another issue with DNS is still the security problem. How can I trust my DNS server if all users are allowed to change data on it? EDITOR NOTE: This section must be elaborated further. 11. Free Choice of Access Technology A device like a mobile phone may have more than one network interface, each one connected to the same or to a different service provider network or Autonomous System (AS) via different access technology bearers (e.g. UMTS, WiMax, WLAN or even a fixed access). In that case the device is termed as a multi-homed-host. In the IP world, every AS has its own IP addressing plan (public and private) and consequently the device's interfaces can have multiple and different IP addresses. Since an IP address defines the location of an end-system (host) in the Internet, in that case the device seems to be located in different locations within the network. Dietz, et al. Expires April 20, 2006 [Page 12] Internet-Draft Operator Issues October 2005 On the other hand, HIP provides a decoupling between the inter- working and transport layers. The IP address does not longer define both the location and the host identity, but only the location of the host in the network. In case of multi-homing, the HI (Host Identity) is used as the end-point (device) identity, while at the same time the IP address represents the topological location of the device within the network. This is the normal approach, since IP will be used only for the purpose that it was initially designed: the routing of data to their destinations. A simple scenario is presented in the following figure. Person Equipment Number IP Service Service of i/fs addr Provider User ----> UE1 ---> i/f1 ----> IP addr1 -> SP1 (e.g. Voice) | +-> UE2 +--> i/f1 ----> IP addr1 -> SP2 (e.g. Surveillance) | +--> i/f2 ----> IP addr2 -> SP2 (e.g. Emergency) | +-> UE3 +--> i/f1 ----> IP addr1 -> SP1 (e.g. Voice) | +--> i/f2 ----> IP addr2 -> SP1 (e.g. WWW) | +--> i/f3 ----> IP addr3 -> SP1 (e.g. Intranet) | +-> UE4 +--> i/f1 ----> IP addr1 -> SP3 (e.g. Gaming) +--> i/f2 ----> IP addr2 -> SP4 (e.g. TV/Video) Figure 1: User ordinary scenario. A user has multiple devices (UEs) each one having a number of interfaces. In every interface an IP address is assigned (public or private) defining in that way the service provider (SP) offering the bearer and/or the service. This is a very possible scenario since most of the people today hold a number of devices. One can easily determine that the HI can be used to easily define the user equipment identity in case the UE has more than one i/fs (e.g. in UE2, UE3 and UE4). In this case one HI is used per UE. With HIP support, a Network Operator or a Service Provider in order to provide services to the user of the end-point, needs first to know his/her identity in order to authenticate the host and finally the user. The storage of the private keys and HITs in a network element (e.g. HLR/AuC in mobile world) is an issue for further study. The associations are now being established at a higher layer (the HIP layer). Even in case of an IP address change, the association (and of course the communication session) is kept alive because the transport layer (e.g. TCP) is intact from the change. The socket Dietz, et al. Expires April 20, 2006 [Page 13] Internet-Draft Operator Issues October 2005 call is now in the following form: {tcp, source HIT, source port, dest HIT, dest port} No IP address is used anymore and in turn the transport layer is becoming independent from the IP layer. Moreover, due to the possibility of different access technology support, the applications shall have different QoS guarantees than device's interfaces can provide in accordance to the Operators offered user services. For instance, from a 3G interface the user can make rich voice and video calls, while from the WiFi interface the user can have wireless access to a corporate LAN via an access point and from there to a Web/Email/FTP Server. All of these services can occur simultaneously with no QoS degradation, a usual phenomenon occurred in ordinary communication bearers because the bearers are now independent and optimized for the service that they intend to support. The device has now the possibility to simultaneously use multiple access technologies, to reach different contents. Each access technology is used to transport the traffic for which it is most suitable. The access technology selection procedure could be done by a control function located in an operator network element or the device logic itself, based on different criteria or a combination of them (e.g. decrease in the communication session quality, session content, charging tariffs etc.) With the assistance of HIP, another option is that an operator can reroute the content transfer session, already established via a certain interface over the most appropriate access technology and consequently to another interface, depending on quality measurements performed by a control function installed on the operator network and/or the device can be able to initiate the session handover over another access bearer. In case that the bearers supported by the device are provided by different operators (as depicted in Figure 1), then a session handover between two different AS is occurred. In that case, HITs storage and transport, security and QoS issues shall be carefully examined. What is happening in a case where the session transfer shall be moved towards a new UE (e.g. due to battery outage in a mobile phone)? One possible solution is that the HLR/AuC shall keep in its database all the mappings between the user UEs, HIs and private keys. In a case of a session transfer towards the new UE a session transfer mechanism (located in the device and/or the network) shall trigger the session Dietz, et al. Expires April 20, 2006 [Page 14] Internet-Draft Operator Issues October 2005 transfer procedure. In case that the new UE i/f IP address is belonging to a different network operator, then inter-AS and inter-UE session handover shall be performed simultaneously. The session transfer is for further study. 12. IANA Considerations This memo includes no request to IANA. 13. Security Considerations Currently there are no Security Considerations within this document. 14. Informative References [1] 3GPP, "Overall high level functionality and architecture impacts of flow based charging; Stage 2", 3GPP TS 23.125 6.6.0, October 2005. [2] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. [3] Matos, A., "Host Identity Protocol Location Privacy Extensions", draft-matos-hip-privacy-extensions-00 (work in progress), July 2005. Dietz, et al. Expires April 20, 2006 [Page 15] Internet-Draft Operator Issues October 2005 Authors' Addresses Thomas Dietz NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Email: dietz@netlab.nec.de Marcus Brunner NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Email: brunner@netlab.nec.de Nick Papadoglou Vodafone Group Services Limited Voafone House The Connection Newbury, Berkshire RG142FN Great Britain Email: Nick.Papadoglou@vodafone.com Vasilios Raptis Vodafone Panafon 1-3 Tzavella Str. Chalandri 15231 Athens Greece Email: Vasilios.Raptis@vodafone.com Kostas Kypris Vodafone Panafon 1-3 Tzavella Str. Chalandri 15231 Athens Greece Email: Kostas.Kypris@vodafone.com Dietz, et al. Expires April 20, 2006 [Page 16] Internet-Draft Operator Issues October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dietz, et al. Expires April 20, 2006 [Page 17]