Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
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. 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. 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. The fabrications made for this document amount to fraud on the public. 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. 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
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
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
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, 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
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Bill, That why in the next paragraph I said: 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. Also, if Dean feels that the alternative mitigation is so compelling that he could muster WG consensus around it, he has until this Friday to describe the mitigation on the mailing list. Ron [EMAIL PROTECTED] wrote: On Tue, Sep 09, 2008 at 01:00:09PM -0400, Ron Bonica wrote: 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!. Ron, This is not the first time I've heard that arguement and it -always- strikes me as being dismissive and ignoring potential contribution. To develop and grow, one must encourage new ideas and rethinking old ones because the underlaying assumptions might have changed. I'm persuaded that its never too late to jump up and say 'I (think) I have a better idea!' --bill ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
On Tue, 9 Sep 2008, Ron Bonica wrote: 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. We agree! Well, probably not: I haven't made any argument based on the moral status of any individual. The existance of false statements, contrived attacks, discredited sources, and lack of evidence of harm, are technical issues concerning the actual state of the world. They are not moral issues; I offer no moral judgements. 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! I've studied the law on the subject of defamation in detail. Truth is an absolute defense. 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? Actually, its you who are trying to have it both ways. Proponents claim that the attack is a real threat, but in fact, they are encouraging people to conduct the attack. Lawyers call that solicitation. The attacks using open recursors are contrived, SOLICITED, by the people advocating the closure of open recursors, and SELLING DNSSEC software. My position is consistent: Even though proponents are soliciting the attacks, the attacks are still easily mitigated, and in fact do not represent a real threat that requires special handling. --Dean -- 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
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
[cc's cleaned up] Hi, At his point, I will sit quietly for a while and let the WG comment on whether they think that your proposed alternative mitigation is adequate. On Friday, the WG chairs will gauge consensus and I will take appropriate action. Given the stunningly successful implementation of BCP038 over the 8 years since it has been published, I believe relying on it as a mitigation strategy against open resolver attacks is simply silly and discussing it largely a waste of time. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
In message [EMAIL PROTECTED], David Conrad writes: [cc's cleaned up] Hi, At his point, I will sit quietly for a while and let the WG comment on whether they think that your proposed alternative mitigation is adequate. On Friday, the WG chairs will gauge consensus and I will take appropriate action. Given the stunningly successful implementation of BCP038 over the 8 years since it has been published, I believe relying on it as a mitigation strategy against open resolver attacks is simply silly and discussing it largely a waste of time. While I encourage everyone to deploy BCP 38, wherever possible, I don't believe we should be relying on BCP 38 deployment to prevent recursive servers being abused. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
On Wed, 10 Sep 2008, Mark Andrews wrote: In message [EMAIL PROTECTED], David Conrad writes: At his point, I will sit quietly for a while and let the WG comment on whether they think that your proposed alternative mitigation is adequate. On Friday, the WG chairs will gauge consensus and I will take appropriate action. Given the stunningly successful implementation of BCP038 over the 8 years since it has been published, I believe relying on it as a mitigation strategy against open resolver attacks is simply silly and discussing it largely a waste of time. While I encourage everyone to deploy BCP 38, wherever possible, I don't believe we should be relying on BCP 38 deployment to prevent recursive servers being abused. BCP 38 is one tool in the mitigation box, but it doesn't mean that it can only be the *only* tool available. So I agree with Mark. wfms ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
William F. Maton Sotomayor wrote: On Wed, 10 Sep 2008, Mark Andrews wrote: In message [EMAIL PROTECTED], David Conrad writes: At his point, I will sit quietly for a while and let the WG comment on whether they think that your proposed alternative mitigation is adequate. On Friday, the WG chairs will gauge consensus and I will take appropriate action. Given the stunningly successful implementation of BCP038 over the 8 years since it has been published, I believe relying on it as a mitigation strategy against open resolver attacks is simply silly and discussing it largely a waste of time. While I encourage everyone to deploy BCP 38, wherever possible, I don't believe we should be relying on BCP 38 deployment to prevent recursive servers being abused. BCP 38 is one tool in the mitigation box, but it doesn't mean that it can only be the *only* tool available. So I agree with Mark. First layer of defense: BCP 38 Second layer of defense (because there are those who cannot or will not implement the first layer): Restrict recursive service by default Third layer of defense (because there are those who cannot or will not implement the first or second layers): Reactively filter abusive recursors (as Dean suggested). - Kevin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
