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

[Tom Herbert <[e-mail]>]

On Wed, Mar 6, 2024 at 10:05 AM C. M. Heard <[e-mail]> wrote:
>
> On Wed, Mar 6, 2024 at 8:18 AM Tom Herbert  wrote:
> > 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."
>
> The requirements that you cite certainly apply to the UDP checksum, but
> where does 1122 or any other IETF standard say "or CRC"?

Mike,

There are many protocols that have CRCs. My point is that if we tell
users that APC is an alternative to the UDP checksum then it seems
likely to me that they'll expect it to basically work the same way. If
they miss some of the differences then that could lead to silent data
corruption as we've discussed.

>
> Admittedly, the way that we have traditionally written our
> specifications creates that expectation. But an expectation is not
> necessarily a requirement. As currently specified, APC (and AUTH,
> when it is completed) will allow mutually consenting endpoints to
> use a stronger integrity check (or authentication).

There's no such thing as mutually consenting endpoints in UDP, there
is no negotiation that would allow this (except maybe for the very
limited use case of a simple request/response protocol).

> That makes them
> useful building blocks. And there is something to be said for having
> them be incrementally deployable. I recall a long-ago comment of Michael
> Richardson's that it was a historic mistake for the IP AH specification
> to require mandatory drop for authentication failures because doing so
> inhibited incremental deployment.

Considering AH requires SAs to be set up at both endpoints to be
useful I'm not sure why that would be needed. But even if AH was
optional, would you REALLY want a receiver to ever ignore it? For
instance, if an app is sending bank transactions over the Internet
with AH, would it ever be acceptable for the server to just ignore the
AH without authenticating the request? In my view, absolutely not! If
I send an AH I definitely want the receiver to validate it, because if
they just ignore it then that means they ignore all AH which basically
means there's no security in the system which guarantees the system
will be breached and I will be receiving a letter of apology from my
bank saying their system was breached (although they might neglect
telling me the part about ignoring AH because that would make them
look incompetent, but of course they're not going to get that past
regulators :-) ).

Tom


>
> Mike Heard