Re: [tsvwg] OCS option in draft-ietf-tsvwg-udp-options-07

[Raffaele Zullo <[e-mail]>]

On 2019-03-12 22:53, Joe Touch wrote:

Hello,

> Yes, when UDP CS=0 we don't cover length or ports.
> 
> Length isn't an issue unless the reassembly checksum is also zero, in
> which case we're doing the right thing - leaving it alone.


OK, but
what happens if UDP Length (that was 8) is increased to
8 < UDP Length <= IPPayloadLength?
Will part of the Options area be delivered to user as a regular UDP 
Payload?


Raffaele Zullo


> As to ports when the frag checksum is NOT zero, I'm much less
> concerned given how devices happily recompute that along packet paths
> for their own convenience.
> 
> Joe


> On 2019-03-12 05:10, Raffaele Zullo wrote:
> 
>> On 2019-03-09 19:28, Joe Touch wrote:
>> 
>>> 3. we have to deal with LITE/LITE+FRAG
>>> we *can* use UDP CS=0, but that also may involve overriding
>>> the
>>> user's desires here (i.e., the user API says "use UDP CS" and
>>> we're
>>> not doing that)
>>> which means we have a choice:
>>> (d) override so that things work, i.e., force UDP CS=0 and
>>> then
>>> (d.1) do OCS as a check on our stuff only
>>> OR
>>> (d.2) disallow the use of OCS (if CS=0, what's the point?)
>>> OR
>>> (d.3) use OCS=0 (this seems like a waste)
>>> OR
>>> (e) ignore the user setting of CS, then:
>>> (e.1) always do OCS as a check
>>> OR
>>> (e.2) if UDP CS=0, omit OCS (save space), basically like
>>> d.2
>>> OR
>>> (e.3) if UDP CS=0, use OCS=0 (basically like e.2
>>> 
>>> If we do any of the (e) variants, we could either:
>>> (f.1) require users to disable UDP CS to use OCS
>>> OR
>>> (f.2) ignore the user UDP CS setting
>>> 
>>> So which is it?
>>> 
>>> I don't like assuming user correct configuration (f.1).
>>> 
>>> So to me it's (f.2) and (d.1).
>>> 
>>> Thoughts?
>> 
>> Maybe I'm missing something but there could be
>> two other problems when using CS=0 with LITE+FRAG
>> 
>> 1) We lose coverage of UDP Length
>> If the UDP Length due to an error becomes 8 < UDP Length <=
>> IPPayloadLength
>> Options will probably become not parsable
>> but part of the Options is delivered as UDP Payload to the user.
>> 
>> 2) We lose coverage of Source and Dest Ports
>> If there are several UDP connections ongoing between two hosts (or
>> two NATs)
>> an error on Source/Dest Port can make the packet be delivered to the
>> wrong connection.
>> This issue is very limited since LITE+FRAG carries an identifier.
>> 
>> Raffaele Zullo