2.5.1 Host Identity Protocol (HIPRG)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Current Meeting Report

HIP-RG meeting minutes, Nov. 11, 2005, Vancouver (IETF 64)

The HIP RG met on Nov. 11, 2005, from 12:30 to 3PM (after IETF 64 
meeting).  Tom Henderson chaired the meeting (co-chair Andrei Gurtov 
could not make this meeting).  There were 40 attendees.

Three new drafts wre reviewed; one on the use of SIP presence data to 
convey HITs, one describing possible operator issues with deploying HIP, 
and one on the use of a TCP option for opportunistic HIP.  In addition, 
the RG heard about updates to the legacy NAT/middlebox traversal draft, 
the HIP-aware middlebox traversal draft, the draft on the use of SRTP as 
a HIP transport, and the draft on using SIP to convey host identities.

The meeting agreed that draft-tschofenig-hiprg-hip-natfw-traversal-03.txt 
could be advanced to the state of RG draft, pending discussion on the 
mailing list.  

At the end of the meeting, Tom Henderson reviewed the status of the 
various public HIP implementations, and asked for ideas on what people 
would like to see next with HIP software and experiments.  He emphasized 
that the RG is primarily interested in moving beyond basic 
interoperability and software stability, to actual experiments using HIP 
to solve practical (security, mobility performance, reachability) 
networking problems.  The meeting participants provided a number of ideas 
for future experiments, discussed below.

Administrative and agenda discussion

Experiment report status
- draft-irtf-hip-experiment-01.txt

- draft-papadoglou-hiprg-hit-presence-00.txt  (new draft)
- draft-tschofenig-hiprg-hip-srtp-01.txt (update)
- draft-tschofenig-hiprg-host-identities-02.txt (update)

Legacy NAT/middlebox traversal  (update)
- draft-irtf-hiprg-nat-00.txt

Advanced NAT/middlebox traversal  (update)
- draft-tschofenig-hiprg-hip-natfw-traversal-03.txt

Issues of HIP in an Operator's Network
- draft-dietz-hip-operator-issues-00  (new draft)

Opportunistic HIP (Miika Komu)
- draft-lindqvist-hip-opportunistic-00.txt (new draft)

HIP software review, demos, and discussion

Detailed minutes (compiled by Tom Henderson)

1.  Agenda and Experiment Report
Tom reviewed the HIP experiment report, intended to summarize the HIP 
RG's findings on the impact of deploying HIP.  He stated that there had 
not been an update since July.  Aaron Falk (IRTF chair) encouraged that 
there should be another update before the next meeting cycle, and Tom 
agreed to take that as an action item.

2.  SIP and HIP
There were three drafts presented on the subject of SIP and HIP 
integration.  Nick Papadoglou from Vodaphone proposed the use of the 
Presence Information document as a means to disseminate HITs between 
hosts.  He argued that there were several potential benefits from this 
approach, such as the ability to dynamically change HITs if needed, the 
conveyance of knowledge about the peer's support of HIP, and possible use 
as a unique device identifier.  He cited some open issues with respect to 
current SIP security model (authentication, interaction with SIP 

Gonzalo Camarillo:  Presence authorization rules-- any reason you might 
want to hide your HIT?

Pekka Nikander:  If you have secure SIP/presence infrastructure, makes 
sense to try to leverage it.

Steve Norreys:  How long are the HIT lifetimes?  (answer:  same amount of 
time that presence info is valid.  Roaming is not part of this).  How 
does SIP forking interact?  (answer:  we did not address forking)

Jari Arkko:  Like this approach; encourage more work on details.  Is 
presence information uniform or can you vary which HIT is visible to 
which peer?  

Hannes Tschofenig:  Under presence authorization framework, you can vary 

Tom:  What scenarios do you envision that HIT is frequently changed?

Nick:  Operator doesn't want HIT to be statically bound to a device.

Andrew McGregor:  (explained one case where HITs are likely to be 

Haris Zisimopoulos (co-author of draft):  Presence data combines multiple 
views of the data.

Steve:  Question on dynamic updating of presence model.  Last thing that 
you want in an emergency is for presence to change.  Keep this in mind.

Pekka:  Would like a operational view of how to use this, or does there 
seem to be any problem?

Hannes Tschofenig next introduced the SIP and HIP (and SRTP) drafts and 
stated that these drafts have not solicited the desired feedback from the 

Tom:  What is the specific benefit that HIP provides to SIP, in your 

Hannes:  Good to have locator/id split at endpoints to enhance mobility 
of media streams-- not to replace SRTP security.

Nick:  I'm not seeing the benefits of holding multiple HITs on the device 

Pekka:  There is a deliberate vagueness of what is a "host" in HIP-- a 
single device can host multiple "hosts"

Nick:  What is the relationship between SIP URI and HIT?  One-one or one-

Hannes:  We don't make any assumptions.

Pekka:  The SRTP transport probably needs something like PF_KEY for IPsec.  

Hannes:  What next for SIP drafts?

Tom:  Would like to organize currently contributed SIP material to 
summarize i) applicability statement, ii) operator issues, iii) benefits 
expected from HIP + SIP, and iv) open issues.  Not ready for moving out 
of RG to SIP or HIP WGs.  Would like to encourage those people doing 
mobility experiments to contribute results.

3.  HIP and legacy NAT traversal
Lars Eggert introduced the draft problem statement on legacy NAT 
traversal.  This document could be candidate to move to the WG if it 
recharters to cover the problem.

Pekka:  There was a call-home BOF this meeting where Jonathan Rosenberg
described four mechanisms necessary to talk through a NAT (connection, 
registration, keep alive, and message formats).  This document should try 
to coordinate with him and with the IAB draft on NATs-- provide diffs 
against the more general cases of those drafts.

Hannes:  This could also apply to the HIP NAT traversal solution draft, 
and also the advanced HIP-aware draft.

Pekka:  Also consider expanding the scope of this work to include SRTP 
and shim6 variants.

4.  HIP-aware firewalls
Hannes Tschofenig introduced the update of this draft and requested more 
feedback from the RG on it.  At the end of the discussion, the RG decided 
to take the draft as a RG draft, pending discussion on the mailing list.

Pekka: Realised that we need to differentiate between current type of NATs 
that change addresses without the peer hosts' explicit consent, and new 
types of architected NATs that change addresses under explicit control 
or co-operation with end hosts.  Looking for new name for the latter 
boxes, perhaps TANN (Translating Addresses not NAT), but discussion still 
going on.

5.  Operator issues of deploying HIP
Nick Papadoglou introduced this draft, which generated a lot of 
discussion.  The sections concerning lawful interception and the 
operator's dislike of end-to-end encryption drew a lot of comments.  In 
the slides, Nick described how an operator (with control of the devices) 
might deploy and use host identities, and the various open issues.

Pekka:  Would like to see i) legitimate use cases for not supporting end-
to-end communications, and ii) incentives to add flexible charging

Steve:  Disagree with draft stating that operator needs to be able to 
charge on content.  Operators need to exchange accounting info only.  
Don't see how content-based charging can work in practice.

Steve:  This goes beyond lawful interception to also include regulatory 
issues for emergency services.  

Pekka:  Some of these issues can be handled without breaking the protocol, 
using more advanced concepts such as delegation.

Nick:  Operator needs to have the keys used by the endpoints-- otherwise 
will not deploy.  IMEI is terminal unique identifier-- operator could 
bind a HIT to that.  From operator perspective, want to bind host 
identity to device in a one-to-one mapping.

James Kempf:  Key escrow is what you want.  Note that identity-based 
crypto (based on SIP URI) may also work here.

Jordi Palet:  Have written a book on legal aspects of deploying IPv6 that 
is relevant to this discussion.

Tom:  Thanks to authors for contributing this-- would like to encourage 
contributions with perspectives like these to come to the RG.  

Nick:  Will revise draft in future.

6.  Opportunistic HIP
Miika Komu presented on behalf of Janne Lindqvist.  The basic idea is to 
piggyback the HIT as a TCP option, to avoid sending separate I1, with 
fallback to normal TCP handshake.  A more complicated piggybacking scheme 
was in the draft but not presented and is not recommended at this time.

Lars Eggert:  Don't like this as a TCP option because it doesn't belong 
in the transport-- would rather it be an IP option.  At least for IPv6 
(end-to-end option)-- IPv4 is more problematic.

Pekka:  I potentially like this type of optimization-- would like to 
encourage implementation and experiments.

7.  HIP software and experiments
Tom Henderson reviewed the status of the various public HIP 
implementations, and asked for ideas on what people would like to see 
next with HIP software and experiments.  He emphasized that the RG is 
primarily interested in moving beyond basic interoperability and software 
stability, to actual experiments using HIP to solve practical (security, 
mobility performance, reachability) networking problems.  

Tim Shepard:  Road warrior (leave home to come to IETF and keep your 
sessions alive across the mobility event)

Pekka:  Work going to make IETF tools server available via HIP

Andrew:  Open source competitor for Skype

(Andrew or Tim?):  Jabber server

Lars:  T/TCP integration with HIP

Pekka:  IPv4 to IPv6 roaming (were several times at meeting that I could 
not get IPv4 address but could get IPv6 address)


HIT Exchange in Presence Data
HIP and SIP Update
Legacy Middlebox Traversal
HIP-Aware Middlebox Traversal
Operator Issues with HIP
Opportunistic HIP