Re: [multipathtcp] High-level design decisions /architecture

["Ford, Alan" <[e-mail]>]

Hi Bill, all,

> > The MPTCP connection is identified, from an apps perspective, by the
> > addresses associated with the original path (even if that subflow
/path
> > closes)
> 
> I'm concerned about this idea. One of the corner cases where shim6
> falls apart is: once the connection migrates away from the original
> addresses, how do the endpoints decide whether a new connection
> request for the original addresses means the migrated addresses or the
> current holder of the addresses? Think: FTP.

This is indeed an issue. However, what is likely to happen here is that
the next connection will just be rejected, the application will fail and
have to try again from scratch, this time starting with a valid
connection.

The bigger issue here is what security impacts this may have. I find it
hard to see how an attacker could engineer a compromised situation out
of this. There may be some end users receiving odd connection attempts
due to this, but that case can occur today with DNS caching.

> > A SYN/ACK exchange (on a single path) checks that both ends support
MPTCP,
> > with automatic fall-back to TCP if not
> 
> We have an awful lot of TCP options that are only valid in the
> SYN-SYN/ACK exchange and only 40 bytes to put them all. What's wrong
> with starting all TCP connections in non-MP mode and allowing the
> connection's initiator to request MPTCP starting with any packet that
> expects an ACK?

We had began with assuming that a connection was either MPTCP or regular
TCP from the start, so endpoints would know whether they could make use
of Multipath immediately and start more subflows immediately.

I'm intrigued with your suggestion, though. I see your point that there
may not be any critical reason why this information should be known at
the beginning of a session. I can't immediately think of any technical
reason why doing it later in a session wouldn't work. But it would need
further thought.

Regards,
Alan