> Another approach here would be to make it easy for other RFC authors to > leverage tcpcrypt to protect the privacy of there options. For any > options that are tied to data, moving them in-band to special TLV > frames > might make the most sense.
Formally, that would require a proposed standard specification of TCPINC because only then it can be used in standards produced by other working groups such TCPM. And I believe we are here discussing a mechanism that may have to update RFC 793, which is an Internet Standard that is ubiquitously deployed in the Internet. Also, I think this mechanism is not required for payload protection and should thus be moved into a separate document separated from the base TCPINC protocol. Furthermore, at least the MPTCP WG had a past consensus call against using options inside TLV frames, even for option data tied to payload. There can be subtle challenges when moving TCP options to a TLV structure and this has been discussed extensively in MPTCP (in 2010/2011). So, it could make sense to first sync with implementers of other TCP options whether there is actually interest in this sort of mechanism, and what the actual requirements would be. Again, this is an indication that such a mechanism should be separated from a base protocol. Finally, I believe it is not appropriate for this WG to further discuss any mechanism that affects RFC 793, which defines the handling of options in TCP. Such a discussion belongs to the TCPM list. Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
