[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Hipsec] RE: Updated HIP mobility & multi-homing draft
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