[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Dean Anderson wrote:
> On Mon, 8 Sep 2008, Ron Bonica wrote:
>
>> Do you deny that the vulnerabilities described in this document *could*
>> be exploited? If this is your claim, and you can substantiate it, the WG
>> will entertain your objection.
>
> I'm asserting that whatever vulnerabilities that do exist can be
> mitigated in ordinary ways without closing open recursors, including by
> BCP38.
>
Dean,
I think that this is the main crux of your argument. If I read you
correctly, you are saying that the vulnerability does exist, but it can
be mitigated by the universal deployment of ingress filtering (BCP 38).
If this is the case, I believe that the document in question should be
published. While I respect the guidance provided in BCP 38, I am fully
aware that many ISPs have not deployed ingress filters and are not
likely to do so in the future. Therefore, we need to develop mitigations
that work in the real world, From dnsop-bounces at ietf.org Tue Sep 9 10:01:54 2008
Return-Path: <dnsop-bounces at ietf.org>
X-Original-To: dnsop-archive at optimus.ietf.org
Delivered-To: ietfarch-dnsop-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A086928C200;
Tue, 9 Sep 2008 10:01:54 -0700 (PDT)
X-Original-To: dnsop at core3.amsl.com
Delivered-To: dnsop at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9770428C1FD;
Tue, 9 Sep 2008 10:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.315
X-Spam-Level:
X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Iw6gPMExqB0P; Tue, 9 Sep 2008 10:01:51 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171])
by core3.amsl.com (Postfix) with ESMTP id 8B6D028C1F2;
Tue, 9 Sep 2008 10:01:40 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob109.postini.com
([64.18.6.12]) with SMTP; Tue, 09 Sep 2008 10:00:45 PDT
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net
with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 9 Sep 2008 10:00:16 -0700
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with
Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 10:00:16 -0700
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with
Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Sep 2008 13:00:14 -0400
Received: from [172.23.1.69] ([172.23.1.69] RDNS failed) by proton.jnpr.net
with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 9 Sep 2008 13:00:14 -0400
Message-ID: <48C6AB99.6060104 at juniper.net>
Date: Tue, 09 Sep 2008 13:00:09 -0400
From: Ron Bonica <rbonica at juniper.net>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Dean Anderson <dean at av8.com>
References: <Pine.LNX.4.44.0809090942230.795-100000 at citation2.av8.net>
In-Reply-To: <Pine.LNX.4.44.0809090942230.795-100000 at citation2.av8.net>
X-Enigmail-Version: 0.95.7
X-OriginalArrivalTime: 09 Sep 2008 17:00:14.0695 (UTC)
FILETIME=[875CEF70:01C9129D]
Cc: Peter Koch <pk at DENIC.DE>, "Contreras,
Jorge" <Jorge.Contreras at wilmerhale.com>,
IETF DNSOP WG <dnsop at ietf.org>, iesg at ietf.org
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
X-BeenThere: dnsop at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
<mailto:dnsop-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop at ietf.org>
List-Help: <mailto:dnsop-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
<mailto:dnsop-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces at ietf.org
Errors-To: dnsop-bounces at ietf.org
Dean Anderson wrote:
> On Mon, 8 Sep 2008, Ron Bonica wrote:
>
>> Do you deny that the vulnerabilities described in this document *could*
>> be exploited? If this is your claim, and you can substantiate it, the WG
>> will entertain your objection.
>
> I'm asserting that whatever vulnerabilities that do exist can be
> mitigated in ordinary ways without closing open recursors, including by
> BCP38.
>
Dean,
I think that this is the main crux of your argument. If I read you
correctly, you are saying that the vulnerability does exist, but it can
be mitigated by the universal deployment of ingress filtering (BCP 38).
If this is the case, I believe that the document in question should be
published. While I respect the guidance provided in BCP 38, I am fully
aware that many ISPs have not deployed ingress filters and are not
likely to do so in the future. Therefore, we need to develop mitigations
that work in the real world, where weFrom dnsop-bounces at ietf.org Tue Sep 9 10:01:54 2008
Return-Path: <dnsop-bounces at ietf.org>
X-Original-To: dnsop-archive at lists.ietf.org
Delivered-To: ietfarch-dnsop-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id A086928C200;
Tue, 9 Sep 2008 10:01:54 -0700 (PDT)
X-Original-To: dnsop at core3.amsl.com
Delivered-To: dnsop at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 9770428C1FD;
Tue, 9 Sep 2008 10:01:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.315
X-Spam-Level:
X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284,
BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Iw6gPMExqB0P; Tue, 9 Sep 2008 10:01:51 -0700 (PDT)
Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171])
by core3.amsl.com (Postfix) with ESMTP id 8B6D028C1F2;
Tue, 9 Sep 2008 10:01:40 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob109.postini.com
([64.18.6.12]) with SMTP; Tue, 09 Sep 2008 10:00:45 PDT
Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp02.jnpr.net
with Microsoft SMTPSVC(6.0.3790.3959);
Tue, 9 Sep 2008 10:00:16 -0700
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb01-sac.jnpr.net with
Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 10:00:16 -0700
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with
Microsoft SMTPSVC(5.0.2195.6713); Tue, 9 Sep 2008 13:00:14 -0400
Received: from [172.23.1.69] ([172.23.1.69] RDNS failed) by proton.jnpr.net
with Microsoft SMTPSVC(6.0.3790.1830);
Tue, 9 Sep 2008 13:00:14 -0400
Message-ID: <48C6AB99.6060104 at juniper.net>
Date: Tue, 09 Sep 2008 13:00:09 -0400
From: Ron Bonica <rbonica at juniper.net>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Dean Anderson <dean at av8.com>
References: <Pine.LNX.4.44.0809090942230.795-100000 at citation2.av8.net>
In-Reply-To: <Pine.LNX.4.44.0809090942230.795-100000 at citation2.av8.net>
X-Enigmail-Version: 0.95.7
X-OriginalArrivalTime: 09 Sep 2008 17:00:14.0695 (UTC)
FILETIME=[875CEF70:01C9129D]
Cc: Peter Koch <pk at DENIC.DE>, "Contreras,
Jorge" <Jorge.Contreras at wilmerhale.com>,
IETF DNSOP WG <dnsop at ietf.org>, iesg at ietf.org
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
X-BeenThere: dnsop at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
<mailto:dnsop-request at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/dnsop>
List-Post: <mailto:dnsop at ietf.org>
List-Help: <mailto:dnsop-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>,
<mailto:dnsop-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsop-bounces at ietf.org
Errors-To: dnsop-bounces at ietf.org
Dean Anderson wrote:
> On Mon, 8 Sep 2008, Ron Bonica wrote:
>
>> Do you deny that the vulnerabilities described in this document *could*
>> be exploited? If this is your claim, and you can substantiate it, the WG
>> will entertain your objection.
>
> I'm asserting that whatever vulnerabilities that do exist can be
> mitigated in ordinary ways without closing open recursors, including by
> BCP38.
>
Dean,
I think that this is the main crux of your argument. If I read you
correctly, you are saying that the vulnerability does exist, but it can
be mitigated by the universal deployment of ingress filtering (BCP 38).
If this is the case, I believe that the document in question should be
published. While I respect the guidance provided in BCP 38, I am fully
aware that many ISPs have not deployed ingress filters and are not
likely to do so in the future. Therefore, we need to develop mitigations
that work in the real world, where we cannot rely on the universal
deployment of BCP 38.
>> However, if you are arguing any or all of the following, the WG will not
>> entertain your objection:
>>
>> - that there have only been two attacks
>> - that these attacks were contrived
>> - that the organization reporting these attacks is not credible
>> - that the organization reporting these attacks has not satisfied your
>> requests for evidence
>> - that there are easier ways to attack DNS
>>
>> This is because vulnerabilities need to be mitigated, regardless of
>> whether they have been exploited.
>
> All protocols have theoretical vulnerabilities. Your assertion that
> "vulnerabilities need to be mitigated, regardless of whether they have
> been exploited" is without basis. ICMP PING can be exploited, and is not
> especially mitigated by the IETF. Whatever vulnerabilities posed by
> open recursors can be mitigated in other, cheaper ways, without closing
> open recursors. This document, (and the specific action it states:
> closing open recursors) is not necessary to mitigate open recursor
> abuse. Open recursors have legitimate users and legitimate uses,
> especially in light of recent cache poisoning attacks. One does not want
> to trust someone else's recursor. Closing open recursors has an
> significant expense in security and cost of new servers, and should be
> well-justified.
If you believed that there were better mitigations, you should have
written a competing draft years ago when the issue was under
consideration. At this point, it is a little late in the process to jump
up and say "I have a better idea!".
If you think that you have an alternative plan for mitigating this
attack, you might be able to resurrect open resolvers with a new draft
that describes this mitigation.
<The conversation goes downhill from here...>
>
> Your assertion that false statements, contrived attacks, discredited
> sources, and lack of evidence of harm, are somehow not legitimate
> reasons to dispute a document is also without basis, and indeed is
> refuted by IESG actions in TLS-AUTHZ.
I stand by my previous statement. This is a technical argument and not
an argument about the moral status of any group or individual.
>
> The fabrications made for this document amount to fraud on the public.
Be careful about this kind of statement. In any interesting technical
discussion, we all run the risk of being wrong. I'm wrong sometimes and
I am sure that you are wrong sometimes, too.
When you make this kind of statement and you end up being wrong, you
have committed a grave offense!
>
> It appears that proponents of this document are _encouraging_
> exploitation of open recursors in the Rapid Enumeration Tool. (see
> www.dnssec.net/software) The 'recursors-are-evil' document is just a
> fraudulent scheme to sell DNSSEC software.
You can't have it both ways. On one hand, you are saying that the
vulnerability isn't significant because it is easily mitigated and on
the other hand you are complaining about those bad guys who aren't
keeping it low enough profile. If it's so easy to mitigate, why do you
care whether knowledge of the vulnerability goes public?
Ron
>
>
> Rapid Enumeration Tool (RET) by Nominet UK
>
> --------------------------------------------------------------------------------
> The Rapid Enumeration Tool (RET) is designed to use DNSSEC NSEC records
> to enumerate quickly zone data whilst evading detection by systems which
> might be designed specifically to identify zone enumeration activity. It
> does this by using one or more open recursive resolvers to forward
> queries to the authoritative name servers for the zone. Each resolver is
> configured with its own 'personality', specifying query rates, query
> failure/success ratio, proportions of query types, query name
> decoration, etc. This allows the RET to feed queries to each resolver,
> that are specifically tailored to match the queries that a resolver
> might typically send to the authoritative name server. Unlike other NSEC
> resource recwhere we cannot rely on the universal
deployment of BCP 38.
>> However, if you are arguing any or all of the following, the WG will not
>> entertain your objection:
>>
>> - that there have only been two attacks
>> - that these attacks were contrived
>> - that the organization reporting these attacks is not credible
>> - that the organization reporting these attacks has not satisfied your
>> requests for evidence
>> - that there are easier ways to attack DNS
>>
>> This is because vulnerabilities need to be mitigated, regardless of
>> whether they have been exploited.
>
> All protocols have theoretical vulnerabilities. Your assertion that
> "vulnerabilities need to be mitigated, regardless of whether they have
> been exploited" is without basis. ICMP PING can be exploited, and is not
> especially mitigated by the IETF. Whatever vulnerabilities posed by
> open recursors can be mitigated in other, cheaper ways, without closing
> open recursors. This document, (and the specific action it states:
> closing open recursors) is not necessary to mitigate open recursor
> abuse. Open recursors have legitimate users and legitimate uses,
> especially in light of recent cache poisoning attacks. One does not want
> to trust someone else's recursor. Closing open recursors has an
> significant expense in security and cost of new servers, and should be
> well-justified.
If you believed that there were better mitigations, you should have
written a competing draft years ago when the issue was under
consideration. At this point, it is a little late in the process to jump
up and say "I have a better idea!".
If you think that you have an alternative plan for mitigating this
attack, you might be able to resurrect open resolvers with a new draft
that describes this mitigation.
<The conversation goes downhill from here...>
>
> Your assertion that false statements, contrived attacks, discredited
> sources, and lack of evidence of harm, are somehow not legitimate
> reasons to dispute a document is also without basis, and indeed is
> refuted by IESG actions in TLS-AUTHZ.
I stand by my previous statement. This is a technical argument and not
an argument about the moral status of any group or individual.
>
> The fabrications made for this document amount to fraud on the public.
Be careful about this kind of statement. In any interesting technical
discussion, we all run the risk of being wrong. I'm wrong sometimes and
I am sure that you are wrong sometimes, too.
When you make this kind of statement and you end up being wrong, you
have committed a grave offense!
>
> It appears that proponents of this document are _encouraging_
> exploitation of open recursors in the Rapid Enumeration Tool. (see
> www.dnssec.net/software) The 'recursors-are-evil' document is just a
> fraudulent scheme to sell DNSSEC software.
You can't have it both ways. On one hand, you are saying that the
vulnerability isn't significant because it is easily mitigated and on
the other hand you are complaining about those bad guys who aren't
keeping it low enough profile. If it's so easy to mitigate, why do you
care whether knowledge of the vulnerability goes public?
Ron
>
>
> Rapid Enumeration Tool (RET) by Nominet UK
>
> --------------------------------------------------------------------------------
> The Rapid Enumeration Tool (RET) is designed to use DNSSEC NSEC records
> to enumerate quickly zone data whilst evading detection by systems which
> might be designed specifically to identify zone enumeration activity. It
> does this by using one or more open recursive resolvers to forward
> queries to the authoritative name servers for the zone. Each resolver is
> configured with its own 'personality', specifying query rates, query
> failure/success ratio, proportions of query types, query name
> decoration, etc. This allows the RET to feed queries to each resolver,
> that are specifically tailored to match the queries that a resolver
> might typically send to the authoritative name server. Unlike other NSEC
> resource record 'walkers', the RET does not explicitly query for NSEC
> RRs to walk the zone. Instead, it combines a 'walker' approach with a
> dictionary attack (combined with a random name generator for more
> awkward cases). This means that discernible artifacts in the pattern of
> queries that arrive at the authoritative servers should be minimised.
>
> --
> Av8 Internet Prepared to pay a premium for better
> service? www.av8.net faster, more reliable, better service
> 617 344 9000
>
>
>
>
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
cannot rely on the universal
deployment of BCP 38.
>> However, if you are arguing any or all of the following, the WG will not
>> entertain your objection:
>>
>> - that there have only been two attacks
>> - that these attacks were contrived
>> - that the organization reporting these attacks is not credible
>> - that the organization reporting these attacks has not satisfied your
>> requests for evidence
>> - that there are easier ways to attack DNS
>>
>> This is because vulnerabilities need to be mitigated, regardless of
>> whether they have been exploited.
>
> All protocols have theoretical vulnerabilities. Your assertion that
> "vulnerabilities need to be mitigated, regardless of whether they have
> been exploited" is without basis. ICMP PING can be exploited, and is not
> especially mitigated by the IETF. Whatever vulnerabilities posed by
> open recursors can be mitigated in other, cheaper ways, without closing
> open recursors. This document, (and the specific action it states:
> closing open recursors) is not necessary to mitigate open recursor
> abuse. Open recursors have legitimate users and legitimate uses,
> especially in light of recent cache poisoning attacks. One does not want
> to trust someone else's recursor. Closing open recursors has an
> significant expense in security and cost of new servers, and should be
> well-justified.
If you believed that there were better mitigations, you should have
written a competing draft years ago when the issue was under
consideration. At this point, it is a little late in the process to jump
up and say "I have a better idea!".
If you think that you have an alternative plan for mitigating this
attack, you might be able to resurrect open resolvers with a new draft
that describes this mitigation.
<The conversation goes downhill from here...>
>
> Your assertion that false statements, contrived attacks, discredited
> sources, and lack of evidence of harm, are somehow not legitimate
> reasons to dispute a document is also without basis, and indeed is
> refuted by IESG actions in TLS-AUTHZ.
I stand by my previous statement. This is a technical argument and not
an argument about the moral status of any group or individual.
>
> The fabrications made for this document amount to fraud on the public.
Be careful about this kind of statement. In any interesting technical
discussion, we all run the risk of being wrong. I'm wrong sometimes and
I am sure that you are wrong sometimes, too.
When you make this kind of statement and you end up being wrong, you
have committed a grave offense!
>
> It appears that proponents of this document are _encouraging_
> exploitation of open recursors in the Rapid Enumeration Tool. (see
> www.dnssec.net/software) The 'recursors-are-evil' document is just a
> fraudulent scheme to sell DNSSEC software.
You can't have it both ways. On one hand, you are saying that the
vulnerability isn't significant because it is easily mitigated and on
the other hand you are complaining about those bad guys who aren't
keeping it low enough profile. If it's so easy to mitigate, why do you
care whether knowledge of the vulnerability goes public?
Ron
>
>
> Rapid Enumeration Tool (RET) by Nominet UK
>
> --------------------------------------------------------------------------------
> The Rapid Enumeration Tool (RET) is designed to use DNSSEC NSEC records
> to enumerate quickly zone data whilst evading detection by systems which
> might be designed specifically to identify zone enumeration activity. It
> does this by using one or more open recursive resolvers to forward
> queries to the authoritative name servers for the zone. Each resolver is
> configured with its own 'personality', specifying query rates, query
> failure/success ratio, proportions of query types, query name
> decoration, etc. This allows the RET to feed queries to each resolver,
> that are specifically tailored to match the queries that a resolver
> might typically send to the authoritative name server. Unlike other NSEC
> resource record 'walkers', the RET does not explicitly query for NSEC
> RRs to walk the zone. Instead, it combines a 'walker' approach with a
> dictionary attack (combined with a random name generator for more
> awkward cases). This means that discernible artifacts in the pattern of
> queries that arrive at the authoritative servers should be minimised.
>
> --
> Av8 Internet Prepared to pay a premium for better
> service? www.av8.net faster, more reliable, better service
> 617 344 9000
>
>
>
>
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
ord 'walkers', the RET does not explicitly query for NSEC
> RRs to walk the zone. Instead, it combines a 'walker' approach with a
> dictionary attack (combined with a random name generator for more
> awkward cases). This means that discernible artifacts in the pattern of
> queries that arrive at the authoritative servers should be minimised.
>
> --
> Av8 Internet Prepared to pay a premium for better
> service? www.av8.net faster, more reliable, better service
> 617 344 9000
>
>
>
>
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www.ietf.org/mailman/listinfo/dnsop