Why is it that the NSPs I've encountered refuse to do any sort of sanity filtering on their customer connections? i.e. If UUNet knows that FDT has only 205.229.48/20 and 208.215.0/20, why should they let me send traffic through their network with random source addresses? FDT has been the target of forged source address UDP attacks for the past 2 days. It's all being stopped at our router that takes our UUNet T1, but the extra T1 traffic is causing UUNet's usually unreliable network to be even less reliable, and we've lost connectivity to UUNet several times this evening. 5 minute input rate 1326000 bits/sec, 318 packets/sec 5 minute output rate 469000 bits/sec, 286 packets/sec PUNet suppost says there's nothing they can do, and that I should talk to their security people about buying a firewall for FDT on monday...like a firewall on our side of the T1 is going to do us a lot of good.... ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
FYI, this type of ingress filtering has been documented in draft-ferguson-ingress-filtering-02.txt. - paul At 09:44 PM 07/11/97 -0400, Jon Lewis wrote:
Why is it that the NSPs I've encountered refuse to do any sort of sanity filtering on their customer connections? i.e. If UUNet knows that FDT has only 205.229.48/20 and 208.215.0/20, why should they let me send traffic through their network with random source addresses?
FDT has been the target of forged source address UDP attacks for the past 2 days. It's all being stopped at our router that takes our UUNet T1, but the extra T1 traffic is causing UUNet's usually unreliable network to be even less reliable, and we've lost connectivity to UUNet several times this evening.
5 minute input rate 1326000 bits/sec, 318 packets/sec 5 minute output rate 469000 bits/sec, 286 packets/sec
PUNet suppost says there's nothing they can do, and that I should talk to their security people about buying a firewall for FDT on monday...like a firewall on our side of the T1 is going to do us a lot of good....
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
Jon,
From provider side of things they have more packets to fly than that of FDT. The more one has to filter, the less cpu there is to route packets.. I suspect that this may be the only cause...
regards, -dave On Fri, 11 Jul 1997, Jon Lewis wrote:
Why is it that the NSPs I've encountered refuse to do any sort of sanity filtering on their customer connections? i.e. If UUNet knows that FDT has only 205.229.48/20 and 208.215.0/20, why should they let me send traffic through their network with random source addresses?
FDT has been the target of forged source address UDP attacks for the past 2 days. It's all being stopped at our router that takes our UUNet T1, but the extra T1 traffic is causing UUNet's usually unreliable network to be even less reliable, and we've lost connectivity to UUNet several times this evening.
5 minute input rate 1326000 bits/sec, 318 packets/sec 5 minute output rate 469000 bits/sec, 286 packets/sec
PUNet suppost says there's nothing they can do, and that I should talk to their security people about buying a firewall for FDT on monday...like a firewall on our side of the T1 is going to do us a lot of good....
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
Dave Pokorney wrote:
Jon,
From provider side of things they have more packets to fly than that of FDT. The more one has to filter, the less cpu there is to route packets.. I suspect that this may be the only cause...
If a router is designed to allow handling of packet filtering efficiently, then it CAN be done without undue loading. Perhaps you're all using equipment and software that doesn't permit filtering at line speeds. If that's the case, then INSIST that this be changed in the next version of software or hardware you buy. Perhaps my co-author of the ingress draft can comment, but I thought Cisco was implementing packet filtering on the switch processor cards to allow just this kind of filtering. Since I don't use Cisco gear (they're our competitor), I don't have all the scoop there. Another thing I'd like folks to consider. Many of you manage the routers at customer sites. I would guess that in most cases, folks forging IP addresses are NOT the folks who have access to routers at a site. If you, as an ISP, manage the router at the customer end of a circuit, ADD FILTERS THERE! Make sure that packets transmitted from the customer's router to your network are VALID addresses. The router at a customer site plugged into a T1 should be able to filter outbound packets at T1 speeds without trouble. If the routers you're using out there can't handle that speed, then you're using the wrong gear. One way or another, both ISP's and customers must take responsibilty for forged addresses. If the network community will not take responsibility for this, I fear the courts may ultimately step in. Let's use the technology we have, and develop additional technology as needed, rather than risk legal intervention. Dan Senie OpenROUTE Networks, Inc.
regards, -dave
On Fri, 11 Jul 1997, Jon Lewis wrote:
Why is it that the NSPs I've encountered refuse to do any sort of sanity filtering on their customer connections? i.e. If UUNet knows that FDT has only 205.229.48/20 and 208.215.0/20, why should they let me send traffic through their network with random source addresses?
FDT has been the target of forged source address UDP attacks for the past 2 days. It's all being stopped at our router that takes our UUNet T1, but the extra T1 traffic is causing UUNet's usually unreliable network to be even less reliable, and we've lost connectivity to UUNet several times this evening.
5 minute input rate 1326000 bits/sec, 318 packets/sec 5 minute output rate 469000 bits/sec, 286 packets/sec
PUNet suppost says there's nothing they can do, and that I should talk to their security people about buying a firewall for FDT on monday...like a firewall on our side of the T1 is going to do us a lot of good....
------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
-- ------------------------------------------------------- Daniel Senie dts@openroute.com OpenROUTE Networks, Inc. http://www.openroute.com/ 508-898-2800
On Sat, 12 Jul 1997, Daniel Senie wrote:
Another thing I'd like folks to consider. Many of you manage the routers at customer sites. I would guess that in most cases, folks forging IP addresses are NOT the folks who have access to routers at a site. If you, as an ISP, manage the router at the customer end of a circuit, ADD FILTERS THERE! Make sure that packets transmitted from the customer's router to your network are VALID addresses. The
FDT has an office with a Sprint/Centel T1 in which Sprint supplies and maintains the router at our end...an intollerable situation, but that's another story. The topic of access-list filters has come up many times, and Sprint refused to add any filters to the 2501 at our end, and would not give FDT access to it in any way. I noticed they were doing no filtering whatsoever, and promptly gave them some real life examples of why egress filtering is a good thing by forging packets into their NOC. They proved their cluelessness by adding tcp and udp egress filters, rather than just ip. Last time I tried, I could still forge icmp from tlh. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ________Finger jlewis@inorganic5.fdt.net for PGP public key_______
Jon Lewis writes...
Why is it that the NSPs I've encountered refuse to do any sort of sanity filtering on their customer connections? i.e. If UUNet knows that FDT has only 205.229.48/20 and 208.215.0/20, why should they let me send traffic through their network with random source addresses?
I'm assuming that they don't want to overload their router with all that extra filtering, especially on the interface inbounds. OTOH, I've always believed that all routers should be required to apply routing decisions first to the source address and determine if the interface it arrived on is at least a valid return path (not necessarily best) and if not, drop the packet. Then do the destination work. Again, too much work for the routers to do. But then, I wonder how much work they are doing routing source forged packets and other denial of service traffic. -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
Phil Howard wrote:
Jon Lewis writes...
Why is it that the NSPs I've encountered refuse to do any sort of sanity filtering on their customer connections? i.e. If UUNet knows that FDT has only 205.229.48/20 and 208.215.0/20, why should they let me send traffic through their network with random source addresses?
I'm assuming that they don't want to overload their router with all that extra filtering, especially on the interface inbounds.
There's more to consider. The choice of routing gear and router software can allow filtering without adversely affecting performance.
OTOH, I've always believed that all routers should be required to apply routing decisions first to the source address and determine if the interface it arrived on is at least a valid return path (not necessarily best) and if not, drop the packet. Then do the destination work.
We considered this in the first published draft of: draft-ferguson-ingress-filtering-02.txt but ultimately removed this from the text. The return path is often not the same as the forward path, thanks to the BGP policies through the core routers. In many cases, alternate paths will not be known.
Again, too much work for the routers to do.
No. It IS work, but a router and/or router software designed to handle this capability is NOT a hard thing. If that's an important feature, then the hardware and software CAN be designed that perform these functions efficiently. -- ------------------------------------------------------- Daniel Senie dts@openroute.com OpenROUTE Networks, Inc. http://www.openroute.com/ 508-898-2800
participants (5)
-
Daniel Senie -
Dave Pokorney -
Jon Lewis -
Paul Ferguson -
Phil Howard