Re: [tsvwg] Regarding DTLS and UDP options

[Joe Touch <[e-mail]>]

Hi Tom,


On 4/18/2017 12:33 PM, Tom Herbert wrote:
>> But I'm not sure I understand the example.
>>
> My example is should be simple packet:
>
> IP|UDP|UDP_payload|FRAG_option
>
> I think if a legacy host receives this they accept it as a regular UDP
> packet, if a host with support received it they see a UDP fragment
> packet. (This is UDP, not UDP LITE)
We already discuss this as a bad idea until you confirm FRAG support
with the other end of the socketpair.

Another solution is to only use FRAG with LITE, but that adds overhead
you might not need  - which is why I think the protocol spec should say
"SHOULD use FRAG with LITE" and "MAY use FRAG without LITE but only
where confirmed".

> My suggestion to use UDP checksum in combination with length to
> eliminate this ambiguity:
>
> Sender host:
> - Length includes UDP options
I'm guessing you mean IP length (which would have to); UDP length cannot
(we can't find the options and they'd be misinterpreted as user data by
legacy hosts).

> - UDP checksum covers everything up to IP length
But that's not the current definition, which means you'll break any UDP
checksum software/hardware (NATs, offload).
> - Checksum over UDP options is nonzero (add an option if necessary to
> force this)
> - Protocol agnostics HW checksum offload should just work


> Receiver that support options:
> - Note IP length != UDP length so options may be present
> - Validate checksum that covers everything up to IP length (sum to
> zero with pseudo header included)
> - Check IP options sum to non-zero
> - Requirements for validating UDP checksum have been met, UDP options
> are valid and checksummed
>
> Receive that does not support options:
> - Since IP options part summed to non-zero, UDP checksum will be bad,
> packet is simply dropped
That means you'll be dropped by NATs too... which is something the
current approach avoids.

> - This is equivalent to packet dropped because options not supported
>
> Now our attacker can either forge fragment or forge a normal packet,
> but not both at the same time. UDP checksum will only be valid for one
> of two interpretations.
Attackers can forge anything. Why would they bother with this sort of
stuff? Why wouldn't they just forge real content that all endpoints
would think is valid?

> In other words the combination of length and UDP checksum can be used
> to identify UDP options with high probability and disallows
> misinterpretation scenario above. This also will work with HW checksum
> offload and obviates the need to have separate checksum in the UDP
> options.
I'm still missing something here.

A forger can forge anything it wants (again, presuming no UDP AE or
IPsec). It can forge both a fragment and a normal packet and send them
both in - thus interfering with either receiver variant. I don't see
what's magic about a single packet that both endpoints interpret - but
if that's the concern, the FRAG/LITE already avoids that and can be used.

Joe