"Black, David" <[email protected]> writes: > Hi David, > > This looks good, although I think this "SHOULD" requirement ought to be a > "MUST": > >> > If a host sends a SYN-only SYN+ENO segment bearing data and >> > subsequently receives a SYN-ACK segment without an ENO option, that >> > host SHOULD reset the connection even if the SYN-ACK segment does not >> > acknowledge the SYN data. The issue is that unacknowledged data may >> > nonetheless have been cached by the receiver; later retransmissions >> > intended to supersede this unacknowledged data could fail to do so if >> > the receiver gives precedence to the cached original data. > > and I would clearly characterize the following as suggestions for future work: > >> > Connection resets are potentially avoidable if SYN data caching is >> > empirically found not to occur, or in response to an API command (for >> > cases where a higher-layer integrity check would anyway terminate a >> > garbled connection). > > This leaves specification of circumstances in which it's ok not to reset the > connection to a future draft that explains why that's ok.
I'm not sure I understand your suggestion. Wouldn't changing the SHOULD to a MUST preclude the future work you are suggesting? I'm hoping to reserve MUST for things that prevent future TEPs from conflicting with one another or with TFO, not to prevent a future TEP from shooting itself in the foot. Shouldn't we decide whether or not it's okay to violate this recommendation if and when somebody proposes a TEP that violates this rule (presumably armed with a giant measurement study)? Also, following the previous discussion, I've looked over the "SHOULDs" in the document, and many of them are not followed by an explicit exception. Let me group them here to get your feedback about whether this is a problem, and whether I need to be more specific in the document. Here's a list of types of SHOULD that are not immediately followed by an exception: * Many of the uses concern APIs that implementations SHOULD provide. The reason for the SHOULD is that in some cases this may be impossible or inapplicable. For example, if you are implementing TCP-ENO inside a dedicated NAS server, there might not be the same notion of applications giving API commands. On the other hand, these points are pretty important to the success of TCP-ENO, and should be followed in the vast majority of cases. * "TEP specifications SHOULD refer to hosts A and B to specify asymmetric behavior." Again, no explicit exemption, but the point is that there might be a TEP that is not asymmetric, or where some other optimization makes it better to specify hosts by the numeric order of their Diffie-Hellman parameters or something. I suppose I could change that to a MAY, but if TEPs talk about active/passive openers, that could mess up simultaneous open. * Implementations SHOULD provide forward secrecy. The important point is that the TEPs MUST be amenable to forward secrecy. We didn't say MUST for the implementation because that may not always be possible--e.g., implementation considerations may someday require keying material to be shared across servers or with a load-balancer or something. We don't want to say you can't implement TCP-ENO under such circumstances, but we want people to think long and hard about the implications for confidentiality. * Applications SHOULD authenticate endpoints, SHOULD treat session IDs monolithically, SHOULD use the application aware bit. Again, these are all obviously very good things. But there are so many different things an application can do, and so many constraints applications can be subject to, that it seems inappropriate for a transport-layer document to use MUST in regards to applications. Anyway, we can't enforce what applications will do. * Applications SHOULD migrate to option TBD from the ExID. RFC7413 used the word SHOULD for exactly the same point in its IANA considerations section, so we just copied what those authors did. The TCP-ENO team is clearly not well versed in the practice of allocating and specifying TCP option kind numbers, so we are happy to follow any specific guidance from the working group on whether to change that SHOULD to a MUST. * TEPs SHOULD compute session IDs using only well-studied and conservative hash functions. Here the problem is that the terms well-studied and conservative are subjective. So while I think it's an important point people need to worry about violating, the point is also nebulous enough that I don't see how to enforce it with a MUST. Put another way, the hash functions SHOULD be as conservative as practical, with an implicit exception where more conservative hash functions are not practical. * We say the non-SYN-form ENO option SHOULD be 0 bytes if not otherwise specified by the TEP, but I'll change that to a MUST in the next draft, since it doesn't matter anyway. Thanks, David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
