[tsvwg] LITE+FRAG UDP CS=0 (was Re: OCS option in draft-ietf-tsvwg-udp-options-07)

[Derek Fawcus <[e-mail]>]

On Mon, Mar 11, 2019 at 11:18:39PM +0100, Derek Fawcus wrote:
> 
> Actually, my original thought here (which I then culled), was to have another
> option, or ACS.  That other option would encode the current style of checksum,
> so for concerns about CPU cost of using CRC, we could mitigate it.
> 
> What I had in mind was an option containing two 16 bit fields, one would
> encode the partial-checksum for the pseudo-header as the originator sent
> it, the other the partial-checksum for the original UDP payload.
> 
> e.g.:  [ Type = Frag-Chks | Len | part-phdr-chk | part-data-chk ]
>   
> That way the receiver can recover from any NAT mangling of the packet which
> would otherwise mess with the checksum calculation.
> 
> i.e. for the UDP portion, assuming the packet was encoded with UDP CS=0
> 
>   1. Calculate partial checksum for pseudo-header as received
>   2. Compare to option part-phdr-chk
>   2a. If equal verify UDP data against part-data-chk
>   2b. If differ verify UDP data against part-data-chk + (part-phdr-chk - phdr-chk)

It might help to explain my line of reasoning here..

My first idea for using UDP CS=0 for LITE+FRAG was simply to move
the original UDP CS in to an option.

i.e. the host stack would operate as normal, building its UDP header.
Then during building the options area, it would copy the
UDP CS in to an option (call it the Moved Checksum - MCS),
and zero the CS in the UDP header.

So we end up with something like:

  [Kind=MCS|Len=4|16 bit checksum]

Then I realised this would be broken by NATs.

Hence concluding one would have to also carry the partial
checksum for the original pseudo-header
(i.e. src-ip/dst-ip/src-port/dst-port/proto) such that
NAT manipulations can be compensated for:

  [Kind=MCS|Len=6|16 bit part-phdr-chk|16 bit original-chk]

So the processing on the TX side to generate that is no
more costly, the RX side would have a bit more work.

Conceptually generating:

  new-chk = original-chk - (part-phdr-chk - rx-phdr-chk)

Then writing that over the UDP CS field, before passing the
packet in to the original receive / validate routine.

Sending two partial checksums is just another way of achieving
the same effect.  Maybe the moved version is clearer?

Since we know that this checksum is for the pseudo-header
and UDP header alone, with len=0 and no carried data;
I'm just wondering now if that can be improved?

DF