HIP-RG meeting minutes, Nov. 11, 2005, Vancouver (IETF 64) Overview -------- 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. Agenda ------ Administrative and agenda discussion Experiment report status - draft-irtf-hip-experiment-01.txt SIP and HIP - 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 certificates). 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 this. 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 changed) 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 RG. Tom: What is the specific benefit that HIP provides to SIP, in your view? 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 simultaneously. 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- many? 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) |