[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how mobile do we want to be



I think the question is more a recognition that the network is now a network in motion: systems move and networks move. And while it is true that some part so the network, doesn't move, or moves very slowly, an overwhelming amount of the edge is in motion. And I think it is important to realize that a large number of sessions should remain viable despite this continuous motion.

In other words I think the question is not, "how mobile do we want to be", but how mobile are we and how mobile will we be by the time a shim6 solution is implemented and widely deployed.

It is for these reasons that I am arguing so insistently that we must include systems and networks in motion (if we want to reserve the term mobility for MIP4/6 to avoid confusion) as part of the problem space shim6 must take into account.

a.


On 12 mar 2005, at 10.44, Iljitsch van Beijnum wrote:

In the discussion in the BOF yesterday there were different viewpoints on the relationship between mobility and multihoming in general and shim6 in particular.

Apparently, some people are equating renumbering with mobility. Now obviously mobility mechanisms can be used to renumber without skipping a beat, but that doesn't mean mobility and renumbering are the same thing.

I think the important difference is the timescale. In mobility, the assumption is that TCP sessions and other state are longer-lived than locator addresses. In site renumbering, I very much doubt that this is the case. At the very least, we're talking about the order of days here, and _very_ few sessions or associations last for days. So in nearly all cases, site renumbering can be addressed with regular stateless autoconfiguration address deprecation.

Please don't forget: adding a new address in the middle of a session is a security nightmare. The only way this can be done reasonably is with the help of strong crypto (magic PKI dust) or a home agent that is impervious to on-path nastiness such as sniffing and MitM. Obviously, for a good number of applications strong crypto isn't a problem as they already use it today. But mandating strong crypto for *everything* is very problematic for reasons of performance, configuration and robustness. (Let the person who never clicked "accept" on an SSL warning cast the first stone here.)

I think HBAs are a very good compromise between reasonable security and usability. It would be a shame to throw this out the window just so one or two applications are saved from reconnecting once in a blue moon. It takes a lot of reconnects to waste the same amount of time that it takes to obtain and install an X.509 certificate...