On Monday, October 01, 2007 10:34:37 AM -0600 Danny McPherson
[EMAIL PROTECTED] wrote:
Note that in real deployments just this behavior has broken things
on occasion, as many firewall and other such policy application points
assume things like DNS resolution will only be UDP/53
From: [EMAIL PROTECTED]
Second, you're talking about potentially orders of magnitude more
data: for each destination, there are worldwide likely hundreds (or
more) of ISP's which are likely to be viable backbone transits.
...
With ISP's which are directly connected
Danny McPherson writes:
Really? How many ISPs are you aware of that have
*decommissioned* every piece of routing gear in their
network in the past 7 years?
I think we're an ISP (AS559), and we don't have any equipment that
would be unable to filter against spoofed source addresses.
In fact I
On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote:
Note that in real deployments just this behavior has broken things
on occasion, as many firewall and other such policy application
points
assume things like DNS resolution will only be UDP/53 transactions.
That assumption has always
On Oct 1, 2007, at 8:55 PM, Mark Andrews wrote:
I'm not blaming the victim, I'm pointing out the contributory
negligence on behalf of the ISP that is supplying the
attacker bandwidth.
BCP 38 is over 7 years old now. The time has past where you can
On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote:
Note that in real deployments just this behavior has broken things
on occasion, as many firewall and other such policy application =20
points
assume things like DNS resolution will only be UDP/53 transactions.
That assumption
On Oct 2, 2007, at 1:41 AM, Mark Andrews wrote:
Someone should talk to ucdavis.edu and get this idiocy pulled.
And NIST, and many many others..
Because there are lots of recursive and authoritative
nameservers out there behind firewalls that get it right.
On Oct 1, 2007, at 8:55 PM, Mark Andrews wrote:
I'm not blaming the victim, I'm pointing out the contributory
negligence on behalf of the ISP that is supplying the
attacker bandwidth.
BCP 38 is over 7 years old now. The time has past where you can
blame the
On Tue, 2 Oct 2007 01:48:36 -0600
Danny McPherson [EMAIL PROTECTED] wrote:
Again, any pointers empirical data along these lines would
be appreciated.
I said this awhile back:
http://www.merit.edu/mail.archives/nanog/msg02196.html
As a datapoint I ran some tests against a reasonably
From: Danny McPherson [EMAIL PROTECTED]
where's the authoritative source for who owns what prefixes
This, one could imagining putting together.
and who's permitted to originate/transit what prefixes?
This is a whole different kettle of bits.
For one thing, there's no
On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews
[EMAIL PROTECTED] wrote:
The Introduction seems a bit defensive in stating that the DOS attacks
are not due to any flaw in the design of DNS or its implementations.
While the blame for the attacks lies with the attackers, some
On Oct 1, 2007, at 10:10 AM, Jeffrey Hutzelman wrote:
No; the blame for an attack _always_ lies with the attacker, not
the victim. While I certainly wish more network providers would
implement BCP 38, those who fail to do so are not to blame for the
bad acts of others.
Given the
On Tuesday, September 25, 2007 09:36:23 AM +1000 Mark Andrews
[EMAIL PROTECTED] wrote:
The Introduction seems a bit defensive in stating that the DOS attacks
are not due to any flaw in the design of DNS or its implementations.
While the blame for the attacks lies with the
It does, but normally only responses which are too long for UDP
require the use of TCP. A recursive nameserver could mitigate this
type of attack by lowering the maximum response size it is willing
to send via UDP, forcing the use of TCP and thus a three-way
handshake for
On Monday, October 01, 2007 10:34:37 AM -0600 Danny McPherson
[EMAIL PROTECTED] wrote:
Note that in real deployments just this behavior has broken things
on occasion, as many firewall and other such policy application points
assume things like DNS resolution will only be UDP/53
At 15:51 -0400 9/24/07, Stephen Hanna wrote:
Finally, I wonder whether other more fundamental techniques for
addressing the problem have been explored. For instance, if DNS clients
were required to perform a simple handshake before a DNS server sent
a long response, fake requests would provide
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just
18 matches
Mail list logo
