> 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
