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