Thinking about this over lunch, I realized that a big part of the problem is the over-emphasis on perimeter security.
During the SARS outbreak of a few months ago, the disease was successfully contained not by imposing more scrutiny at customs and immigration, but by imposing sterile protocol and quarantine of infected areas. Outbreak areas that already used such protocols and imposed quarantine immediately contained the virus quickly; those that did not the epidemic continued until the measures were put into place. In other words, it's far more effective to work to keep viruses from spreading than to try to isolate large areas. In the case of the SoBig virus, perimeter security was nearly useless because even one single infected machine was enough to cause a local epidemic, and there are many more ways that this can happen besides direct attack from outside the perimeter. If one person hooks up an infected laptop, or one person brings in an infected CD, or one person reads his AOL mail from within the network, and on any network of significant size the perimeter security has become ineffective. Just as in the SARS outbreak, what is needed are mechanisms to keep the virus from spreading to other machines (both inside and outside of the local network). Placing firewalls *within* a network rather than merely at the perimeter would be a crude start. Far better would be to develop a comprehensive plan for providing security in depth from a cetral configuration - and to use this to automatically configure filtering at the perimeter, internal firewalls, and hosts - and also to back this up with automated testing for configuration failures. But in the context of such mechanisms - which I'm convinced are the only workable solutions to this problem - private addressing is of such marginal utility as to be useless, and it imposes so many difficulties for operations that it's worse than useless. The trick, of course, is getting people to realize this, when the "conventional wisdom" that Private Addresses Are Good is so widespread. Keith > These are people who *will* get fired if their network is seriously > penetrated. In fact, I expect quite a few will be fired in the near > future because of inadequate protection against the current virus > pandemic. These are people who *will* insist on every single way of > limiting access. They will agree that security by obscurity is only > a partial solution, but they add it to all the other partial > solutions. > > They will *not* tolerate a solution in which misconfigured ACLs in > border routers could expose the RPC ports on individual Windows boxes > to packets from outside the enterprise. That's in addition to > compelling all employees to install the MS03-26 patch and a personal > firewall. > > In this context, some form of private address space is not even > slightly optional. Even when RFC 1597 was published, the above > pressures were there. They are 100 times greater now. > > So it's simply inevitable that enterprises will use private > (i.e. non-PA, non-routeable) space. Our challenge is to make it > as good as we can. > > Brian > > Pekka Savola wrote: > > > > On Sun, 24 Aug 2003, Michel Py wrote: > > > > Pekka Savola wrote: > > > > 1. Shouldn't we first see the requirements for site-local > > > > replacement (and other issues) and not jump straight to the > > > > requirements for local addressing? > > > > > > Do you mean that the Hain/Templin draft is too generic, or not > > > specific enough? > > > > Yes. It takes for granted that we need local-use addressing, and > > lists a lot of requirements for local-use addressing (some of which > > are most probably redundant if you'd apply local-use addressing only > > to *specific* scenarios). > > > > What I'm trying to say is that we need to first figure out where we > > need local-use applications -- and, as an interim feature, maybe > > reword the current draft so that it's apparent which current > > perceived local-use scenarios require specific requirements. > > > > > >> 3.1 -- "Network managers have stated, and historical > > > >> experience has shown, that there is a need for addresses > > > >> that do not require public registration." > > > > > > > ==> there is no supporting evidence of this expect vague > > > > statements. Please be more explicit as I don't see how we > > > > can take this for given. > > > > > > Maybe you are too young to remember but network administrators > > > have hijacked addresses for ages, > > > > yep.. > > > > > which is one of the reasons that eventually > > > led to RFC1597. What makes you believe that the reasons they did > > > it in the past do not exist anymore? > > > > And what problems has this caused that are really, really > > problematic? > > > > If you have a disconnected network which you don't plan to connect > > without renumbering (which has to be done anyway), it doesn't matter > > if you hijack a prefix. > > > > On the other side, I fail to see the need to hijack a prefix for > > your running system. IPv6 addresses are quite obtainable nowadays > > if you're an equivalent of LIR. > > > > In addition, compared to the situation back in 1994 (and earlier), > > people actually use Routing Registries to check advertisements. You > > really cannot assume that you could hijack a prefix and have it work > > in the Internet. > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- -- "Of course the people don't want war. But ... it is always a simple matter to drag the people along. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger... It works the same way in any country." - Hermann Goering, 1946. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
