On Thu, 28 Aug 2008, Brian Dickson wrote:
However, if *AS-path* filtering is done based on IRR data, specifically
on the as-sets of customers and customers' customers etc., then the
attack *can* be prevented.
Yes, but I can't do this for everybody else. Doing AS-path and prefix
filtering (ma
Alex Pilosov wrote:
On Thu, 28 Aug 2008, Brian Dickson wrote:
However, if *AS-path* filtering is done based on IRR data, specifically
on the as-sets of customers and customers' customers etc., then the
attack *can* be prevented.
The as-path prepending depends on upstreams and their peers ac
On Thu, 28 Aug 2008, Brian Dickson wrote:
> However, if *AS-path* filtering is done based on IRR data, specifically
> on the as-sets of customers and customers' customers etc., then the
> attack *can* be prevented.
>
> The as-path prepending depends on upstreams and their peers accepting
> the pr
Alex P wrote:
*) There is no currently deployable solution to this problem yet.
*) Filtering your customers using IRR is a requirement, however, it is
not
a solution - in fact, in the demonstration, we registered the /24 prefix
we hijacked in IRR. RIRs need to integrate the allocation data wi
We mainly use UDP for tracker announces, and only use TCP when we have
to, and can confirm that the server spends far more time on the TCP
setup/teardown than on computing the tracker response.
- LP
On Jul 29, 2008, at 12:21 PM, Mikael Abrahamsson wrote:
On Tue, 29 Jul 2008, Steven M. Bell
On Tue, 29 Jul 2008, Steven M. Bellovin wrote:
In this situation, UDP uses one query packet and one reply. TCP uses 3
to set up the connection, a query, a reply, and three to tear down the
connection. *Plus* the name server will have to keep state for
every client, plus TIMEWAIT state, etc. (
On Tue, 29 Jul 2008, Steven M. Bellovin wrote:
On Tue, 29 Jul 2008 15:56:19 +0200
Colin Alston <[EMAIL PROTECTED]> wrote:
DNS uses UDP.
Ahh yes of course..
Why does it use UDP? :P
In this situation, UDP uses one query packet and one reply. TCP uses 3
to set up the connection, a query,
On Tue, 29 Jul 2008 15:56:19 +0200
Colin Alston <[EMAIL PROTECTED]> wrote:
> > DNS uses UDP.
>
> Ahh yes of course..
>
> Why does it use UDP? :P
>
In this situation, UDP uses one query packet and one reply. TCP uses 3
to set up the connection, a query, a reply, and three to tear down the
conne
Colin Alston wrote:
Why does it use UDP? :P
Faster? Smaller? Less code to break? No perceived need for state?
--
Requiescas in pace o email Two identifying characteristics
of System Administrators:
Ex turpi causa non oritur actio
Tony Finch wrote:
On Mon, 28 Jul 2008, Colin Alston wrote:
In fact, why *don't* implementations discard authoritative responses
from non-authoritative hosts? Or do we? Or am I horribly wrong?
The response is spoofed so that it appears to come from the correct host.
There's an argument that I
On Mon, 28 Jul 2008, Colin Alston wrote:
>
> In fact, why *don't* implementations discard authoritative responses
> from non-authoritative hosts? Or do we? Or am I horribly wrong?
The response is spoofed so that it appears to come from the correct host.
> There's an argument that IP spoofing can
On Mon, 28 Jul 2008, Colin Alston wrote:
>
> If NS records pointed to IP's instead of names then this problem might not
> exist.
That would make no difference to Kaminsky's attack, since it's the NS
records he's overwriting, not the glue.
Tony.
--
f.anthony.n.finch <[EMAIL PROTECTED]> http://d
* Paul Vixie:
>>> Listen on 200 random fake ports (in addition to the true query ports);
> at first glance, this is brilliant, though with some unimportant nits.
It doesn't work OOTB for most users because the spoofed packets never
reach the name server process if you don't use the ports to send
> however, since it is off-topic for nanog
ha ha. please stop telling people that they are off topic for nanog.
randy
What would the ip-blocking BGP feed accomplish? Spoofed source
addresses are a staple of the DNS cache poisoning attack.
Worst case scenario, you've opened yourself up to a new avenue of
attack where you're nameservers are receiving spoofed packets intended
to trigger a blackhole filter, blockin
ole filter, blocking communication between your network
and the legitimate owner of the forged ip address.
Michael Smith wrote:
Hello All:
From: Paul Vixie <[EMAIL PROTECTED]>
Date: Tue, 29 Jul 2008 01:24:43 +
To: Nanog <[EMAIL PROTECTED]>
Subject: Re: Great Suggestion for the D
Hello All:
> From: Paul Vixie <[EMAIL PROTECTED]>
> Date: Tue, 29 Jul 2008 01:24:43 +
> To: Nanog <[EMAIL PROTECTED]>
> Subject: Re: Great Suggestion for the DNS problem...?
>
> [EMAIL PROTECTED] ("Jay R. Ashworth") writes:
>
>> [ unthreade
[EMAIL PROTECTED] ("Jay R. Ashworth") writes:
> [ unthreaded to encourage discussion ]
>
> On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote:
>> Nameservers could incorporate poison detection...
>>
>> Listen on 200 random fake ports (in addition to the true query ports);
>> if a response
On 2008/07/28 09:52 PM Jay R. Ashworth wrote:
On Mon, Jul 28, 2008 at 12:35:30PM -0700, Tomas L. Byrnes wrote:
As you pointed out, the protocol, if properly implemented, addresses
this.
There should always be Glue (A records for the NS) in a delegation. RFC
1034 even specifies this:
4.2.2
A
On Mon, Jul 28, 2008 at 12:35:30PM -0700, Tomas L. Byrnes wrote:
> As you pointed out, the protocol, if properly implemented, addresses
> this.
>
> There should always be Glue (A records for the NS) in a delegation. RFC
> 1034 even specifies this:
>
> 4.2.2
> As the last installation step, the
t; To: Jay R. Ashworth
> Cc: nanog@nanog.org
> Subject: Re: Great Suggestion for the DNS problem...?
>
> On 2008/07/28 09:05 PM Jay R. Ashworth wrote:
> > Is there any reason which I'm too far down the food chain
> to see why
> > that's not a fantastic idea?
> [ unthreaded to encourage discussion ]
>
> On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote:
> > Nameservers could incorporate poison detection...
> >
> > Listen on 200 random fake ports (in addition to the true query ports);
> > if a response ever arrives at a fake port, then it must
On 2008/07/28 09:05 PM Jay R. Ashworth wrote:
Is there any reason which I'm too far down the food chain to see why
that's not a fantastic idea? Or at least, something inspired by it?
If NS records pointed to IP's instead of names then this problem might
not exist.
The root holds glue going up
[ unthreaded to encourage discussion ]
On Sat, Jul 26, 2008 at 04:55:23PM -0500, James Hess wrote:
> Nameservers could incorporate poison detection...
>
> Listen on 200 random fake ports (in addition to the true query ports);
> if a response ever arrives at a fake port, then it must be an attack,
24 matches
Mail list logo
