Re: [tsvwg] Regarding DTLS and UDP options

[Tom Herbert <[e-mail]>]

On Tue, Apr 18, 2017 at 11:36 AM, Joe Touch <[e-mail]> wrote:
>
>
> On 4/18/2017 11:16 AM, Tom Herbert wrote:
>>> UDP packets and TCP packets can already be forged.
>>>
>>> If that's your concern, you need to use true transport-layer or network
>>> layer security.
>>>
>> 1) Yes, that is my concern. UDP is already dicey in terms of security,
>> the risks introduced with these extensions needs to be thoroughly
>> vetted before I'd ever deploy in my network
> Do you feel the same about new TCP options?
>
>> 2) It can't be a requirement to turn up security everywhere just to
>> use UDP options
> It isn't for new TCP options either, though.
>
>> 3) My example is a contrived attack against the new protocol that
>> might be deployed, the mitigations to defend such an attack should be
>> part of the protocol not deferred to some other layer
> The protocol extension already includes OCS and AE for that reason,
> though there's no way that UDP can protect the entire IP header too
> (that's what IPsec is designed for).
>
>>
>>> And endpoints can claim conformance all they want; forged packets are
>>> already noncompliant. No protocol is robust to forged packets except
>>> those that support authentication or encryption.
>>>
>> That's misses the crux of my argument. In my example, an attacker
>> forged a packet with can be "correctly" interpreted as either fragment
>> or a non-fragment. Which interpretation depends on the node that
>> processes it (sort of a Copenhagen Interpretation for network
>> protocols I suppose :-) ). But a packet cannot simultaneously be a
>> fragment and a not fragment, that is nonsensical (packets don't have
>> duality in this instance). This must be considered an error condition.
> The solution to your  example would be for the protocol to allow only
> the hidden FRAG mechanism. Right now that's optional.
>
> However, note that forged packet can add a new extension that has two
> effects - one for upgraded endpoints, one for legacy - already. In TCP.
>
> The solution to *that* ambiguity is to confirm new options before using
> them and use them only when confirmed - as noted in Section 10.
>
>> This ambiguity does not occur in IP or IPv6 and has been introduced by
>> the protocol specification not incorrect implementation.
> It occurs the same way you could forge a new IP option that is accepted
> or ignored, depending on the endpoint support.
>
>> It's unlikely
>> in practice that this would cause problems, however, as I mentioned
>> above, if this can be exploited as a security vulnerability that will
>> be a concern of mine.
>>
>> I thought a one point there was the idea that the UDP checksum would
>> be incorrect so that in the case I describe above a fragment would be
>> dropped and not misinterpreted by a node that doesn't support
>> fragments. Is there a reason that wouldn't work?
>
> I'm not sure - again, I think your concerns about misinterpreting the
> data are addressed by allowing only FRAG as LITE.
>
> 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)

My suggestion to use UDP checksum in combination with length to
eliminate this ambiguity:

Sender host:
- Length includes UDP options
- UDP checksum covers everything up to IP length
- 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
- 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.

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.

Tom





> Consider that if I can forge a FRAG, I can forge an entire UDP packet. I
> don't need anything new to have this vulnerability.
>
> Joe
>