"Scharf, Michael (Nokia - DE)" <[email protected]> writes:
>> 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. First, I'm fine with not further discussing as you suggest. However, IANA does assign TCP option kinds to experimental RFCs (e.g., RFC6824, with option kind 30 for multipath TCP, and I hope one day TCP-ENO as well). So I hope it's not completely unreasonable to imagine future experimental RFCs that use TCP options to say something about tcpcrypt. Second, I want to clarify that by "make it easy for other RFC authors to leverage tcpcrypt," I wasn't at all suggesting describing some alternate TCP option mechanism in any TCPINC document. Rather, I just meant giving some consideration to future side channel mechanisms, for instance by explicitly having a bunch of reserved frame types along with language about how implementations MUST skip over those frames if they don't understand them. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
