On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch <to...@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-a...@ietf.org > https://www.ietf.org/mailman/listinfo/int-area
