DNS Amplification Attacks... and a trivial proposal

[David Miller]

On 06/13/2013 05:33 AM, Phil Mayers wrote:
> On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote:
>
>> 1)  If everyone on the planet were to somehow magically and
>> immediately be
>> converted over to DNSSEC tomorrow, then would DNS amplification attacks
>> become a thing of the past, starting tomorrow?  Does DNSSEC "solve" the
>> DNS amplification attack problem?  Or does it have no direct bearing on
>
> No, quite the opposite in fact. By increasing the size of responses,
> DNSSEC arguably makes the amplification problem (slightly) worse.

"slightly" is generous.  I would say "dramatically".

$ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +nodnssec

; <<>> DiG 9.9.2-P1 <<>> mx isc.org @ord.sns-pb.isc.org +noall +stats
+nodnssec
;; global options: +cmd
;; Query time: 223 msec
;; SERVER: 199.6.0.30#53(199.6.0.30)
;; WHEN: Thu Jun 13 11:28:49 2013
;; MSG SIZE  rcvd: 403


$ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +dnssec

; <<>> DiG 9.9.2-P1 <<>> mx isc.org @ord.sns-pb.isc.org +noall +stats
+dnssec
;; global options: +cmd
;; Query time: 242 msec
;; SERVER: 199.6.0.30#53(199.6.0.30)
;; WHEN: Thu Jun 13 11:28:54 2013
;; MSG SIZE  rcvd: 2427


DNS reflection attacks are all about amplification (a small request
resulting in a response larger than the request).  A 6 times greater
response size is a large jump in amplification.

>
> DNSSEC is a good thing and necessary for other reasons, but it does
> not help amplification attacks.

+1

>
>> 2)  Has anyone ever proposed adding to the DNS protocol something
>> vaguely
>> reminicent of the old ICMP Source Quench?  If so, what became of that
>> proposal?
>
> <snip>
>
>> Basically, the whole idea is just simply to allow a victim to switch to
>> "safe TCP only mode" with all of the intermediaries that are
>> participating
>
> The problem with that idea is that it needs software updates on both
> the reflecting DNS server and the victim. It also seems to require
> keeping a lot of soft state in the endpoints.

This would require both software updates and an update to the DNS protocol.

This idea does require state at the endpoints.  We seem to have already
lost that battle - example RRL.  Would this require more state at the
endpoints than RRL?  I think that this probably would require more state.

One concern I have is that it turns the problem on its head and now the
network that is the target of the attack is required to get packets out
through their loaded equipment to stop the attack.

This could lead to wrong headed statements like, "Yes, we sent X GB of
traffic at your network.  You didn't implement DNS source quench?  You
should have."

The chain of responsibility for these attacks is:
1. The person(s) originating the spoofed traffic.
2. The network(s) allowing the origination of spoofed traffic.
3. The network(s) transmitting the spoofed traffic.
4. The operators of nodes amplifying the traffic towards the victim.
5. The victim.

A system that requires the victim to take action to stop attacks might
be misconstrued by some to be abdicating the responsibility of the upper
four levels.

>
> Altogether, it seems easier for everyone to just apply RRL patches, do
> BCP38 and de-peer with people who don't do BCP38.

Agreed.  Close all open resolvers as well.

Using this strategy, however, you will have to do an awful lot of
de-peering.

-DMM

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130613/2c6d6e63/attachment.html>