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

[Joe Touch <[e-mail]>]

FYI - all of the stuff below was considered when designing LITE+FRAG and suggesting the reassembled packet had its own reassembly checksum - that did NOT include the pseudo header. 

I.e., IMO, the LITE+FRAG mechanism we have already does basically all we CAN do.

> On Mar 11, 2019, at 4:28 PM, Derek Fawcus <[e-mail]> wrote:
> 
>> 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
>