Last Modified: 2005-01-17
| Done | First version of the HIP basic mobility and multi-homing mechanism specification. | |
| Done | First version of the HIP DNS resource record(s) specification. | |
| Done | First version of the HIP basic rendezvous mechanism specification. | |
| Dec 04 | WGLC on the HIP architecture specification | |
| Jan 05 | Submit the HIP architecture specification to the IESG | |
| Mar 05 | WG LC on the base protocol specification | |
| Mar 05 | WG LC on the base protocol specification | |
| Apr 05 | Complete the base protocol specification and submit it to the IESG for Experimental | |
| Done | WG LC on the HIP basic mobility and multi-homing specification. | |
| Apr 05 | WG LC on the basic HIP rendezvous mechanism specification. | |
| May 05 | Submit the HIP DNS resource record(s) specification to the IESG for Experimental. | |
| May 05 | Submit the HIP basic mobility and multihoming specification to the IESG for Experimental. | |
| May 05 | Submit the basic HIP rendezvous mechanism specification to the IESG for Experimental. | |
| May 05 | Recharter or close the WG. |
|
Minutes HIP WG at IETF 62
Minutes edited by Gonzalo Camarillo Based on notes by Miika Komu and Christian Vogt Meeting chaired by Gonzalo Camarillo and David Ward WEDNESDAY, March 9, 2005, 1300-1500 Topic: Agenda Bash by chairs There were no comments on the agenda. Architecture draft: there was consensus in the room to address the IESG comments and publish this document as a snapshot of our understanding of the HIP architecture in 2003. In the future, nothing prevents us to review this work, but at this point we only want to publish this snapshot and focus on the rest of our charter items. Topic: Base spec Discussions led by: Pekka Nikander Relevant documents: draft-ietf-hip-base-02.txt draft-jokela-hip-esp-00.txt Publishing these two drafts is the highest priority of the WG. Pekka will discuss how to use multiple hash functions on the list. The hash function being used may be identified using the top most bits of the HITs. There were discussions on how to support devices that will not use IPsec but may want to use HIP mobility (e.g., VoIP devices using SRTP). The feedback received from the IESG so far is that we need a MUST implement in the spec for interoperability reasons. The chairs need to ask the security ADs what they think about allowing HIP to use IPsec with null encryption. Further discussions needed on the list. Consensus in the room to take the current ESP draft as a WG item. Topic: Generalising HIP Discussion led by: Thomas Henderson Relevant document: draft-henderson-hip-generalize-00.txt The focus of the WG is on stabilizing the spec. Generalising is good, but for the future. Pekka Nikander's proposal: study what it takes to introduce proposal number one (other identifiers) and to allow an easy introduction of new packets at a later point so that people can reuse HIP. If it can be done and still WGLC the document before Paris, we do it. Thomas accepted the proposal. Topic: Using HIP with Legacy Applications Discussions led by: Thomas Henderson Relevant document: draft-henderson-hip-applications-00.txt Until we finish some of our current charter items, the WG will not take any new WG items. Thomas will take this work to the research group. Topic: Credit-Based Authorization for HIP Mobility with Concurrent IP-Address Tests Discussions led by: Christian Vogt Relevant document: draft-vogt-hip-credit-based-authorization-00.txt Until we finish some of our current charter items, the WG will not take any new WG items. The WG will study whether it makes sense to incorporate some of these ideas to the mobility draft. Topic: End-Host Mobility and Multi-Homing Discussions led by: Thomas Henderson Relevant document: draft-ietf-hip-mm-01.txt Thomas has a volunteer to work on the security section of the draft. We need more implementation experience with this spec. Topic: HIP Registration Extensions Discussions led by: Julien Laganier Relevant document: draft-koponen-hip-registration-00.txt Only a few people had read the document. More people should read it. Topic: HIP Rendezvous Servers Extensions Discussions led by: Julien Laganier Relevant document: draft-ietf-hip-rvs-01.txt Hannes will send comments on this draft to the list and discuss it in the research group meeting. Topic: HIP DNS Extensions Discussions led by: Julien Laganier Relevant document: draft-ietf-hip-dns-01.txt Further discussions on the list needed on the issue of sending an I1 to a HIT and receiving a different one in a R1. Doing this may not be a good idea. End of the meeting. The following is a detailed log of the conversations that took place during the meeting. Pekka Nikander: base spec ------------------------- Pekka: What would we do with SHA? The weakness in the SHA-1 is that is more not so secure. There is no hurry with this. Alternative solutions: use SHA-256 or HMAC to create a HIT. Probably 90 bits would enough, so 128 is more than enough. Or use multiple hash functions: my proposal is that we encode the hashing function to the topmost bits in a HIT. Now if we do this, we can code this so that the HIT prefix prevents collisions with IPv6 addresses. Feedback? Suggest defining the exact number of bits on the mailing list. I see some nods, so I think it is ok. Pekka: Update the implementations. DL May. Pekka Nikander: hip esp draft ----------------------------- Pekka: ESP still mandatory. Discuss on the mailing list. Pekka: open issues. Is it useful to model this this way. Some people said that it is not currently written good enough. Second question, is this a must implement? Gonzalo: MUST implement (for IESG) Thomas: I have been arguing about the must-use ESP. Some people use light weight devices. Make ESP-NULL mandatory? Gonzalo: definitely need a common ground. May have two implementations that do not interoperate. IESG feedback was this. Pekka: the ESP-NULL is only for testing. We can say that we are not doing IPsec to avoid conflicts with IPsec specs. We have to discuss with the security ADs. Jari Arkko: it is probably a problem that we are not using standard ESP. Pekka: I don't have a opinion on the ESP-NULL. Thomas: HER and HES have a one-to-one mapping, so it is a unnecessary abstraction? Arkko: don't use the conceptual layers if don't need them. Pekka: the next steps. Do people feel that it is well baked? Can we adapt this as a working group item? Gonzalo: we wanted to go through the formal procedure. Ask the working group. Please HUM now if you want this as a working group item. Nobody opposed. Thomas Henderson: Generalizing HIP ---------------------------------- Gonzalo: Opinions? Pekka: not directly answering to this. Let's take a step back. Two related issues in the draft. First, we can make some changes that make the protocol multipurpose. Second, we can define packet formats in a separate draft. I don't understand whether Tom wants just the other or both of these. Keep the base spec as it is, and not make HIP a profile of a carrier protocol. Doing another split requires rechartering. Encourage completing the base spec, so that other people can reference to it. Keep HIP as a separate protocol and do not generalize it. Hannes: some of things you show on the slides require big modifications. Don't think this a good idea. There more categories to be worried about (resolving issues etc). Thomas: one motivation is to find a good transition mechanism for HIP. Other people are interested in HIP, but some features are not required from them like for example non-routable identifiers. Tim Sheppard: what do you hope, do you think that we can do this before Paris? Thomas: Yes. We don't change the current design but rather the wordings in the draft. It does not change how the protocol is implemented, so implementing can be done easily. Tim: can the implementors make this in time? Gonzalo: (missed this comment) Tim: lot of value in getting base spec done. Gonzalo: Let's keep in the Paris schedule. Kempf: the problem with profiles is interoperability. If you don't have synchronized implementations, it is a problem. I was getting a feeling the last time that people want a stable spec. Nikander: I have a concrete proposals. Do #1: the write-up. There is room for non-HIP specifiers. Currently the HIP length is fixed, but should be some alternative fixed sizes. What comes to the other proposals, we can renumber the packets. This way, other people can reuse HIP protocol. Move everything else to the RG, edit and make a separate document. Tom: Pekka's proposal was good, so I'll do this. Thomas Henderson: API draft --------------------------- Pekka Savola: is this API something that is really required in the base spec? It delays the finalizing of the base spec. Thomas: it will not delay base space, this is a separate draft. Gonzalo: the main point is to get the base space completed. Keith: this will break applications. Does not work.... not much use if it is transparent. Pekka: the purpose of this wg is to experiment. I don't know if it works but it has some value. The purpose is to get an API that works without recompilation. Keith: this is not engineering. It does not work. We are recommending and building systems that actually work. Tim: disagree. Experimentation is essential too. Ward: I must remind the charter has not changed during the meeting. Tom: I wanted a home for this draft. Maybe RG is a better place. I was not going to ask whether this comes a WG action item. I am fine in doing this in RG. I'll raise the issue on the mailing list. Vogt: Credit Base Authorization ------------------------------- Vogt: interest to wg after the base spec is published? Add to mm draft? Julien: another simpler approach with only one RTT. Do the reachability check in parallel? Vogt: earlier discussion about this. Reregistration attack... Pekka: the proposal sounds good. But consider keeping the WG charter focused. Thomas: hip mm -------------- Thomas: discuss on the mailing list. Need some implementation experience. Security section needs work and a person has volunteered. Finished around November. Julien: registration extensions ------------------------------- Julien: adopt this as a WG item? Gonzalo: who has read this? (only few hands rise). Suggest that more people read this before making the decision. Julien: HIP rendezvous extensions --------------------------------- Julien: here is a basic protocol scenario. Pekka: I suggest telling the rendezvous type already in the registration parameter. Julien: Tunneling encapsulation feedback? Is it really necessary? Hannes: What do you want to tunnel? Julien: You may have an IPsec SA and send HIP messages in the tunnel. Hannes: Will send some comments on the list. Pekka: Running out time. I get the feeling that the previous (not this) is not well baked yet. Take the issue up on the RG meeting. Hannes: Align rendezvous and NAT signalling. Julien: DNS extensions ------------------------- Pekka: Just a clarifying question. DNS RR in I1 and also in R1. Julien: You say that it is bad to initiate to one HIT with I1 and receive a different in R1? Tim: The other end drops it. Julien: We have to discuss it further on the mailing list. |