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

On Tue, Jul 18, 2017 at 11:37 PM,  <mohamed.boucadair@orange.com> wrote:
> Hi Tom,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Int-area [mailto:int-area-bounces@ietf.org] De la part de Tom Herbert
>> Envoyé : mercredi 19 juillet 2017 00:43
>> À : Joe Touch
>> Cc : tsv-area@ietf.org; Internet Area
>> Objet : 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!
>>
>
> [Med] We would love to avoid requiring adding a function in the network to assist devices to make use of their multiple interfaces/paths. Nevertheless, the situation is that servers do not support MPTCP.
>
> The proposed solution allows to:
> * elect some flows to benefit from network-assisted MPTCP while avoiding session failures.
> * Policies are configured to identify traffic that won't be forwarded via a proxy
> * 0-RTT proxying
> * MPTCP can be used e2e if both end points are MPTCP-capable (that is, the proxy is withdrawn from the path).
> * No interference with TCP options to be negotiated between endpoints.
>
> Do you have in mind such use cases when you referred to the "stateful firewalls model"?

One of the problems with stateful firewalls (as well as transparent
proxies) is that they require all packets for a flow to consistently
traverse the same middlebox device. The middlebox is not addressed by
the packet, so the assumed requirement is that packets for the flow go
though the same network node by virtue of routing. For a firewall in a
single-homed site to the Internet this works because the firewall is
the only egress/ingress point to the network. If a site is
multi-homed, then the hope is that routing of packets in both
directions will go through the same point. But there is absolutely no
requirement that network layer packets for a flow are always routed
the same way, and if routing does change and packets need to flow
through different points the session breaks.

If I'm reading the draft correctly, then it has the same property of
maintaining transport state in the network so it implies the same
requirement that all packets for a flow follow the same path.
Personally,  would find it ironic that a a protocol to allow muli-path
transport would require the network layer to be single path.

Tom

>
>> 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
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area