Re-, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Tom Herbert [mailto:[email protected]] > Envoyé : mercredi 19 juillet 2017 17:45 > À : BOUCADAIR Mohamed IMT/OLN > Cc : Joe Touch; [email protected]; Internet Area > Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP > > On Tue, Jul 18, 2017 at 11:37 PM, <[email protected]> wrote: > > Hi Tom, > > > > Please see inline. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Int-area [mailto:[email protected]] De la part de Tom > Herbert > >> Envoyé : mercredi 19 juillet 2017 00:43 > >> À : Joe Touch > >> Cc : [email protected]; Internet Area > >> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP > >> > >> On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch <[email protected]> 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, [Med] This is not the actual proposal. The proxy is explicitly configured so that all packets are sent to it directly. That is, the destination address of outgoing packets will be set to the one of that proxy. 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. > [Med] I fully agree with you. But, we are not in a transparent/implicit mode. > 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. [Med] We don't have such requirement. The proxy is not supposed to be on one of the default forwarding paths; all what we require is that it is reachable using any of the available paths. Subflows can be placed using any or all of the available paths. > Personally, would find it ironic that a a protocol to allow muli-path > transport would require the network layer to be single path. > [Med] Sorry, but we don’t have such constraint/requirement. See my explanation above. > 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 > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/int-area > >> > >> _______________________________________________ > >> Int-area mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
