Issues of HIP in an Operators Network

1
Issues of HIP in an Operators Network

• Nick Papadoglou
• Thomas Dietz

2
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

3
Charging Issues

• HIP has P2P semantics
• NOs 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

4
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

5
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.

6
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.

7
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.

8
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

9
HIT creation, bootstrapping and distribution

• HIs can be created by the end device
• Limits its use by an operator
• HIs can be either public or anonymous
• Public offers also some authentication principals
• Anonymous offers privacy
• HIs can be short term or long term (static)
• Short term offer some privacy

10
HIs 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

11
HIs 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
12
Logical Association
Host ID
End-point Identifier
13
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.

14
Free choice of Access Network

• Person Equipment Number IP Service
  Service
• of i/fs
  addr Provider
• User ----gt UE1 ---gt i/f1 ----gt IP addr1 -gt SP1
  (e.g. Voice)
• -gt UE2 --gt i/f1 ----gt IP addr1 -gt
  SP2 (e.g. Surveillance)
• --gt i/f2 ----gt IP
  addr2 -gt SP2 (e.g. Emergency)
• -gt UE3 --gt i/f1 ----gt IP addr1 -gt
  SP1 (e.g. Voice)
• --gt i/f2 ----gt IP
  addr2 -gt SP1 (e.g. WWW)
• --gt i/f3 ----gt IP
  addr3 -gt SP1 (e.g. Intranet)
• -gt UE4 --gt i/f1 ----gt IP addr1 -gt
  SP3 (e.g. Gaming)
• --gt i/f2 ----gt IP
  addr2 -gt SP4 (e.g. TV/Video)

15
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 UEs
• Binding between different elements

16
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?

17
Thank You