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

From: [email-masked] (marcelo bagnulo)
Date: Fri Jan 2 03:05:03 2004

Hi Pekka,

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.
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),
detect movment (mobility), detect outages (multi-homing), locator selection
for initial contact, etc.

It would be interesting to try to understand how HIP (and the extensions
presented in this draft ) can deal with all these issues, so it can provide
a complete solution to preserve established communications.
You mention that another draft is comming, perhaps are you planning to
inlcude all the rest of the issues in this next draft?

Thanks for the draft, regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Pekka Nikander
> Enviado el: lunes, 29 de diciembre de 2003 9:15
> Para: [email-masked]
> CC: [email-masked]
> Asunto: Updated HIP mobility & multi-homing draft
>
>
> I've posted an updated version of the HIP mobility
> and multi-homing draft to the repositories.  In the
> mean time, it is available from the following URLs.
>
> http://www.tml.hut.fi/~pnr/HIP/draft-nikander-hip-mm-01.txt
> http://www.tml.hut.fi/~pnr/HIP/draft-nikander-hip-mm-01.html
> http://www.tml.hut.fi/~pnr/HIP/draft-nikander-hip-mm-01.xml
>
> This version is *considerably* different from the previous
> one, in the sense that it has been fully integrated with
> the new NES mechanism.  The AC and ACR packets are gone.
> It is quite hard to understand the protocol without knowing
> the details of the base HIP protocol.
>
> I'd like to get some feedback of the approach.  My belief is
> that the new approach will result in less code, provided that
> the hosts already implement NES (which is mandatory in HIP).
> However, it is also appear harder to understand.
>
> I'm now starting to work on another draft, which will explain
> the HIP multihoming mechanism from a multi6 point of view.
>
> --Pekka Nikander
>
>

---

From: [email-masked] (Jari Arkko)
Date: Fri Jan 2 05:59:01 2004

Hi Marcelo,

> enough to provide multi-homing nor mobility support.

I agree its just a part of the whole solution.

> 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

---

From: [email-masked] (marcelo bagnulo)
Date: Sat Jan 3 03:33:01 2004

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

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

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

> enough. Probably the draft should say that address with the widest

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

---

From: [email-masked] (Jari Arkko)
Date: Sat Jan 3 03:46:01 2004

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

> The point is are those mechanism compatible with the hip solution? how do

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.

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

> 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

---

From: [email-masked] (Masataka Ohta)
Date: Sat Jan 3 06:03:03 2004

Jari Arkko;

> issue appears even when you do not employ e.g. HIP or SEND or MOBIKE.

That's why proposals should be intended to be complete.

At this stage, incomplete solutions are totally useless for
productive discussions.

However, the solutions are not required to solve mobility specific
ingress filtering issues, unless they actively disturb exsiting
capability of ingress filtering with some existing mobility
protocols.

> that HIP has created. Details to be worked out, however.

You can work forever to fix the details, only after which, make
public proposals.

> explanation of functionality that would cover all these aspects?

Multi6 is expected to have a completed solution on multihoming problems
of IPv6.

						Masataka Ohta

---

From: [email-masked] (marcelo bagnulo)
Date: Sat Jan 3 14:40:01 2004

> issue appears even when you do not employ e.g. HIP or SEND or MOBIKE.

I agree this is a common problem of many of the multihoming solution, and it
should be addressed by each of the particualr solutions.
Since we are considering a multihoming solution based in HIP, we should try
to understand how a HIP solution can deal with this and how it can interact
with possible solutions for this problem.

...

> have not been involved in multi6 work.

I can try to help with this.

> Is there a problem statement or an

RFC 3582 contains the goals for multihoming
Elliot's draft contain a good amount of interesting questions that we should
try to answer when designing a multi6 solution
(draft-lear-multi6-things-to-think-about-00.txt)
You can also read D. Crocker's draft for an analysis of the big picture
draft-crocker-mast-analysis-01.txt

Hope this helps,

Regards, marcelo

---

From: [email-masked] (marcelo bagnulo)
Date: Sat Jan 3 14:40:04 2004

> At this stage, incomplete solutions are totally useless for

FWIW, IMHO this HIP draft is interesting and useful

Regards, marcelo

---

From: [email-masked] (Masataka Ohta)
Date: Sat Jan 3 20:45:02 2004

marcelo bagnulo;

With your context of:

> Since we are considering a multihoming solution based in HIP, 

it should be.

But, I am not interested in considering a multihoming solution based
on HIP that it is neither interesting nor useful.

						Masataka Ohta