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

[Joe Touch <[e-mail]>]

On 2019-03-12 16:01, Raffaele Zullo wrote:

> 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?

If the reassembly checksum isn't zero, this would be caught (with high
probability) during reassembly. 

If the reassembly checksum is zero, then yes - corrupt data would go to
the user. But that would have been what the user wanted (by setting the
reassembly checksum to zero). 

Joe 

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