2.3.12 Host Identity Protocol (hipbof) Bof

Current Meeting Report

Minutes, HIP WG, 59th IETF

Notes by Julien Laganier, Mika Kousa, Andrew McGregor, and Miika Komu.
Minutes edited by Gonzalo Camarillo.
Meeting chaired by Gonzalo Camarillo (David Ward did not travel to Seoul).

HIP Meeting, Wednesday, March 3, 2004, 1530-1730

Topic: Status
Slides presented: pres-ietf59-hip-chairs.ppt
Discussions led by: Chair

Supplemental web page at http://hip.piuha.net
Architecture document will be re-submitted as an individual submission.

Issue: Adopt draft-moskowitz-hip-09.txt as a WG item.
Conclusion: Strong consensus to adopt it as WG item.

Issue: We need an initial DNS draft.
Conclusion: Julien Laganier volunteered to write an initial version of the draft and Vijay <vijayak@india.hp.com> volunteered to help with the DNS RR editing.

Open Issues in the Base Specification
Relevant document: draft-moskowitz-hip-09.txt

Topic: Handling Re-Transmitted I2: Issue 23

Slides presented: pres-ietf59-hip-nikander-issue23.pdf
Discussions led by:  Pekka Nikander

Issue: HIP cannot handle R2 losses.
Discussion: The responder needs to move to the "Established" state when it receives ESP data, not when it sends R2 (R2 may get lost).
Conclusion: Pekka will send text adding this new state to the state machine to the mailing list. If we have consensus on the mailing list, this will be added to the base spec.

Topic: Resynchronization: Issues 12, 15, 19, 20, 22
Slides presented: pres-ietf59-hip-henderson-resync.ppt
Discussions led by: Thomas Henderson

Issue:Unkown incoming SPI because the host crashed and rebooted. What to do, discard the packet or restore state?
Discussion: It seems that IKEv2 defines an unauthenticated unknown SPI ICMP message that could be useful here.
Conclusion: Thomas will contact the IPSec folks to ask them about this issue. Depending on the conclusion, this maybe moved outside the base spec.

Topic: Reject Mechanism: Issue 21
Slides presented: pres-ietf59-hip-henderson-reset.ppt
Discussions led by: Thomas Henderson

Issue: do we need a message that notifies the sender that the message received was not acceptable? (instead of just dropping it silently).
Discussion: no comments.

Topic: APIs Issues
Slides presented: pres-ietf59-hip-henderson-api.ppt
Discussions led by: Thomas Henderson

Issue: How applications use HIP? Do we need an informational document defining a HIP API?
Conclusion: we need to understand how applications will use HIP (e.g., when can the kernel remove a HIT to IP address mapping).

Issue: do we need LSIs in the protocol?
Discussion: We could remove them from the spec. They only have local significance.
Conclusion: Discussions should continue on the list.

Open Issues in the Mobility and Multi-Homing Specification
Relevant document: draft-nikander-hip-mm-01.txt
Slides presented: pres-ietf59-hip-nikander-mm.pdf
Discussions led by: Pekka Nikander

Topic: Address Grouping
Clarification: address grouping is mainly for ESP replay protection. In IPSec they use a SA per QoS type, but they have not done multihoming.
Conclusion: Pekka will check whether or not this has any impact in the base spec or in the architecture document.

Topic: Return Routability
Conclusion: Andrew will submit text on RTT estimation in return routability.
Conclusion: Further discussion needed on the list.

Simple Rendezvous (I1 HIP-to-HIP routing)
Relevant document: draft-eggert-hip-rendezvous-00.txt
Slides presented: pres-ietf59-hip-eggert-rendezvous.pdf
Discussions led by: Lars Eggert

Note: the current draft has a wider scope than needed in the WG. That is, the draft contains WG material and RG material.
Clarification: Lookup service outside the scope of the WG.

Idea: DNS record with the RVS's (Rendezvous Server) address, instead of the host's address. Need a protocol so that the host can inform the RVS of its current location.

Conclusion: For the HIP DNS work, we should reuse IPSec work as much as possible.

Action Items
  • Petri to submit the next version of draft-moskowitz-hip-09.txt as a WG item.
  • Julien Laganier to release an initial version of the DNS draft.
  • Thomas to contact the IPSec folks to ask them about IKEv2 and how packets with unkown SPI are handled.
  • Pekka to check whether or not address grouping has any impact in the base spec or in the architecture document.
  • Andrew to submit text on RTT estimation in return routability.
Detailed Discussions

Topic: Status
Thomas: Modify the architecture document.
Pekka: The architecture isn't a WG item, it will be an individual submission published as informational.

Gonzalo: Adopt the base spec as a WG item -  draft-moskowitz-protocol-09?
Floor: strong consensus to take it as a WG item.

Gonzalo: We need an initial DNS draft.

Jose Rey: What about the IPR issues?
Pekka: There have been two kinds of IPR claims.  HIP shares some public key mechanisms with IKE, and Certicom has made claims on them. Those have been discussed in the IPsec WG, and the general opinion seems to be that they are not a problem in usual cases.  Additionally, some companies (don't remember which) have claimed IPR on the puzzle mechanism, but as far as I know, there seems to be prior art.  Other than that, I am not aware of any real or potential IPR claims. Furthermore, even in the mentioned two cases, there have been no specific IPR claims on the HIP drafts.

Gonzalo: A comment on the charter. This WG need to be very focused, deadlines are are pretty tough..

Open Issues in the Base Specification

Topic: Handling Re-Transmitted I2: Issue 23

Thomas:Why cannot we accept any I2?
Pekka: If you're established since one hour, I don't think that.... OK you need to be prepared to resend R2 as long as you don't get data
from the initiator.

Thomas: The other question is, is there a good way to implement this?, to know
that there is ESP traffic?
Pekka: OK I will send an add-on on the list to poll people and have the editor edit the text if it's ok.

Gonzalo: I want the notetakers to write when we make a decision.

Topic: Resynchronization: Issues 12, 15, 19, 20, 22

Tim: How do we know if it is a HIP SPI? Perhaps it is just an application timeout.
Pekka: Resync was in the base spec when we get the draft form Bob Moskowitz. I remember that there was discussion at the IPsec mailing list, but I don't remember the conclusion.
Tero Kivinen: IPsec has multiple reason to get rid of that. Several vendors use different solutions to do Dead Peer Detection. In IKEv2, if you received some kind of ICMP, you can suspect that something went wrong, so you go with DPD.
Pekka: Is there an IPsec consensus to specify this type of new ICMP message?
Tero: Unknown SPI is an IKEv2 message, unauthenticated though.
Pekka: We probably have a deeper look at what people do on IPsec.
Gonzalo: So, go talk to the IPsec folks.

Topic: Reject Mechanism: Issue 21

No discussions.

Topic: APIs Issues

Pekka: It's OK at the IP level don't care, but I think that the implement should be a MUST. The stack must or at least should support HITs in the
socket interface. It's up to the application to choose.
Erik: The kernel maintains mapping between the HIT and the IP address. What about garabage collection? What is the actual lifetime of this cache? There is a challenge here even when ignoring the hard case which are referal to third parties.
Pekka: The spec says that the HIP association have a lifetime. If you don't have traffic for some time, you just drop association.  Maybe the draft is too vague here.  Maybe we need to specify the behaviour in more specific terms, but that can also be done when the spec advances from Experimental to Proposed (that is, if it does).
Thomas: I tend to agree with that.

Pekka: It is probably acceptable to do NAT anyway. From the application point of view, there is already NAT in v4. A bit further, the application first make connect, then I1, R1. What you could do is that the resolver triggers the I1, gets the R1. It's not so much computation. Leave the base spec as it is..
Erik: An LSI is a local representation of the remote host. Some kinds of implication works.
Thomas: Trying to close this, might be better to take LSI out.
Gonzalo: Who cares?
Floor: A lot of people care.
Gonzalo: So let's take this to the list.

Open Issues in the Mobility and Multi-Homing Specification

Topic: Address Grouping

Tom: Is the main motivation for having multiple parallel SAs allowing different QoS classes, and ESP replay window. Can we loosen the replay window?
Pekka: It is one solution, but if two links are very different (e.g., GPRS and WLAN), it would be very hard to use the same SA. Let's let the IPsec people in the room comment on this.
Tero Kivinen: We have not covered this multihoming issue. Multiple SAs are needed for QoS.
Thomas: Are the adress group in the base spec or arch? Let's take this to the list. We were thinking that there was a single association between two HIT.
Pekka: Conceptually there is a single SA. It is just implemented underneath using several ones.
Floor: We don't need additional text on address selection. We could rely on multi6. Andrew wil write text about RTT estimations with RR. We don't need additional text on movement detenction either.

Topic: Return Routability

Pekka: Which way to go?
Floor: 10 people care, 2 want to keep -01 and 1 wants to go back to -00.
Pekka: Let's take it to the list. We do not have consensus.

Erik: Is there consensus on how to be triggered that data is coming on the new SPI?

Simple Rendezvous (I1 HIP-to-HIP routing)

Gonzalo: I want to clarify that LS is out-of scope for the WG, it is a topic for the RG.

Pekka: If I look at this issue, the biggest difference between I1 only and general RVS is how to locate RVS. A RVS will need to store its address into another RR (not A or AAAA). The protocol will be the same.
Lars: I agree we don't want to overload RRs.

Pekka: The other protocol we want to look at is the protocol to find RVS... but it goes to the RG. So, 5 pages defining base protocol, using only an additionnal thing for saying "this is not a peer but a RVS". I think the biggest issue is DNS draft.

Pekka: We used to have a DNS section in the base spec, but we removed it one year ago and wanted to keep the base spec simple. We probably need one or two new RR storing the HI (PK), IP addresses of the RVS. This is very similar to IPsec KEY RR. The only difference is that IPsec key stays on the reverse tree, and we want it to be on the forward tree. We could keep most of the KEY RR tree.
Rob Austein: Chair of IPsec KEY, I agree completely. Reuse the existing stuff.


HIP Reject
HIP resynchronization
HIP API issues in base spec
HIP base issue 23: Retransmitted I2
Mobility and Multi-homing
HIP Rendezvous Options