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 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@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
