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

[Gorry Fairhurst <[e-mail]>]

On 26/09/2023 18:10, Joe Touch wrote:
> Swap /Teheran/ with /then/.
>
>> On Sep 26, 2023, at 10:08 AM, Joe Touch <[e-mail]> wrote:
>>
>> 
>> Changing that behavior would be inconsistent with the design of the 
>> options overall.
>>
>> The definition of a safe option is just that. Of you make APS unsafe, 
>> Teheran it cannot interoperate with legacy endpoints at all.
>>
>> Joe

Yes, I do understand that.

- I thought the utility was a stronger check that worked without a 
pseudoheader. That in itself requires a sender to know which approach is 
going to be taken by the receiver. This is UNSAFE.

- The sender could negotiate out of band what it needs, or the 
application developer can decide when both client and server are 
designed, but this needs to be consistent.

Gorry

>>
>>> On Sep 26, 2023, at 9:11 AM, Gorry Fairhurst <[e-mail]> 
>>> wrote:
>>>
>>> 
>>> On 26/09/2023 16:46, Joe Touch wrote:
>>>> Gorry,
>>>>
>>>> Your view of APC doesn’t align with the text, which had been stable 
>>>> for a while now.
>>>>
>>>> The current text also explains why the current behavior is needed.
>>>>
>>>> Joe
>>>
>>> Yes, I see, I seem to have overlooked this change when it was added 
>>> in -09, it wasn't what I expected to read. Can we change this 
>>> behaviour?
>>>
>>> As stated, it isn't an alternative to a UDP Checksum: it adds bytes 
>>> that a receiver may or may not ignore, so therfore a sender still 
>>> needs to add a checksum, and I am not sure how this helps a sender 
>>> whoi can anyway include a CRC within the data it sends, to me this 
>>> just seems weird?
>>>
>>> Gorry
>>>
>>>
>>>
>>>
>>>>
>>>>> On Sep 25, 2023, at 11:58 PM, Gorry Fairhurst 
>>>>> <[e-mail]> wrote:
>>>>>
>>>>> 
>>>>> On 26/09/2023 05:30, [e-mail] wrote:
>>>>>>
>>>>>>
>>>>>>> On Sep 25, 2023, at 7:36 PM, Tom Herbert 
>>>>>>> <tom=[e-mail]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Sep 25, 2023, 7:35 PM Tom Herbert <[e-mail]> 
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     On Mon, Sep 25, 2023, 5:31 PM [e-mail]
>>>>>>>     <[e-mail]> wrote:
>>>>>>>
>>>>>>>         See below.
>>>>>>>
>>>>>>>         —
>>>>>>>         Dr. Joe Touch, temporal epistemologist
>>>>>>>         www.strayalpha.com <http://www.strayalpha.com/>
>>>>>>>
>>>>>>>>         On Sep 25, 2023, at 5:21 PM, Tom Herbert
>>>>>>>>         <tom=[e-mail]> wrote:
>>>>>>>>
>>>>>>>>         On Mon, Sep 25, 2023 at 5:08 PM [e-mail]
>>>>>>>>         <[e-mail]> wrote:
>>>>>>>>>
>>>>>>>>>         On Sep 25, 2023, at 4:14 PM, Tom Herbert
>>>>>>>>>         <tom=[e-mail]> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         On Mon, Sep 25, 2023, 3:55 PM [e-mail]
>>>>>>>>>         <[e-mail]> wrote:
>>>>>>>>>>
>>>>>>>>>>         FWIW,  you can also “require ACS” at the receiver, if
>>>>>>>>>>         you want. That would ensure that ACS was both present
>>>>>>>>>>         and valid.
>>>>>>>>>>
>>>>>>>>>>         UDP options are based on the core rule that senders
>>>>>>>>>>         decide what to offer and receivers decide what’s
>>>>>>>>>>         required.
>>>>>>>>>
>>>>>>>>>         Joe,
>>>>>>>>>
>>>>>>>>>         For something like CRC, the sender is in a much better
>>>>>>>>>         position to decide if it's needed.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         Whether it is or is not, that’s not something UDP
>>>>>>>>>         options supports - what UDP supports is based on a
>>>>>>>>>         bunch of principles, including the need to support
>>>>>>>>>         legacy receivers. So if something is “required”, the
>>>>>>>>>         receiver has to demand and check for it.
>>>>>>>>>
>>>>>>>>>         For example, if two hosts were communicating over a
>>>>>>>>>         rack switch, the ACS is probably pointless since
>>>>>>>>>         Ethernet CRC is sufficient. But, if the hosts were
>>>>>>>>>         communicating over an unreliable satellite link then
>>>>>>>>>         ACS might be critical.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         Or the link/phy layer might have its own checks
>>>>>>>>>         anyway, e.g., block checksums. End to end errors
>>>>>>>>>         happen during reassembly or in memory, not all that
>>>>>>>>>         often on links that aren’t checked, AFAIR.
>>>>>>>>>
>>>>>>>>>         In both those cases, it's the sender that has the best
>>>>>>>>>         view as to what's required because it may require
>>>>>>>>>         knowledge of the path to the destination. So, if the
>>>>>>>>>         sender computes the ACS, then the receiver should
>>>>>>>>>         honor that and verify it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>         In some other protocol where those semantics can be
>>>>>>>>>         demanded, perhaps. But remember that anything the
>>>>>>>>>         sender “demands”, except for encryption, is at best a
>>>>>>>>>         “request”; receivers always get to decide what they
>>>>>>>>>         enforce anyway.
>>>>>>>>
>>>>>>>>         Joe,
>>>>>>>>
>>>>>>>>         I believe the general consensus in IETF is that
>>>>>>>>         checksum or CRCs may
>>>>>>>>         be optional to send, but not optional to validate when
>>>>>>>>         received. The
>>>>>>>>         precedent was established in RFC1122: "If a UDP
>>>>>>>>         datagram is received
>>>>>>>>         with a checksum that is non-zero and invalid, UDP MUST
>>>>>>>>         silently
>>>>>>>>         discard the datagram."
>>>>>>>
>>>>>>>         That’s for checksums you know are coming. A legacy
>>>>>>>         receiver won’t know or care.
>>>>>>>
>>>>>>>         UDP option-aware receivers work like legacy receivers
>>>>>>>         UNTIL they are explicitly told otherwise. That’s the
>>>>>>>         basic operational principle.
>>>>>>>
>>>>>>>         So you can tell your receiver to care about ACS if it
>>>>>>>         shows up all the time. Or not.
>>>>>>>
>>>>>>>         Here’s the current text, which follows these principles:
>>>>>>>
>>>>>>>             >> UDP packets with incorrect APC checksums MUST be passed to the
>>>>>>>             application by default, e.g., with a flag indicating APC failure.
>>>>>>>
>>>>>>>             Like all SAFE UDP options, APC needs to be silently ignored when
>>>>>>>             failing by default, unless the receiver has been configured to do
>>>>>>>             otherwise. Although all UDP option-aware endpoints support APC
>>>>>>>             (being in the required set), this silently-ignored behavior ensures
>>>>>>>             that option-aware receivers operate the same as legacy receivers
>>>>>>>             unless overridden.
>>>>>>>
>>>>>>>>         For user perspective, if I set the ACS in my packets
>>>>>>>>         but the receiver
>>>>>>>>         may or may not validate it then it doesn't seem very
>>>>>>>>         useful as a check
>>>>>>>>         for corruption of the sender's data.
>>>>>>>
>>>>>>>         It is useful when the receiver agrees it is useful.
>>>>>>>
>>>>>>>>         I'd probably put a CRC in the UDP
>>>>>>>>         payload instead that I can assure it is always verified
>>>>>>>>         by the
>>>>>>>>         receiving application.
>>>>>>>
>>>>>>>         You can do that if you want, but then it means that it
>>>>>>>         cannot be silently ignored by a legacy receiver.
>>>>>>>
>>>>>>>
>>>>>>>     Right, that's exactly the desired non-deterministic
>>>>>>>
>>>>>>>
>>>>>>> Deterministic  I meant
>>>>>>>
>>>>>>>     behavior that we want with regards to a CRC. Silently
>>>>>>>     ignoring the CRC also means that data corruption would also
>>>>>>>     be silently ignored.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> So you have two choices:
>>>>>>
>>>>>> 1. Use UDP options with ACS (which is now APC)
>>>>>> a cooperating receiver would know to set APC as required and 
>>>>>> would drop packets if APC fails
>>>>>>
>>>>>> 2. Create a new application that knows to require APC
>>>>>> so that the application can enforce CRC in the payload
>>>>>>
>>>>>> But if you can do (2), why not do (1) and have the application 
>>>>>> enforce APC-required?
>>>>>>
>>>>>> Joe
>>>>>
>>>>> I'm reading this with some doubt now.
>>>>>
>>>>> I think option the above option 2 needs to be strongly 
>>>>> discouraged: it provides a place to send an integrity check, but 
>>>>> it doesn't protect the parsing of the other options nor their 
>>>>> data, which would leave all other fields unprotected. That check 
>>>>> would better be provided within the application data, and we ought 
>>>>> to remove this option if that is all it does.
>>>>>
>>>>> Here is what I thought had been designed:
>>>>>
>>>>> I expect a sender chooses whether to add an APC option.
>>>>>
>>>>> If a receiver receives the APC option, the receiver must to either:
>>>>>
>>>>> - discard all datagrams that contain an APC that it decides not to 
>>>>> check, or when the APC fails.
>>>>>
>>>>> - forward datagrams that contain an APC that passes. (It MIGHT be 
>>>>> configured to always expect an APC: which I think is the ONLY 
>>>>> receiver decision).
>>>>>
>>>>> ... This differs from the benign "use or ignore" processing that 
>>>>> applies to most options, but it is exactly the required logic that 
>>>>> I would expect and I thought we previously discussed.
>>>>>
>>>>> Gorry
>>>>>
>>>>>
>>>