Subject: [Hipsec] Comments on draft-nikander-hip-mm

From: [email-masked] (Henderson, Thomas R)
Date: Tue Apr 20 18:55:00 2004

> -----Original Message-----
> From: Jonathan Wood [mailto:[email-masked]]=20
> Sent: Tuesday, April 20, 2004 10:50 AM
> To: [email-masked]
> Subject: Re: [Hipsec] Comments on draft-nikander-hip-mm
>

> > Anyway, the intention of the -02 text is to be more
> > flexible, and allow you to continue using the same
> > SA and SPI.  But you still need to send the SPIs both
> > ways so that middle boxes can learn them.
>=20
> I understand. How does this work in the 02-pre1 draft
> when the REA does not accompany a NES?
>=20
> <...>

This is indeed a problem-- the 02-pre1 draft needs to be
fixed to accommodate middleboxes in the most general
scenario.  Basically, one-way REAs won't work unless REA=20
were to have additional info on the reverse direction--=20
which is probably not the best idea.

> >
> >> This probe can also be used
> >> to estimate RTTs for each path, which can then be used to
> >> set the ESP replay window. The path RTTs can also be fed
> >> to transport protocols.
> >
> > As far as I see, there is nothing in the draft that
> > prevents you from implementing it in this way.
> >
> > Would you like to write an appendix where you describe
> > some of these implementation options?  The text Tom
> > provided is fine, but I don't see why we should
> > include it in the protocol proper?  Is there some reason?
> > Or could it be in an appendix?
>=20
> Well, the issue of whether it should be in the protocol proper
> or in an appendix depends on whether you use multiple SAs
> or an RTT  estimate to manage the replay window. If the latter,
> it should be in the protocol, IMHO. I am also concerned about
> overloading messages too much. We have 255 message types
> to play with, so adding a heartbeat message for clarity might
> not hurt too much (and shouldn't necessitate too much extra
> code). But I think we need to resolve the primary focus of this
> thread first - if I am convinced that using multiple SAs is necessary
> and good, then I don't think heartbeats will be necessary (but maybe
> optional? Need to think about that more...)
>=20

How to use RTT estimates seems to me to be an issue that, if covered in=20
detail, does not affect interoperability (similar to cookie generation)=20
and may be best handled in an appendix or separate informational draft.  =

I think that feeding RTT estimates and other info to transport protocols
is beyond our scope right now.

In general, I am hoping that a loose enough replay window will suffice
for most mobility situations, but being able to use multiple SAs
seems to be necessary and good.

UPDATE + ECHO_REQUEST/RESPONSE (both within signature) could be used
to implement the heartbeat-- or another message (I agree that the
bits in the type field are there).=20

> >
> >> ... there is no such
> >> mechanism in place to ensure the the RR reply gets
> >> best effort delivery (whether it be data or a HIP TLV).
> >> If it gets lost, the address verification is left in limbo.
> >
> > Is this a problem?  The address will stay in UNVERIFIED
> > state, and you will need to re-initiate return routability
> > on that if you intend to use the address.
> >
> > I don't see where you have a problem here.  But perhaps I'm
> > missing something?
>=20
> What about the case where a MN moves and gets a new CoA.
> It sends its peer an REA with the new CoA as the new preferred
> address. The RR fails due to a dropped packet. Now the peer
> host cannot communicate with the MN since the only verified
> address it has is the MN's old CoA. Detecting that the old address
> is unreachable could take some time, during which all packets
> to the MN are lost.

So in a mobility situation, send the REA in an UPDATE, which is
timer protected.  REA + NOTIFY would only be useful in cases for
which you don't care as much about reliability (e.g., backup
addresses in multihoming), but in light of the middlebox problems,
maybe REA + NOTIFY should be deprecated.

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 27 06:13:00 2004

After a long delay, I've now eventually managed to start
creating issues on the mobility and multi-homing draft in
roundup.  See http://hip4inter.net/cgi-bin/roundup.cgi/hip-mm/

> scenario.  Basically, one-way REAs won't work unless REA
> were to have additional info on the reverse direction--

I've given this middle box issue the tracking number #2.
Tom, Jon and I are trying to work this out in private.

--Pekka

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 27 06:15:06 2004

> How to use RTT estimates seems to me to be an issue that, if covered in
> detail, does not affect interoperability (similar to cookie generation)
> and may be best handled in an appendix or separate informational draft.

Agreed.

> is beyond our scope right now.

IMHO they are definitely beyond the scope of WG work.  However, I'm
interested to see some work on this at the RG side.

--Pekka