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

[Tom Herbert <[e-mail]>]

On Sun, Jan 5, 2020 at 8:25 AM Joe Touch <[e-mail]> wrote:
>
> 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]), 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.

Since when was options considered in the design of UDP? I'm looking at
RFC768 and see nothing about this.

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

Joe,

As discussed before, the fact that a legacy receiver can receive a
blank packet is potentially problematic. We cannot eliminate the
possibility that zero length UDP packets don't have some detrimental
side effect by some receiving application. We're accepting that the
risk of this is small, but this behavior is far from optimal and if
there were a way to ensure that legacy receivers dropped packets with
UDP options we'd do that. Forcing option-aware receivers to have this
same sub-optimal behavior just to be consistent with legacy receivers
makes no sense.
>
> So regardless of any rules, we MUST NOT try to declare any rule where the receiver “sees NO packet”.
>
Your draft doesn't meet this requirement. e.g. "Option lengths MUST
NOT exceed the IP length of the packet. If this occurs, the packet
MUST be treated as malformed and dropped".

Tom

> Joe
>