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

Thu Jun 3 15:19:22 UTC 2004

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: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.
> > >
> > >
>