North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Real-Time Mitigation of Denial of Service Attacks Now AvailableWith AT&T
no need to email your resume ... -chris On Thu, 3 Jun 2004, Krichbaum, Eric wrote: > > They went to a loose configuration to get the Isat (most of our sat > users) back to an operational state. The Isat vendor is now testing a > tunneled version. > > > Eric Krichbaum, Chief Engineer > MCSE: NT4, 2000, 2003, MCSE: Messaging, MCSE: Security, MCP+I, MCDBA, > MCSD.Net, ASE, CCNP, CCDP, CCSP, CCIP, ISSP, CNA, A+, Net+, iNet+, > Security+, Server+, Linux+, CQS-VPN Specialist, CQS- Firewall > Specialist, CQS- IDS Specialist, CQS-Wireless Design, CQS-Wireless > Support, CQS-IP Telephony, etc. > > -----Original Message----- > From: Daniel Senie [mailto:[email protected]] > Sent: Thursday, June 03, 2004 9:20 AM > To: Krichbaum, Eric; [email protected] > Subject: RE: Real-Time Mitigation of Denial of Service Attacks Now > Available With AT&T > > At 08:04 AM 6/3/2004, Krichbaum, Eric wrote: > > >Because there are legitimate reasons for async routing. > >DirectPC/Isat/etc. (Satelite based services) come to mind immediately. > > DirecPC has had satellite return path for a long time. Their older > systems with dialup/cable for upstream involved loading of software into > your PC. > That software could EASILY have encapsulated the upstream packets into > UDP packets so that their upstream packets were valid. > > >Customers dial-up to an ISP and downstream traffic returns via the sat > >connection. Reverse-path immediately disables every one of these > >customers. Qwest deployed this on us with no notice and killed off > >thousands of customers in one fell swoop. > > > >Although I agree with the principal, the implentation needs more > >thought than a simple 'turn it on for 100%'. > > The documents leading up to BCP38 began in 1996. This didn't just happen > out of the blue. Some assumptions made by more than one group that > routing decisions would forever be made based on destination IP address > only. > > One of these was mobile IP, and that WG worked on an alternative as soon > as the ingress filtering draft started gaining momentum. Tunnels are a > good answer where legitimate traffic has to flow in a way that does not > match the addressing topology. > > Having this dropped on you by Qwest without warning was a bad thing. I > wonder if you asked them to temporarily undo it while while you worked > with the vendor (Hughes in this case) to implement tunneling of the > return traffic? > > > >-----Original Message----- > >From: [email protected] [mailto:[email protected]] On Behalf Of > > >Alexei Roudnev > >Sent: Thursday, June 03, 2004 1:40 AM > >To: Jon R. Kibler; [email protected] > >Subject: Re: Real-Time Mitigation of Denial of Service Attacks Now > >Available With AT&T > > > > > >You even do not need to maintain ACL - many routers have 'back-path > >verification' feature. > >I wonder, why DSL and other 'consumer level' providers are not doing it > > >for 100% of their customers. > > > > > >----- Original Message ----- > >From: "Jon R. Kibler" <[email protected]> > >To: <[email protected]> > >Sent: Wednesday, June 02, 2004 8:25 AM > >Subject: Re: Real-Time Mitigation of Denial of Service Attacks Now > >Available With AT&T > > > > > > > John Obi wrote: > > > > ... since DDoS is the > > > > nightmare of the internet now. > > > > > > > > > > The sad fact is that simple ingress and egress filtering would > > > eliminate the majority of bogus traffic on the Internet -- including > > > > (D)DoS attacks. If all ISPs would simply drop all outbound packets > > > whose source address is not a valid IP for the subnet of origin, and > > > > all inbound packets that do not have valid source IP addresses, the > > > DDoS problem would be (for all intents and purposes) fixed. If > > > proper filtering was done, then any DoS attacks would have to have > > > either valid source IP addresses, or IP addresses that spoofed IPs > > > within their network of origin. In either case, identifying and > > > shutting down the attackers would become a greatly simplified task > > > compared to the mess it is today. > > > > > > Why no filtering by ISPs? "Because it takes resources and only > >benefits > > > the other guy" -- unless your network is the one under attack. > > > > > > Maintenance of the ACLs should not be the issue. A single ACL for > > > each subnet would be all that would be required for egress > > > filtering. About 30 ACLs on an inbound border router would be > > > required for ingress filtering. Keeping the ingress ACLs current is > > > a brain-dead task -- > >just > > > subscribe to the bogon mailing list at cymru.com. > > > > > > ACLs have had a bad reputation for greatly slowing down routers. > > > That may have been true in the past, but properly written ACLs do > > > not seem to have a significant impact on most new routers. Yes, they > > > > may cut peak through-put a few percent -- but if you are running > > > that close to the edge, it is time to upgrade anyway. > > > > > > IMHO, there is absolutely no excuse for not doing ingress and egress > > > > filtering. In fact, if you are an ISP, I would argue that you are > > > negligent in your fiduciary responsibilities to your customers and > > > shareholders if you are not filtering source IP addresses. > > > > > > Fancy solutions may make great marketing, but simple proper router > > > filtering is a very workable lower-cost solution. > > > > > > (Step down from soap box.) At least, that's my $0.02 worth. > > > > > > Jon Kibler > > > -- > > > Jon R. Kibler > > > Chief Technical Officer > > > A.S.E.T., Inc. > > > Charleston, SC USA > > > (843) 849-8214 > > > > > > > > > > > > > > > ================================================== > > > Filtered by: TRUSTEM.COM's Email Filtering Service > > > http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email. > > > > > > >
|