dsl providers that will route /24

Fri Mar 30 10:50:53 UTC 2001

On Fri, 30 Mar 2001, David Schwartz wrote:

> 
> 	I won't play your name calling game.

Name calling?  I don't play games.  I label as I see fit however.  If it
fits, which it obviously did, deal with it or FIX YOUR PROBLEM.

> 
> > 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!
> 
> 	What the heck does that have to do with anything we're discussing? We
> weren't talking about what you do with it, we were talking about whether you
> could tell if it was spoofed or not.

Um, the last time I checked, we were talking about spoofed packets.  It
has EVERYTHINH to do with that.

> 
> > (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!
> 
> 	Okay, so you have a filter that checks with ARIN? Or does your
> filter, *surprise* have no way to tell whether a packet is spoofed or
> not.

No. I've got better.  Check this out.
http://www.isi.edu/ra/RAToolSet/RtConfig.html

Wow!  It will build filter sets based on registered objects!  What a
^&(#&#*( concept!

> 
> > It's that simple.  Believe it or not, MOST _REAL_ providers use police
> > very close to what I have outlined.
> 
> 	I'm not talking about that. I'm talking about whether it's
> possible for a filter to tell whether a packet is spoofed or not.

Yes!  It is!  If you build  your filters based on what IP addresses you
know should be sourced from Customer-X, you *CAN* know and filter spoofed
packets.

It all comes down to this.

Do you announce it?  yes?  You should probably accept traffic to/from it.

You DON'T announce it?  Well.. In that case, you've got one of two things
going on:

(1) Customer-X is spoofing
(2) Customer-X isn't announcing address space to you that they're going to
be originating traffic from.

In EITHER case, if CUSTOMER-X hasn't made prior arrangement (and you with
your upstreams and them with theirs) the traffic is going to be dropped
SOMEWHERE anyway because you won't have a route object for it in the irrd.

> > > > 	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.
> 
> 	Yes, it's easy to build a filter to match. I never said it
> wasn't. However, the filter will simply determine whether a packet
> matches the list of IP address you know the customer is authorized to
> use. It can't actually tell if a packet is spoofed or not.
> 

OK.   Check this concept out.  If the customer isn't authorized to use the
address space, AND THEY ARE......

IT'S SPOOFED -- BOGUS -- BAD -- BAD -- BAD!!!!!

> 	Get it?
> 

I got it years ago, Son.  Do YOU get it or are we all wasting our time
trying to educate the terminally ignorant?

> 	A spoofed packet is one that's introduced to the Internet and didn't
> originate from a machine whose administration is authorized to source that
> IP on the global Internet. No filter can establish where a packet actually
> originated, so no filter can tell that. Okay? Get it? A filter cannot
> determine whether or not a packet is spoofed.
> 

Huh?  If they're authorized to originate the packet, they TELL YOU and you
VERIFY THAT and you open your filters up for them to DO SO!  If NOT, you
NIX IT!

Check this out.  YOUR INGRESS FILTER, if YOU'RE their connection to the
global internet, or ONE of their connections to the global internet, can
tell if where the packet originated from!  It's filtering THEIR
CONNECTION!  Do we have to take up a collection to buy you some clue or
what?

> 	Believe me, if a filter really could tell whether a packet was
> spoofed or not, the problem of ending spoofing would be much, much
> simpler.

The problem is SIMPLE.

It's just two simple steps.

INGRESS filter your customers.

Everyone does that, we have a FEW rogues (you fit that mold) to
filter/blackhole/disconnect.

> > > 	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".
> 
> 	And the point I'm trying to make is that an unspoofed attack can
> do just as much damage as a spoofed attack. So stopping spoofing may
> or may not reduce the damage an attack does. It all depends upon how
> long it takes you to stop the attack at its source.
> 

Stopping spoofing brings ready accountability to the networks that are
actually ORIGINATING the attacks and reduces the time involved in tracking
them down.

When we KNOW it's not spoofed, we can track the REAL SOURCE down REAL
QUICK!  How can you be so ignorant to this fact and still possess the
mental faculties required to type?

> > 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?
> 
> 	That's the provider for the particular machine I'm sitting at at
> 2 in the morning. I have no connection to them (except that I'm a
> customer).

Oh. OK.  So you don't ever run a network and I've wrongfully malligned
someone who most likely has a ^&*# clue?  Everyone who is associated with
AS14649 and 161.211.0.0/16, I'm sorry.  Once again, I've been duped into
thinking I was replying to someone who actually RAN A ^%#*& NETWORK just
because they managed to subscribe to NANOG and NANOG-POST.  We _REALLY_
need to get more stringent subscription requirements for NANOG-POST.

> 
> 	DS
> 

Wouldn't be prudent and you probably wouldn't understand it if I did.

---
John Fraizer
EnterZone, Inc