Well, the ranges...
164.128.116.0
164.128.119.0
164.128.122.0
164.128.123.0
164.128.57.0
164.128.81.0
...are ours, and they are used in our backbone infrastructure. I was a bit
surprised to see some of our backbone addresses on the list, because a few
weeks back I went around all of the potential amplifiers and configured no
ip directed-broadcast.
I turns out that the ranges mentioned are all used to address serial access
lines to customers - they are all /30 or /32.
I have a bit of a problem with blocking of address ranges that really
cannot be used as significant amplifiers. We take our responsibilities an
ISP seriously: we have blocked all LANs that are connected by fat pipes
and/or have large amplification factors, and we have started configuring
'no ip directed-broadcast' on ALL interfaces as a matter of standard. But
we have several hundred legacy /30 interfaces that can't be reconfigured
overnight.
While I support the sentiment that ISPs responsible for large amplifiers
should be blocked until they take action, I feel that the decision to block
an address range should actually be tempered by an assessment of how
damaging an amplifier the address block represents. If a smurf attack is
detected from an address range, is it really that difficult to check what
the amplification factor is before deciding if it should go onto a blocking
list? I would certainly suggest that /30s should not be blocked, since they
are so numerous and the damage they can cause is limited.
How about a compromise: two lists - one of known smurf amplifier ranges >
/30, which are blocked, and another of ranges where the amplifiers are =<
/30, and which are no blocked, but simply publicised?
As another thought, maybe what we need is a rough 'smurf effectivness
metric' composed of amplification factor and access bandwidth. If address
ranges only get onto the list because an attack has been sourced from them,
then it should be possible to approximate these numbers.
Phil