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

[Joe Touch <[e-mail]>]

A deliberate design decision is to let the receiver decide what to do when authentication fails. 

If they know about authentication, then they can enforce it. But they can always have ignored it so there’s no benefit to “forcing” it to be acted upon.

And it’s not “regardless of having an example”. That’s the reason why we decided not to design features into this mechanism - the lack of an example.

A design goal from the start was that receivers would decide whether they wanted to enforce an option; it isn’t in the hands of the transmitter to make that decision, largely because UDP is stateless. If you want enforcement, create state - and let that state be the way that these sorts of things are enforced.

Without that state, you can’t know what’s being ignored or implemented incorrectly anyway.

Joe

> On Jan 4, 2020, at 1:42 PM, Tom Herbert <[e-mail]> wrote:
> 
> 
> 
> On Sat, Jan 4, 2020, 1:24 PM Joe Touch <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>> On Jan 4, 2020, at 10:44 AM, C. M. Heard <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> On Fri, Jan 3, 2020 at 8:36 PM Joe Touch <[e-mail] <mailto:[e-mail]>> wrote:
>> No example has been given of a transport protocol need for “drop if the option isn’t supported” that doesn’t modify the frag payload.
>> 
>> What about ACS? It does not modify the payload, but it affects how the payload is handled: if the ACS check fails, the payload is not delivered to the user. Those semantics can be violated if the ACE option is ignored.
> 
> ACS is mandatory so it can’t be ignored if UDP options are implemented. If it is used with FRA+LITE, the payload would be ignored by legacy receivers and would have to be accepted by option-aware receivers.
> 
>> That issue is handled in the -08 draft by making it mandatory to recognize and implement -- a point with which I disagree, as I think it should be optional to implement. But even if I don't get my way on that, the point still remains that we can't retroactively make FUTURE options such as ACS mandatory to implement.
> 
> Such as. That seems to be the mantra.
> 
> I’ve asked for a specific example of something the draft doesn’t already cover. Still waiting.
> 
> Authentication (AE option without encryption so no payload modification). Per the draft, it is not mandatory, but similar to ACS a packet with option can't be accepted unless validated.
> 
> Regardless of having an example, Mark's point is valid about adding mandatory options in the future can't be done retroactively. If the intent of the draft is that options like this can't added after the initial publication then the draft should make that requirement clear.
> 
> Tom
> 
> 
> Joe