Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Tom Herbert <[e-mail]>]

On Wed, Jul 17, 2019 at 10:25 AM C. M. Heard <[e-mail]> wrote:
>
> On Tue, Jul 16, 2019 at 6:13 PM Tom Herbert wrote:
> > On Tue, Jul 16, 2019 at 5:43 PM C. M. Heard wrote:
> > > What I intended to say might be more accurately expressed by saying
> > > that the default receive behavior is:
> > >
> > > - If UDP CS != 0, perform the UDP checksum validation and discard the
> > >   entire packet if the validation fails. In addition, if a surplus area
> > >   is present, perform the OCS validation, and discard the surplus area
> > >   if the validation fails.
> > >
> > > - If UDP CS == 0, do not perform either of those checks. Accept or
> > >   discard the UDP datagram and its surplus area depending on whether
> > >   UDP CS == 0 is or is not allowed for the socket in question.
> > >
> > > Implementations MAY, but need not, support the following configuration
> > > options: (a) disable checking of OCS when UDP CS != 0 and (b) enable
> > > checking of OCS when UDP CS == 0.
> >
> > Mike,
> >
> > UDP options should not need to change the specified behavior of UDP
> > checksum.
>
> I don't think that the words above say that; in any case, I certainly didn't
> intend to suggest that. What I did intend to say was the opposite, i.e.,
> that the presence or absence of the UDP check should affect how the option
> checksum is handled.
>
> > In IPv4, if the checksum is zero, the packet is accepted.
>
> RFC 1122 allows the application to control that behavior:
>
>             If a UDP datagram is received with a checksum that is non-
>             zero and invalid, UDP MUST silently discard the datagram.
>             An application MAY optionally be able to control whether UDP
>             datagrams without checksums should be discarded or passed to
>             the application.
>
>
> My assumption was that would imply a per-socket option.
>
Mike,

Yes, the RFC optionally allows it, but I doubt any implementations has
bothered to implement it. In IPv4, accepting UDP datagrams wiht zero
checksums is always protocol compliant. Interestingly, the converse to
true for IPv6; dropping UDPv6 datagrams with a zero checksum is always
protocol compliant.

> > In IPv6, if the checksum is zero then the packet is dropped with the
> > narrow exception that that a tunneling protocol is used and the port
> > is explictly configured to allow zero checksums. That's what the specs
> > say and that's what's currently implemented.
>
> The text was intended to allow (not require) exactly that.
>
> > Also, if you say "is or is not allowed for the socket in question"
> > that implies that we have to perform a socket lookup in the fast path
> > just to decide whether to basic packet verification. That's not cheap
> > and some devices performing the checksum verification might not even
> > have a way to configure this. It's much better just be deterministic
> > without needing state or configuration and verify the packet solely
> > based on its contents and what the protocol specification says to do.
>
> Should I have used the word "port" rather than "socket"? The assumption
> I made is that in IPv6 the application would do the explicit configuration
> to allow UDP CS=0 datagrams through the (socket) API.

Technically, it's a tuple (socket) lookup. The way the Linux
implentation works is a socket lookup is performed, and if a socket is
matched there is a field in the returned structure that indicates if
UDPv6 zero checksum is allowed. Conceptually, this would specific
control over connected sockets (e.g. full 4-tuple is matched), however
the only users of this are UDP encapsulation protocols that just bind
to some socket so it is effectively a lookup by port.

>
> In any case, it would be best to phrase this in terms of actual behavior
> (as RFC 1122 does) instead of in terms of a particular API.

Yes. For instance, "socket" is not a protocol term, but "port" and
"5-tuple" are.

Tom

>
> Mike