Faulty Rules Foul Router Protection

Computerworld - This week, my team and I discovered a vulnerability in the Cisco Systems Inc. equipment we use in our global network. There are 253 possible IP-based protocols in IP Version 4, and the majority of Cisco routers and switches have a serious problem with four of them. The flaw leaves unpatched equipment open to denial-of-service attacks.
Once the Cisco device receives a certain number of IP packets of Type 53, 55, 77 or 103, it stops functioning. If a switch or router doesn't know what to do with a given packet, it just leaves it in the queue until the queue fills up and the device stops working.
The first reports of this vulnerability made it clear that the packets had to be targeted at the router being attacked in order to succeed. I immediately thought we would be fine, since our core routers have access-control lists (ACL). We set these up to operate like a minifirewall that can allow and deny various kinds of traffic.
To protect our routers, we set a rule that routers accept specific traffic types coming only from our internal management machines. We don't bother listing every kind of bad data. Instead, we drop everything except the handful of things we need. So our routers drop those four vulnerable protocols without processing them, along with every other IP-based protocol except TCP and the User Datagram Protocol.
This meant we didn't have to do anything. Or did it? We checked our internal routers to make sure the right protections were in place and then performed the same check on our Internet-facing routers. Our firewall drops the four protocols mentioned earlier, so it would be difficult for someone to attack our internal routers. However, the external routers that connect to multiple Internet service providers have to be outside the firewall, and so they might accept those protocols if they were misconfigured.
I checked our external-facing routers from a remote provider's site, connecting to each and scanning to see on which protocols and ports the routers were listening, and I was very surprised when one answered on Telnet.
We use Telnet to manage some of our routers because not all versions of Cisco's Internetworking Operating System (IOS) support Secure Shell, our preferred encryption method. But Telnet wasn't supposed to accept connections from outside our company. The router's ACL should have limited connections to only those from authorized devices with addresses internal to our network.
As it turned out, the ACL had been applied correctly, and other traffic was