Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft

[Jari Arkko <jari.arkko@piuha.net>]

Hi Marcelo,

Thanks for your comments. Some discussion inline:

> If i understand it correctly, the draft essentially specifies the required
> mecnahins and extensions to the HIP protocol to safely modify the set of
> addresses that can be used by two communicating hosts to reach each other.
> While this is a fundamental part of a mechanism to preserve established
> communications in multi-homed and mobile environments, it is not by itselt
> enough to provide multi-homing nor mobility support.

I agree its just a part of the whole solution.

> Additional mechanisms and tools are required to preserve established
> communications both in mobile and multihomed environments, including
> mechanisms to deal with ingress filtering (multi-homing and mobility),

I do not understand why we need anything special for ingress filtering.
Hosts should only use the addresses they have been given in the
particular interface. If you move around, you will use new addresses.

> detect movment (mobility),

This is definately an issue. We already realized this in Mobile IPv6.
Currently, the IETF is planning a new WG to address movement detection
issues, the DNA working group. My hope is that the results of that will
be generally applicable to HIP, MIPv6, as well as plain hosts with no
mobility support. I think we also want to avoid putting solutions for
this in the HIP documents themselves.

HIP does introduce a few additional twists to movement detection,
however. For instance, in Mobile IPv6 you only care about IPv6 to IPv6
movement. In HIP we also need to deal with IPv4 to IPv6, and its also
quite likely that you have both IPv4 and IPv6 available at the same
time, making you "multi-homed" even on a single link. Still, my hope
is that the DNA WG (and related IPv4 efforts) will address these issues.
What might be useful perhaps, is an informational document which explains
how to apply DNA and related IPv4 mechanisms in the HIP context. However,
that can only be done once the results of DNA are ready.

> detect outages (multi-homing),

This may go beyond what DNA intends to achieve, at least if you intend
to detect outages beyoned link-layer connectivity. I think DNA at least
_should_ cover link-layer outages, not sure if they think so.

Draft-nikander-hip-mm-01 already says that hosts may initiate its own
address change due to learning some new "traffic information" or ICMP
errors. But there is not a whole lot of text on what the peer does
with the multiple addresses it has. I think we need some of this text --
and we are likely going to need a similar approach as taken in the
MOBIKE BOF i.e. the multiple addresses are primarily used for for
fail-over, not for load-balancing. Or Pekka were you thinking that
only the sender controls his own addresses -- but if this were so,
sending one current address would suffice... I think we need a way
for the responder to change the address of the peer even when its
not getting any instructions from the peer.

> locator selection for initial contact, etc.

Hmm... what's the problem? Selecting among addresses seems simple
enough. Probably the draft should say that addresss with the widest
scope should be preferred. Or are RFC 3484 rules already sufficient?

--Jari