Re: [tsvwg] Checksums in UDP options

[Tom Herbert <[e-mail]>]

On Thu, Sep 6, 2018 at 12:00 PM, C. M. Heard <[e-mail]> wrote:
> On Thu, Sep 6, 2018 at 11:30 AM Tom Herbert wrote:
>> On Thu, Sep 6, 2018 at 11:03 AM, C. M. Heard wrote:
>>> On Thu, Sep 6, 2018 at 10:45 AM Tom Herbert wrote:
>>>> On Thu, Sep 6, 2018 at 10:23 AM, C. M. Heard wrote:
>>>>> That is certainly correct, and for that reason I would agree that AE
>>>>> and any other option that requires reversal of a transform on the
>>>>> data must be used in conjunction with LITE, in order to prevent
>>>>> misinterpretation of payload data in case of an OCS failures.
>>>>>
>>>>> I don't want to see this required for all UDP options, though. That
>>>>> would exclude some desirable use cases. Consider the case of
>>>>> DNSSEC, which is known to have issues with IPv6 fragmentation.
>>>>> A client can safely include a FRAG option with offset zero,
>>>>> length 12, and checksum zero in a UDP datagram sent to any server.
>>>>> That FRAG option is a no-op that indicates that it is safe for the
>>>>> server to return a reply using UDP fragmentation.
>>>>
>>>> Where's the security in that? If an attacker spoof my address and
>>>> sends a FRAG option to a DNS server, then AFAICT the DNS server will
>>>> think that the host with my address supports FRAG.So next time I do a
>>>> DNS look up, the the server may respond with UDP fragments. If my host
>>>> doesn't support UDP options, then the application gets DNS response
>>>> that are gibberish. This is a perfect Denial of Service Attack.
>>>
>>> Your legacy host won't see gibberish if FRAG is combined with LITE as
>>> we've been discussing. Rather, it will see a UDP length of zero in each of
>>> the fragments, and its UDP layer will deliver no data to its application layer.
>>> That's actually more innocuous that the threat that already exists today.
>>>
>> It's still a problem. The server may infer that receiving the FRAG
>> option means that the sending host supports options. So then when the
>> server starts sending options with LITE, the packets are now dropped
>> at the client. The effect of DOS attack is still the same. The client
>> isn't seeing responses from the server, the server thinks everything
>> is okay since there's no error reports coming back to it,
>>
>> You might get away with this negotiation method in a request/response
>> protocol like DNS if the server only responds using UDP options if it
>> the client indicated support in the request.
>
> Indeed, in the DNS case, the negotiation I describe is safe only if
> the server does not retain memory of the client's ability to use FRAG
> across transactions. The negotiation has to apply to exactly one
> request -- which is what I was implicitly assuming. But subject to
> that proviso, I fail to see any security vulnerabilities (either from a
> spoofing attack or a MITM attack) that do not already exist today.
>
> I grant that this is a special case, but I believe that it is a potentially
> important special case (though the DNSOP folks may not agree --
> see draft-song-atr-large-resp for an alternative approach).
>
I'm not sure I would call DNS a special case. Isn't that one of the
biggest users of UDP on the Internet?

> Again, though, you bring up a good point: negotiating the use of
> options that transform the data can introduce security vulnerabilities
> unless there is some means to authenticate the remote peer.
>
Look at it this way, we've spent about forty years trying to get TCP
handshake to be secure and efficient and it's still not perfect. These
are not easy problems to solve! :-)

>> But note, only the
>> server side can use mandatory options like FRAG, not the client in
>> this case.
>
> I think what you meant to say here was not "mandatory options"
> but rather something like "options that transform the data" -- is
> that correct?
>
"Mandatory" in the sense that they must be processed, not that they
must be in the packet. I consider options with strong CRCs set by the
sender to be in that class, since the effects of ignoring a CRC really
isn't innocuous.

Tom


> Mike Heard