Scaled Back Cybersecuruty

: One of the criticisms of the change relative to this group
: is that the previous stronger wording for the network
: operator industry was watered down. Instead of
: expecting/demanding/mandating that the industry collaborate
: on network security (creating an ISAC and other measures),
: the latest draft simply recommends that the industry
: consider these measures.

: Is there anything happening with collaborative security
: policy and remediation in the industry? Has any effort
: showed progress towards an effective ISAC or similar? Can
: networks realistically collaborate on security, or do the
: political and operational barriers not justify the effort?

: Pete.

Anything should of an action plan involving money or regulation
is a very weak policy. Suggestions have never had much of an
effect on Internet operators.

I guess the real question is: What is going to happen over the
next few years to get the infrastructure of the Internet to be more
robust? I don't see market forces doing it. I don't suggest that
the government use regulation, either.

Perhaps the Feds (and maybe states) could use their purchasing power
to effect change. Short of that, or regulation, the I don't see how
the serious issues we have with the 'net will get resolved.

I suppose that the "problem" is likely that people don't understand
what a nice actually well-written worm could/would do if it were
targeted at the infrastructure.

Avi

[ SNIP ]

I suppose that the "problem" is likely that people don't understand
what a nice actually well-written worm could/would do if it were
targeted at the infrastructure.

If any operator doesn't believe it's coming, then I
think they can safely be labeled naive.

Even then, nothing is for free.

-M

All of the initiatives (only a couple) I've found related to
Internet operator security collaboration all appear to be
pre 2000. At the May 2001 NANOG, which specifically focused
on networking security, there was no presentation or
(significant) discussion about inter-operator security
collaboration.

I was hoping to find that due to increased focus on
infrastructure security post 9-11, there would actually have
been increased activity in this area. Though there's
certainly increased interest (probably more on the part of
customers and government) I have not been able to find any
evidence of increased activity. If anything, it /appears/
that generally inter-operator cooperation is actually
decreasing. This may be a result of the competitive and
financial changes in the market.

This is alarming, considering the increase in attacks
against infrastructure, and the sophistication of attacks
over the last year. And we still use basically the same
ineffective techniques to counteract and track attacks that
became household words two years ago.

I suspect a very effective worm would change this pretty
quickly, most likely through onerous regulation. It's
surprising that it hasn't happened already.

Pete.

Avi Freedman <freedman@freedman.net> writes:

Perhaps the Feds (and maybe states) could use their purchasing power
to effect change. Short of that, or regulation, the I don't see how
the serious issues we have with the 'net will get resolved.

I suppose that the "problem" is likely that people don't understand
what a nice actually well-written worm could/would do if it were
targeted at the infrastructure.

People do. I've been beating this particular horse for a while now,
and we are starting to deploy the capex hammer. I suggest others start
to do the same. See my presentation at the eugene nanog.

/vijay

This is alarming, considering the increase in attacks
against infrastructure, and the sophistication of attacks
over the last year. And we still use basically the same
ineffective techniques to counteract and track attacks that
became household words two years ago.

yes.

I suspect a very effective worm would change this pretty
quickly, most likely through onerous regulation. It's
surprising that it hasn't happened already.

i've had absolutely no luck getting the source isp's to care about
the problems i've seen at my home firewall in recent weeks. (see
below if you wonder whether i'm implicating anyone here.) there's
no other way to view the internet than as a worm-infested zombie.

(this is a grep of just the port scans and attacks against ftp here.)

Jan 1 18:40:44 fwlha /kernel: ipfw: 1800 Deny TCP 64.139.35.209:2559 204.152.184.163:21 in via dc0
Jan 1 18:41:32 fwlha /kernel: ipfw: 1800 Deny TCP 64.139.35.209:3478 204.152.188.62:21 in via dc0
Jan 3 06:15:19 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2113 204.152.184.163:57 in via dc0
Jan 3 06:15:37 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2595 204.152.184.163:21 in via dc0
Jan 3 06:15:40 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2595 204.152.184.163:21 in via dc0
Jan 4 09:02:17 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:4992 204.152.184.163:21 in via dc0
Jan 4 09:02:20 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:3314 204.152.184.163:21 in via dc0
Jan 4 09:03:08 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:3590 204.152.188.62:21 in via dc0
Jan 4 12:00:21 fwlha /kernel: ipfw: 1800 Deny TCP 61.187.223.85:4452 204.152.184.163:135 in via dc0
Jan 4 14:31:22 fwlha /kernel: ipfw: 1800 Deny TCP 203.44.175.56:21 204.152.184.163:21 in via dc0
Jan 4 14:31:29 fwlha /kernel: ipfw: 1800 Deny TCP 203.44.175.56:21 204.152.188.62:21 in via dc0
Jan 4 23:06:51 fwlha /kernel: ipfw: 1800 Deny TCP 81.50.67.165:1839 204.152.184.163:21 in via dc0
Jan 4 23:06:54 fwlha /kernel: ipfw: 1800 Deny TCP 81.50.67.165:1839 204.152.184.163:21 in via dc0
Jan 4 23:12:31 fwlha /kernel: ipfw: 1800 Deny TCP 81.50.67.165:2765 204.152.188.62:21 in via dc0
Jan 5 01:35:21 fwlha /kernel: ipfw: 1800 Deny TCP 24.204.53.253:3903 204.152.184.163:80 in via dc0
Jan 5 04:28:47 fwlha /kernel: ipfw: 1800 Deny TCP 202.96.237.247:4425 204.152.184.163:21 in via dc0
Jan 5 04:53:48 fwlha /kernel: ipfw: 1800 Deny TCP 12.102.38.251:1865 204.152.184.163:21 in via dc0
Jan 5 04:54:48 fwlha /kernel: ipfw: 1800 Deny TCP 12.102.38.251:2368 204.152.188.62:21 in via dc0
Jan 5 11:13:21 fwlha /kernel: ipfw: 1800 Deny TCP 12.212.111.82:1861 204.152.188.62:1433 in via dc0
Jan 10 15:35:21 fwlha /kernel: ipfw: 1800 Deny TCP 218.216.228.24:2258 204.152.184.163:445 in via vlan0
Jan 11 00:14:57 fwlha /kernel: ipfw: 1800 Deny TCP 217.57.93.19:54706 204.152.184.163:21 in via vlan0
Jan 11 00:16:31 fwlha /kernel: ipfw: 1800 Deny TCP 217.57.93.19:59226 204.152.188.62:21 in via vlan0
Jan 11 15:43:23 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.153.5:44688 204.152.184.163:21 in via vlan0
Jan 11 15:44:21 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.153.5:46979 204.152.188.62:21 in via vlan0
Jan 12 20:22:21 fwlha /kernel: ipfw: 3700 Deny TCP 207.1.8.15:2628 204.152.184.163:27374 in via vlan0
Jan 12 20:22:21 fwlha /kernel: ipfw: 3700 Deny TCP 207.1.8.15:2665 204.152.184.163:12345 in via vlan0
Jan 12 21:35:21 fwlha /kernel: ipfw: 4000 Deny TCP 209.237.238.161:1261 204.152.184.73:80 in via vlan0
Jan 12 21:35:21 fwlha /kernel: ipfw: 4000 Deny TCP 209.237.238.164:4200 204.152.184.73:80 in via vlan0
Jan 12 21:35:21 fwlha /kernel: ipfw: 4000 Deny TCP 209.237.238.165:4791 204.152.184.73:80 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3539 204.152.188.1:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3540 204.152.188.2:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3541 204.152.188.3:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3542 204.152.188.4:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3543 204.152.188.5:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3544 204.152.188.6:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3545 204.152.188.7:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3546 204.152.188.8:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3547 204.152.188.9:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3548 204.152.188.10:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3549 204.152.188.11:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3550 204.152.188.12:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3551 204.152.188.13:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3552 204.152.188.14:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3553 204.152.188.15:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3554 204.152.188.16:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3555 204.152.188.17:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3556 204.152.188.18:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3557 204.152.188.19:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3558 204.152.188.20:21 in via vlan0
Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3559 204.152.188.21:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3560 204.152.188.22:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3561 204.152.188.23:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3562 204.152.188.24:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3563 204.152.188.25:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3565 204.152.188.27:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3566 204.152.188.28:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3567 204.152.188.29:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3568 204.152.188.30:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3569 204.152.188.31:21 in via vlan0
Jan 12 23:21:17 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3601 204.152.188.62:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3539 204.152.188.1:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3540 204.152.188.2:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3541 204.152.188.3:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3542 204.152.188.4:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3543 204.152.188.5:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3544 204.152.188.6:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3545 204.152.188.7:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3546 204.152.188.8:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3547 204.152.188.9:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3548 204.152.188.10:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3549 204.152.188.11:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3550 204.152.188.12:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3552 204.152.188.14:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3551 204.152.188.13:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3553 204.152.188.15:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3554 204.152.188.16:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3555 204.152.188.17:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3557 204.152.188.19:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3556 204.152.188.18:21 in via vlan0
Jan 12 23:21:19 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3558 204.152.188.20:21 in via vlan0
Jan 13 03:40:28 fwlha /kernel: ipfw: 6200 Deny TCP 204.152.187.70:1492 204.152.188.18:21 in via vlan0
Jan 13 03:43:22 fwlha /kernel: ipfw: 6100 Unreach TCP 204.152.187.70:1497 204.152.188.18:21 in via vlan0
Jan 13 04:15:40 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4252 204.152.184.143:21 in via vlan0
Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4104 204.152.184.71:21 in via vlan0
Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4109 204.152.184.73:21 in via vlan0
Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4137 204.152.184.82:21 in via vlan0
Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4157 204.152.184.93:21 in via vlan0
Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4167 204.152.184.99:21 in via vlan0
Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4177 204.152.184.104:21 in via vlan0
Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4186 204.152.184.110:21 in via vlan0
Jan 13 04:15:43 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:4252 204.152.184.143:21 in via vlan0
Jan 13 04:15:45 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:4811 204.152.184.163:21 in via vlan0
Jan 13 04:15:48 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:4811 204.152.184.163:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2023 204.152.188.1:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2025 204.152.188.2:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2028 204.152.188.3:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2029 204.152.188.4:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2030 204.152.188.5:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2032 204.152.188.6:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2034 204.152.188.7:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2036 204.152.188.8:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2041 204.152.188.9:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2042 204.152.188.10:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2043 204.152.188.11:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2044 204.152.188.12:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2052 204.152.188.13:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2056 204.152.188.14:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2057 204.152.188.15:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:2060 204.152.188.16:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2061 204.152.188.17:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2065 204.152.188.18:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2067 204.152.188.19:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2070 204.152.188.20:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2073 204.152.188.21:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2077 204.152.188.22:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2080 204.152.188.23:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2081 204.152.188.24:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2084 204.152.188.25:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2090 204.152.188.27:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2091 204.152.188.28:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2092 204.152.188.29:21 in via vlan0
Jan 13 04:17:20 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2096 204.152.188.31:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2023 204.152.188.1:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2025 204.152.188.2:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2028 204.152.188.3:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2029 204.152.188.4:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2030 204.152.188.5:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2032 204.152.188.6:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2034 204.152.188.7:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2036 204.152.188.8:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2041 204.152.188.9:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2042 204.152.188.10:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2043 204.152.188.11:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2044 204.152.188.12:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2052 204.152.188.13:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2056 204.152.188.14:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2057 204.152.188.15:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:2060 204.152.188.16:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2061 204.152.188.17:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2065 204.152.188.18:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2067 204.152.188.19:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2070 204.152.188.20:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2073 204.152.188.21:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2077 204.152.188.22:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2084 204.152.188.25:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2090 204.152.188.27:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2091 204.152.188.28:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2092 204.152.188.29:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2094 204.152.188.30:21 in via vlan0
Jan 13 04:17:23 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2096 204.152.188.31:21 in via vlan0
Jan 13 04:17:24 fwlha /kernel: ipfw: 3500 Unreach TCP 80.128.237.81:2162 204.152.188.62:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2030 204.152.188.5:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2029 204.152.188.4:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2028 204.152.188.3:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2025 204.152.188.2:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2057 204.152.188.15:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2056 204.152.188.14:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2052 204.152.188.13:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2044 204.152.188.12:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2043 204.152.188.11:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2042 204.152.188.10:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2041 204.152.188.9:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2036 204.152.188.8:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2034 204.152.188.7:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2081 204.152.188.24:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2080 204.152.188.23:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2073 204.152.188.21:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2070 204.152.188.20:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2067 204.152.188.19:21 in via vlan0
Jan 13 04:17:29 fwlha /kernel: ipfw: 6100 Unreach TCP 80.128.237.81:2061 204.152.188.17:21 in via vlan0
Jan 13 07:21:57 fwlha /kernel: ipfw: 3500 Unreach TCP 217.141.146.245:4524 204.152.184.163:1433 in via vlan0
Jan 13 07:21:59 fwlha /kernel: ipfw: 3500 Unreach TCP 217.141.146.245:4524 204.152.184.163:1433 in via vlan0
Jan 13 14:43:21 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:4049 204.152.184.163:57 in via vlan0
Jan 13 14:43:33 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:4970 204.152.184.163:21 in via vlan0
Jan 13 14:43:36 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:4970 204.152.184.163:21 in via vlan0
Jan 13 14:43:37 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1036 204.152.188.16:21 in via vlan0
Jan 13 14:43:37 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1061 204.152.188.62:21 in via vlan0
Jan 13 14:43:40 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1036 204.152.188.16:21 in via vlan0
Jan 13 14:43:40 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1061 204.152.188.62:21 in via vlan0
Jan 13 14:43:42 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:4970 204.152.184.163:21 in via vlan0
Jan 13 14:43:46 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1036 204.152.188.16:21 in via vlan0
Jan 13 14:43:46 fwlha /kernel: ipfw: 3500 Unreach TCP 204.27.104.169:1061 204.152.188.62:21 in via vlan0
Jan 14 05:25:58 fwlha /kernel: ipfw: 1610 Deny TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:26:06 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:26:07 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:26:07 fwlha /kernel: ipfw: 1610 Deny TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:26:07 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:26:09 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:26:09 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:26:12 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:26:14 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:26:14 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:26:17 fwlha /kernel: ipfw: 1610 Deny TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:26:17 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:26:17 fwlha /kernel: ipfw: 1610 Deny TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:26:24 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:26:25 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:26:27 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1744 204.152.188.26:21 in via vlan0
Jan 14 05:26:28 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:26:29 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1744 204.152.188.26:21 in via vlan0
Jan 14 05:27:07 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:27:16 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:27:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.12:53 204.152.188.26:53 in via vlan0
Jan 14 05:27:27 fwlha /kernel: ipfw: 1620 Deny TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:27:42 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1899 204.152.188.26:21 in via vlan0
Jan 14 05:27:43 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1899 204.152.188.26:21 in via vlan0
Jan 14 05:27:44 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1899 204.152.188.26:21 in via vlan0
Jan 14 05:27:48 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:28:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.21:53 204.152.188.20:53 in via vlan0
Jan 14 05:28:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.21:53 204.152.188.26:53 in via vlan0
Jan 14 05:28:51 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:29:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.21:53 204.152.188.26:53 in via vlan0
Jan 14 05:29:21 fwlha /kernel: ipfw: 1610 Deny UDP 213.140.2.12:53 204.152.188.26:53 in via vlan0
Jan 14 05:29:55 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:30:51 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:2446 204.152.188.26:21 in via vlan0
Jan 14 05:30:52 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:2446 204.152.188.26:21 in via vlan0
Jan 14 05:30:52 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.15.167:1081 204.152.188.26:21 in via vlan0
Jan 14 05:30:53 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:2446 204.152.188.26:21 in via vlan0
Jan 14 05:30:53 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.15.167:1081 204.152.188.26:21 in via vlan0
Jan 14 05:30:53 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.15.167:1081 204.152.188.26:21 in via vlan0
Jan 14 05:30:59 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:31:24 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:2627 204.152.188.26:21 in via vlan0
Jan 14 05:32:03 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:32:29 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:33:07 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:33:46 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:34:11 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:34:35 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:34:50 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:35:15 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:1666 204.152.188.26:21 in via vlan0
Jan 14 05:35:39 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:35:54 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:36:43 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:36:58 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:37:44 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.136:2060 204.152.188.26:21 in via vlan0
Jan 14 05:37:47 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:37:52 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.136:2090 204.152.188.26:21 in via vlan0
Jan 14 05:38:02 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:38:51 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:39:07 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:39:55 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:40:10 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:40:59 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.54.138:4660 204.152.188.26:21 in via vlan0
Jan 14 05:41:14 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.9.155:2483 204.152.188.26:21 in via vlan0
Jan 14 05:46:25 fwlha /kernel: ipfw: 1604 Reset TCP 213.156.56.136:3065 204.152.188.26:21 in via vlan0
Jan 14 05:52:50 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.139:2559 204.152.188.26:21 in via vlan0
Jan 14 05:55:36 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.136:3375 204.152.188.26:21 in via vlan0
Jan 14 05:55:37 fwlha /kernel: ipfw: 1602 Reset TCP 213.140.14.136:3379 204.152.188.26:21 in via vlan0

> This is alarming, considering the increase in attacks
> against infrastructure, and the sophistication of attacks
> over the last year. And we still use basically the same
> ineffective techniques to counteract and track attacks that
> became household words two years ago.

yes.

> I suspect a very effective worm would change this pretty
> quickly, most likely through onerous regulation. It's
> surprising that it hasn't happened already.

i've had absolutely no luck getting the source isp's to care about
the problems i've seen at my home firewall in recent weeks. (see
below if you wonder whether i'm implicating anyone here.) there's
no other way to view the internet than as a worm-infested zombie.

One problem with notifications typically (that I've seen) is that there is
no one to notify... there may be an email address, but most likely that's
not even watched/read/responded-to/reacted-upon. From my experience we
recieve less than 1 in 3K responses :frowning: For UUNET I know that there is a
response and action on 'all' complaints, provided there is enough info to
take some action. NOTE, that action might not be 'disconnect' it might be
'notify downstream customer'... but atleast someone is doing something :slight_smile:
And there is a 24/7 security group responsible for dealing with live
incidents. This is also not very common at most organizations. :frowning:

To start fixing this problem every ISP really needs some security folks
dedicated to customer security issues... These folks need to have the
ability to contact customers and shut off services until the problem has
been rectified.

Hopefully, once there are security folks at all ISP's the ISP's will be
able to speak intelligently and civily to each other to cooperate and
contain problems.

I'd be happy if every ISP had at least one competent engineer who cared
about their job...

Andy

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Andy Dills 301-682-9972
Xecunet, LLC www.xecu.net
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dialup * Webhosting * E-Commerce * High-Speed Access

i've had absolutely no luck getting the source isp's to care about
the problems i've seen at my home firewall in recent weeks. (see
below if you wonder whether i'm implicating anyone here.) there's
no other way to view the internet than as a worm-infested zombie.

hehe... I know the feeling. With DShield, we try hard to send out
correlated and filtered reports in a standardized format to valid
'contact' addresses. There are some success stories, but more misses
than hits overall. The 'misses' fall into two categories:

- ignored/bad contact/ ( /dev/null group )

- or the "portscanning is not a crime" group. (at least they respond).

What is an appropriate reaction if an ISP receive an abuse report?
I know abuse@ is getting swamped with Excel Spreadsheets, screenshots
and hate mail, and most of them are 'begnin' (P2P file sharing after
glow and the like).

But would it be too much for an ISP to send an email to the customer
as they receive the first reports, a phone call after the third ... ?

(BTW: Any ISPs here that would like a daily unfiltered report? I just
streamlined that function last week.)

here some dshield data for the IPs in your list

Jan 1 18:40:44 fwlha /kernel: ipfw: 1800 Deny TCP 64.139.35.209:2559 204.152.184.163:21 in via dc0

scanned 9 different targets , > 30 days ago

Jan 3 06:15:19 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2113 204.152.184.163:57 in via dc0
Jan 3 06:15:37 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2595 204.152.184.163:21 in via dc0
Jan 3 06:15:40 fwlha /kernel: ipfw: 1800 Deny TCP 80.145.56.173:2595 204.152.184.163:21 in via dc0

2 targets, > 30 days ago... TONLINE is receiving a daily summary report from us. For a while,
they bounced it forth and back between departments for days. Now they just /dev/null it I think.

Jan 4 09:02:17 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:4992 204.152.184.163:21 in via dc0
Jan 4 09:02:20 fwlha /kernel: ipfw: 1800 Deny TCP 193.251.0.37:3314 204.152.184.163:21 in via dc0

Wanadoo.fr... do I need to say more?

Jan 12 23:21:16 fwlha /kernel: ipfw: 6400 Deny TCP 212.202.170.154:3540 204.152.188.2:21 in via vlan0

3 different tagets... does ftp and P2P...

I can see how purchasing power may motivate a vendor (and
maybe lots of individual vendors) to fix their own problems,
develop better products, or be more responsive.

I'm trying to envision an RFP that awards business to one or
a few network operators, but requires that they interoperate
effectively with other operators who don't win any of the
business. I've only got a state-level purchasing
perspective, but I don't see it happening at any level.

Is spending really an effective hammer (or gun) to make
people work together if they aren't otherwise motivated to?
Behavior related to the '96 Telecom Act doesn't inspire
confidence.

Can technical solutions be an effective band-aid for a
complex poli-socio-economic problem like this?

Pete.

So you award the contract to a provider that has clueful engineers.

How do you mandate/enable/whatever that they be able to interoperate
effectively with the clueless vendor that didn't get the contract?
Remember to address the fact that the clueless vendor would probably
have to expend resources to support somebody else's contract, with no
income to back it up.

In addition, how would you enforce this without getting sued? You award
the contract to Vendor A, they can't interoperate because Vendor B is a
bunch of clueless weenies - now what do you do?

Which ISP is terminating spammers and hackers? The bean counters
are looking TOS violations as revenue loss. I'd love
to see a bar chart of TOS terminations in the US from 1998
to 2003. Would we be surprised?

Is anyone surprised that SPAM became, and remained, a
problem, a DDoS in it's own right?

Trying to keep on the topic of infrastructure, the best
thing that Uncle Sam could do for us is to fund research
into new methods and procedures to detect infrastructure
attacks which help us to define operational procedures
on prevention and defense. Much like SPAM, we're not
going to win a war on these people. We can only detect
and defend. Perhaps countermeasures could fit in their
was well in the case of a grand attack.

I'd love to see a Operational security focused list
sponsored by NANOG.

-M

One problem with notifications typically (that I've seen) is that there is
no one to notify...

We tried notifications to the netblock owner for every incident that
exceeded a reasonable threshold. [1]

It takes a lot of time to find netblock owners. Even after investing
self to try to make the net a better place, the satisfactory response rate
is very small.

there may be an email address, but most likely that's not even
watched/read/responded-to/reacted-upon.

ditto.

recieve less than 1 in 3K responses :frowning:

We may not have time to answer each of the mechanized notifications, but
we process and respond to each incident. If only every ISP did at least
that.

To start fixing this problem every ISP really needs some security folks
dedicated to customer security issues...

I am the point of contact for the net in the sig below. We take all
network abuse notifications seriously, and follow up with our customers.

I am not hard to find.

whois -h whois.arin.net bb122-arin

Hopefully, once there are security folks at all ISP's the ISP's will be
able to speak intelligently and civily to each other to cooperate and
contain problems.

Amen.

At your service,
-bryan bradsby

Texas State Government Net
me: 512-936-2248
NOC: 512-475-2432 877-472-4848

I recommend you blackhole the offending /32s from F. Obviously these
worms, connected via unresponsive or incapable networks, are a danger to
F and to our national infrastructure.

And while you're at it, renumber F into 69/8, preferably with the last
octet 0 or 255.

The problem is that the "government" does not have large purchasing power
compared to the commercial side of the house. The government doesn't buy in
bulk, doesn't buy often and usually selects the lowest cost. Vendors design
equipment/services for the customers who will buy it. The majority of those
customers are revenue driven commercial entities that have always questioned
the need to pay for any additional security. In the past, "security" has
never been an easy sell to anyone when a cost was attached because it was
never perceived to have the potential to bring in additional revenue and
because those who were aware of security breaches of substance would not
acknowledge them (this goes for government and industry). And sadly there
are some vendors who are so big or have such a large share of their market
space, that they just do what they want regardless.

John S. Maddaus

Whenever "security" comes up people get a little weird. Nevertheless there
have been several inter-provider initiatives since 2000.

   - INOC-Dial by ASN included security contacts
   - ISP security BOF and nsp-security
   - FCC NRIC focus group on provider security best practices