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

[Joe Touch <[e-mail]>]

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

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

http://www.strayalpha.com/" rel="noreferrer noreferrer noreferrer nofollow" target="_blank">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