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

[Tom Herbert <[e-mail]>]

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

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
>