Folks,
Someone on DNSOPS points out that I am calendar challenged. September 5
has already past. I meant to say Friday, September 12.
Ron
Ron Bonica wrote:
> 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 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, [EMAIL PROTECTED] 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
>>> 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@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
