On 10/13/2014 11:22 AM, Christian Huitema wrote:
>> I.e., any option-based solution might not work through a middlebox -
>> including the one that signals the use of TCPINC. At that point, we're
>> back to running TLS, and it seems pointless to discuss this as a TCP
>> variant, IMO.
>
> I agree with Joe. Can we list the attacks that would not be prevented by
> TLS, but that would be prevented by a version of TCPINC that does not
> protect the TCP header?
This discussing really needs consensus what middlebox behaviors should
be supported. IMO:
YES: NAT
re-segmenting with option rewriting
(shouldn't break connectivity at least,
but might break protection)
MAYBE: segment rewriting with known option processing
(should this keep protection or not?)
NO: segment rewriting with unknown option copying
(no evidence this is more than hypothetical)
unknown option removal (if so, we can't signal
use of the option using TCP anyway)
I.e., if we're worried about whether protecting the header interferes
with the above, we ought to worry about whether it interferes with a
TCP-level solution, including use of the TCP option space to signal use
of TCPINC.
Joe
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
