[tsvwg] Re: I-D Action: draft-ietf-tsvwg-udp-options-33.txt

[Sebastian Moeller <[e-mail]>]

Hi Joe,


> On 10. Sep 2024, at 17:05, [e-mail] wrote:
> 
>> On Sep 10, 2024, at 7:52 AM, Sebastian Moeller <[e-mail]> wrote:
>> 
>> Hi Joe.
>> 
>>> ...
>>> 
>>> So far, you are the only party claiming this default is a problem. AFAICT, we have three others who feel otherwise. I would like to hear from others on the list as well.
>> 
>> [SM] Since you asked...
>> 
>> Trying to assume I would build a real protocol using the UDP options framework:
>> If I desire authentication I likely will want a "proper" client on the receiver side that is able to handle that properly, as purely opportunistic AUTH does not seem to be what I want.
>> 
>> Now my options are:
>> a) require a UDP options aware stack on the other end
>> b) re-implement the required UDP option capabilities for authentication for legacy clients, and sends these as part of the UDP-payload (so these clients see the data)
>> 
>> If I chose a) than making AUTH UNSAFE seems like what I would want (I also need a handshake to make sure the remote end actually speaks my protocol) as that legacy client will not be proper for my protocol anyway.
>> 
>> If I choose b) I likely would not care, as if I have my own option handling, why should I not use that unconditionally?
>> 
>> So let me ask, what good will it do to have a legacy UDP receiver see an unauthenticated and potentially corrupted packet that was intended to be authenticated as part of an UDP options based protocol? What utility do you see in such opportunistic unidirectional authentication without error signalling, that makes it worth to allow that?
> 
> This views impact from the perspective of AUTH that fails with a good key. It can also be viewed from the perspective AUTH that could also succeed with a good key but would cause a legacy receiver to fail.
> 
> “Opportunistic” just that - opportunistic.

[SM] Yes, but the question is, what protocol do you envision where opportunistic authentication is a desired feature? 

> IMO, that means “benefits where it can, but doesn’t break when it’s not used”.

[SM] But you are not really breaking anything when making AUTH payload UNSAFE, as these are new users by definition so there is no existing legacy use-cases that could exist and need to be taken care of, no?

> AUTH that isn’t checked at the receiver doesn’t just pass failed authenticity checks; it passes ones that would have succeeded to, so it acts like it’s not there. That’s “opportunistic” to me.

[SM] Yes, but what utility does this offer to somebody employing AUTRH in a new protocol based on top of UDP options? Surely if AUTH is used UDP options are required and hence that legacy receiver is not a valid client, so dropping such a packet will hardly di any harm? Note that such a client is unlikely to actually implement any feedback that is likely part of the new protocol either...

> 
>> I understand that making AUTH UNSAFE has some mild implications on how to define what UNSAFE means, but is that really an unacceptable cost?
> 
> The issue is impact to legacy receivers who might not be aware AUTH. Any option is arguably something the sender wants the receiver to react to, but if we make all options UNSAFE, we end up basically with a new protocol hidden only in the surplus area.

[SM] Which honestly would be my preference...

> An important consideration of UDP options is to have features that legacy receivers could ignore but still do useful work.

[SM] Again explain how a new UDP-options based protocol that wants to use AUTH can actually do something reasonable with legacy clients?

> 
> In the case of AUTH, what you pass to the user as default is something as if AUTH isn’t there. That’s true for all SAFE options. It simply doesn’t perform the check. If the receiver cares - especially if it has a key, but even if it doesn’t - it can simply override the default.

[SM] That is not how I understand that protocols work... these are not pick your own choice kind of affairs, so what is the value proposition here?

> 
> Again, we’re talking about DEFAULT behavior, and design principle 6 is to try where possible to make the receiver with options have the same default behavior as one without.

[SM] Makes little sense here. If my protocol wants to use AUTH I will need to have non-legacy clients anyway... a legacy clent, by definition, can not use a UDP-options based protocol, so I wonder what utility is in having such a client application see AURH payload?

> The question is whether doing AUTH on a packet means “you’d better do this or else” - but again, everything in UDP is designed to let the receiver decide what to do, not the sender force.

[SM] Sure, but UDP already exists, UDP options is advertized as framework to build protocols on top of UDP, if "anything goes" is desired, why would I not simply stick to existing UDP?

> 
> FWIW, if we’re talking about precedent across IETF protocols, that’s a fundamental - transmitter offers, receiver decides. In stateful protocols, e.g., TCP, SCTP, etc., option capabilities are announced in the SYN but the receiver decides whether to accept them or not. The initiator has to wait for feedback to decide whether to proceed based on that information.
> 
> In this case, the transmitter can try to figure out of the receiver will honor AUTH using an app level exchange; if it doesn’t, then it can always decide to cease transmissions too.

[SM] Yes, and respectfully UPD options as framework should offer a convenient way to perforrm such a negotiation/handshake, does it?


> 
>> Regards
>> Sebastian
>> 
>> P.S.: I wonder whether "working code" could not be helpful to decide such questions…
> 
> AFAICT this would be a decision that would determine the behavior of working code, not the converse, so I don’t see how that would affect this discussion.

[SM] I disagree, working code likely would show whether a theoretical idea has real utility... 

> 
> Joe