Re: DoS attacks, NSPs unresponsiveness

[Daniel Senie <dts () senie com>]

dies wrote:
>         Well since everyone else is stating their opinions, I'll join in
> as well.  First off I think pulling the plug is a great idea ( =] ).

Actually, adding the requirement for ingress filtering to the terms of
service for backbones (and smaller) networks is a better idea. Start
with the legal stuff, then enforce it.

> Anyways the point comes down to this.  Who should be doing the ingress
> filtering?  Tier-2's, Tier-1's, the actual customer?  I know this whole
> idea sounds very pretty and nice, however, when it comes down to it there
> are many real problems with this idea.


>  One, the hardware on most ISP's
> backbones cannot realistically do ingress filtering.

It's a political issue. When we first wrote the drafts which became RFC
2267 and later RFC 2827, we had this exact argument from several
folks... "our equipment can't handle it" or "it'll melt our routers."
That was 4 years ago. And they were right, the routers of that era would
melt down, and we knew that. Most of those folks have replaced their
router and switch gear since then. Do you suppose they added wire-speed
ingress filtering to their requirements list when shopping for new
product? Some did, others chose to ignore it. Vendors will build what
you ask for.

Equipment DOES exist which can filter at wire speed up to and including
gigabit Ethernet. The question is whether there's the will or desire to
actually deploy such things. I think you're going to see larger end-user
customers selecting ISPs based on who has a commitment to requiring
ingress filtering of all customers.

>  I'm sorry to say but
> a GSR is not able to do ingress filtering on 5 Channelized OC-12's that
> hold 400+ Customers a piece.  It just does not work, I don't care what
> Cisco claims, it just does not work.

So you have a problem with one of your vendors. Beat 'em up, throw their
gear out, or whatever.

>  What about other vendors?  I have no
> experience with Bay or Lucent, however, Juniper (which I do have
> experience with) has the ability due to the hardware based filtering
> available but that brings up a whole set of other questions.  How will
> ingress filtering from an ISP level effect downstream customers that do
> asymmetrical routing?

It is entirely possible to develop a product which can handle ingress
filtering based on BGP tables, and do it all automatically. Cisco has
not done this, and it's not clear their gear can do it in their present
designs. I don't know if anyone else is doing it either. That's not
because it's impossible, just that the capability wasn't on a list of
requirements when the hardware and software were designed. If this is
important to you, make sure your vendors know this. Tell them in
writing, so the message sticks around.


>  How about the management overhead that comes into
> play when you are a Tier-1 or a large Tier-2 with tens of thousands of
> customers?

Tier-1 and Tier-2 providers seem to handle management of IP address
space delegation, routing topology, BGP route filtering and lots of
other per-customer tasks without trouble. It's a commitment thing. If
providing ingress filtering becomes a standard part of the suite of
functions, then it'll get integrated into the rest and it'll be
supportable. Have you asked those you buy from if they'll do this? Did
you suggest you'd switch to a tier-1 who does? Lacking incentives,
status quo will rule.

>  What is comes down to is that customers need to be doing
> egress filtering, it's the only scalable solution, however this just is
> not happening.

Egress filtering is ingress filtering being done on the other end of the
pipe. The ISP has no control, and thus will not be aware of whether it's
really taking place. For ISPs who manage the routers at customer
locations, this is clearly a no-brainer, but how many do implement the
filters?

Pushing the problem out and saying it's really the end-user's issue is a
dodge. The ISPs have to be responsible for their own networks too. I'm
waiting to see how many negligence lawsuits are filed by the various
targets of the DoS attacks last spring. Those who didn't implement
ingress filtering (and end users who don't implement egress filtering)
may well be found liable for failing to do so, and thereby contributing
to damage of others' systems.

>  Don't blame the ISPs only, it's their customers that are
> really the problem.  Lack of security/knowledge on the customer's end
> leads to hacked boxes, which in turn lead to DoS attacks.  It really comes
> down to not the responsibility of the ISP, but in fact the responsibility
> of the customers!  Maybe we all should thinkg about that before we point
> fingers.

Maybe those who should have the clue (the ISPs) should take on the
responsibility and do the work. Let's face it, sales staff at the ISPs
are busy trying to sell lines to every business, small and large, and
those businesses aren't going to be networking experts. The ISPs are in
the appropriate position to understand the problem and implement the
solution.

The solution from an ISP's perspective could be a variety of things,
ranging from a Terms of Service item that requires filtering at the
customer router, to actually implementing filtering at the access
router/server/switch where the customers attach.

> On Thu, 2 Nov 2000 Valdis.Kletnieks () vt edu wrote:
>
> > On Thu, 02 Nov 2000 09:59:04 EST, Mark Mentovai <mark-list () mentovai com>  said:
> > > This can't go on forever.  I'd like to spread the clue about ingress
> > > filtering, and am willing to commit time to the cause.  Is anyone with me?
> >
> > The problem is that for many ISPs, I fear the only way to get them to
> > implement 2827-style filtering is for their upstreams to implement a
> > policy of fascist-mode ingress filtering - "We see a bogon packet that
> > your site should have filtered, we pull the plug on your link till you
> > fix it".
> >
> > Time alone won't be enough.  Bring a baseball bat.  And a spare bat.
> >
> > --
> >                               Valdis Kletnieks
> >                               Operating Systems Analyst
> >                               Virginia Tech


-- 
-----------------------------------------------------------------
Daniel Senie                                        dts () senie com
Amaranth Networks Inc.                    http://www.amaranth.com