Gregory,
Although I can't disagree with your assessment of the direct discussion
on protecting TCP headers, the conclusion below seems to ignore the
discussion on "Forcing the restart of a TCPINC connection".
I wonder how people think their solution will magically protect against
forced restarts if the TCP header isn't included.
I agree.
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. When one subflow dies due to a RST, another subflow
can be restarted to continue the connection. Having multiple paths could
also be an advantage from a security viewpoint, but that's another story.
Olivier
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
