Re: [tsvwg] Rregarding soft-state and UDP options

[Joe Touch <[e-mail]>]

Just to dive a little into the TCP example, additionally:

> On Jan 4, 2020, at 7:10 PM, C. M. Heard <[e-mail]> wrote:
> 
> Since you brought it up, let's compare and contrast the operation of TCP-AO and TCP-MD5 with that of UDP-AE, in the case that an endpoint erroneously (due, e.g., to a misconfiguration) attempts to initiates an exchange containing the option with a peer that does not understand it.
> 
> For TCP-AO or TCP-MD5, the listener will receive a SYN segment with the option. Since it does not understand the option, it will return a SYN-ACK that does not contain the option.


The presence of unknown TCP options **NEVER** causes a SYN to be ignored, discarded, or to generate a RST. It is simply ignored.

It is the result of *state exchange* that enables the endpoints to know when to use - or not use - those options. It is the responsibility of the sender to know what options to use; the receiver is ALWAYS ALLOWED TO INGORE OPTIONS that it hasn’t confirmed by state exchange - even after a connection is established.

E.g., even if the side opening the connection, sending the SYN+AO were to ignore the reply (SYN-ACK without AO, never RST), let’s look at what happens to the connection afterwards. Let’s say the side opening the connection decides to include AO anyway. The receiver WOULD CONTINUE TO IGNORE OPTIONS IT DOESN’T UNDERSTAND.

See RFC1122, Sec 4.2.2.5.

Your subsequent claim is incorrect, as per the citations below:
	> Seeing a SYN-ACK without the option, the initiator will return a RST segment. 

RFC2385 for TCP-MD5, Sec 2.0:
   Unlike other TCP extensions (e.g., the Window Scale option
   [RFC1323 <https://tools.ietf.org/html/rfc1323>]), the absence of the option in the SYN,ACK segment must not
   cause the sender to disable its sending of signatures.  This
   negotiation is typically done to prevent some TCP implementations
   from misbehaving upon receiving options in non-SYN segments.  This is
   not a problem for this option, since the SYN,ACK sent during
   connection negotiation will not be signed and will thus be ignored.
   The connection will never be made, and non-SYN segments with options
   will never be sent.  More importantly, the sending of signatures must
   be under the complete control of the application, not at the mercy of
   the remote host not understanding the option.

RFC5925 for TCP-AO, Sec 11:
   TCP-AO does not include a fast decline capability, e.g., where a SYN-
   ACK is received without an expected TCP-AO and the connection is
   quickly reset or aborted. 

—

For UDP, the original design goal was to follow this behavior, i.e., that the receiver always ignores options it doesn’t understand individually. That’s largely because options overall can be ignored - there’s no way to “unring the bell”. Even if we bury options or user data inside the FRAG+LITE, the *ONLY* correct behavior is to have the receiver see a zero-length UDP packet arrival.

There is NO way to prevent that for legacy receivers - and thus there should be no way to do otherwise for option-aware receivers. The best we should ever try to do is to make option-aware receivers see what legacy receivers see in that case (unknown options) - a blank packet.

So regardless of any rules, we MUST NOT try to declare any rule where the receiver “sees NO packet”.

Joe