Real-Time Mitigation of Denial of Service Attacks Now Available With AT&T

Thu Jun 3 14:00:37 UTC 2004

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:dts at senie.com] 
Sent: Thursday, June 03, 2004 9:20 AM
To: Krichbaum, Eric; nanog at merit.edu
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: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of

>Alexei Roudnev
>Sent: Thursday, June 03, 2004 1:40 AM
>To: Jon R. Kibler; nanog at merit.edu
>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" <Jon.Kibler at aset.com>
>To: <nanog at merit.edu>
>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.
> >
> >