NAP/ISP Saturation WAS: Re: Exchanges that matter...

   The fact remains that a ping packet stream a Linux 386SX would barely
   notice maxes out a 7010 (far more powerful CPU)

Bzzzt. That's a 30Mhz 68040 you're talking about. You're 386SX is on par
if not ahead.

Well I'd have said 68030~=386SX but anyway...

And you might recall that it's handled at process level,
whereas Linux does it at kernel level (or at least other Unixen do).

Well this is the real point isn't it. Though Cisco has obviously paid
an awful lot of attention to switching packets fast its host IP stack
seems to be particularly bad compared to something built with a decent
TCP/IP stack. If Cisco don't implement ICMP response in some sort
of kernel layer below "application" layers handling other such functions
the obvious question is "why not?". It must be possible to do this - just
take your Netstar and downgrade the processor to a 386SX and see if it
still works (fast external switching engine, slow processor).

   Rather and obvious DoS attack, and one which even MS were red faced
   enough to fix in their NT s/w pretty sharpish.

You can DoS attack anything with echos. Trying to make echo handling "fast
enough" is an untenable problem. So you should simply drop them on the
floor...

I believe Microsoft's response was (a) to handle ICMP echos further down
in the kernel or at least without breaking upper layers quite so much and
(b) to drop ICMPs if they arrived too often. I did *not* say Cisco should
answer all ICMP echo requests, just not break (or try and avoid it).
"Even" Solaris has things to tweak ICMP response. With all respect (as
you know far more about Cisco inards than I do) this sounds very like
people at certain OS vendors who said "SYN flood attacks, ah yes, well
such DoS attacks are inevitably extremely difficult to prevent". Indeed.
But will it really take someone ICMP streaming with forged source addresses
at Sprint's core routers for Cisco to fix it?

Alex Bligh
Xara Networks

If Cisco don't implement ICMP response in some sort
   of kernel layer below "application" layers handling other such functions
   the obvious question is "why not?". It must be possible to do this - just
   take your Netstar and downgrade the processor to a 386SX and see if it
   still works (fast external switching engine, slow processor).

It is indeed possible. However, it will not "solve" the problem. Note
that the major impact of doing things at process level is pulling the
entire packet across the bus. Just putting it in the "kernel" (i.e.,
during fast switching, in interrupt context) would be far less interesting
than eliminating the bus copy. Of course, if you eliminate that, then you
increase buffer occupancy.

   I believe Microsoft's response was (a) to handle ICMP echos further down
   in the kernel or at least without breaking upper layers quite so much and

The upper layers will break regardless. That's part of life with a real
time control system. Even if you handle it in the kernel, you're consuming
the system.

   (b) to drop ICMPs if they arrived too often. I did *not* say Cisco should
   answer all ICMP echo requests, just not break (or try and avoid it).
   "Even" Solaris has things to tweak ICMP response. With all respect (as
   you know far more about Cisco inards than I do) this sounds very like
   people at certain OS vendors who said "SYN flood attacks, ah yes, well
   such DoS attacks are inevitably extremely difficult to prevent". Indeed.
   But will it really take someone ICMP streaming with forged source addresses
   at Sprint's core routers for Cisco to fix it?

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:

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.

Now, if you truly believe that you want solution 1, you should show up at
your favorite router vendor with a large box o' cash. Probably 10X what
you're currently paying. Solution 2 is fine for a bit, but is less certain
because it implies that you can quickly and easily differentiate beneficial
traffic from detrimental traffic. Solution 3 is by far the easiest and
cheapest, but it requires cooperation.

As to what cisco will do, you should probably ask cisco.

Tony

3) Deal with it legally. This is what the telco's do. It implies that we
would need real mechanisms for tracking down offenders.

  Personally, I'd like to see a protocol that allows you to ask a
router to which you were directly connected to stamp an interface ID on
all incoming packets bound for a particular network. You could then trace
back router by router, interface by interface, where the packets were
entering a block of cooperating providers.

  Thus if I saw an incoming flood of SYN packets or ICMP echoes
with forged origin addresses, I could ask my router to ask all its direct
peers to begin stamping interface numbers (and/or interface IPs) on the
packets they send to me. My router would eat those numbers/IPs so traffic
would appear unaffected.

  Then my tracing tool would know which interface the packets were
coming in on and could ask that router to do the same thing (on a
hop-by-hop basis for security reasons). Thus I could track it back to a
specific enough interface path that perhaps an automated method to
install a filter would be sufficient.

  This stuff needs a lot of work, but might be a direction that
would both facilitate emergency filtering and effective tracing for IP
packets with forged origin addresses -- assuming the packets have enough
in common to allow them to be detected (all pings, or heavy load, or all
to same destination IP).

  David Schwartz