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