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

[Raffaele Zullo <[e-mail]>]

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