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

["C. M. Heard" <[e-mail]>]

On Sat, Jan 4, 2020 at 3:19 PM Joe Touch wrote:

> I don’t know how best to say this repeatedly, but we are NOT INTRODUCING
> STATE INTO UDP.
>
> We have repeatedly indicated that endpoints using certiain options may
> need to coordinate - OUTSIDE OF UDP. That’s always been true of some
> options - e.g., TCP-AO and TCP-MD5. The same would be true for AE - a
> receiver could decide to allow or ignore checks or could require them. A
> transmitter that needs to know otherwise needs to confirm.
>
> That’s what we’re talking about when we refer to the soft-state mechanism
> - the assumption being that because UDP can’t establish or enforce this
> state, it would at best be soft.
>

A "drop the datagram if you don't recognize this UDP option" -- which is
what I thought we were discussing -- DOES NOT INTRODUCE STATE INTO UDP. It
is totally stateless, and it allows a receiver to drop datagrams that it
should not accept without any prior coordination. In situations where prior
coordination is required in order to make an option work as intended, it
provides protection against failures of that coordination.

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. Seeing a SYn-ACK without the option, the
initiator will return a RST segment. That will terminate the connection,
and since the 3-way handshake never completed, the listener will not
deliver any data that may have accompanied the SYN segment.

For UDP-AE, the listener receives a datagram with an option affecting the
handling of the user data that it does not understand. In my view (and
Tom's) it should discard that datagram -- the same thing that happens with
TCP-AO or TCP-MD5. The easiest way to ensure that, without requiring
knowledge of what every option means, is to systematically embed in the
Option Kind encoding information on whether the option can be safely
ignored or not. We certainly can't do that with a three-way handshake
because, as you point out, there is no such thing in UDP (and I agree that
UDP options must not introduce it; leave that to efforts like QUIC).

Granted, UDP-AE is in the spec, so a diligent implementation that does not
understand the option will discard packets containing it. But what about
options defined in the future?

This has been discussed many times at multiple IETFs and hasn’t changed.
>

It has been indeed been discussed at length, with each of us of repeating
our arguments and failing to convince the other. But AFAICT there has been
no determination of what the WG consensus is, and that determination is not
for you or me to make.

I'm going to refrain from further discussion until I see a new version of
the draft, at which point I will do a complete review.

Thanks and regards,

Mike Heard