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

["[e-mail]" <[e-mail]>]

And, regarding 7605, although NAT boxes at arbitrary midpoints in the net cannot reliably interpret port numbers, there are NATs at the edges of deployments or even embedded inside machines (e.g., within hypervisors) that can reliably do so.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 5, 2024, at 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.
> 
> Mike Heard
>