"Mirja Kuehlewind (IETF)" <i...@kuehlewind.net> writes: > Yes, it’s better. It doesn't redefines what to do with the FIN, so > that’s good. For the first sentence it now sounds like this is > independent of the FIN in the regular TCP. Is there a reason why you > don’t want to go for a phrasing as I proposed where you say something > like if TCP would set the FIN (as defined in RFC793) you also have to > set the FINp?
Daniel and I discussed this, and our feeling is that even though FIN and FINp have similar names and a related purpose (it's fair to say the FINp bit protects the TCP FIN bit), it was actually more confusing to try to explain their roles together. In particular, the end of a TCP connection could involve a TCP segment containing multiple tcpcrypt frames, or a tcpcrypt encryption frame that spans multiple TCP segments. So one could go down some complicated bifurcating analysis of what to do in all cases, or just say set FINp on the last frame which seemed both intuitive and correct. We could add one sentence about what TCP does with FIN to say something like the following: A sender MUST set the `FINp` bit on the last frame it sends in the connection (unless it aborts the connection), and MUST NOT set `FINp` on any other frame. TCP sets the `FIN` flag when a sender has no more data, which with tcpcrypt means setting `FIN` on the segment containing the last byte of the last frame. However, a receiver MUST report the end-of-file condition to the connection's local user when and only when it receives a frame with the `FINp` bit set. If a host receives a segment with the TCP FIN flag set but the received datastream including this segment does not contain a frame with `FINp` set, the host SHOULD abort the connection and raise an error condition distinct from the end-of-file condition; if there are unacknowledged segments whose retransmission could potentially result in a valid frame, the host MAY instead drop the segment with the TCP FIN flag set. This is maybe a bit pedantic/redundant, but potentially clearer. Do you prefer this proposed language? David _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc