Re: [tcpm] review of rev 14 of RFC 793 bis part 2 of 2 - Technical Comments & Questions

[Gorry Fairhurst <[e-mail]>]

On 01/09/2019, 19:16, Joe Touch wrote:
> Some comments below...
>
>> On Aug 28, 2019, at 8:39 AM, Gorry Fairhurst<[e-mail]>  wrote:
>> ...
>> ---
>> Section 3 - OLD:
>>      Reserved for future use.  Must be zero in generated segments and
>>      must be ignored in received segments, if corresponding future
>>      features are unimplemented by the sending or receiving host.
>> - why is this not an RFC2119 requirement to set and check the reserve fields, this
>> would seem much more normal and the receiver behaviour at least is required?
>> ---
>> Section 3 - OLD:
>>      If a
>>      segment contains an odd number of header and text octets to be
>>      checksummed, the last octet is padded on the right with zeros to
>>      form a 16 bit word for checksum purposes.
>> - why is this not an RFC2119 requirement to insert the padding, this
>> seems required for correctness?
> Because padding is only one way to compute the checksum; another is to simply take the final byte and left-shift it. That can be computed without actually inserting a pad.
I agree, there are multiple ways to achieve this. So could we rewrite 
this so "is padded", is replaced by a sentence that includes "The 
checksum value needs to ensure the 16-bit alignment of the data being 
checksumed. If the segment contains an odd number of header and payload 
octets, this can be achieved by calculating a checksum that pads the 
last octet on the right with zeros to form a 16-bit word." ... or 
something similar but clear?

>> ---
>> OLD:
>>        This option code may be used between options, for example, to
>>         align the beginning of a subsequent option on a word boundary.
>> - this seems like a RFC2119 "MAY", since it specifies permission to include this.
> That code can appear anywhere anyway. It might be useful to reword as “One use this option code is to align subsequent options”
>   to a word boundary.”
That sounds clear to me.
>> ---
>> OLD:
>>         There is no guarantee that senders will use this option, so
>>         receivers must be prepared to process options even if they do
>>         not begin on a word boundary.
>> -  this seems like a RFC2119 "MUST", since it specifies requirement to process this.
> It would be better to just say up front that “options need not be aligned.” You don’t need to describe all the cases for which receivers MUST succeed. In general “Receivers MUST process any well-formed header”, but that’s already a given (if they didn’t, what’s the point of the whole spec?).
I'd think it better to be clear that the receiver needs to process 
well-formed options with any alignment.
>> ...
>> ---
>> OLD, Section: "   Initial Sequence Number Selection"
>> - This I think needs to refer to "Defending against Sequence Number Attacks" in RFC 6528, which formally updated RFC793. I question - if the RFC793 text is safe and correct.
> Yes, but as a SHOULD, not a MUST. It’s worth noting that if this is cited.
>
>> - In reviewing this, please also fix "cryptographic has of the concatenation"
>> ---
>> OLD, Section: "   The TCP Quiet Time Concept"
>> - Found this section quite amusing. Is this concept widely implemented in stacks?
> This section should be more normative than amusing. It basically helps protect against the same issues as TIME-WAIT when old connections are not known due to a crash.
New text may help.
>> ---
>> OLD:
>>    We assume that the TCP will signal a user,
>>    even if no RECEIVEs are outstanding, that the other side has closed,
>>    so the user can terminate his side gracefully.
> AFAICT, “TCP MUST” make this signal available to the user (but it need not be initiated by TCP), but that’s already covered by the API, which already requires that the user be able to detect this or any other state of TCP anyway (STATUS).
Rewording "assume" would help.
> ---
Gorry