Re: [tsvwg] Alternative version of the UDP FRAG option

[Joe Touch <[e-mail]>]

On 2019-03-12 15:56, C. M. Heard wrote:

> On Tue, Mar 12, 2019 at 3:40 PM Joe Touch wrote: 
> 
>> I'm still not following the need for this alternative.
>> 
>> FRAG+LITE works fine - even through broken middleboxes with the checksum
>> bug - if used with CS=0, which is how it ought to be used.
> 
> Not all of us agree that this is how it ought to be used, since CS=0 affords
> no protection for the UDP header itself.

Not exactly. CS=0 with nonzero fragment checksum still ends up (IMO)
implicitly validating the length of the payload that results anyway -
and OCS on the reassembled set (i.e., OCS as the first UDP option in the
reassembled payload) would provide a check on the options. 

The only thing missing is protection of the port numbers - which get
rewritten and recomputed many times inside the net in many cases, to the
point that I don't think it even makes sense to consider that an E2E
protected field anymore. 

>> The trailing checksum in the last fragment is over the reassembled total
>> (or not if also zero) and there's no utility in checksumming the fragments
>> themselves.
> 
> My position is that the level of protection that we should strive to
> achieve is what is available with conventional IP fragmentation coupled
> with the standard UDP checksum. That combination protects the entire UDP
> datagram, including the UDP header. The trailing checksum the terminal
> FRAG option, when used with CS=0, does not do that.
> 
> A second reason for preferring this proposal to FRAG as now presented
> in the draft is that it eliminates the hazard of FRAG without LITE.

Understood, but AFAIR your proposal ends up computing checksums multiple
times over the same data. 

And no, those checksums can't be combined to save work - that undermines
the whole point of a reassembly checksum. 

I.e., we're not really giving up much (in terms of protection, see
above) but we gain a LOT (much less work - enough that will end up
mattering in cases with high reassembly load, such as DNS servers, IMO).


Joe