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

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

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

In the multihoming case, one interface has multiple global addresses
assigned, and the host must select which one to include in the packet as
source address
Once that the packet leaves the host, it is up to the intrasite routing
system to carry the packet to one of the exit isps.
The problem appears when the exit isp selected by the routing system and the
source address selected by the host don't match (ingress filtering discards
the packet)

So a mechanism is needed to coordinate the exit isp and the source address
Several options are possible, like source  routing in multiple flavors,
source address rewriting, letting the routing system inform the host which
address to use with a given destination address.

I guess that it would be interesting to understand how compatible are those
mechanisms with the HIP solution... for instance it would be possible to
rewrite the source address of the HIP packets?

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

I agree that this document shouldn't contain all the issues that i have
mentioned. Actually IMHO this document should only contain the extension to
support multiple addresses in HIP
Then IMHO it would be interesting to have a separate document describing how
HIP interact with the other parts of a multihoming solution (and a similar
one for mobility i guess)


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

outage detection is essential to provide fault tolerance
in multihoming you have to be able to detect an outage in currently used
path in order to change to an alternative one
there are several ideas about how to do this, like letting the routing
system to deal with this (and we need a mechanism to ensure ingress
filtering compatibility), let the host to perform outage detection, like
using upper layer protocols hints
The point is are those mechanism compatible with the hip solution? how do
they interact with them?

> 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 address with the widest
> scope should be preferred. Or are RFC 3484 rules already sufficient?
>

Maybe, maybe not, depending on other parts of the solution (especially on
the mechanism you use to provide ingress filtering compatibility)
If you use some form of source routing for instance, a packet may not reach
its final destination because of its source address, since the destination
address may not be reachable through the isp associated with the selected
source address, so you may need to retry with a different source address.
This is just one example, there may be different problems depending on the
additional mechanisms that you choose.

So my point is that there are many parts of a multihoming solution and all
of them have to interact. So in order to really understand how the hip
solution may work, we need to understand how it will interact with all the
rest of the pieces that will be used

Does this makes sense to you?

Regards, marcelo

> --Jari
>