Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

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

RE: dsl providers that will route /24

  • From: John Fraizer
  • Date: Fri Mar 30 05:00:58 2001

On Fri, 30 Mar 2001, David Schwartz wrote:

> 	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.

I'm not misreading anything.  I'm reading what you have written which is
(reading between the lines) "I'm too lazy to keeo track of what IP space
my customers use or will be originating traffic from..."

> 
> 	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.

WHAT?  If something comes from a customer that doesn't match your filters
for that customer you DROP IT!  IT'S THAT SIMPLE!  Inconvenience for ONE
customer or ONE customer's customers is MUCH less or a problem than your
customer (or customer's customer) sending traffic from unauthorized
address space!

> 	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.
> 

OK.  It's apparent from your arguement that you are not a transit
> 
AS.  Here's the simple answer for you:

(1)You use address space provided by (your company) or: (

2)You use address space that you have PROOF (whois.arin.net, etc) that you
are authorized to use.

(3)Any packets sourced from address space not fitting the above two
critiria will be DROPPED!

It's that simple.  Believe it or not, MOST _REAL_ providers use police
very close to what I have outlined.


> 	Regardless of whether I filter or not, the fact remains that a
> filter can't tell a spoofed packet from an unspoofed packet.

Yes you can.  You know what the customer is assigned and what they have
told you they will be sourcing from.  It's EASY to build a filter to
match.

> 	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.

David, the only obvious thing here is that you're either clueless or
criminally negligent.  (Both may be true.)  The above example has no
bearing on this discussion.  We're talking (at least those of us with
clue) about filtering packets sourced from address space that is not
assigned to or OK'd to be used by "customer X".

> 	This is rapidly degenerating from a discussion of network
> operations into a series of personal attacks.

I agree.  I've already wasted too much of my time on you.  You're
obviously too arrogant/clueless to effect the changes necessary to remove
your network from the ever growing list of connected networks that make up
the Internet.  I reply only in hope that others will see the error of your
ways and not be pointed out a myself and many others have done to you.


14649 eh?  Why doesn't the high number surprise me?

161.211.0.0/16

How did you fall into a /16 being so clueless?

> 	DS

Coming closer but, still not going there...


---
John Fraizer
EnterZone, Inc







Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.