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

From: Joe Touch <[email-masked]>
Date: Sun, 1 Sep 2019 11:16:12 -0700

Some comments below...

> On Aug 28, 2019, at 8:39 AM, Gorry Fairhurst <[email-masked]> 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.

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

> ---
> 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 "MUSR", 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?).

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

---

---

From: Joe Touch <[email-masked]>
Date: Sun, 1 Sep 2019 12:08:53 -0700

I omitted the note for this one:

> would seem much more normal and the receiver behaviour at least is required?

In this case, because the intent is that legacy will silently ignore its
use in future variants (future uses will be optional). That's not the
only choice, though.

i.e.,:

In general, fields reserved for future use have the following properties:

    MUST be set by non-participating (legacy) transmitters to a known
value (zero, typically)

depending on use, one of the following two MUST be selected *at initial
design time*:

a) for fields that are intended to be optional to legacy variants:

    legacy receivers MUST ignore the field value

b) for fields that are intended to be required in future variants:

    legacy receivers MUST validate that the field has the known
legacy-transmitter value

        and if not, MUST specify a behavior (silently drop the packet,
drop the packet and reply/signal, drop the connection, etc.)

Fields with more than two values can specify a number of receiver behaviors.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 02 Sep 2019 08:09:03 +0100

On 01/09/2019, 19:16, Joe Touch wrote:
> Some comments below...
>
>> On Aug 28, 2019, at 8:39 AM, Gorry Fairhurst<[email-masked]>  wrote:
>> ...
>> ---
>> Section 3 - OLD:
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?

> That code can appear anywhere anyway. It might be useful to reword as “One use this option code is to align subsequent options”
That sounds clear to me.
>> -  this seems like a RFC2119 "MUST", since it specifies requirement to process this.
I'd think it better to be clear that the receiver needs to process 
well-formed options with any alignment.
> 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.
> 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 o…
Rewording "assume" would help.
Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 02 Sep 2019 08:09:57 +0100

> Fields with more than two values can specify a number of receiver behaviors.
Something like that would seem good.

Gorry