Internet DRAFT - draft-dietz-hip-operator-issues
draft-dietz-hip-operator-issues
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]
