On 07/31/2014 06:28 PM, Yoshifumi Nishida wrote: > My naive question here is do we really need to distinguish header and > payload when we apply protections? > I mean, if there's no significant overhead differences, why bother > checking the boundary between header and payload, or checking TCP > flags? Can't we simply protect a TCP segment? > Or, the discussion point is not overhead, but interactions with > middleboxes that update TCP headers or payloads?
Yes, the concern is that there are widespread middleboxes which modify
packets as they pass through -- those middleboxes tend to modify the IP
headers and TCP headers, but leave the payload alone (e.g. NAT).
If we were to protect everything including the TCP headers, then any
flows which traverse such a middlebox would fail. This would make
people unlikely to deploy tcpinc, because their connections would break.
But at the same time, there are parts of the headers that we don't
expect middleboxes to modify, which would be nice to protect, since the
header itself can be spoofed by an attacker to interfere with an ongoing
TCP session.
So we are trying to decide what parts to protect, and how peers that
implement this protection should behave if they discover that the
protected parts of the tcp header are damaged.
hope this helps to clarify,
--dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
