On 3/13/2015 2:35 PM, Olivier Bonaventure wrote: > Joe, > >>>> >>>> I don't think "don't protect the headers" is an accurate description >>>> of Honolulu if it also leaves the system exposed to resets, as there >>>> clearly was a fair amount of concern expressed about spurious resets. >>>> >>> >>> IMO, the best approach to deal with suprious resets, caused by >>> middleboxes, attackers or whatever, is to use the same approach as in >>> Multipath TCP by considering a TCPINC connection to be composed of >>> several subflows. >> >> TCPINC isn't limited to Multipath TCP, thus that approach is >> inappropriate. > > > I know the charter of the TCPINC working group. When I write "use the > same approach as in Multipath TCP by considering a TCPINC connection to > be composed of several subflows" I mean include in TCPINC a mechanism > that contains : > > - a form of connection id as the tokens used in Multipath TCP > - a way to enable a TCP connection to be composed of a series of TCP > connections (i.e. the datastream that started on the previous subflow > continues on the next one)
TCP is intended to protect TCP, not turn all TCP users into Multipath-lite users. > With this kind of mechanism, a TCP variant can have the ability to react > to spurious resets. Only if you substantively protect those connection ID tokens. Which means you're protecting "header" information - and you;ave' made it worse by protecting a header that doesn't even exist yet. It's a lot easier to protect the headers we alredy have. Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
