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

From: Scott Brim <[email-masked]>
Date: Wed, 04 Nov 2009 20:08:59 -0800

John Leslie allegedly wrote on 10/27/2009 3:18 PM:
> Ford, Alan <[email-masked]> wrote:
>> We now have a new version of the MPTCP protocol draft available, which
>> will be presented in Hiroshima.
>>
>> http://www.ietf.org/id/draft-ford-mptcp-multiaddressed-02.txt
> 
>    Very nicely done!
> 
>    I stumbled over the term "TCP Session" in section 1.3. I'm not sure
> whether there might be a better name for that concept, but in any case
> I'd recommend a "glossary" entry for whatever term is used.

Agree.  In some contexts a "session" can involve multiple, possibly only
loosely coordinated, transport "connections" between different
applications..

---

From: Scott Brim <[email-masked]>
Date: Fri, 06 Nov 2009 11:33:51 +0900

Ford, Alan allegedly wrote on 10/27/2009 10:03 AM:
> Hi all,

Hi Alan and all.  Please forgive my lateness.

I'm a control plane kind of person, not a congestion management person,
so most of these comments are about the protocol itself.

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

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

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

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

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

Thanks ... Scott

---

From: John Leslie <[email-masked]>
Date: Fri, 6 Nov 2009 09:04:28 -0500

> so most of these comments are about the protocol itself.

   Good to have someone thinking that far ahead!

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

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

> if A loses 1.1.1.1 and sends a "remove" for its ID, unintended

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

> 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 <[email-masked]>

---

From: "Ford, Alan" <[email-masked]>
Date: Fri, 6 Nov 2009 14:34:44 -0000

Hi Scott,

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

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

> today, if a connection cannot be established to the first address
attempted.

Good point.

> if A loses 1.1.1.1 and sends a "remove" for its ID, unintended

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.

> 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

---

From: Rémi Després <[email-masked]>
Date: Fri, 6 Nov 2009 15:51:15 +0100

Le 6 nov. 09 à 15:34, Ford, Alan a écrit :

>>>    o  Do we want a connection identifier in every packet?  E.g.
>>>      would make implementation of IDS much easier?
>>

To deal with the option space limit, a possible approach, which I  
personally recommend, consists in using a TCP option only in the  
initial SYN ACK exchange.
Once it is established that both ends support MPTCP, a MPTCP service  
field in in the TCP payload can be used.

RD