2001-01-02-09:02:37 Deron J. Ringen:
That makes perfect sense to me...there is not a better way to protect a box from a DOS/hack than to only give it a private address.
this is a common fantasy. changing the its license place does not change the vulnerability of your car to an accident.
True...but parking your car in a garage as opposed to on the street does make it less vulnerable to theft.
I think, based on other comments Randy made, that the real root of this particular disagreement is just terminology. Randy made other followups on this thread. One, in response to a remark similar to yours, is quite suggestive: 2000-12-31-15:40:50 Randy Bush:
that's called a firewall, or in the extreme a disconnected network, not nat.
and then a little later, in a thread on Loose Source Routing (lsr): 2000-12-31-17:02:24 Randy Bush:
lsr is not required to get through a nat. the nat presents an outer address that maps directly to the inner address. attack the outer address directly and you have attacked the inner address.
So the picture that emerges is that Randy is very definitely speaking of NAT as Bi-directional or Two-Way NAT (in the terminology of RFC 2663), where no address conservation is practiced, and machines with private addresses are directly reachable via public addresses, through a fixed incoming mapping applied by the NAT device. I'd expect that many participants in this discussion --- possibly including most of those thinking that NAT adds security --- are automatically thinking about the varient of NAT named in that RFC as Network Address Port Translation (NAPT) --- where connections can be established from private->public only, and the NAT device dynamically remaps the private [srcaddr,srcport] onto per-connection-assigned public addr/port pairs, using one (it's own) or a small number of public addresses as the target of its mapping; this is the mode that can conserve public addresses, and also provides stateful packet filtering allowing outbound-only connections. As if this weren't messy enough already, an additional complication arises because at least one NAT implementation is part of a tool frequently used as a firewall (ipchains), does NAPT only, and when doing NAPT turns from a stateless simple packet filter into a stateful packet filter, with an increase in practical security. Especially with his remark "that's called a firewall, not nat", I think it's clear that Randy sharply separates things that are doing routing functions (including NAT) from things that are enforcing security policy constraints at network traffic choke points (firewalls). And there's jargon usage to support his view, ipchains itself doesn't call it's NAPT implementation NAT, but rather Masquerading. Sadly, others of us muddy the water by using the term firewall to designate a function --- policy control and enforcement --- which can sometimes, depending on details of the desired policy and the available functionality, be actually implemented partly or even entirely by a router. Looking past the variations in usage, Randy's remarks stand very plainly and indisputably: Network Address Translation, as a routing function, implies nothing about security; and the use of private addrs which it permits would clearly add no security to the mix given Bi-directional NAT. Packet filtering, as a firewall function, can add security. The fact that one popular style of NAT pretty consistently implies a variety of packet filtering would seem to be the source of the unfortunate confusion. Now all this discussion brings to my mind a fascinating possibility. In the big recurring battle on NANOG, the topic of RFC 1918 addrs comes up because some people like using them for endpoints of point-to-point links between routers within their transit networks, and others condemn that practice, citing the urgent operational necessity to run traceroute, which requires "seeing" each interface on the path through the transit network, and the recommendation in RFC 1918 itself to filter RFC 1918 addrs at the border. The juxtaposition of these two threads, RFC1918+NAT for security and RFC 1918 link addrs, brought to my mind an interesting question. Since some folks get so outspokenly upset if they see RFC 1918 addrs in a traceroute, I wonder if it'd be possible to configure a border router to NAT those RFC 1918 addrs. Obviously this would be something you'd want to be able to switch on and off on a per-customer basis; folks who'd rather see the real assigned addrs in their traceroute output would ask for this to be left off, those who cannot abide the sight of those addrs could have it turned on, and so would see repetitions of the NAT-ting border router addr with the increasing hop count until the far edge of the net was reached. Hmm. If that NAT trick would work, it might also deal with another downside to RFC 1918 link addrs, that limits their usefulness; if a router has interfaces onto nets with different MTUs, assigning any of its interfaces an RFC 1918 addr is liable to be bad, since the RFC 1918 addr is likely to be blocked at someone's border, and that combination would cause the ICMP dest unreachable fragmentation needed packet, required by Path MTU Detection, to be dropped, making TCP connection setup fail. Perhaps NATting those RFC 1918 addrs at the border would address that problem, and so allow more extensive use of RFC 1918 addrs for router interfaces. Hmm. I doubt the brawl over RFC 1918 link addrs will ever really get settled; but at least there will be a possibility for peace soon; network operators will be able to decide whether their internal routers are in fact public servers, and if they decide they aren't, they will be able to run MPLS or something like it, something that propogates transit traffic in tunnels right across their net, and so prevents the existence of the intermediate routers from being visible even to people using custom-forged short TTLs (i.e. traceroute) to try and detect them. -Bennett