Re: [tcpinc] AD review of draft-ietf-tcpinc-tcpcrypt

[Daniel B Giffin <[e-mail]>]

Hi Mirja (et al.),

Below I've tried to address the concerns you last raised.
We're ready to submit the tcpcrypt and ENO documents as soon
as we're all happy with these last few details.

Mirja wrote:
> The assignment should only be made in one of the documents and I think this
> one it the right one. So that should be removed from
> draft-ietf-tcpinc-tcpeno.

Ok, great ... we will strip those assignments from ENO.

> So in RFC793, if I recognize correctly, abort is rather something like a
> silent close. Is this what you want, or would it make sense to send a reset?

You're right, this wasn't clear.  I've inserted this paragraph
at the end of Section 3.3:

   Throughout this document, to "abort the connection" means to issue
   the "Abort" command as described in [RFC793], Section 3.8.  That is,
   the TCP connection is destroyed, RESET is transmitted, and the local
   user is alerted to the abort event.

> No, what I meant is maybe to say this:
> 
> "A host MUST NOT resume with a session secret if it has already failed
>     to negotiated resumption in the past with the same secret,
>     in either role."
> 
> Is that still what you wanted to say? If so, I think that's more clear.

Not quite; I've changed the wording of that paragraph (in Section 3.5) to be
more straitforward:

   A session secret may not be used to secure more than one TCP
   connection.  To prevent this, a host MUST NOT resume with a session
   secret if it has ever enabled encryption in the past with the same
   secret, in either role.  In the event that two hosts simultaneously
   send SYN segments to each other [...]

Lastly, concerning FIN/FINp in Section 3.7:

> I would rather state this the other way around:
> 
> "If the TCP FIN is set (on the last segment), the sender MUST set the "FINp"
> bit on the last frame that is send in that segment (unless it aborts the
> connection). A sender MUST NOT set the "FINp" bit except when the TCP FIN
> flag is set on the segment carrying that frame."
> 
> I know that sounds a bit confusing and maybe you can phrase it better. The
> point is you should not re-define (normatively) when the TCP FIN flag must
> be set, as this is defined in RFC793 and it is not good practice to define
> things twice in different documents.

Got it.  I've amended it to this, which avoids any
redefinition of FIN usage:

   A sender MUST set the "FINp" bit on the last frame it sends in the
   connection (unless it aborts the connection), and on no other frame.

   A receiver MUST NOT report the end-of-file condition to the
   connection's local user until receiving 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; however, 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.

Does that seem better?

d