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

[Joe Touch <[e-mail]>]

Hi Derek,


On 2/28/2017 12:46 PM, Derek Fawcus wrote:
> ...
>>> Section 5.3 (Option Checksum)
> ...
>>> This would be compatible with the LITE swap scheme
>>> you describe in section 5.5, just with one having
>>> to swap 6 bytes rather than 4 bytes.  It would also
>>> take no more space than the existing checksum - assuming
>>> such was always included.
>> It takes two additional bytes - we can't redefine the existing checksum
>> and be compatible with legacy receivers.
> Sorry,  I've lost the thread here.
>
> I was not suggesting altering how the normal UDP checksum works.
>
> I was mainly driving at how in implementing this in a host stack I'd
> like to verify the options.  Namely that in the absense of the Lite
> option,  it would allow one to use the existing checksum validation
> routine to run across the whole of the surplus area, and if it summed
> to the usual (1's complement) zero,  it is good.
I'm not sure I see that.
The existing checksum runs over the IP pseudoheader, the UDP header, and
the UDP body.

OCS runs over just the option area.

Even in the absence of LITE, the UDP checksum wouldn't cover the option
area.

> In the presence of Lite option it only becomes slightly more complex,
> in that one performs the check as two partial sums.
>
> This could be combined with whatever logic is extracting/detecting
> the presence of the options.  That would obviously requiring using
> the usual 1s complement of the 1s complement sum.  It would have
> to occur before normal UDP processing, and be driven off the UDP
> length and the IP header payload length being different
>
> [I'm assuming the presence of a routine like:
>    uint16_t ip_partial_checksum(uint16_t old_sum, void *start, uint16_t length)
>  which sums the supplied range in to the old_sum, returning the new value.
>  Initialisation and final 1s-complement being done outside that routine.
> ]
>
>
> Or are you referring to existing implementations of your current
> option code?

The spec. There are two checksum options:
    OCS - over just the option area
    ACS - a stronger replacement for the UDP checksum over the same area
as the UDP checksum carries (though it might need to just be the body,
since a NAT is going to mess up the IP pseudoheader and UDP ports)
>
>> I don't want to design a transport protocol capability based on what a
>> middlebox might do. That's "laws for the lawless", IMO, and there's
>> little point. So I'd rather not address this.
> The reference to middle boxes was an unimportant side comment,
> please forget I mentioned it.
>
> The significant point was allowing the same style of checksum
> as already exists, and hence using the same (or similar)
> set of routines.  Especially since if we assume the checksum
> is always present, it costs no more in terms of payload that
> the 8 bit scheme.
The offload routines could be adapted to handle this, sure.

>>> If fragmentation is present with Lite, and two such packets
>>> are received to be reassembled, what happens to the Lite data
>>> from each packet?  Should this combination be rejected, or
>>> defined in some fashion?
>> Good point. I'll think about this and create an ordering list.
> Tom's suggestion here was interesting.  It would seem to be
> re-defining the FRAG+LITE case where the UDP User Data is zero length,
> such that the LITE is now segmented,  and non-Lite.  I'm not sure
> about that yet,  it feels a bit weird.
>
> However, the overall checksum he mentioned could itself be in an
> option,  and would only need to be in one of the fragments.
Right - that would be reassembly verification checksum.

Joe