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
- [Crisp] IRIS-LWZ and security issues due to spoof… William Leibzon
- Re: [Crisp] IRIS-LWZ and security issues due to s… William Leibzon
- Re: [Crisp] IRIS-LWZ and security issues due to s… Shane Kerr
- Re: [Crisp] IRIS-LWZ and security issues due to s… Andrew Newton
- Re: [Crisp] IRIS-LWZ and security issues due to s… Andrew Newton
- Re: [Crisp] IRIS-LWZ and security issues due to s… William Leibzon
- Re: [Crisp] IRIS-LWZ and security issues due to s… William Leibzon