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

[Joe Touch <[e-mail]>]

Thank you for AGAIN failing to give an example.

Joe

> On Jan 4, 2020, at 7:10 PM, C. M. Heard <[e-mail]> wrote:
> 
> 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