This was responded to on the DNSEXT mailing list.
Sorry, but your question was accidentally attributed to Paul who
forwarded the message.
DNSEXT Archive: http://ops.ietf.org/lists/namedroppers/
-Doug
On Thu, 06 Aug 2009 06:51:24 +
Paul Vixie wrote:
> Christopher Morrow writes:
>
> > how does SCTP ensure against spoofed or reflected attacks?
>
> there is no server side protocol control block required in SCTP.
> someone sends you a "create association" request, you send back a
> "ok, her
On Thu, Aug 6, 2009 at 11:16 AM, Paul Vixie wrote:
> note, i went off-topic in my previous note, and i'll be answering florian
> on namedroppers@ since it's not operational. chris's note was operational:
>
>> Date: Thu, 6 Aug 2009 10:18:11 -0400
>> From: Christopher Morrow
>>
>> awesome, how does
On Thu, Aug 06, 2009 at 03:16:25PM +, Paul Vixie wrote:
> > ...: "Do loadbalancers, or loadbalanced deployments, deal with this
> > properly?" (loadbalancers like F5, citrix, radware, cisco, etc...)
>
> as far as i know, no loadbalancer understands SCTP today. if they can be
> made to pass SC
note, i went off-topic in my previous note, and i'll be answering florian
on namedroppers@ since it's not operational. chris's note was operational:
> Date: Thu, 6 Aug 2009 10:18:11 -0400
> From: Christopher Morrow
>
> awesome, how does that work with devices in the f-root-anycast design?
> (bo
On Thu, Aug 6, 2009 at 2:51 AM, Paul Vixie wrote:
> Christopher Morrow writes:
>
>> how does SCTP ensure against spoofed or reflected attacks?
>
> there is no server side protocol control block required in SCTP. someone
> sends you a "create association" request, you send back a "ok, here's your
On Thu, 6 Aug 2009, Florian Weimer wrote:
This doesn't seem possible with current SCTP because the heartbeat
rate quickly adds up and overloads servers further upstream. It
also does not work on UNIX-like system where processes are
short-lived and get a fresh stub resolver each time they are
* John Levine:
> 3) Random case in queries, e.g. GooGLe.CoM
This does not work well without additional changes because google.com
can be spoofed with responses to 123352123.com (or even 123352123.).
Unbound strives to implement the necessary changes, some of which are
also required if you want t
* Paul Vixie:
> there is no server side protocol control block required in SCTP.
SCTP needs per-peer state for congestion control and retransmission.
> someone sends you a "create association" request, you send back a
> "ok, here's your cookie" and you're done until/unless they come back
> and s
* Douglas Otis:
> DNSSEC UDP will likely become problematic. This might be due to
> reflected attacks,
SCTP does not stop reflective attacks at the DNS level. To deal with
this issue, you need DNSSEC's denial of existence. The DNSSEC specs
currently doesn't allow you to stop these attacks dead
* Douglas Otis:
> Establishing SCTP as a preferred DNS transport offers a safe harbor
> for major ISPs.
SCTP is not a suitable transport for DNS, for several reasons:
Existing SCTP stacks are not particularly robust (far less than TCP).
The number of bugs still found in them is rather large.
On
Christopher Morrow writes:
> how does SCTP ensure against spoofed or reflected attacks?
there is no server side protocol control block required in SCTP. someone
sends you a "create association" request, you send back a "ok, here's your
cookie" and you're done until/unless they come back and say
On Wed, Aug 5, 2009 at 6:53 PM, Douglas Otis wrote:
> On 8/5/09 2:49 PM, Christopher Morrow wrote:
>>
>> and state-management seems like it won't be too much of a problem on
>> that dns server... wait, yes it will.
>
> DNSSEC UDP will likely become problematic. This might be due to reflected
> att
On 8/5/09 2:49 PM, Christopher Morrow wrote:
and state-management seems like it won't be too much of a problem on
that dns server... wait, yes it will.
DNSSEC UDP will likely become problematic. This might be due to
reflected attacks, fragmentation related congestion, or packet loss.
When it
On Wed, 5 Aug 2009 15:07:30 -0400 (EDT)
"John R. Levine" wrote:
> >> 5 is 'edns ping', but it was effectively blocked because people
> >> thought DNSSEC would be easier to do, or demanded that EDNS PING
> >> (http://edns-ping.org) would offer everything that DNSSEC offered.
> >
> > I'm surpri
On Wed, Aug 5, 2009 at 5:24 PM, Douglas Otis wrote:
> On 8/5/09 11:31 AM, Roland Dobbins wrote:
>>
>> On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote:
>>
>>> Having major providers support the SCTP option will mitigate disruptions
>>> caused by DNS DDoS attacks using less resources.
>>
>> Can you el
On 8/5/09 11:31 AM, Roland Dobbins wrote:
On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote:
Having major providers support the SCTP option will mitigate disruptions caused
by DNS DDoS attacks using less resources.
Can you elaborate on this (or are you referring to removing the spoofing
vecto
On 8/5/09 11:38 AM, Skywing wrote:
That is, of course, assuming that SCTP implementations someday clean up their act a bit.
I'm not so sure I'd suggest that they're really ready for "prime time" at this
point.
SCTP DNS would be intended for ISPs validating DNS where there would be
fewer iss
3 works, but offers zero protection against 'kaminsky spoofing the
root' since you can't fold the case of "123456789.". And the root is
the goal.
Good point.
5) Download your own copy of the root zone every few days from
http://www.internic.net/domain/, check the signature if you can find the
5 is 'edns ping', but it was effectively blocked because people
thought DNSSEC would be easier to do, or demanded that EDNS PING
(http://edns-ping.org) would offer everything that DNSSEC offered.
I'm surprised you failed to mention http://dnscurve.org/crypto.html,
which is always
o: John Levine
Cc: nanog@nanog.org
Subject: Re: DNS hardening, was Re: Dan Kaminsky
On 8/5/09 9:48 AM, John Levine wrote:
> Other than DNSSEC, I'm aware of these relatively simple hacks to add
> entropy to DNS queries.
>
> 1) Random query ID
>
> 2) Random source port
>
On Aug 6, 2009, at 1:12 AM, Douglas Otis wrote:
Having major providers support the SCTP option will mitigate
disruptions caused by DNS DDoS attacks using less resources.
Can you elaborate on this (or are you referring to removing the
spoofing vector?)?
---
On 8/5/09 9:48 AM, John Levine wrote:
Other than DNSSEC, I'm aware of these relatively simple hacks to add
entropy to DNS queries.
1) Random query ID
2) Random source port
3) Random case in queries, e.g. GooGLe.CoM
4) Ask twice (with different values for the first three hacks) and
compare the
bert hubert (bert.hubert) writes:
>
> 5 is 'edns ping', but it was effectively blocked because people
> thought DNSSEC would be easier to do, or demanded that EDNS PING
> (http://edns-ping.org) would offer everything that DNSSEC offered.
I'm surprised you failed to mention http://dnscurve
On Wed, Aug 5, 2009 at 6:48 PM, John Levine wrote:
> 3) Random case in queries, e.g. GooGLe.CoM
> 4) Ask twice (with different values for the first three hacks) and
> compare the answers
>
> I presume everyone is doing the first two. Any experience with the
> other two to report?
3 works, but off
25 matches
Mail list logo
