Re: [tsvwg] Checksums in UDP options

["C. M. Heard" <[e-mail]>]

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).

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.

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

Mike Heard