69/8 is harder to fix than it looks at first glance
the problem is simple: outdated filters.
Agreed, more or less.
the solution is simple: tell people that their filters are out of date
Sorry, but this fixes nothing. It notifies people that a problem exists but it doesn't fix the filters. Several things need to be done for a lasting fix. - we need to identify where the broken filters are. - we need to find contact information for all those places. - we need to notify all the places that their filters are broken. Already, this is a heck of a lot of work and I would not describe this as a simple solution. But now the real fun begins because all of those people that were notified will reply. - some will tentatively accept your info but ask for proof that their filter is broken. - some will strongly deny that anything is wrong with their filters - some will ask what will fix their broken filter - some will ask whether your fix is short term or whether it is general enough to handle similar issues And therein lies the crux of the problem. We have no good answer to this last one other than to tell these people to change their filters today and then to regularly hunt through some mailing lists or websites to find notifications that the filters need to be changed again. And again. And again and again and again. When does it stop? The fact is that are operating these 21st century networks using 19th century business technology. This does not scale. The net is too big to be managed by person to person exchange of information. That's why we have DNS protocols instead of issuing updated copies of the hosts file. And that's why we need an automated system to publish current status of IP address ranges in a format that would be acceptable to firewall admins and firewall vendors. These people already trust LDAP enough to use it for distributing keys and certificates. IP address range attributes are similar sorts of out-of-band information that is not essential to packet forwarding but needs to be distributed in order to configure devices correctly. In this case, the attribute that we are primarily interested in distributing is whether or not an IP address range has been allocated by ARIN for use or not. But there are other useful attributes that could be distributed as well such as contact information. Let's all stop this lazy style of knee-jerk engineering that assumes all problems are simple and can be solved using a router and some PERL scripts. Some problems are hard technically and socially. These kinds of problems can only be solved if you are willing to look at the big picture as well as the immediate impacts. --Michael Dillon
On Wednesday, Mar 12, 2003, at 12:11 Canada/Eastern, Michael.Dillon@radianz.com wrote:
The fact is that are operating these 21st century networks using 19th century business technology. This does not scale. The net is too big to be managed by person to person exchange of information. That's why we have DNS protocols instead of issuing updated copies of the hosts file. And that's why we need an automated system to publish current status of IP address ranges in a format that would be acceptable to firewall admins and firewall vendors.
The DNS is managed by person-to-person exchange of information, and it scales. HOSTS.TXT was an example of a centrally-managed database, which didn't scale. Your examples seem to be backwards in some way. Most of the Internet operates on the basis of person-to-person (or router-to-router, or AS-to-AS) information exchange, a characteristic which has *allowed* it to grow. Information which cannot be distributed in this manner frequently becomes troublesome to administer and mired in policy discussion with little forward momentum (e.g. the contents of the root zone, IP address assignments). Saying that the Internet is too big for distributed information processing to scale (and promoting centralised management of information as a preferred alternative) is just odd. Joe
participants (2)
-
Joe Abley
-
Michael.Dillon@radianz.com