Subject: BOUNCE [email-masked]: Admin request of type /\bsubscribe\b/i at line 7 (fwd)

From: Kurtis Lindqvist <[email-masked]>
Date: Mon, 14 Mar 2005 22:22:36 +0100 (CET)

Appproved: tered0

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Mar 2005 07:53:52 +0200

Hi Iljitsch,

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

>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,
>  
>
Or CGAs. Or HITs. This shows that there are plenty of
approaches that do not require magic PKI dust...

>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...
>  
>
The arguments about the difference in time scale and the
requirement for security are quite valid. But on the other
hand we already know that we have mechanisms in this
WG that can handle even the tiniest timescales (HBA with
CGA support) or in other WGs (HIP) in secure manner.

So in theory there is a difference between multihoming
and mobility, in practise its the same protocol mechanisms
that can deal with both of them.

(Of course, that still leaves the question open on how much
we should concentrate in SHIM6 work on the mobility aspects.
And whatever we do, we should still make sure that existing
mobility mechanisms are not rendered inoperational by
SHIM6.)

--Jari

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Tue, 15 Mar 2005 12:10:41 -0500 (EST)

Iljitsch van Beijnum wrote:

> here, and _very_ few sessions or associations last for days.

I don't know what you call "_very_ few", but I can think of three
applications that I use daily which have long lived TCP connections...
often lasting days or more. These three are ssh (with tunneled apps), IM
(aol, yahoo), and mp3 streaming (as a listener). I probably wouldn't care
_too_ much if they broke occasionally due to renumbering and I had to
restart them, but if this behavior became frequent, then it would become
annoying. However, I can only speak for myself. There may be others (eg,
mp3 streaming servers) who would find it more than annoying if it happened
at all.

<snip>

> or two applications are saved from reconnecting once in a blue moon.

How much demand for timeliness do you think is enough to justify
addressing it? In my opinion, I think the fact that there are _any_
demands for it now (mobility & my 3 example apps), is reason enough to
address timeliness. If timeliness isn't addressed, aren't we being
short-sighted with respect to future applications?

~armando

0--                                              --0
| Armando L. Caro, Jr. |  Protocol Engineering Lab |
| www.armandocaro.net  |    University of Delaware |
0--                                              --0