Issues of HIP in an Operators Network

Nick Papadoglou

Thomas Dietz

Overview

• Charging• LI• SIP and HIP; How can one improve the other?• HIT creation, bootstrapping and distribution• HIP associations• DNS• Choice of Access Technologies• Open Issues

Charging Issues• HIP has P2P semantics• NO’s need flexible charging models:

– On/off-line charging– Volume and/or time based charging

• Problem/Restriction:– It arises when an E2E encrypted tunnel exists between end-hosts– Charging function can not apply different policies based for example on different

media type. – Hence, for existing and future services only volume or time based charging can

be applied. • Potential Solution(s):

– Break the e2e security association and terminate it at a network sub-element where the CF may be applied

– CF to obtain/poses the keys of the sessions established. (Scalability issues)– Accept this as a de-facto standard and apply only volume/time based charging– Introduce a kind of HIP signalling that indicates the service/media type

Lawful Intercept

• National laws define local intercept requirements. • The base requirement would be for the interceptor to be

in the path of the HIP exchange, as well as on the data path.

• Issues/Problems similar to charging• Potential solution:

– Accept the breakage of e2e security– Keys known by the operator

• Though, if keys are owned (generated) by the user (device) the NO may not be liable for the communication

How HIP could improve SIP• Open issue whether HIP actually improves the operation of SIP• Currently only one-level mapping between SIP URI to IP address (static or

dynamic)• If HIP present then

– SIP URI to HI– HI to IP address

• 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 may require 2 DNS requests 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 HIT 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.

How HIP could improve SIP (cont.)

• HIP could be used to setup the IPsec security associations, but the response time increases due to the processing for the HIP base exchange.

• SIP can offer terminal mobility through the re-registration 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 either 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.

• HIP inherently provides mobility support to the higher layers without requiring optional SIP features.

• Hence, Even though 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.

How HIP could improve SIP (cont.)

• SIP extensions enable SIP connectivity between hosts behind NATs and firewalls.

• Finally, 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.

How SIP could improve HIP

• How to trustfully obtain a HIT?– Avoid using opportunistic mode

• Can use SIP signalling methods– Include HIT in SIP Invite/Ack (extend SDP

field)– Part of the Presence information– Other…

• Possible use of SIP proxy/registrar as HIP rendezvous server

HIT creation, bootstrapping and distribution

• HI’s can be created by the end device– Limits its use by an operator

• HI’s can be either public or anonymous– Public offers also some authentication

principals– Anonymous offers privacy

• HI’s can be short term or long term (static)– Short term offer some privacy

HI’s associations: The Possibilities

• Association with the most common entities– This is not an exhaustive list

• Binding of HI with either/and:– Device/User Terminal– Network Interface– Person/User– Session– SIM

HI’s associations: The Proposal

• Bind the HI with the device.

• Associate the device with SIM, FQDN/SIP URI, IP address etc.

• Maintain the semantics of HIP

HI

Logical AssociationActor (Legal entity)

User Level Descriptor User readable

Device Physical Entity

Network point of attachment Locator Identifier

8

1

1

1

8

1

Host ID End-point Identifier

8

8

Use of DNS in a HIP architecture

• Main issue is for Mobility (well Known)

• Problem: If mobility factor is high and the end-host needs to update the binding between HI and Locator.

• One Possible Solution: Use of Dynamic DNS

• Outcome: Still this is inefficient.

Free choice of Access NetworkPerson 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)

Free choice of Access Network (cont.)

• Benefits are:– Split of Identifier and Locator enabling binding in a

higher layer– Storage of HI and HIT in a secure network element

(HLR/AuC) with binding to IMSI for authentication/authorisation of user as well as the introduction of multihoming and better delivery of services based on Access Network capabilities (e.g. QoS).

• Open Issues– Handover between different NP and SP– Handover between 2 UE’s– Binding between different elements

Open Issues

• Binding associations between HI (HIT) and other identifiers (locators) within a Network Operator and Service Provider networks

• Charging/LI

• Mobility and DNS

• Bootstrapping/distribution and privacy concerns.

• How do we proceed further?

Thank You