North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: dsl providers that will route /24

  • From: David Schwartz
  • Date: Fri Mar 30 04:15:39 2001

	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 [email protected]$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