Subject: [dnsext] Amplification attacks, RFC3704 etc.

From: "George Barwood" <[email-masked]>
Date: Tue, 1 Sep 2009 12:52:21 +0100

I have some questions:

(1) Since RFC3704 ( http://www.ietf.org/rfc/rfc3704.txt ) is there any
evidence of progress on prevention of IP spoofing?

(2) Are there amplification attacks that have similar or greater amplification 
than the DNS-based attacks ( which have an amplification of roughly x 70 ) ?

which leads to

(3) Is everyone happy about deploying EDNS/DNSSEC when it can be used to
mount DoS attacks on third parties?

George

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 1 Sep 2009 05:25:21 -0700

> evidence of progress on prevention of IP spoofing?

THe MIT Spoofer project:
http://spoofer.csail.mit.edu/summary.php

> than the DNS-based attacks ( which have an amplification of roughly  

There are sufficient non-DNSSEC queries you can target at open  
recursive resolvers which also have high amplification factors.

EG, you can always make one: a giant TXT record on amplifier 
(x).baddomain, and then launch spoofed queries to recursive resolvers  
to trigger it.

---

From: "George Barwood" <[email-masked]>
Date: Tue, 1 Sep 2009 14:13:45 +0100

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 01, 2009 1:25 PM
Subject: Re: [dnsext] Amplification attacks, RFC3704 etc.

> http://spoofer.csail.mit.edu/summary.php

Thanks, that looks scary.

> (x).baddomain, and then launch spoofed queries to recursive resolvers  

Yes, but are there any non-DNS ones with high amplification?

I'm suggesting that EDNS be fixed/replaced.

Would that contribute anything to internet stability?

If there are other high amplification attacks out there (that cannot be fixed), it won't.

If not, it might.

George

---

From: Jim Reid <[email-masked]>
Date: Tue, 1 Sep 2009 14:44:22 +0100

> Would that contribute anything to internet stability?

No.

EDNS is not broken. It doesn't need fixing or replacing. Tinkering  
with working protocols in the vague hope of devising something better  
-- for some definition of better -- is very damaging to stability and  
interoperability. BTW, it's not enough to just "suggest that EDNS be  
fixed/replaced". You need to explain why.

Even if something better could be devised -- and that's a very big if  
-- it will not make the slightest difference to DNS amplification  
attacks. You seem to have ignored that these attacks depend on a DNS  
query causing a server to return a large amount of data. That  
behaviour is determined by what data the server holds for some name/ 
qtype/class tuple, not how that data get transmitted over the network.

Also, given the endless discussion here about middleboxes failing to  
support EDNS packets and/or fragmentation of DNS packets, you should  
realise by now nothing other than replacement is ever going to fix  
those broken devices. So what hope is there that these boxes which  
don't do The Right Thing with EDNS today will somehow behave perfectly  
with something totally new that "fixes" or supersedes EDNS?

BTW, the scope for DNS amplification attacks (and all sorts of other  
nasties) would be much reduced if ISPs did proper egress filtering.  
That's a topic for another WG.

---

From: "George Barwood" <[email-masked]>
Date: Tue, 1 Sep 2009 15:28:41 +0100

----- Original Message ----- 
From: "Jim Reid" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 01, 2009 2:44 PM
Subject: Re: [dnsext] Amplification attacks, RFC3704 etc.

> fixed/replaced". You need to explain why.

The reason why is that it appears to be a menace.
It has already being used for attacks on third parties.
 
> qtype/class tuple, not how that data get transmitted over the network.

No, it does very much depend on how it is transmitted.

If there is a hand-shake, as with TCP, spoofing amplification attacks
are not possible ( if the hand-shake is correctly implemented ).

So prima facie, it certainly can make a difference.

It may be that the internet is so unstable anyway that in practice
the difference is negligible, that's part of what I'm trying to ascertain.

> with something totally new that "fixes" or supersedes EDNS?

Most of these boxes will pass UDP and TCP perfectly well, especially
if  fragmentation is avoided ( which is the case for TCP ).

Fixing these boxes will do nothing to stop amplification attack, which
in my mind is potentially a much more serious concern.
 
> That's a topic for another WG.

Agreed. But 

(a) I'm not convinced it will ever happen ( but not my field, so I'm asking ).

(b) I don't think it is a good security model. It's better to assume that
adversaries have the ability to inject bad faith packets into a global
packet switched network, and design protocols so that they are
reasonably robust under that assumption, and at a minimun cannot
be used as attack weapons.

George

---

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Sep 2009 17:13:00 +0000

> From: "George Barwood" <[email-masked]>
> Date: Tue, 1 Sep 2009 15:28:41 +0100
> 

EDNS isn't nec'y or sufficient for menacing third parties.  Widespread lack
of BCP38 deployment is nec'y, and any wide area UDP protocol is sufficient;
any moderate sized DNS response (google.com MX, for example) is sufficient.

The fact that DNSSEC with EDNS makes these attacks more easily devastating
does not mean EDNS is required for them to be devastating.  Let's not add
moving parts and friction to the machine unless it *solves* a problem.  If
you want to *solve* amplified DDoS, focus your efforts on deploying BCP38.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Sep 2009 09:38:48 +1000

> you want to *solve* amplified DDoS, focus your efforts on deploying BCP38.

Especially as BCP 38 solves a whole lot of other non amplification problems
as well.  Spoofed packets are just plain

	BBBBBBBB              AA           DDDDDDDD      ##
        BB     BB	    AA  AA         DD     DD     ##
        BB      BB	   AA    AA        DD      DD    ##
        BB     BB	  AA      AA       DD      DD    ##
        BBBBBBB           AAAAAAAAAA       DD      DD    ##
        BB     BB	  AA      AA       DD      DD    ##
        BB      BB        AA      AA       DD      DD
        BB     BB         AA      AA       DD     DD     ##
	BBBBBBBB          AA      AA       DDDDDDDD      ##

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Doug Otis <[email-masked]>
Date: Tue, 01 Sep 2009 19:03:41 -0700

On 9/1/09 4:38 PM, Mark Andrews wrote:
> In message<[email-masked]>, Paul Vixie writes:
>>> From: "George Barwood"<[email-masked]>
> as well.  Spoofed packets are just plain bad!

Mark,

George is not wrong about a potential problem.

While implementing BCP38 is highly recommended, reflected attacks are 
not inhibited by egress filtering, since both source and destination IP 
addresses are valid.  Based upon the MIT link provided by Nicholas 
Weaver, half of the IP addresses do not have egress filtering, and many 
use large CIDR filters.  With hundreds of millions of compromised 
systems, BCP38 should not be considered comprehensive protection from 
reflected attacks.  Only a protocol can offer comprehensive protection.

In addition to EDNS0 enabling the distribution of higher gain reflected 
DNS payloads, packet reassembly is also made vulnerable.  As such, 
reliance upon packet reassembly might prove a bad practice.  The number 
of compromised systems is steadily rising.  Based upon email heuristics, 
the last 6 months has seen the number of botted systems more than 
double.  Reflected attacks both obscure botted systems, and in the case 
of EDNS0, increases their damage.  Simply put, reflected attacks can 
defeat local egress filtering.  In other words, your statement that 
local BCP38 filtering only permits direct attacks is not correct.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Sep 2009 12:38:12 +1000

In message <[email-masked]>, Doug Otis writes:
> addresses are valid.

If you have strict BCP38 in place you can only attack the path
between the attacker and the responder.  There is NOTHING you can
do to prevent this.  If you have wider filters then the attackers
neighbours can be attacked as well however all traffic will be
going through the same administative entities as is traceable.

> Based upon the MIT link provided by Nicholas 

Which just means that finer grain BCP38 filters are needed.  Put them
close to source and they are not expensive.  BCP 38 is not whack-a-mole
so applying presure to get BCP38 deployed is still a worthwhile effort.

> local BCP38 filtering only permits direct attacks is not correct.

If you do BCP38 correctly you can't.  ISP's should be putting the
BCP 38 filters as close to the customer edge as possible.  This
reduces the amount of machines that will be impacted by non perfect
filters to machines that are direct neighbours of the attacking
machine.

If the ISP is not doing this then they are not really doing BCP38.

If I have a address 1.2.3.4 and my ISP only allows packet with a
source address of 1.2.3.4 to pass from me to them, how can I launch
a reflection attack agains 2.3.4.5 using 5.6.7.9 as the reflector?
I can cause a lot of traffic between 1.2.3.4 and 5.6.7.9 but all
of that traffic will have 1.2.3.4 and 5.6.7.9 in the IP packet
headers.  This is a amplication attack on the path not a reflection
attack.  There is no protocol change that will help this if you
really need the data to be returned.  All you can do is balance out
the flows by making normal operations more bandwidth expensive and
that is a bad tradeoff.

Mark

---

From: Paul Wouters <[email-masked]>
Date: Tue, 1 Sep 2009 22:41:34 -0400 (EDT)

On Tue, 1 Sep 2009, Doug Otis wrote:

> With hundreds of millions of compromised systems

You have no need of amplification......

Paul

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 2 Sep 2009 05:22:53 -0700

On Sep 2, 2009, at 1:29 AM, George Barwood wrote:

> From: "Paul Wouters" <[email-masked]>
> To: "Doug Otis" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, September 02, 2009 3:41 AM
> Reflective attacks are hard to take down.
> The 4000 byte TXT attack had a weakness, it could be stopped by  
> taking down the TXT record.
> But attacks using open resolvers to fetch say ANY SE cannot be  
> stopped in this way.
> So you have to take the compromised systems down one by one, a very  
> difficult task,
> and new machines may be being compromised as fast as you take others  
> down.

It doesn't have to be 4000B txt records.  EG, it could be 4000B worth  
of "legitimate" a record answers.

DNSSEC does NOT make it easier to conduct these amplification attacks,  
unless you assume a complete lack of attacker imagination.

> What will probably happen / has already happened is that operators
> will start filtering DNS fragments / DNS packets > some size.
>
> I'm thinking that it is this that accounts for Nicholas Weavers  
> statistics.

Nah.  Its that fragments are suprisingly HARD to deal with.

EG, if you build a firewall with simple rules like ACLs, you fail to  
pass fragments unless you also say "all fragments after the first are  
allowed".

> The network has reacted to EDNS like your body reacts to a virus -  
> it has rejected it.

This is a ridiculous statement, and untrue.  EDNS and large DNS  
replies are widely accepted out there.  ITs just not UNIVERSALLY  
accepted.

---

From: "George Barwood" <[email-masked]>
Date: Wed, 2 Sep 2009 14:58:22 +0100

----- Original Message ----- 
From: "Nicholas Weaver" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Nicholas Weaver" <[email-masked]>; "Paul Wouters" <[email-masked]>; "Doug Otis" <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 02, 2009 1:22 PM
Subject: Re: [dnsext] Amplification attacks, RFC3704 etc.

> unless you assume a complete lack of attacker imagination.

It's mainly an EDNS problem, but DNSSEC makes it worse by
providing a source of valid large responses that cannot be taken down.

> replies are widely accepted out there.  ITs just not UNIVERSALLY  

It is speculative ( I hope I made that clear, "I'm thinking..." )

But it seems to make sense. See page 8 of

https://www.dns-oarc.net/files/dnsops-2006/Larson-Attacks.pdf

"Limit DNS packet size to 512 bytes, breaks many things!"
"Drop fragments toward the victim"

Well only detailed investigation can establish for sure 
why fragmented responses are being dropped by the network
( and not by the client equipment, according to Ray's report ).

---

From: Douglas Otis <[email-masked]>
Date: Wed, 02 Sep 2009 17:03:56 -0700

On 9/1/09 7:38 PM, Mark Andrews wrote:
> In message<[email-masked]>, Doug Otis writes:

Mark,

Sorry for using the term egress.  BCP38 refers to this as ingress (into
the router), rather than egress (out of the network).  BCP38 drops
emitted packets from hosted networks lacking permitted source IP
addresses.  BCP84 provides an overview of problems created by BCP38 for
multi-homing, default, asymmetrical routing, and honey-pots.  Some
practical strategies lessen the specificity of ingress filtering.

>> While implementing BCP38 is highly recommended, reflected attacks
>> are not inhibited by egress filtering, since both source and
>> destination IP addresses are valid.
>
> between the attacker and the responder.  There is NOTHING you can do
> to prevent this.

It is not clear what is meant by saying "you".  Once DNSSEC becomes
widely deployed, bad actors can exploit any authoritative server that
accepts queries from compromised systems where a source IP address of
the victim's network does not cause the query to be dropped.

Authoritative servers and compromised systems might exist in foreign
networks outside that of the victim's networks.  In which case, attack
payloads will not be affected by BCP38 filters, nor can payload sources
be blocked without causing network bulkanization.

Even with BCP38, avenues for ENDS0 attack remain, either within filter
CIDRs, network exceptions, or hidden tunnels.  Not mandating use of
EDNS0 (which introduces an 8x increased DNS related risk), permits
lower risk strategies that are not reliant upon the world's adoption of
BCP38.

> If you have wider filters then the attackers neighbours can be
> attacked as well however all traffic will be going through the same
> administative entities as is traceable.

This clearly ignores two of the three agents involved in a reflective
attack that might not be within the attacked network, even an attacked
network using strict BCP38.

Bad-actor w/spoofed src --------> DNS -------> Victim
                        (no BCP38)     (BCP38)

>> Based upon the MIT link provided by Nicholas Weaver, half of the IP
>> addresses do not have egress filtering, and many use large CIDR
>> filters.  With hundreds of millions of compromised systems, BCP38
>> should not be considered comprehensive protection from reflected
>> attacks.  Only a protocol can offer comprehensive protection.
>
> Which just means that finer grain BCP38 filters are needed.  Put
> them close to source and they are not expensive.  BCP 38 is not
> whack-a-mole so applying pressure to get BCP38 deployed is still a
> worthwhile effort.

BCP38 does not make ENDS0 inherently safe, only safer.  With high
amplifications, attack vectors can emerge from small avenues.

[]
>> In other words, your statement that local BCP38 filtering only
>> permits direct attacks is not correct.
>
> If you do BCP38 correctly you can't.

Change this to "If everyone does BCP38 correctly, bad actors can't."

> ISP's should be putting the BCP 38 filters as close to the customer
> edge as possible.  This reduces the amount of machines that will be
> impacted by non perfect filters to machines that are direct
> neighbours of the attacking machine.

When address neighbors become problematic, ISPs might decide to block
port 53 traffic not directed toward their resolvers.  Alternatively,
they might impose transparent proxies to mitigate EDNS0 related risks.

> If the ISP is not doing this then they are not really doing BCP38.

While BCP38 suggests ingress filters be placed at periphery routers, it
provides no guidelines for filter sizes.  As such, any source IP address
filter can be described as implementing BCP38.

> source address of 1.2.3.4 to pass from me to them, how can I launch a
> reflection attack against 2.3.4.5 using 5.6.7.9 as the reflector?

The reflected attack can start outside of your ISP's network.  BTW, have 
you heard of PNRP and RFC 4380? Applications police themselves, while 
exchanging complex structures mapping pathways between systems that 
penetrate intervening firewalls.  Even firewall rules within the system 
itself! That's present in a system with a bundled browser connecting the 
Internet to all application interfaces designated "script safe".

> I can cause a lot of traffic between 1.2.3.4 and 5.6.7.9 but all of
> that traffic will have 1.2.3.4 and 5.6.7.9 in the IP packet headers.
> This is a amplification attack on the path not a reflection attack.

Which was not the concern, nor a reflected attack that still remains 
possible with bot-nets.  While bot-nets are indeed numerous and able to 
to cause direct damage, their activity is less noticeable on the 
compromised system, and less obviously involved in mischief to the 
non-attacked ISP when their strategy takes advantage of high gain 
reflected responses made possible with EDNS0.

> There is no protocol change that will help this if you really need
> the data to be returned.  All you can do is balance out the flows by
> making normal operations more bandwidth expensive and that is a bad
> tradeoff.

Resources used to endure attack scenarios need to be fully considered.
More than just the transport state, in-flight traffic buffering will
dramatically increase when confronting packet loss and head-of-line
blocking.  While such buffering growth is a property of TCP or a UDP
paging scheme, SCTP is able to avoid in-flight traffic buffering.

With SCTP able to eliminate in-flight buffering complexities related
to TCP retries, resource limited SOHO firewall devices are then better 
able to effectively handle DNS traffic at network speeds while having 
limited amounts of memory.  Otherwise, significantly greater resources 
would be needed to support TCP as an alternative to EDNS0, which is now 
virtually non-existent, as is ENDS0 support of jumbo frames.

A good property obtained by SCTP as a DNS transport is that it makes
blind packet spoofing virtually impossible, even at 10 Gb/s rates over a
single IP port.  It is not just a matter of telling SOHO manufactures to 
do the right thing, the right thing needs to be both practical, and 
inherently safe.

-Doug

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Sep 2009 11:10:59 +1000

> practical strategies lessen the specificity of ingress filtering.

Whether we argue for BCP38 or BCP84 spoofed traffic from most
compromised boxes can be filtered out by either one of them.

> the victim's network does not cause the query to be dropped.

Please tell me how they get a packet with a source address that
matches the victims IP address past the filter.  You have yet to
show how that is done.

> lower risk strategies that are not reliant upon the world's adoption of

CIDR's blocks can be made small enough to not be a practical issue.
A bot behind a deliberate exception doesn't pass the laugh test.
Hidden tunnels are not a issue.  The tunnel end should be doing BCP
38/84 and blocking it there.  Logically it's like the compromised box
is on the tunnel end point's network.
 
> Bad-actor w/spoofed src --------> DNS -------> Victim

Which is why we are encouraging all networks to deploy BCP38/84.
No one is saying that if you deploy BCP38/84 you will be protected
from others.  What we are saying is that if you deploy BCP38/84 you
protect others (and yourself with tight enough filters) from
compromised machines on your network and if enough people do this
it is effective.
 
BCP38/84 is enlighted self interest.  Leaving EDNS along will
encourge more enlighted self interest.  There really are very few
really bad players.  There are lots of lazy player.

BCP38/84 is like herd immunity.  You need to get enough members of
the herd vacinated to prevent the disease speading or to bring it
under control.

> Change this to "If everyone does BCP38 correctly, bad actors can't."

If the compromised machine/bad actor is behind a BCP38/84 filter ...
 
> they might impose transparent proxies to mitigate EDNS0 related risks.

It's also usually easy to see who is generating the queries unless
mac addresses are also being spoofed and you don't have mac address
filters in place.

> filter can be described as implementing BCP38.

An ISP's periphery includes customer/isp and isp/isp.  In each place
there is a logically correct filter to apply.  Even internally within
a ISP/organisation there are plenty of places where filtering should
occur.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 02 Sep 2009 22:11:27 -0700

On 9/2/09 6:10 PM, Mark Andrews wrote:
> In message<[email-masked]>, Douglas Otis writes:

When a bad-actor's compromised system and the DNS server acting as a 
reflector is outside the network being attacked, then packets 
representing the reflected attack carry the source IP address of the DNS 
server and the destination IP address of the victim.  Since bad-actor's 
compromised systems are everywhere by the hundreds of millions, finding 
unfiltered paths to some DNS server supporting EDNS0 willing to emit 
large UDP packets is likely to become increasingly easier, and not 
harder.

> CIDR's blocks can be made small enough to not be a practical issue.

These filters represent both added cost and added maintenance.  Typical 
ingress filter CIDRs are /8, /16, or /24 with a mean at about /22.  The 
density of compromised systems today can inundate any of these networks 
with reflected attacks.

> A bot behind a deliberate exception doesn't pass the laugh test.

This would depend upon whether the exceptions represent fat inter-ISP 
links, for example.

> 38/84 and blocking it there.

Tunnels are being setup by the bad-actors as a common ploy.

 > Logically it's like the compromised box is on the tunnel end point's 
network.

Perhaps one might view this as colanders placed over ingress CIDRs, 
where every leak is bolstered eight fold by ENDS0. ;^)

> compromised machines on your network and if enough people do this

Today, about half of the IP address remain unprotected.  When a source 
IP addresses is not filtered by the first router, chances of this being 
filtered grows slim.

> BCP38/84 is enlightened self interest.  Leaving EDNS along will
> encourage more enlightened self interest.  There really are very few
> really bad players.  There are lots of lazy players.
>
> the herd vaccinated to prevent the disease spreading or to bring it
> under control.

Or it might take a few DDoS events before enlightened self interest 
filters EDNS0 packets and UDP fragments.  What you describe as lazy 
players, might be actions aimed at minimizing issues when dealing with 
complex mobile, multi-homing, or asymmetrical routes.

[]
> If the compromised machine/bad actor is behind a BCP38/84 filter ...

This really needs to be stated as being behind a sufficiently narrow 
ingress filter.  I agree.  BCP38 represent a good goal.  Do you really 
think it is reasonable to suggest EDNS0, after 10 years of little use, 
will soon provide significant motivation to implement BCP38 everywhere? 
  Or will it's potential for harm provide significant motivation to 
abandon EDNS0?

There is another issue that should be considered.  SCTP can be 
implemented in a manner supportable by SOHO devices without demanding 
extensive memory requirements.  SCTP can also protect non-DNSSEC 
transactions from blind spoofing, and prevent reflected attacks without 
waiting for what you have described as the proper adoption of BCP38.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 03 Sep 2009 10:57:42 -0700

On 9/3/09 8:57 AM, Paul Wouters wrote:
> On Wed, 2 Sep 2009, Douglas Otis wrote:
>
>> will soon provide significant motivation to implement BCP38
>> everywhere? Or will it's potential for harm provide significant
>> motivation to abandon EDNS0?
>
> You mean to lay UDP to rest.

No. UDP with jumbo frames should only be sent after the source of a 
small request has been verified, likely as part of an association setup 
as found with SCTP over UDP, for example.

> Because with DNS gone, there will be another "best amplification attack" using UDP.

IKE amplification?

RFC 4306 section 2 has a requirement for handling packets as large as 
1280 bytes and MAY shorten messages by leaving out some certificates or 
cryptographic suite proposals if that will keep messages below the 
maximum.  It also cautions that fragmentation of oversize UDP packets 
opens the implementation to DoS attack.  IKE will also benefit from the 
use of SCTP.

SIP amplification?
See RFC 5393 that addresses SIP amplification vulnerabilities.

For SIP RFC 3261, section 18.1.1 requires packets larger than 1300 bytes 
MUST be sent over a transport having congestion control.  SIP can also 
run over SCTP. :^)

-Doug