Subject: [Crisp] IRIS-LWZ and security issues due to spoofed sources

From: William Leibzon <[email-masked]>
Date: Mon, 27 Feb 2006 05:18:41 -0800 (PST)

There have been a lot of discussions going on in the last few days
at NANOG and other dns operations lists that are related to issue of
public recursive dns servers being used way to amplify an attack:
  http://www.gossamer-threads.com/lists/nanog/users/89657
  http://lists.oarci.net/pipermail/dns-operations/2006-February/thread.html

The general description of the problem is that bad guys are sending
spoofed udp packets to servers in a way so that the servers would send 
data (to spoofed source) that is considerably larger then the original 
request - thus the amplification. For more information, you may want 
to read http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf

Now it occurs to me that the same problem may also happen with those
using IRIS-LWZ UDP method as IRIS response is very likely to be larger 
then original request and thus there is a possibility of amplification.

So before its too late and IRIS-LWS draft is published as an RFC,
I think we need to have this possiblity documented in the Security 
Considerations section (which is rather small right now...) and try
to come up with some suggestions on how to deal with the problem when 
people want to run public IRIS server.

---
William Leibzon
   mailto: [email-masked]
Anti-Spam and Email Security Research Worksite:
   http://www.elan.net/~william/emailsecurity/
Whois & DNS Network Investigation Tools:
   http://www.completewhois.com

_______________________________________________
Crisp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/crisp

---

From: William Leibzon <[email-masked]>
Date: Mon, 27 Feb 2006 05:39:39 -0800 (PST)

BTW - Don't assume that this is quite as much an issue for IRIS as it is
for DNS. While the problem is basicly the same, the number of IRIS servers
that are going to be run around this world is likely going to be several
orders of magnitude smaller then number of dns servers so really number of 
targets for miscreants to abuse would be very small and they would have to 
send lots of requests to each server to accomplish something.

So the issue would be for IRIS server operators is to know that spoofed 
pockets are possibility and this is something that miscreants can use for
amplification attack (so don't send too large a response to anonymous udp 
request) and deploy mechanisms that stop sending responses if too many
requests appear from particular source through IRIS-LWZ.

On Mon, 27 Feb 2006, William Leibzon wrote:

> spoofed udp packets to servers in a way so that the servers would send data 
> (to spoofed source) that is considerably larger then the original request - 
> thus the amplification. For more information, you may want to read 
> http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf
>
> using IRIS-LWZ UDP method as IRIS response is very likely to be larger then 
> original request and thus there is a possibility of amplification.
>
> to come up with some suggestions on how to deal with the problem when people 
> want to run public IRIS server.
>
> ---
> William Leibzon

---

From: Shane Kerr <[email-masked]>
Date: Mon, 27 Feb 2006 14:08:10 +0100

William,

I can only think of a couple of solutions, neither of which is very
attractive.

The first is to require that requestor packets be as big as or larger
than the response. This is bad for everyone involved, and requires that
the client know how big the response will/can be (this might be easy
with dchk, I don't know).

The second is to limit the responses, depending on client identifier.
For anonymous users this will have to be client IP address. AFAIK, all
Whois public servers do this now. This breaks down for IPv6: because
each user gets 2^80 different addresses (or at least 2^64), some sort of
aggregation is necessary unless your server can track that many
addresses. The problem with aggregation is punishing the wrong person,
leading to DoS attack against the service (imagine preventing an entire
university from querying the IRIS server by spoofing a lot of packets
from their network).

Since this is a general UDP problem, perhaps it makes sense to point to
another document for this problem. Is there such a thing?

--
Shane

William Leibzon wrote:

> orders of magnitude smaller then number of dns servers so really
> number of targets for miscreants to abuse would be very small and they
> would have to send lots of requests to each server to accomplish
> something.
>
> So the issue would be for IRIS server operators is to know that
> spoofed pockets are possibility and this is something that miscreants
> can use for
> amplification attack (so don't send too large a response to anonymous
> udp request) and deploy mechanisms that stop sending responses if too
> many
>> spoofed udp packets to servers in a way so that the servers would
>> send data (to spoofed source) that is considerably larger then the
>> original request - thus the amplification. For more information, you
>> may want to read
>> using IRIS-LWZ UDP method as IRIS response is very likely to be
>> larger then original request and thus there is a possibility of
>> amplification.
>>

---

From: Andrew Newton <[email-masked]>
Date: Mon, 27 Feb 2006 09:41:08 -0500

> another document for this problem. Is there such a thing?

That was gonna be my first question:  just how do they mitigate this  
with DNS?  Or DHCP?  Or anything else that uses UDP?  It seems BCP 78  
is applicable to this.

Also, I was under the assumption that an amplification attack  
resulted in an order of magnitude higher response.  In other words,  
if I send a 100 byte packet, the amplification is in hundreds of  
times higher bytes and usually across multiple packets.  Perhaps if  
we could get a pointer to the classic attack scenario that would help.

According to this:
http://www.lancs.ac.uk/postgrad/pissias/netsec/ddos/index.html
There really are two types of attacks: reflection attacks and  
amplification attacks.  As any interesting as reflection attacks are,  
they don't seem to be that much more gain than a direct attack.  The  
amplification attack usually yields a 300 to 400 times magnification,  
which I do not think IRIS would do.

More reading from CERT:
http://www.cert.org/incident_notes/IN-2000-04.html
The problem, it would seem, in the DNS world is a recursive name  
server configured to answer for anybody.  I don't think this is  
applicable to IRIS.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Mon, 27 Feb 2006 09:58:31 -0500

On Feb 27, 2006, at 9:41 AM, Andrew Newton wrote:

> It seems BCP 78 is applicable to this.

Sorry.  BCP 38.
ftp://ftp.isi.edu/in-notes/rfc2827.txt

-andy

---

From: William Leibzon <[email-masked]>
Date: Mon, 27 Feb 2006 08:49:18 -0800 (PST)

On Mon, 27 Feb 2006, Andrew Newton wrote:

> That was gonna be my first question:  just how do they mitigate this with 
> DNS?  Or DHCP?  Or anything else that uses UDP?

They don't deal with it very well. But there are actually only few protocols
to which it is applicable since most protocols that use UDP would do it for
things like creating a data stream that is not subject to TCP retransmission.
In those cases real transmission does not begin until response is received
from originator - i.e. they simulate TCP in a way and do create a sort of
a session before larger amount of data is sent.

Where it is applicable is one-query request/response protocols which are
only few (most use TCP) such as DNS and DHCP. For DHCP the solution is 
simply that DHCP servers only  respond to requests from within local lan 
and not to whole world. For dns there is no good solution that everyone
likes - hence current set of discussions on how to deal with this issue
at operational mail lists.

> It seems BCP 78 is applicable to this.

You mean BCP 38 (RFC2827), right?

> Also, I was under the assumption that an amplification attack resulted in an 
> order of magnitude higher response.  In other words, if I send a 100 byte 
> packet, the amplification is in hundreds of times higher bytes and usually 
> across multiple packets.  Perhaps if we could get a pointer to the classic 
> attack scenario that would help.

Anything that is several times greater then what originator sent has an
amplification use potential. The highier the difference the more likely
it is that it would began tobe used for malicious reasons.

> There really are two types of attacks: reflection attacks and amplification 
> attacks.  As any interesting as reflection attacks are, they don't seem to be 
> that much more gain than a direct attack.  The amplification attack usually 
> yields a 300 to 400 times magnification, which I do not think IRIS would do.

Yes, 300 to 400 is too much and the reasons for abuse of dns right now is
exactly because it does offer potential for big amplication (not 300 to 
400 but with recursion, use of ANY and large txt records, it could get 
into 1:100 difference - which is more then good enough for attacker)

> The problem, it would seem, in the DNS world is a recursive name server 
> configured to answer for anybody.  I don't think this is applicable to IRIS.
>
> -andy
>

---

From: William Leibzon <[email-masked]>
Date: Mon, 27 Feb 2006 09:06:21 -0800 (PST)

On Mon, 27 Feb 2006, William Leibzon wrote:

> simply that DHCP servers only  respond to requests from within local 
> lan and not to whole world. For dns there is no good solution that 
> everyone likes - hence current set of discussions on how to deal with 
> this issue at operational mail lists.

Just so you know - in dns the recursion is being used as a way to cause 
responder to send back large data where it would normally not have done
it (this is kind-of poisoning) as there are only few sites that have 
large dns records and are good amplification potential as-is [this 
reminds me that I need to bring this issue up on DKIM since it is
going to introduce large dns records which as I said many times is
really not a good thing to have].

---
William Leibzon