[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,
On the surface, I deem your objection to be without merit. Unless you
can convince me otherwise, I will send
draft-ietf-dnsop-reflectors-are-evil to the RFC editor for publication
on Friday, September 5. See below for point by point responses.
Dean Anderson wrote:
> Anytime you discover that the facts asserted and relied on for a
> document are false, or the sources of those facts and assurances
> discredited, that's a "new" fact. A good example was the discovery in
> TLS-AUTHZ that the assurances made by the document authors that patents
> were disclosed according to RFC3979 was false. In the TLS-AUTHZ case,
> the discovery of false facts justified the removal of IESG approval.
>
> In this case, it was asserted that there was a serious problem with open
> recursors being used in attacks. That asserted fact was the motivation
> for this document. However, in the time since the first two attacks, we
> have seen no evidence of any further attacks, and the two small
> motivating attacks now seem in retrospect to be contrived for this
> document. The motivating attacks were first reported on NANOG, which
> has previously From dnsop-bounces at ietf.org Mon Sep 8 19:24:34 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 B231C3A6963;
Mon, 8 Sep 2008 19:24:34 -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 65DE63A6963;
Mon, 8 Sep 2008 19:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.238
X-Spam-Level:
X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361,
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 mDPrmOLSjCGA; Mon, 8 Sep 2008 19:24:33 -0700 (PDT)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161])
by core3.amsl.com (Postfix) with ESMTP id BE4BF3A67FE;
Mon, 8 Sep 2008 19:24:29 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob104.postini.com
([64.18.6.12]) with SMTP; Mon, 08 Sep 2008 19:24:08 PDT
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with
Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Sep 2008 19:24:23 -0700
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with
Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Sep 2008 22:24:21 -0400
Received: from [172.23.1.69] ([172.23.1.69] RDNS failed) by proton.jnpr.net
with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 8 Sep 2008 22:24:21 -0400
Message-ID: <48C5DE50.1080804 at juniper.net>
Date: Mon, 08 Sep 2008 22:24:16 -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.0809080951230.498-100000 at citation2.av8.net>
In-Reply-To: <Pine.LNX.4.44.0809080951230.498-100000 at citation2.av8.net>
X-Enigmail-Version: 0.95.7
X-OriginalArrivalTime: 09 Sep 2008 02:24:21.0282 (UTC)
FILETIME=[2B168020:01C91223]
Cc: Peter Koch <pk at DENIC.DE>, 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,
On the surface, I deem your objection to be without merit. Unless you
can convince me otherwise, I will send
draft-ietf-dnsop-reflectors-are-evil to the RFC editor for publication
on Friday, September 5. See below for point by point responses.
Dean Anderson wrote:
> Anytime you discover that the facts asserted and relied on for a
> document are false, or the sources of those facts and assurances
> discredited, that's a "new" fact. A good example was the discovery in
> TLS-AUTHZ that the assurances made by the document authors that patents
> were disclosed according to RFC3979 was false. In the TLS-AUTHZ case,
> the discovery of false facts justified the removal of IESG approval.
>
> In this case, it was asserted that there was a serious problem with open
> recursors being used in attacks. That asserted fact was the motivation
> for this document. However, in the time since the first two attacks, we
> have seen no evidence of any further attacks, and the two small
> motivating attacks now seem in retrospect to be contrived for this
> document. The motivating attacks were first reported on NANOG, which
> has previously made falFrom dnsop-bounces at ietf.org Mon Sep 8 19:24:34 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 B231C3A6963;
Mon, 8 Sep 2008 19:24:34 -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 65DE63A6963;
Mon, 8 Sep 2008 19:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.238
X-Spam-Level:
X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361,
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 mDPrmOLSjCGA; Mon, 8 Sep 2008 19:24:33 -0700 (PDT)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161])
by core3.amsl.com (Postfix) with ESMTP id BE4BF3A67FE;
Mon, 8 Sep 2008 19:24:29 -0700 (PDT)
Received: from source ([66.129.228.6]) by exprod7ob104.postini.com
([64.18.6.12]) with SMTP; Mon, 08 Sep 2008 19:24:08 PDT
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with
Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Sep 2008 19:24:23 -0700
Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with
Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Sep 2008 22:24:21 -0400
Received: from [172.23.1.69] ([172.23.1.69] RDNS failed) by proton.jnpr.net
with Microsoft SMTPSVC(6.0.3790.1830);
Mon, 8 Sep 2008 22:24:21 -0400
Message-ID: <48C5DE50.1080804 at juniper.net>
Date: Mon, 08 Sep 2008 22:24:16 -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.0809080951230.498-100000 at citation2.av8.net>
In-Reply-To: <Pine.LNX.4.44.0809080951230.498-100000 at citation2.av8.net>
X-Enigmail-Version: 0.95.7
X-OriginalArrivalTime: 09 Sep 2008 02:24:21.0282 (UTC)
FILETIME=[2B168020:01C91223]
Cc: Peter Koch <pk at DENIC.DE>, 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,
On the surface, I deem your objection to be without merit. Unless you
can convince me otherwise, I will send
draft-ietf-dnsop-reflectors-are-evil to the RFC editor for publication
on Friday, September 5. See below for point by point responses.
Dean Anderson wrote:
> Anytime you discover that the facts asserted and relied on for a
> document are false, or the sources of those facts and assurances
> discredited, that's a "new" fact. A good example was the discovery in
> TLS-AUTHZ that the assurances made by the document authors that patents
> were disclosed according to RFC3979 was false. In the TLS-AUTHZ case,
> the discovery of false facts justified the removal of IESG approval.
>
> In this case, it was asserted that there was a serious problem with open
> recursors being used in attacks. That asserted fact was the motivation
> for this document. However, in the time since the first two attacks, we
> have seen no evidence of any further attacks, and the two small
> motivating attacks now seem in retrospect to be contrived for this
> document. The motivating attacks were first reported on NANOG, which
> has previously made falsemade false statements deceiving the public and network
> operators, and is therefore not a reliable source. See
> http://www.iadl.org/nanog/nanog-story.html Requests for substantiation
> and evidence of the claims of serious attacks have not been
> affirmatively answered in two years. No direct or indirect evidence for
> further, serious attacks has been produced at all.
>
> Analysis also shows an alternative DNS attack that requires less effort
> from the attacker, does not expose the attacker to discovery, and is
> much harder to mitigate and more damaging. There is no reason anyone
> considering using DNS as an attack vector would use open recursors.
> Analysis also shows that an attack using open recurors is easy to
> mitigate.
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.
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.
>
> The above are significant contrary facts that undermine the original
> consensus (if there even was one, next)
>
> On the point of consensus, I do not see that a WGLC succeeded for this
> document. A last call held in November 2006 resulted in most people
> being against this document. The last message with "WGLC" and "evil" in
> the subject line was on November 21, 2006, extending date of the WGLC.
> After the extension, there are several new versions, but no WG last
> call. I'm not entirely sure why this document is in the state 'IESG
> Evaluation' or how it got to state "Publication Requested" by Ron Bonica
> given the Working Group record and the objections raised. According to
> Section 7.5 of RFC2418, a rough consensus must exist before such a
> request for publication is made by the WG chair(s) to the Area
> director. It should also be noted that strong disapproval was voice in
> the 2006 WGLC. The strong disapproval was based, in part, on the lack of
> credible evidence supporting the need for this document. Two years
> later, lack of evidence of real attacks is still a problem. There is no
> widespread ISP support for, or call for, this document.
Please see the minutes from IETF 67. It appears that most comments were
accepted and addressed in subsequent versions of the draft. The WG chair
appropriately determined that another WG last call was not required.
Ron
>
> I strongly disapprove this document, object to the submarined approval
> process, and will appeal this document to the limit of the appeals
> process.
>
> --Dean
>
> On Sat, 6 Sep 2008, Peter Koch wrote:
>
>> On Mon, Sep 01, 2008 at 10:45:02AM -0700, Internet-Drafts at ietf.org wrote:
>>
>>> Title : Preventing Use of Recursive Nameservers in Reflector Attacks
>>> Author(s) : J. Damas, F. Neves
>>> Filename : draft-ietf-dnsop-reflectors-are-evil-06.txt
>>> Pages : 8
>>> Date : 2008-09-01
>> this draft is in the "IESG Evaluation" state.
>> The purpose of this update was to address the issues raised in the last remaining
>> DISCUSS during IESG review (as mentioned during the DNSOP session in Dublin).
>> You can visit the changes (non-editorial only affecting the security
>> considerations section) through the tools site:
>> <http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reflectors-are-evil/>
>> Editors, AD and shepherd (me) judged these changes to be minor enough and
>> non controversial not to require another WG round.
>> The draft will be approved as soon as the DISCUSS will have been released.
>>
>> To clarify, there's nothing that would suggest against the chairs' judgse statements deceiving the public and network
> operators, and is therefore not a reliable source. See
> http://www.iadl.org/nanog/nanog-story.html Requests for substantiation
> and evidence of the claims of serious attacks have not been
> affirmatively answered in two years. No direct or indirect evidence for
> further, serious attacks has been produced at all.
>
> Analysis also shows an alternative DNS attack that requires less effort
> from the attacker, does not expose the attacker to discovery, and is
> much harder to mitigate and more damaging. There is no reason anyone
> considering using DNS as an attack vector would use open recursors.
> Analysis also shows that an attack using open recurors is easy to
> mitigate.
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.
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.
>
> The above are significant contrary facts that undermine the original
> consensus (if there even was one, next)
>
> On the point of consensus, I do not see that a WGLC succeeded for this
> document. A last call held in November 2006 resulted in most people
> being against this document. The last message with "WGLC" and "evil" in
> the subject line was on November 21, 2006, extending date of the WGLC.
> After the extension, there are several new versions, but no WG last
> call. I'm not entirely sure why this document is in the state 'IESG
> Evaluation' or how it got to state "Publication Requested" by Ron Bonica
> given the Working Group record and the objections raised. According to
> Section 7.5 of RFC2418, a rough consensus must exist before such a
> request for publication is made by the WG chair(s) to the Area
> director. It should also be noted that strong disapproval was voice in
> the 2006 WGLC. The strong disapproval was based, in part, on the lack of
> credible evidence supporting the need for this document. Two years
> later, lack of evidence of real attacks is still a problem. There is no
> widespread ISP support for, or call for, this document.
Please see the minutes from IETF 67. It appears that most comments were
accepted and addressed in subsequent versions of the draft. The WG chair
appropriately determined that another WG last call was not required.
Ron
>
> I strongly disapprove this document, object to the submarined approval
> process, and will appeal this document to the limit of the appeals
> process.
>
> --Dean
>
> On Sat, 6 Sep 2008, Peter Koch wrote:
>
>> On Mon, Sep 01, 2008 at 10:45:02AM -0700, Internet-Drafts at ietf.org wrote:
>>
>>> Title : Preventing Use of Recursive Nameservers in Reflector Attacks
>>> Author(s) : J. Damas, F. Neves
>>> Filename : draft-ietf-dnsop-reflectors-are-evil-06.txt
>>> Pages : 8
>>> Date : 2008-09-01
>> this draft is in the "IESG Evaluation" state.
>> The purpose of this update was to address the issues raised in the last remaining
>> DISCUSS during IESG review (as mentioned during the DNSOP session in Dublin).
>> You can visit the changes (non-editorial only affecting the security
>> considerations section) through the tools site:
>> <http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reflectors-are-evil/>
>> Editors, AD and shepherd (me) judged these changes to be minor enough and
>> non controversial not to require another WG round.
>> The draft will be approved as soon as the DISCUSS will have been released.
>>
>> To clarify, there's nothing that would suggest against the chairs' judgement
>> statements deceiving the public and network
> operators, and is therefore not a reliable source. See
> http://www.iadl.org/nanog/nanog-story.html Requests for substantiation
> and evidence of the claims of serious attacks have not been
> affirmatively answered in two years. No direct or indirect evidence for
> further, serious attacks has been produced at all.
>
> Analysis also shows an alternative DNS attack that requires less effort
> from the attacker, does not expose the attacker to discovery, and is
> much harder to mitigate and more damaging. There is no reason anyone
> considering using DNS as an attack vector would use open recursors.
> Analysis also shows that an attack using open recurors is easy to
> mitigate.
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.
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.
>
> The above are significant contrary facts that undermine the original
> consensus (if there even was one, next)
>
> On the point of consensus, I do not see that a WGLC succeeded for this
> document. A last call held in November 2006 resulted in most people
> being against this document. The last message with "WGLC" and "evil" in
> the subject line was on November 21, 2006, extending date of the WGLC.
> After the extension, there are several new versions, but no WG last
> call. I'm not entirely sure why this document is in the state 'IESG
> Evaluation' or how it got to state "Publication Requested" by Ron Bonica
> given the Working Group record and the objections raised. According to
> Section 7.5 of RFC2418, a rough consensus must exist before such a
> request for publication is made by the WG chair(s) to the Area
> director. It should also be noted that strong disapproval was voice in
> the 2006 WGLC. The strong disapproval was based, in part, on the lack of
> credible evidence supporting the need for this document. Two years
> later, lack of evidence of real attacks is still a problem. There is no
> widespread ISP support for, or call for, this document.
Please see the minutes from IETF 67. It appears that most comments were
accepted and addressed in subsequent versions of the draft. The WG chair
appropriately determined that another WG last call was not required.
Ron
>
> I strongly disapprove this document, object to the submarined approval
> process, and will appeal this document to the limit of the appeals
> process.
>
> --Dean
>
> On Sat, 6 Sep 2008, Peter Koch wrote:
>
>> On Mon, Sep 01, 2008 at 10:45:02AM -0700, Internet-Drafts at ietf.org wrote:
>>
>>> Title : Preventing Use of Recursive Nameservers in Reflector Attacks
>>> Author(s) : J. Damas, F. Neves
>>> Filename : draft-ietf-dnsop-reflectors-are-evil-06.txt
>>> Pages : 8
>>> Date : 2008-09-01
>> this draft is in the "IESG Evaluation" state.
>> The purpose of this update was to address the issues raised in the last remaining
>> DISCUSS during IESG review (as mentioned during the DNSOP session in Dublin).
>> You can visit the changes (non-editorial only affecting the security
>> considerations section) through the tools site:
>> <http://tools.ietf.org/wg/dnsop/draft-ietf-dnsop-reflectors-are-evil/>
>> Editors, AD and shepherd (me) judged these changes to be minor enough and
>> non controversial not to require another WG round.
>> The draft will be approved as soon as the DISCUSS will have been released.
>>
>> To clarify, there's nothing that would suggest against the chairs' judgement
>> oement
>> of WG consensus being maintained. That said, any further discussion of
>> whether or not the draft should have been worked on is probably counterproductive
>> and consuming energy better spent on other current topics.
>> As any document, this document can be revisited at a later stage with time
>> passed and new facts on the table.
>> I'd not consider the perceived absence of facts establishing a "new fact".
>>
>> -Peter [wearing a chair's hat]
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP at ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
of WG consensus being maintained. That said, any further discussion of
>> whether or not the draft should have been worked on is probably counterproductive
>> and consuming energy better spent on other current topics.
>> As any document, this document can be revisited at a later stage with time
>> passed and new facts on the table.
>> I'd not consider the perceived absence of facts establishing a "new fact".
>>
>> -Peter [wearing a chair's hat]
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP at ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
f WG consensus being maintained. That said, any further discussion of
>> whether or not the draft should have been worked on is probably counterproductive
>> and consuming energy better spent on other current topics.
>> As any document, this document can be revisited at a later stage with time
>> passed and new facts on the table.
>> I'd not consider the perceived absence of facts establishing a "new fact".
>>
>> -Peter [wearing a chair's hat]
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP at ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>
_______________________________________________
DNSOP mailing list
DNSOP at ietf.org
https://www.ietf.org/mailman/listinfo/dnsop