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

[Tom Herbert <[e-mail]>]

On Tue, Feb 28, 2017 at 1:46 PM, Derek Fawcus
<[e-mail]> wrote:
> On Tue, Feb 28, 2017 at 01:17:16p.m. -0800, Joe Touch wrote:
>> Hi, Tom,
>>
>> OK - so I think you and Derek are basically arguing for an Internet
>> checksum to verify reassembly, rather than using a new or stronger one.
>
> Actually,  I made a mistake.  I attributed to Tom what was I believe
> was actually suggested by C. M. Heard - namely the suggestion to
> combine FRAG+LITE as a way of allowing existing hosts to discard fragments.
>
> In that he was suggesting adding an overall reassembled checksum,
> which would be necessary as otherwise the repurposed reassembled
> Lite payloads would not have a checksum.  I was simply pointing
> out that in that scenario,  the same could be achieved with a
> single CHECKSUM option, carried in only one of the FRAG packets.
>
> So there would be no need to change the FRAG header definiton to
> add a checksum there.
>
> In the normal case of reassembling FRAG'ed payloads,  I don't see
> that an overall checksum gains us anything.
>
> Possibly an overall CRC would have some value?  That would seem to
> require a second type of ACS-like option, i.e REASSEMBLE-ACS?
> Again it would only need to be sent with only one of the FRAG
> containing packets.  Is such an addition worth it?
>
I would guess not. I think from an implementation point of view it's
almost always better to perform integrity checks, authentication,
encryption, or any other packet transforms over each individual
fragment. If necessary, fragmentation might include it's on integrity
check at reassembly but that might only be over few fields in each
fragment not over all the data. This is how we defined processing
order in GUE fragmentation occurs before other options are set so that
the other options (auth, csum, etc.) are applied per fragment;
receiver processes all other options before attempting reassembly.

Tom