[36220] in North American Network Operators' Group
RE: dsl providers that will route /24
daemon@ATHENA.MIT.EDU (David Schwartz)
Fri Mar 30 04:14:01 2001
From: "David Schwartz" <davids@webmaster.com>
To: "John Fraizer" <nanog@Overkill.EnterZone.Net>
Cc: <nanog@nanog.org>
Date: Fri, 30 Mar 2001 01:06:06 -0800
Message-ID: <NCBBLIEPOCNJOAEKBEAKIEKGOBAA.davids@webmaster.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.LNX.4.21.0103300336180.8528-100000@Overkill.EnterZone.Net>
Errors-To: owner-nanog-outgoing@merit.edu
I don't know if you're just not reading what I'm writing or if we're
speaking different languages or what. We're totally talking past each other.
Here's one misunderstanding. I wrote:
> > ... the problem is there's no good way to tell a spoofed
> > packet from an unspoofed packet.
You wrote:
> Um, David... Do you actually READ the list or do you just randomly
> reply? Here's a clue for you.
>
> 1) Require that your customers notify you of any source addresses that
> they'll be using *PRIOR* to allowing them through. Tunneling is MUCH
> more rare than spoofing.
>
> 2) Require that your customers (BGP speakers) register their networks in
> RADB or whichever database you choose. (Don't worry. From the sounds of
> it, NONE of us want your customers...the spoofing b@$tard$...and as such,
> we're not really interested in who they are beyond filtering them.)
Now, I think you considered what I quoted from you above as replying to
what I quoted from me above. However, neither of the two things you stated
makes it any easier for me to tell if a packet is spoofed or not.
The statement of mine that you were attempting to reply to was, "there's no
good way to tell a spoofed packet from an unspoofed packet". And I've
already made it clear that by "spoofed", I mean a packet that didn't
originate on a machine administered by someone authorized to use that IP
address on the public Internet.
I get a packet with the origin IP address '206.4.2.1'. How do I tell
whether the packet is spoofed or whether it actually originated at the
machine authorized to use the IP address '206.4.2.1'? Perhaps a dialup
machine on my customer's LAN was assigned that IP address from another
provider.
Regardless of whether I filter or not, the fact remains that a filter can't
tell a spoofed packet from an unspoofed packet.
Here's another misunderstanding:
>> Again, no. A unicast UDP flood can do just as much damage. So
>> filters do not reduce the damage.
>How's that? The last time I checked, my "are you a customer" filters
>worked against both TCP and UDP.
Obviously, I was talking about an unspoofed flood. I mention UDP because
most unspoofed floods (at least, that I've seen) are UDP. It's the easiest
flood to launch if you haven't root compromised a box.
This is rapidly degenerating from a discussion of network operations into a
series of personal attacks.
DS
