RE: Real-Time Mitigation of Denial of Service Attacks Now Available With AT&T
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@senie.com] Sent: Thursday, June 03, 2004 9:20 AM To: Krichbaum, Eric; nanog@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@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of
Alexei Roudnev Sent: Thursday, June 03, 2004 1:40 AM To: Jon R. Kibler; nanog@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@aset.com> To: <nanog@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.
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@senie.com] Sent: Thursday, June 03, 2004 9:20 AM To: Krichbaum, Eric; nanog@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@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of
Alexei Roudnev Sent: Thursday, June 03, 2004 1:40 AM To: Jon R. Kibler; nanog@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@aset.com> To: <nanog@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.
participants (2)
-
Christian Malo -
Krichbaum, Eric