I have read draft-bittau-tcpinc-tcpeno-02, given that the topic seems related to other TCP modifications. Below are a couple of comments; some could be more major than others. Disclaimer: I don't have much cycles to look into tcpinc, i.e., I apologize if some aspects been discussed already.
* Abstract, page 1: The abstract confuses me. Should the sentence "The TCP Encryption Negotiation Option (TCP-ENO) addresses both of these problems" imply that this document shall finally also specify the encryption within the transport layer, being the second problem? Why doesn't the abstract simply focus on negotiation and mention that it specifies an option limited to the TCP three-way-handshake to solve the negotiation problem? * Section 2, page 3: To me, the whole text on page 2 includes too much hand-having. Some examples: The relation between this document and EDO is unclear and not further detailed later. The socket interface is not owned by the IETF, and RFC 3493 is an informational document for IPv6 only. It is not clear how TFO (RFC 7413) would be used together with this option, and, if so, if stack vendors would be interested in deploying both options together. Basically, I think page 2 could be removed entirely without affecting the content of the document. * Section 2, page 4: "Provide signaling through which applications can better take advantage of TCP-level encryption (for instance by improving authentication mechanisms in the presence of TCP-level encryption)." Since authentication is listed here: How does this option interact with TCP-AO? For instance, I think this document could perhaps discuss what a receiver may do if a SYN segment both with TCP-ENO and TCP-AO options is received. This is a question much closer to the SYN handshake negotiation mechanics than various other sections of the document. * Section 3, page 5: Regarding the sentence "Encryption specs MAY include extra bytes in a non-SYN ENO option, but TCP-ENO itself MUST ignore them." and Figure 2: I suggest to keep this document entirely self-contained, which to me means something like: "If a non-SYN options contains extra bytes, TCP-ENO itself MUST ignore them." If a protocol negotiated by TCP-ENO indeed needs further TCP option space, this should be documented in the corresponding protocol specification. * Section 3.2, page 7: I am confused by some RFC 2119 language in this section. Examples: - "More precisely, for negotiation to succeed, the TCP-ENO option MUST be present in the SYN segment sent by each host" => lower-capital or (better) reword to required implementation behavior - "Additionally, the ENO option MUST be present in the first ACK segment sent by each host, so as to indicate that no middlebox stripped the ENO option from the ACKed SYN." => lower-capital or (better) reword to required implementation behavior - ... (several further examples of the same form) * Section 3.2, page 7: "An active opener begins with a SYN-only segment, and hence must send two segments containing ENO options." That "must" would be a candidate for RFC 2119, but in fact I think the sentence is actually even wrong, given that an active opener "must" only send ENO options in the first segment for the fallback case. * Section 3.2, page 7: The protocol specification has to correctly specify the behavior for retransmitted segments with SYN flag. The requirement stated on page 12 probably belongs here. * Section 3.2, page 9: "... and MUST NOT present raw TCP payload data to the application." Please specify the behavior for payload data in SYN segments, or explicitly mark it as in-scope of a protocol specification using this option. TFO (RFC 7413) could be relevant in this context. * Section 3.3, page 10: Protocol stacks on top of TCP can be complex and consist of multiple layers, libraries, etc. "application" is not well-defined in this case, and whether an application indeed can be aware of TCP stack internals, or not, is a relatively complex question. The concept of "application-awareness" in a multi-layer stack seems fuzzy to me, with lots of open questions. As a simple remedy, instead of "application-aware", the document could perhaps use a term like "upper layer protocol aware". * Section 4: I don't understand why any of the content in the whole section 4 is needed for interoperable implementations of a TCP option in SYNs. Specifically: - Requirement list: In the IETF, requirement lists are typically useful during WG operation, but they can easily become outdated, e.g., by trends in the market. There has always been lots of research innovation in TCP, and I could imagine that the TCP-ENO negotiation option could find future interesting use outside of what is known today. - Session ID: To me, the definition of session IDs, if at all, has to be done in specification of the encryption spec. I don't understand why this section is needed for building interoperable implementations of TCP-ENO, in particular, if not even the length is defined (and that length definition does not belong in this document, IMHO). - Option kind sharing: For this spec, it is sufficient to specify how the option is used within this specification. This section can thus be removed entirely. * Section 5: So far, the IETF has only rather limited credibility in specifying TCP API extensions, at least in my experience. Given that, this section could e.g. be moved to an appendix (see e.g. RFC 7413). * Section 6: Further topics to be considered here: - Considerations of the space limitation in SYNs. Since this document allows in principle an arbitrarily long TCP option, discussion and guidance on that seems useful. - Compatibility with other TCP extensions. Unless sorted out in this document, potential interactions and/or incompatibility with TCP-AO, MPTCP, TCP Fast Open, etc. should at least be mentioned as open issue. * Section 8: The IANA registration procedure for "cs" values has to be specified, and I could imagine different variants, which should probably be discussed relatively early. * Section 8: Why does TCP-ENO not allocate an TCP Experimental Option Experiment Identifier according to RFC 6994? That would be an easy solution to enable experiments with multiple interoperable implementations over the Internet, prior to assignment of a TCP option kind number. Keep in mind that an experimental document requires an explicit IESG action for TCP option kind assignment. In the past, TSV has asked for this IESG action several times. In those cases, there has been very strong consensus in the corresponding working group regarding the codepoint assignment, backed by reasonable interest by TCP stack vendors in the protocol. Michael _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
