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

[Joe Touch <[e-mail]>]

Hi, Tom,


On 2/28/2017 3:02 PM, Tom Herbert wrote:
>
> ...
>
> 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.

It depends; the variant that Mike proposed for FRAG using LITE with a
zero-size UDP user payload is backward compatible, but just ends up
dropping everything at a legacy receiver). We could actually pull the
same trick with any other mechanism that would have corrupted the
receiver, FWIW (not just FRAG) (see below, though).

> We can also include authentication in that list since that needs key
> negotiation also.
AE wouldn't (just as TCP-AO doesn't); both rely on predeployed keys.

> 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.
I agree that a required checksum cannot be ignored...
>
> 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.
ACS is intended to provide better protection for receivers that support
them, but are intended to be ignored by those that do not.

Using ACS before reassembly would imply "drop if it fails if you support
it" - by design.

Using a CRC after reassembly would not, though - it MUST be dropped (but
then we'd know it was supported if the reassembly succeeded).

Joe