> On Tuesday, April 22, 2003, at 06:57 PM, Spencer Dawkins wrote: > > > I agree with your take from the network side, I'm thinking Terry > > may be looking at it from the applications side (what's the > > difference between one perfectly lovely address that fails > > unpredictably and another perfectly lovely address that also > > fails unpredictably? and the unknowable firewall topology is > > probably within a first approximation of the unknowable site > > topology). On Wed, 23 Apr 2003, S Woodside wrote: > > The differences: > - firewalls are a necessary evil for security, whereas site locals are > (maybe) not > - firewalls are a simple on/off switch and easy to change, whereas site > locals have complex state and are hard to change > > Firewalls and NAT / site-locals might seem to be entangled, but it's > just a coincidence. They both work best in the same place in the > network, so many firewalls also do NAT. Simon, I think there is more entanglement than you do, because sometimes local addresses are used as part of a security strategy aimed at avoiding the need for conventional middlebox firewalls. (A google search for "logic firewall" will point to one example of what I'm talking about.) I'm looking at this from the perspective of diagnosing alleged network problems. It seems to me that conventional middlebox firewalls utterly destroy end-to-end transparency, and with it, any hope of preserving the all-ports-are-equal "network utility" model that has served us so well... whereas, local addresses merely "seriously undermine" that model. Do you prefer vinegar or castor oil? (And can anyone offer me some honey?!) If I have to choose between random locally-controlled firewalls sprinkled throughout my network infrastructure vs. having hosts with local addresses, I would much prefer to live with the latter. From an end-to-end network management perspective, neither is a very happy scenario, but my preference is based on having done both experiments. At least with local addresses, some semblence of the network utility model can be preserved: a technician with a globally-configured laptop can run iperf tests from any outlet and not wonder whether some intervening firewall is failing to preserve the window scaling bit in the tcp header. (And the NOC doesn't periodically lose visibility to devices beyond the firewall because of accidental misconfiguration by the firewall owner.) Networking is all about connecting things; security is all about isolating things. As far as I can tell, a satisfactory compromise still eludes us. (Sometimes in the non-cyber world, too, as SARS and 9/11 remind us.) So, apart from the renumbering/provider-independence arguments for local addresses, I do believe there is a security element too, which in my mind adds fuel to the architectural debate over e2e transparency. There are a range of ways local addresses can play into the security space; some involve NAT, some do not, but at our site we already have compelling evidence that offering some defense-in-depth security alternatives involving local-addressing can greatly diminish the clammer for *conventional* perimeter firewalls, and thus, reduce the pressure on us to abandon the network utility model. Who do we call about the destruction of the network utility model that has served us so well? As an over-simplified generalization, I think the OS vendors have to take the rap. By allowing the accretion of an installed base of end systems that is by-and-large not "Internet safe", they have unwittingly given credence to the widespread view that "it was the networking guys who brought us all these security problems, so it should be the networking guys who solve the security problems." This in turn inevitably leads to middlebox perimeter defense "panaceas", and thence to the search for less network-destructive alternatives. My current hypothesis is that local addresses can play a role in that (slightly) less-destructive solution space. But I continue to seek/wish-for better choices. (Meanwhile, I'll just slip into my asbestos suit, and debate with myself the wisdom of sending this message :) NB: I'm focused on singly-addressed hosts; I have no wisdom to offer regarding the multiply-addressed host problem/controversy. -teg