Ron,
On Wed, Sep 10, 2008 you wrote:
> The questions before the WG are:
>
> - is BCP38 enough to mitigate the attack vectors described in
> draft-ietf-dnsop-reflectors-are-evil-06
> - is filtering after the attack has begun good enough
>
> If the answer to both of these questions is "no", the doc
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Date: Fri, Sep 12, 2008 at 02:08:37PM -0400 Quoting Dean Anderson ([EMAIL
PROTECTED]):
> > Were it universally deployed, yes. Will it be? No. Thus, no.
>
> What do you want to spend your time doing: Getti
On Thu, 11 Sep 2008, Mans Nilsson wrote:
> Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
> Date: Thu, Sep 11, 2008 at 03:39:09PM -0400 Quoting Ron Bonica ([EMAIL
> PROTECTED]):
> > Folks,
> >
> > This is a reminder that only two questi
On Fri, 12 Sep 2008, Kurt Erik Lindqvist wrote:
> > I don't dispute there have been open recursor attacks. However the
> > attacks appear to be contrived and solicited, lacking in number,
> > lacking in intensity, and lacking in actual damage.
>
> People working in the field seems to think otherw
On Fri, 12 Sep 2008, Roy Arends wrote:
> On Sep 10, 2008, at 9:17 PM, Ron Bonica wrote:
> In defense of publishing draft-ietf-dnsop-reflectors-are-evil I'd like
> to put forward the following article that was part of a paper I co-
> authored in 2005. I do this to show that the publication of t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11 sep 2008, at 21.49, Dean Anderson wrote:
> On Thu, 11 Sep 2008, Kurt Erik Lindqvist wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>> (CC trimmed)
>>
>> Having worked for a tier-1 provider and started two ISPs in the past,
>
On Sep 10, 2008, at 9:17 PM, Ron Bonica wrote:
> Folks,
>
> Based on the response that we have seen from the WG so far, I don't
> see
> any reason to amend the draft. BCP 38 is already published.
In defense of publishing draft-ietf-dnsop-reflectors-are-evil I'd like
to put forward the followi
Subject: Re: [DNSOP] I-D Action:draft-ietf-dnsop-reflectors-are-evil-06.txt
Date: Thu, Sep 11, 2008 at 03:39:09PM -0400 Quoting Ron Bonica ([EMAIL
PROTECTED]):
> Folks,
>
> This is a reminder that only two questions are on the table. These are:
>
> - is BCP38 enough to miti
On Thu, 11 Sep 2008, [UTF-8] OndÅej Surý wrote:
> No. And I don't understand why the burden of open resolvers should
> be put on shoulders of attacked DNS operators.
DNS operators aren't generally being attacked, and aren't generally
complaining of the burden. Almost no one is complaining of
On Thu, 11 Sep 2008, Kurt Erik Lindqvist wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> (CC trimmed)
>
> Having worked for a tier-1 provider and started two ISPs in the past,
> I am certain that BCP38 won't be universally deployed as that is
> operationally very hard and cos
On Thu, Sep 11, 2008 at 03:34:36PM -0400, Dean Anderson wrote:
> Please tell about the experiences you personally had with open recursor
> attacks at Afilias.
I guess I wasn't clear enough in my message: I am not in a position to
tell you about that. I am constrained by the non-disclosure terms o
Folks,
This is a reminder that only two questions are on the table. These are:
- is BCP38 enough to mitigate the attack vectors described in
draft-ietf-dnsop-reflectors-are-evil-06
- is filtering after the attack has begun good enough
Discussions of how many times this attack has been observed i
Please tell about the experiences you personally had with open recursor
attacks at Afilias.
Afilias doesn't seem to run open recursors--is that correct? Was
Afilias a target of an attack? If so, what did Afilias do to mitigate
the attack? Why couldn't the attack be mitigated using ordinary
metho
On Thu, 11 Sep 2008, Olaf Kolkman wrote:
> I do not have first hand experience from being under attack but I have
> seen enough arguments that reflector attacks are not only
> hypothetically possible but they also happen in real life. Not only
> from private conversations but also from, for
2008/9/10 Ron Bonica <[EMAIL PROTECTED]>:
>
>>
>>> 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
>>
>> If you mean 'restrict software configuration defaults', I'm O
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(CC trimmed)
Having worked for a tier-1 provider and started two ISPs in the past,
I am certain that BCP38 won't be universally deployed as that is
operationally very hard and costly in larger networks. This
effectively means that there will st
Dear Dean,
[Removing Jorge from the CC-list, this reply is supposed to be
technical in nature. Also removing the IESG since this appears to be a
WG issue, they can go back to the archives if and when relevant]
The answer to both the questions is "yes". There is still no evidence
for "n
On Wed, Sep 10, 2008 at 03:17:51PM -0400,
Ron Bonica <[EMAIL PROTECTED]> wrote
a message of 39 lines which said:
> Based on the response that we have seen from the WG so far, I don't
> see any reason to amend the draft. BCP 38 is already published.
It is certain that any message by is not suf
On 10 Sep 2008, at 15:17, Ron Bonica wrote:
> - is BCP38 enough to mitigate the attack vectors described in
> draft-ietf-dnsop-reflectors-are-evil-06
This question needs clarification. I say this because this is an
operations group, not a protocol group; what is dealt with here is
practice,
On Wed, Sep 10, 2008 at 05:38:05PM -0400, Dean Anderson wrote:
> -Sullivan appears to have no personal knowledge of any attacks working
> at Afilias, and doesn't assert having personal knowledge.
I'm not sure how you conclude I have no personal knowledge, or how you
make any inferences about appe
Hmm. just about 23 hours. So much for sitting quietly while the working
group discusses matters.
The answer to both the questions is "yes". There is still no evidence
for "no", and _still_ no one has come forward with personal knowledge of
any attacks:
-Sullivan appears to have no personal kno
>
>> 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
>
> If you mean 'restrict software configuration defaults', I'm OK with
> that.
>
> If the draft is amended to
On Tue, 9 Sep 2008, Kevin Darcy wrote:
> 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
If you mean 'restrict software configuration defaults', I'm OK with
that.
If t
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 i
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 con
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 a
[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 imp
On Tue, Sep 09, 2008 at 04:19:47PM -0400, Ron Bonica wrote:
> Thanks for this proposal. 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.
My view is that recommending closing open recursors is a wa
On Tue, 9 Sep 2008, Dean Anderson wrote:
>
> > > 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
Dean,
Thanks for this proposal. 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.
Ron
De
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.
>
>
On Tue, 9 Sep 2008, Ron Bonica wrote:
> 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 feel
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 h
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
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 othe
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
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 tha
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
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 :
On Mon, 1 Sep 2008, David Conrad wrote:
> > This draft reminds me of the claims that open relays somehow
> > promoted spam.
> [Trademark Dean Anderson paranoiac drivel deleted]
You misuse the word paranoid. The word 'paranoid', means one has an
unjustified fear. I have no 'unjustified fear', n
Dean,
On Sep 1, 2008, at 6:35 PM, Dean Anderson wrote:
> Given that we now have some high-profile DNSSEC test zones (thanks to
> David Conrad), ...
You're quite welcome, but I really can't take the credit -- the IAB
really was the instigator of the ns.iana.org service (assuming that's
what yo
Has there been any subsequent attacks since the motivating attack was
reported?
Given that we now have some high-profile DNSSEC test zones (thanks to
David Conrad), there is now no reason at all to use a recursor in a DDOS
attack. One would merely make DNSSEC queries against a high-profile
auth
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of
the IETF.
Title : Preventing Use of Recursive Nameservers in Reflector
Attacks
Author(s) : J. Damas, F.
43 matches
Mail list logo
