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

William Leibzon <william@completewhois.com> Mon, 27 February 2006 15:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjrs-0006p2-Mp; Mon, 27 Feb 2006 10:00:56 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjrq-0006ol-9Z for crisp@ietf.org; Mon, 27 Feb 2006 10:00:55 -0500
Received: from [216.151.193.226] (helo=cwhois1.completewhois.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjrn-0005Lz-RN for crisp@ietf.org; Mon, 27 Feb 2006 10:00:54 -0500
Received: from cwhois1.completewhois.com (localhost.localdomain [127.0.0.1]) by cwhois1.completewhois.com (8.13.4/8.13.4) with ESMTP id k1RGnIhV000917; Mon, 27 Feb 2006 08:49:18 -0800
Received: from localhost (william@localhost) by cwhois1.completewhois.com (8.13.4/8.13.4/Submit) with ESMTP id k1RGnIsa000913; Mon, 27 Feb 2006 08:49:18 -0800
X-Authentication-Warning: cwhois1.completewhois.com: william owned process doing -bs
Date: Mon, 27 Feb 2006 08:49:18 -0800
From: William Leibzon <william@completewhois.com>
To: Andrew Newton <andy@hxr.us>
Subject: Re: [Crisp] IRIS-LWZ and security issues due to spoofed sources
In-Reply-To: <40753247-0679-43EA-AF0D-2C5A35F5144A@hxr.us>
Message-ID: <Pine.LNX.4.64.0602270837050.9385@cwhois1.completewhois.com>
References: <Pine.LNX.4.64.0602270503580.9385@cwhois1.completewhois.com> <Pine.LNX.4.64.0602270532250.9385@cwhois1.completewhois.com> <4402F9BA.6050903@ripe.net> <40753247-0679-43EA-AF0D-2C5A35F5144A@hxr.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: Shane Kerr <shane@ripe.net>, CRISP WG <crisp@ietf.org>
X-BeenThere: crisp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Cross Registry Information Service Protocol <crisp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:crisp@ietf.org>
List-Help: <mailto:crisp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/crisp>, <mailto:crisp-request@ietf.org?subject=subscribe>
Errors-To: crisp-bounces@ietf.org

On Mon, 27 Feb 2006, Andrew Newton wrote:

>
> On Feb 27, 2006, at 8:08 AM, Shane Kerr wrote:
>
>> Since this is a general UDP problem, perhaps it makes sense to point to
>> 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?

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.

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

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)

> 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
>
> _______________________________________________
> Crisp mailing list
> Crisp@ietf.org
> https://www1.ietf.org/mailman/listinfo/crisp

_______________________________________________
Crisp mailing list
Crisp@ietf.org
https://www1.ietf.org/mailman/listinfo/crisp