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

["Gorry (erg)" <[e-mail]>]

See below

On 6 Mar 2024, at 05:38, Tom Herbert <tom=[e-mail]> wrote:



On Tue, Mar 5, 2024, 8:22 PM C. M. Heard <[e-mail]> wrote:

On Tue, Mar 5, 2024 at 5:57 PM Tom Herbert wrote:
> I don't understand the intent of this new text:
>
> "Another reason is because APC may fail even where the user data has
> not been corrupted, such as when its contents have been overwritten.
> Such overwrites could be intentional and not widely known; defaulting
> to silent ignore ensures that option-aware endpoints do not change how
> users or applications operate unless explicitly directed to do
> otherwise."

I had a similar question and commented on that when closing Issue #25.

See https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/25#issuecomment-1977823570" rel="noreferrer noreferrer nofollow" target="_blank">https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/25#issuecomment-1977823570
and https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/25#issuecomment-1977982512" rel="noreferrer noreferrer nofollow" target="_blank">https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/25#issuecomment-1977982512

The gist is that middleboxes have been known to overwrite embedded IP
addresses and ports. In that case the middlebox could reasonably be
expected to update the UDP checksum, but an implementation that predates
the specification of APC could not be expected to update it. I see that
a clarification is forthcoming in -32, but we are now past the I-D
submission cutoff date, so it won't appear for a couple of weeks.

> I am not familiar with any IETF protocol that allows UDP payload to be
> updated in flight. In fact, RFC7605 states that UDP port numbers
> cannot be correctly interpreted in the network, so there is no way to
> implement a robust protocol that changes UDP payload inflight. Because
> of this, an intermediate node that is overwriting the UDP payload *is*
> in fact corrupting the UDP payload. So this new provision is seemingly
> accommodating this non-standard, potentially harmful behavior as the
> default.

There are middleboxes that are known to rewrite the embedded IP
addresses in FTP. That's not endorsed by any standard, but it's
a fact of life that we live with. And I see that Dan Wing has named
some UDP-based protocols that do this, too.

If that's the case, wouldn't it be easier to just advise the developers of these handful of protocols like TFTP to not send APC, instead of making it the default for all receivers to ignore APC on the off chance that they might hit one legitimate case in all their traffic?

Tom

Mike Heard

My suggestion is that we do not need to add a new UDP requirement, but to say something like:

Section 3.4 of RFC 8085 advises developers to use additional payload protection when “  where data integrity is important”.

The APC option can be used to provide this by applications  enabling this at the sender and also requiring the presence of a valid APC crc at the receiver.

Gorry (as a WG member, not a chair)