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 Association Actor (Legal entity) User Level Descriptor User readable Device Physical Entity Network point of attachment Locator Identifier 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 Network 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)

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