B0;261;0cHi there,
On Fri, 14 Jun 2013, rfg wrote:
[Quite a lot of off-topic stuff, which I've snipped.]
For the avoidance of doubt, this is absolutely not a reply to any of
Mr. Guilmette's posts, and I neither expect nor even want to see any
reply from him. But I am on the digest list, so f
In message <51bbb83a.7040...@dougbarton.us>, Doug Barton writes:
> Personally I've never understood why RRL wasn't already baked in. The
> only way a legitimate client could send the same query over and over in
> a short period of time (intentionally being vague on both terms) is that
> it is b
> From: Doug Barton
> > RRL needs only authority and open recursive servers to be updated.
> > The vast majority of DNS installations are closed recursive and stubb
> > servers that do not need RRL. (A case could be made for RRL on a
> > minority of private recursive servers.)
>
> You're right o
On 06/14/2013 05:13 PM, Vernon Schryver wrote:
From: Doug Barton
is that (like RRL) your proposal relies on people updating their
software.
RRL needs only authority and open recursive servers to be updated.
The vast majority of DNS installations are closed recursive and stubb
serve
> From: Doug Barton
> is that (like RRL) your proposal relies on people updating their
> software.
RRL needs only authority and open recursive servers to be updated.
The vast majority of DNS installations are closed recursive and stubb
servers that do not need RRL. (A case could be mad
Ronald,
You started this thread a bit off topic, but now you've wandered pretty
far off into the rhetorical weeds. So I'm going to respond to you here
so that the archives have a little more utility, then I'm going to let
you have the last word.
On 06/14/2013 02:04 PM, Ronald F. Guilmette w
In message <51baa714.9020...@dougbarton.us>,
Doug Barton wrote:
>It's obvious you're frustrated (understandable), and enthusiastic
>(commendable), but you might want to consider dialing down your
>"rhetoric" a bit.
Great idea! I have only one small question... Would you be willing to
provi
On Jun 14, 2013, at 6:28 AM, "Ronald F. Guilmette"
wrote:
>
> In message <201306140321.r5e3l7py017...@calcite.rhyolite.com>,
> Vernon Schryver wrote:
>
>>> From: "Ronald F. Guilmette"
>>
>> } That is an interesting contention. Is there any evidence of, or even any
>> } reasonably reliabl
In message <18216.1371209...@server1.tristatelogic.com>, "Ronald F. Guilmette"
writes:
>
> In message <20130614050625.850cf35e5...@drugs.dv.isc.org>,
> Mark Andrews wrote:
>
> >In message <15120.1371179...@server1.tristatelogic.com>, "Ronald F.
> >Guilmette"
> > writes:
> >> >* Large numbers
>OK. I just want to be clear here, and make sure that I have properly
>understood what you have said. Would it be correct, then, to say that
>at the present moment you are not actually able to produce, cite, or
>describe, with any particularity or specificity, even one individual
>specific incide
In message <20130614050625.850cf35e5...@drugs.dv.isc.org>,
Mark Andrews wrote:
>In message <15120.1371179...@server1.tristatelogic.com>, "Ronald F. Guilmette"
> writes:
>> >* Large numbers of ISPs claim they implement BCP 38.
>>
>> I claimed that I was Charlie Chaplin once. Unfortunately, Rob
In message <201306140321.r5e3l7py017...@calcite.rhyolite.com>,
Vernon Schryver wrote:
>> From: "Ronald F. Guilmette"
>
>} That is an interesting contention. Is there any evidence of, or even any
>} reasonably reliable report of any DDoS actually being perpetrated IN PRACTIC
>E
>} using strict
Ronald F. Guilmette wrote:
>
> P.P.S. Yes, yes, I _am_ aware... as someone will surely point out...
> that part (1) above contains the seed of potential abuse. A malicious
> prankster could, in theory send spoofed packets of type (1) above to
> lots and lots of DNS servers which he believes that
Ronald,
It's obvious you're frustrated (understandable), and enthusiastic
(commendable), but you might want to consider dialing down your
"rhetoric" a bit. You've had responses from people here who have been
working on this problem for years, and have a deep understanding of it.*
Trying to u
In message <15120.1371179...@server1.tristatelogic.com>, "Ronald F. Guilmette"
writes:
>
> In message <20130614023140.7735d35e2...@drugs.dv.isc.org>,
> Mark Andrews wrote:
>
> >* Router manufactures have code to support BCP 38 though it defaults to off.
>
> Well then, THAT is going to be a g
In message <20130614032434.72450.qm...@joyce.lan>,
"John Levine" wrote:
>>So, may I infer that rather than being put off until the end of the
>>century, which seemed to be the previous implementation timeline,
>>pervasive implementation of BCP 38 may now be expected at around the
>>time that 32
>So, may I infer that rather than being put off until the end of the
>century, which seemed to be the previous implementation timeline,
>pervasive implementation of BCP 38 may now be expected at around the
>time that 32-bit UNIX clocks are anticipated to wrap-around to negative?
Perhaps, but I thi
> From: "Ronald F. Guilmette"
} That is an interesting contention. Is there any evidence of, or even any
} reasonably reliable report of any DDoS actually being perpetrated IN PRACTICE
} using strictly 512 byte packets?
}
} If that's actually a real problem, then I am forced to assume that there
In message <20130614023140.7735d35e2...@drugs.dv.isc.org>,
Mark Andrews wrote:
>* Router manufactures have code to support BCP 38 though it defaults to off.
Well then, THAT is going to be a great help in solving the problem, isn't it?
>* Large numbers of ISPs claim they implement BCP 38.
I c
In message <20130614022305.72272.qm...@joyce.lan>,
"John Levine" wrote:
>>>The real solution is BCP 38...
>>
>>I agree completely John. I cannot do otherwise. But I have to ask the
>>obvious elephant-in-the-room question... How is that comming along so far?
>
>Based on discussions I've had wi
In message <20130614020930.c1c1c35e2...@drugs.dv.isc.org>,
Mark Andrews wrote:
>Well the process has started. BCP 38. If you want hurry it along
>complain to your local politician that they need to consider drafting
>legislation that requires ISP's to implement BCP 38 in their networks.
See!
In message <201306140126.r5e1quqj032...@calcite.rhyolite.com>,
Vernon Schryver wrote:
>Indeed. As many have mentioned, DNS reflection attacks are merely
>the current fad...
So it is "just a fad".
Whew! That's a load off! I'm glad that somebody told me. Fortunately
there is still time for
In message <14768.1371175...@server1.tristatelogic.com>, "Ronald F. Guilmette"
writes:
>
> In message <20130614004155.72013.qm...@joyce.lan>,
> "John Levine" wrote:
>
> >The real solution is BCP 38...
>
> I agree completely John. I cannot do otherwise. But I have to ask the
> obvious eleph
>>The real solution is BCP 38...
>
>I agree completely John. I cannot do otherwise. But I have to ask the
>obvious elephant-in-the-room question... How is that comming along so far?
Based on discussions I've had with people who work at large networks
and in policy positions in various government
In message <20130614004155.72013.qm...@joyce.lan>,
"John Levine" wrote:
>The real solution is BCP 38...
I agree completely John. I cannot do otherwise. But I have to ask the
obvious elephant-in-the-room question... How is that comming along so far?
Maybe we could find worse ways to spend ou
Well the process has started. BCP 38. If you want hurry it along
complain to your local politician that they need to consider drafting
legislation that requires ISP's to implement BCP 38 in their networks.
Require BCP 38 implementation by all parties as part of trade
negotiation.
Doing anythin
In message <51ba355b.10...@dougbarton.us>,
Doug Barton wrote:
>No. You can still get pretty good amplification with 512 byte responses.
That is an interesting contention. Is there any evidence of, or even any
reasonably reliable report of any DDoS actually being perpetrated IN PRACTICE
using
> From: "John Levine"
> The real solution is BCP 38, to keep spoofed packets out of the
> network in the first place.
Indeed. As many have mentioned, DNS reflection attacks are merely
the current fad, driven partly by 10X or higher amplification
(<50 byte queries, >500 byte responses) and par
In message <201306131753.r5dhrwon093...@calcite.rhyolite.com>,
Vernon Schryver wrote:
>I think that the use of RRL on some roots shows that keeping state
>is not a problem if the state keeping is not utterly stupid.
(I'm not sure what, if anything, I should be reading into that last bit
of a p
Just a thought, below:
On 14/06/13 2:41, Ronald F. Guilmette wrote:
> In message <51b9fb6a.1090...@tiggee.com>,
> David Miller wrote:
>
>> This could lead to wrong headed statements like, "Yes, we sent X GB of
>> traffic at your network.
> Yes.
>
> Last night I reconsidered at some length the sche
In message <51b9fb6a.1090...@tiggee.com>,
David Miller wrote:
>A system that requires the victim to take action to stop attacks...
You mean like the defacto "system" we have right now?
>... might be misconstrued by some to be abdicating the responsibility
>of the upper four levels.
Ummm... I
>The entire problem is fundamentally a result of the introduction of EDNS0.
>Wwouldn't you agree?
No, that just makes it a little easier. You pound the patoot out of
someone with 512 byte packets just as much as you can with 4K packets,
just by making your attacking botnet bigger.
The real solut
In message <51b9fb6a.1090...@tiggee.com>,
David Miller wrote:
>This could lead to wrong headed statements like, "Yes, we sent X GB of
>traffic at your network.
Yes.
Last night I reconsidered at some length the scheme I put forward yesterday.
(Please note that I am very deliberately calling it
On 06/13/2013 02:01 PM, Ronald F. Guilmette wrote:
The entire problem is fundamentally a result of the introduction of EDNS0.
Wwouldn't you agree?
No. You can still get pretty good amplification with 512 byte responses.
There are 2 causes of this problem, lack of BCP 38, and improperly
secure
In message <51b991f7.9070...@imperial.ac.uk>,
Phil Mayers wrote:
>On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote:
>> 2) Has anyone ever proposed adding to the DNS protocol something vaguely
>> reminicent of the old ICMP Source Quench? If so, what became of that
>> proposal?
>...
>> Basical
> From: David Miller
> >> Basically, the whole idea is just simply to allow a victim to switch to
> >> "safe TCP only mode" with all of the intermediaries that are
> >> participating
> >
> > The problem with that idea is that it needs software updates on both
> > the reflecting DNS server and the
On 06/13/2013 05:33 AM, Phil Mayers wrote:
> On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote:
>
>> 1) If everyone on the planet were to somehow magically and
>> immediately be
>> converted over to DNSSEC tomorrow, then would DNS amplification attacks
>> become a thing of the past, starting tomor
On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote:
1) If everyone on the planet were to somehow magically and immediately be
converted over to DNSSEC tomorrow, then would DNS amplification attacks
become a thing of the past, starting tomorrow? Does DNSSEC "solve" the
DNS amplification attack p
38 matches
Mail list logo
