Re: [Int-area] Middleboxes to aid the deployment of MPTCP

On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch <touch@isi.edu> wrote:
> Hi, all,
>
> I've noted this before, but to share with other areas:
>
> Although I'm not averse to middleboxes as optional optimizations, I find
> the proposed mechanisms aren't quite optional -- they inject option
> information into the SYN data. That information would poison a
> connection to a legacy receiver if (more to the point, when) that info
> isn't removed by a proxy upstream of the receiver.
>
> TCP must be E2E and fall back to legacy endpoints without a reconnection
> attempt, as required by RFC793.
>
> These aren't generic solutions; they're attacks on a TCP connection, IMO.
>
I agree. This seems be akin to stateful firewalls model that impose
artificial requirements on networking (like every TCP packet for a
connection must got through some middlebox or the connection is
dropped). We need to move things back to E2E semantics for transport
protocols-- nodes that try to maintain transport state in the network
should be considered the problem not the solution!

Tom

> Joe
>
>
> On 7/18/2017 3:22 PM, Olivier Bonaventure wrote:
>> The working group has discussed this issue several times and today we
>> have presented a new design that supports the creation of such
>> functions to convert MPTCP connections into TCP connections and vice
>> versa. The design was done with MPTCP in mind, but the proposed
>> solution could be more generic and applied to other use cases than
>> MPTCP. The draft that describes the new design is available via:
>>
>> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-converters-01.txt
>>
>>
>> Mirja Kuehlewind suggested to send the document on the int-area and
>> tsv-area mailing lists to see whether other working groups could be
>> interested by this approach.
>
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area