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

[Tom Herbert <[e-mail]>]

On Wed, Mar 6, 2024 at 1:10 AM Gorry (erg) <[e-mail]> wrote:
>
> 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
>> 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
>
>
> 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”.

Gorry, that advice is in regards to the UDP checksum being a weak
algorithm. RFC6936 has similar advice when the UDP checksum is set to
zero for UDP6 tunnels:

"If a tunnel transports other inner payloads that do not use IP, the
assumptions of corruption detection for that particular protocol must
be fulfilled.  This may
 require an additional checksum/CRC and/or integrity protection of the
payload and tunnel headers."

The implication is that we can use an alternate CRC when the UDP
checksum is either not used or considered too weak. I think it's also
implied that any alternate to UDP checksum would need meet the same
salient requirements as UDP checksum which are:

1) Use of the checksum or CRC is optional only by the sender not the
receiver. From RFC1122: "Unlike the TCP checksum, the UDP checksum is
optional; the value zero is transmitted in the checksum field of a UDP
header to indicate the absence of a checksum."
2) If a checksum or CRC is received then the receiver MUST either
validate that it is correct or drop the packet: From RFC1122 "If a UDP
datagram is received with a checksum that is non-zero and invalid, UDP
MUST silently discard the datagram."

APC as defined does not meet either of these requirements. It can be
ignored by the receiver and packets with a bad APC can be received all
the way to the application. Even if the APC is known to be bad, the
draft doesn't require the data to be dropped neither as a MUST or a
SHOULD; from the draft:  "UDP packets with incorrect APC checksums
MUST be passed to the application by default, e.g., with a flag
indicating APC failure."

IMO, APC doesn't meet the requirements to be an alternative to the UDP
checksum per the requirements of RFC8085 and RFC1122.

Tom


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