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

["C. M. Heard" <[e-mail]>]

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
and 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.

Mike Heard