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

[<[e-mail]>]

Hi Tom,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Int-area [mailto:[e-mail]] De la part de Tom Herbert
> Envoyé : mercredi 19 juillet 2017 00:43
> À : Joe Touch
> Cc : [e-mail]; Internet Area
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch <[e-mail]> 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"?

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