Re: [tsvwg] Remaining issues for draft-ietf-tsvwg-udp-options-22

[Tom Herbert <[e-mail]>]

On Mon, Jul 3, 2023 at 5:27 PM C. M. Heard <[e-mail]> wrote:
>
> On Mon, Jul 3, 2023 at 4:50 PM Tom Herbert wrote:
> > Considering that this is a new protocol for which there is no
> > deployment and no one yet understands all the security and deployment
> > ramifications, just saying "let the user decide" seems trite to me
> > without providing some meaningful guidance. The discussions about the
> > interactions with UDP checksum and RFC6936, and firewalls have been
> > very nuanced and complicated to the extent that I wouldn't know the
> > conditions that it's safe to not use a surplus checksum in my
> > deployment-- I think a typical user trying to figure this out for
> > their deployment would be lost.
> >
> > So, to simplify the things,
>
> ... in an utterly trite way ...
>
> > I'd like to suggest this text:
> >
> > "By default, an implementation MUST send the OCS and an implementation
> > MUST expect and validate the OCS checksum on receiving UDP packets
> > with a surplus area. An implementation MAY allow the OCS to be
> > configurable to both send and validate in receive. A user should fully
> > consider the risks and ramifications of disabling the surplus area
> > checksum, especially the risks of misinterpreting surplus area as
> > containing UDP options when in fact it contains unrelated data"
> >
> > So basically, this is saying that if the user decides to disable the
> > surplus area checksum they are doing it at their own risk. This could
> > apply across use cases, so there's no need to tie this to the UDP
> > checksum being zero, nor reference RFC6936. If there are concerns
> > about some firewalls that want the surplus area to be checksummed,
> > that can be mentioned as one thing that should be considered, but if
> > user wants to disable checksum anyway they can.
>
> There's more to it than that, which you decided to ignore.
>

The issues are encompassed in this paragraph from the draft:

"Like the UDP checksum, the OCS is optional under certain
circumstances and contains zero when not used. UDP checksums can be
zero for IPv4 [RFC791] and for IPv6 [RFC8200] when UDP payload already
covered by another checksum, as might occur for tunnels  [RFC6935].
The same exceptions apply to the OCS when used to detect bit errors;
an additional exception occurs for its use in the UDP datagram prior
to fragmentation or after reassembly (see Section 9.4)."

About "UDP checksums can be zero for IPv4 [RFC791] and for IPv6
[RFC8200] when UDP payload is already covered by another checksum",
this statement is incorrect as RFC8200 requires non-zero UDP checksums
since the IPv6 header does not have a checksum and so the checksum
pseudo header is the integrity check for the IP addresses to prevent
misdelivery. There is *no* RFC that states the IPv6 UDP checksum can
be zero based solely on the fact that the payload is already covered
by another checksum; this is an obvious forward reference to RFC6936,
i.e. "as might occur for tunnels  [RFC6935]", however, RFC6935/RFC6936
do not simply say if the payload is covered by an integrity check it's
okay to use a zero checksum, they state the specific requirements for
setting UDP checksum to zero for tunnels (see the ten requirements in
section 5 of RFC6936). Furthermore, specific UDP protocols also need
to consider the risks and mitigations of applying RFC6936 using zero
UDP6 checksums; in section 6.2 of RFC8086 there are three conditions
and ten requirements that must be satisfied to enable zero UDP
checksums for IPv6 (it was not sufficient to just say that RFC6936
applies to GRE/UDP).

Per "The same exceptions apply to the OCS when used to detect bit
errors", as the draft states: "The primary purpose of the OCS is to
detect non-standard (i.e., non-option) uses of that area and
accidental errors". Bit errors could be considered accidental errors,
but non-standard uses of the surplus area are not bit errors. When the
OCS is being used to detect non-standard uses of the surplus area,
which presumably is needed all the time or at least enabled by
default, these exceptions are not applicable. The UDP checksum's
purpose is integrity checksum for bits corrupted in transport, the
surplus checksum is needed to detect non-standard use cases; for
instance, a completely lossless network might justify setting the UDP6
checksum to zero per RFC6396, however the risk of receiving a
non-standard use of surplus area is not mitigated in a lossless
network.

Fundamentally, we *cannot* draw any correlations between the UDP
checksum and surplus area checksum since they cover different areas,
serve different purposes, and the risks of using a zero checksum are
different. This is independent of whether it's IPv4 or IPv6, a tunnel
or not. If a zero checksum in the surplus area is allowed then IMO
there should be requirements in the draft similar to those of RFC6936
but specific to the risks and mitigation for a zero checksum in the
surplus area.

Tom