Re: how mobile do we want to be

[avri@psg.com]

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