I think that there's some lack of clarity on the problem here. Anyone can
stream packets at ANY router and take it down. If it's not ICMP, you can
simply forge routing protocol packets. It's a question of simply
supersaturating the system. To truly deal with DoS attacks, there are
basically three approaches:
Indeed. For instance SYN-flood the BGP port.
1) Throw money at the problem. Build a big box that has enough processor
to deal with the incoming bandwidth for pessimal packets. Even then, the
bad guys can simply supersaturate the incoming bandwidth.
2) Deal with it statistically. For example, most folks for the recent syn
attacks will drop syns if they don't complete reasonably, thereby allowing
some percentage of real traffic to get through.
3) Deal with it legally. This is what the telco's do. It implies that we
would need real mechanisms for tracking down offenders.
Can I have 2(a) - deal with it statistically and intelligently. TCP/IP
stacks which have got far greater public flak than Cisco's (Solaris 2.4
for instance) do not die when sent 128kb/s of ICMP. As I understand it
11.1 allows access lists based on icmp packet type, and this filtering
is already done off CPU. So "all" the CPU has to do is block ICMPs
from particular hosts, or (even) ICMP at all, if it is being flooded.
As to what cisco will do, you should probably ask cisco.
I did. They said "the problem doesn't exist". I am circulating the problem
(before, like SYN flods, it becomes a serious operational problem) to those
with larger annual Cisco spend than me.
Background to bug: We discovered this when we had 2 telco lines running
in parallel and wanted to check the performance of one from a host behind
one router, and had no hosts of our own behind the other router. Naively
we thought pinging the other (NAP) router would be a good test with our
stochastic bandwidth modeling tool, which is based on ICMP. Rather an
unpleasant thing happened to our transit. Just wait until someone decides
you should measure your ISPs performance by running
ping -s 1000 mae-east.sprintlink.net
(8kb/s). Now get 16 people doing it at once, and ...
Alex Bligh
Xara Networks
Correct me if I'm wrong but to the best of my recollection, in
order for a packet to be accepted on the BGP port, it must be originating
from a configured BGP peer. Since the SYN flood method relies on the
attack originating from an unreachable (yet routable) address, it would
seem that this approach will fail.
rfc-1771:
If the local system detects that a remote peer is trying to
establish BGP connection to it, and the IP address of the
remote peer is not an expected one, the local system restarts
the ConnectRetry timer, rejects the attempted connection,
continues to listen for a connection that may be initiated by
the remote BGP peer, and stays in the Active state.
-Ophir
Wouldn't it be more effective to run
ping -s 1000 sty.cisco.com ? 
Michael Dillon - Internet & ISP Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
Indeed. For instance SYN-flood the BGP port.
Correct me if I'm wrong but to the best of my recollection, in
order for a packet to be accepted on the BGP port, it must be originating
from a configured BGP peer. Since the SYN flood method relies on the
attack originating from an unreachable (yet routable) address, it would
seem that this approach will fail.
If you're out for a true DoS attack, it need not even be a SYN attack.
Simply flooding the BGP port would be quite enough to bring the system to
its knees. Forge a known peer's source address, and even the CPU that it
burns testing for authentication and discarding packets would be enough to
be fatal.
The important point is that you can't distinguish the good from the bad
without a whole lot of work.
Tony
Can I have 2(a) - deal with it statistically and intelligently. TCP/IP
stacks which have got far greater public flak than Cisco's (Solaris 2.4
for instance) do not die when sent 128kb/s of ICMP. As I understand it
11.1 allows access lists based on icmp packet type, and this filtering
is already done off CPU. So "all" the CPU has to do is block ICMPs
from particular hosts, or (even) ICMP at all, if it is being flooded.
You can have anything you like ... at Alice's Restaurant.
Assuming we're still talking about a 7010, I suspect that you could do
incoming ICMP filtering in the SSE and discard those. But then the bad
guys simply attack your BGP port to circumvent your filters. And the
filters are not intelligent enough to perform the authentication
computation.
I'm surprised it's as low as 128kb/s. It should be more around 2kpps. Not
that this is a stretch.
I did. They said "the problem doesn't exist".
What? And you didn't believe them?
I suspect that a better approach is to contact the people with clue
directly.... it sounds like you went through TAC.
Tony