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

[[e-mail] (Jari Arkko)]

marcelo bagnulo wrote:
>>>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.

Ah yes. This is in fact a discussion we had also in the SEND WG during last
couple of days. At least some people that I talk to think that this is
a general issue for the IPv6 and multi6 WGs to fix their protocols -- the
issue appears even when you do not employ e.g. HIP or SEND or MOBIKE.

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

Right. No, we do not have an answer to these questions yet. One
potential answer is that we can simply track the usage of the SAs
that HIP has created. Details to be worked out, however.

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

I think the ingress filtering compatibility has to be solved
generally, outside HIP. Perhaps as a part of updates to ND, or
maybe in SEND.

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

It does. I'm just trying to understand the best way to address this "big
picture" problem. Actually, maybe you or someone else can help here, as I
have not been involved in multi6 work. Is there a problem statement or an
explanation of functionality that would cover all these aspects?

--Jari