Re: delayed multihoming/mobility set-up

["Spencer Dawkins" <spencer@mcsr-labs.org>]

Just a couple of notes here...

Spencer

----- Original Message ----- 
From: "Iljitsch van Beijnum" <iljitsch@muada.com>
To: "Christian Huitema" <huitema@windows.microsoft.com>
Cc: "Multi6 Mailing List" <multi6@ops.ietf.org>
Sent: Tuesday, December 02, 2003 4:13 AM
Subject: Re: delayed multihoming/mobility set-up


> On 1-dec-03, at 18:18, Christian Huitema wrote:
>
> > My preferred time-line would be:
>
> > 1) Start a communication using one of the available pairs of
src/dest
> > addresses.
> > 2) If the communication is determined to be worth it (i.e. last
long
> > enough), engage in "multi-homing signaling" to obtain a "set of
> > equivalent addresses"
>
> Hm, this is problematic. Simply exchanging addresses isn't good
enough,
> as this allows for redirection attacks. So the addresses must be
> validated by using them in a way that can't be spoofed by a third
> party. I.e., one side must contact the other using a new address and
> include authentication information that tells the correspondent it's
> still talking to the same party. If we're doing this anyway there is
> little need to exchange the addresses beforehand. Depending on the
type

Well, the GPRS RTT on networks I've measured *is* around one second,
so if we didn't have to wait until our WLAN address lost its
connectivity to exchange addresses, that could be lovely...

> of rehoming authentication used it may be necessary to set up
> authentication state before rehoming happens.
>
> > 3) On a transport event such as retransmission time-out, probe
> > alternate
> > pairs of src/dest addresses, and pick a "better one" if available.
>
> Agree.
>
> Question: do we want to do this on a per transport session basis, or
do
> we move an address and all transports running over it in one go when
a
> rehoming event occurs?

Well, someone got up in Minneapolis and said, "don't bother rehoming
my e-mail connection, because I would rather keep retrieving e-mail
over my WWAN connection than interrupt retrievals every time I lost my
WLAN connection". If these seems desireable, it's probably
per-transport-session; if not, it's probably per-address, unless we
want to go down the ToS/CoS path.

>
> > I would note that a lot of the communication we have today do not
meet
> > the "worth it" requirement. The top applications in the Internet
today
> > are web pages, which mostly consist of a large number of very
short
> > exchanges, and p2p file sharing, which includes its own
application
> > level tools to deal with multi-homing.
>
> Even though it's probably not worth the trouble to protect the
> individual TCP sessions towards a web server (but protecting large
> downloads over HTTP would be very useful), it would still be good to
> have fairly seamless failover to another address when a web address
> fails. I'm sure Amazon or Ebay wouldn't want to run the risk of
losing
> customers because of reachability issues by depending on web
browsers
> to do the right thing. But this assumes the protection is active at
the
> IP address level rather than the transport protocol level.

Christian's opinion is true for per-object HTTP connections, a little
less true for persistent HTTP connections, little less true for
persistent HTTP connections to a proxy, and a little less true for
persistent HTTP connections when the browser is using pipelining. It's
a pity that we can't include some notion of "this is a large object"
in HTML, of course.

Spencer