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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Daniel,

see below.

> Am 29.09.2017 um 22:34 schrieb 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.

Okay.

> 
>> 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.

Good.

> 
>> 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 […]

Ah, I think I actually missed the word session previously. But adding this sentence makes it even more clear. Thanks.

> 
> 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?

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?

Anyway that’s not a big issue. Please just make a decision about what's the right thing to do here and resubmit as soon as possible. I really would like to start the IETF Last call soon, however, I would also like to start it together with the tcpeno draft.

Mirja



> 
> d
>