Re: [tsvwg] Fwd: New Version Notification for draft-touch-tsvwg-udp-options-05.txt

[Tom Herbert <[e-mail]>]

On Mon, Feb 27, 2017 at 3:30 PM, Joe Touch <[e-mail]> wrote:

> Hi, all,
>
> A new version of the UDP options proposal has been posted.
>
> It adds:
>
>     - fragmentation based on IPv6's mechanism (thanks to Mark Smith)
>
>     - MSS (thanks to Mark Smith) and TS based on TCP's mechanism
>
>     - auth/encryption based on TCP-AO and its extensions
>
> It clarifies the report of a non-compliant legacy device (thanks to Mike
> Heard).
>
> It also adds a discussion on control block caching, ala RFC2140 for TCP.
> Feedback welcome.
>
>
Joe,

>From section 9:

"It is useful that the above requirements prevent using UDP options to
implement transport-layer fragmentation and reassembly unless that
capability has been negotiated with an endpoint in advance for a socket
pair. Legacy systems would need to be able to interpret the transport
payload fragments as individual transport datagrams."

This can probably more broadly be worded as saying that any option that
cannot be safely ignored requires the capability to be negotiated. So that
clearly includes fragmentation, encryption, and any other option that
modifies the payload of the original UDP packet. We can also include
authentication in that list since that needs key negotiation also. So
probably the next question is whether a checksum or CRC can be ignored by a
receiver.

Note, VXLAN and LISP have already taken liberty to allow a non-zero
received UDP checksum to be ignored, however this contrary to RFC1122 which
says:

"If a UDP datagram is received with a checksum that is non-zero and
invalid, UDP MUST silently discard the datagram."

There is similar wording for IP and TCP checksums.

I think this is the correct and robust policy for checksum/CRC. If a sender
took the time to compute them and set them in the packet then it should be
incumbent on the receiver to verify them. The whole point of enabling
integrity checks is to catch errors and corruption, if we don't catch the
errors at this layer we can only hope that they are caught later on but
there's no guarantee. What's worse if I'm debugging an issue and snoop
packets on the wire and see that sender is sending checksums but receiver
is not catching bad packets then this is completely misleading. Allowing a
receiver to ignore checksums undermines usefulness of the mechanism.

So IMO, checksums and CRCs are in the class of options that cannot be
ignored by a receiver and would need to be negotiated. That leaves TS and
MSS options which probably can be safely ignored.

Tom