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

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

Hi Scott,

> Ford, Alan allegedly wrote on 10/27/2009 10:03 AM:
> > We now have a new version of the MPTCP protocol draft available,
> > which will be presented in Hiroshima.
> >
> > 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.

Well the key argument against it would be the overhead it would create,
and also any issues with option space limits.

How would such an identifier really benefit these systems, in practice?
In a way that could not be achieved by caching connection id/5-tuple
mappings on initialisation?

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

"Multipath Capable" is maybe a poor name for it. In reality, it is a
"MPTCP Connection Initialization" option.

It is, in effect, the source's definition of the MPTCP analogue of the
source port. Remote hosts can then connect towards that. Without this,
the initiator would not be able to pick a token that was unique to both
the sender and the receiver.

> >    If these packets are unacknowledged, it is up to local policy to
> >    decide how to respond.  It is expected that a sender will
eventually
> >    fall back to single-path TCP (i.e. without the Multipath Capable
> >    Option), in order to work around middleboxes that may drop
packets
> 
> work _through_ them, rather :-)
> 
> >    If an endpoint is known to be multiaddressed (e.g. through
multiple
> >    addresses returned in a DNS lookup), alternative destination
> >    addresses SHOULD be tried first, before falling back to regular
TCP.
> 
> You might want to note this is no different from some TCP behaviors
> today, if a connection cannot be established to the first address
attempted.

Good point.

> >    The "Join" option includes an "Address ID".  This is an
identifier,
> >    locally unique to the sender of this option, and with only per-
> >    connection relevance, which identifies the source address of this
> >    packet.  This serves two purposes.  Firstly, if an address
becomes
> >    unexpectedly unavailable on the sender, it can signal this to the
> >    receiver via a remove address option (Section 4.3.2) without
needing
> >    to know what the source address actually is (thus allowing the
use of
> >    NATs).
> 
> This is good but ...
> 
> >    Secondly, it allows correlation between new connection
> >    attempts and address signalling (Section 4.3.1), to prevent
duplicate
> >    subflow initiation.
> 
> ... I have some problems with address "exchange".  See below.
> 
> >    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.

Hmm, true, although it should open a new subflow from 2.2.2.2 and this
should be able to reliably take over with no great interruption to the
user.

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

Hmm. There are at least two strong use cases for signalling addresses,
which cannot be achieved through an implicit join.

1. Firewalls/NATs in the way. Consider:

        Host A                        Host B
      ----------             ------------------------
      Address A1             Address B1    Address B2
      ----------             ----------    ----------
          |                      |             |
          |    (initial setup)   |             |
          |--------------------->|             |
          |<---------------------|             |
          |                      |             |
          |      ###<--------------------------|
          |                      |             |
          |   (signal address)   |             |
          |<---------------------|             |
          |                      |             |
          |     (additional subflow setup)     |
          |----------------------------------->|
          |<-----------------------------------|
          |                                    |

Here, the multihomed endpoint cannot connect back to host A due to a
firewall in the way (marked as ###), so instead the explicitly signalled
address is used, and Host A can connect out to it to create the second
subflow.

2. IPv6 and IPv4 - in this case, where there is an existing IPv4
subflow, it is not possible for one endpoint to implicitly use another
of its addresses to the same endpoint, since both ends need to know
about IPv6 addresses. So a second subflow should be initiated by an
endpoint signalling its IPv6 address to the other endpoint, who is then
able to use its IPv6 address in an implicit connection. (This kind of
scenario may also apply to other cases).

There is also the undecided security element, where signalling on an
existing subflow is less open to exploits than entirely new TCP
sessions.

Regards,
Alan