Arguing against using public IP space
jeff-kell at utc.edu
Sun Nov 13 19:36:18 CST 2011
On 11/13/2011 4:27 PM, Phil Regnauld wrote:
> That's not exactly correct. NAT doesn't imply firewalling/filtering.
> To illustrate this to customers, I've mounted attacks/scans on hosts
> behind NAT devices, from the interconnect network immediately outside:
> if you can point a route with the ext ip of the NAT device as the next
> hop, it usually just forwards the packets... Phil
"It depends" on your NAT model. If you take a default Cisco PIX or ASA
(a) There is an option to "permit non-NAT traffic through the
firewall". If not selected (nat-control) then there must be a covering
NAT rule for any inside host to communicate with the outside interface,
let alone outside-to-inside.
(b) By default all inbound traffic is default-deny, only "return"
traffic for inside-initiated connections is allowed.
Yes, it's stateful (which is another argument altogether for placing a
stateful device in the chain) but by all means, it does not allow
outside traffic into the inside, regardless of the addressing scheme on
Beyond that, using 1918 space decreases the possibility that a "new,
unexpected" path to the inside network will result in exposure. If you
are using public space on the inside, and some path develops that
bypasses the firewall, the routing information is already in place, you
only need to affect the last hop. You can then get end-to-end routing
of inside hosts to an outside party. Using 1918 space, with even
nominal BCP adherence of the intermediate transit providers, you can't
leak routing naturally. (Yes, it's certainly possible, but it raises
If the added protection were trivial, I would think the PCI requirement
1.3.8 requiring it would have been rejected long ago.
More information about the NANOG