I prefer option 1 for the reasons that John and Michael state.
That said, if header integrity protection is the general consensus, I prefer
> -- include the MAC for the TCP header fields in a TCP option and the
> MAC for the payload in the payload
because I believe it can be made to work through a broader range of
cooperative middle boxes than a solution that combines header and data
integrity protection into a single MAC.
--Brandon
On 10/07/2014 05:32 AM, Scharf, Michael (Michael) wrote:
Option 1. Get passive eavesdropping protection deployed ASAP. If
better protection against TCP attacks is needed, it can be done
separately as an enhancement without holding back what is needed now
which is deployable passive eavesdropping protection.
+1
Keep in mind the KISS principle
I think the TCP header is an orthogonal issue that can and should be solved
separately. TCPM currently discusses hashing/MAC of headers/options fields for
other purposes (e.g., middleboxes breaking EDO). If we need a MAC of header
fields in TCP connections not using tcpinc, we should define *one* generic and
modular solution for all TCP usage scenarios (on STD track) and not a
tcpinc-specific MAC. Otherwise, I would be really concerned about
interoperability between multiple TCP extensions calculating some form of MACs
in their own way. In short, this looks to me like a separate RFC.
As a side note, this design choice really correlates with the question whether
tcpinc runs an own framing in the payload.
Michael
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
--
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
