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