Re: [multipathtcp] FW: New Version Notification for draft-ford-mptcp-multiaddressed-02

[John Leslie <[e-mail]>]

Scott Brim <[e-mail]> wrote:
> 
> I'm a control plane kind of person, not a congestion management person,
> so most of these comments are about the protocol itself.

   Good to have someone thinking that far ahead!

>> Questions and discussion very much welcome beforehand too!
> 
>>    o  Do we want a connection identifier in every packet?  E.g. would
>>       make implementation of IDS much easier?
> 
> I think so.  What are the arguments against it?  It deterministically
> avoids the kind of cases that Joe was concerned about.

   'Twould seem to me to complicate the analysis of MPTCP packets that
"look like TCP packets" to existing middleboxes.

   I have no objection to it -- it just feels like something which
deserves to be enabled/disabled with a negotiated option.

> > 4.1 Session Initiation
> 
> Why is there a "multipath capable" option exchange at all?  The question
> is implicit in a "join" option.  If the receiver does not understand the
> "join", it is not multipath-capable, and you fall back.

   From the history of TCP options, it's considered "safe" to use new
option in a SYN, but unsafe to introduce them later without having
negotiated that both ends know what they are (during the SYN exchange).

   Note that although JOIN is on a SYN (and thus "safe"), it's intended
to signal a subflow which may "create" a combination of subflows which
look like a single TCP session to the application. The new subflow
could fail for quite a few different reasons: I'd prefer to disambiguate
the case where the other end doesn't talk MPCTP.

   (There's no actual reason we _need_ two different option numbers,
of course...)

>>    TBD: Instead of an Address ID, are there any cases where a Subflow ID
>>    (i.e. unique to the subflow) would be useful instead?  For example,
>>    two addresses which become NATted to the same address?
> 
> "Remove" is important but there are corner cases under all options I can
> think of.  I'm in favor of just documenting possible rare unintended
> disruptions, and then just specifying "remove".  For example, I could
> see a scenario where A and B are communicating, and A is using address
> 1.1.1.1 which is NATted to 3.3.3.3 by the time a packet reaches B.  A
> loses 1.1.1.1 and switches to 2.2.2.2, but an upstream network helpfully
> NATs to the the same external address, 3.3.3.3, to be helpful to A.  So
> if A loses 1.1.1.1 and sends a "remove" for its ID, unintended
> disruption will occur.

   It may be caffeine deficiency, but I don't follow why the "Address ID"
isn't sufficient to disambiguate this case.

> > 4.3.1.  Adding Addresses
> 
> re "Add Address", I wouldn't bother.  A source cannot know what its
> addresses will look like to a destination, and NATs are here to stay.  A
> NAT on a particular path cannot know what a NAT on a different path will
> do.  Under no conditions should an address for one path be carried as
> payload on another path.  It's important to get layer violations out of
> the control plane.  Instead of promoting a mechanism that _might_ work
> occasionally (and might open security holes??), let's focus on making
> the data plane mechanisms work really well.

   I'm a bit nervous about "Add Address", in that a middlebox might
"helpfully" transform the IPvN address. This feels like a special case
of JOIN where we don't actually want to establish a subflow (perhaps
out of a desire to avoid extra state information or a suspicion that
the MPTCP flow won't last long enough.

   We do have a "chicken/egg" problem though: a pair of JOINs to
introduce new addresses might both fail, whereas a JOIN between the
pair of new addresses would succeed.

   Conversely, it looks too easy to forge source-IP on an "Add Address"
and introduce a security risk.

   I do believe we need a mechanism to announce a new address; I'm not
sure we wouldn't be better off doing it as a special-case of JOIN...

--
John Leslie <[e-mail]>