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