Arguing against using public IP space

Tue Nov 15 14:52:19 UTC 2011

On Nov 14, 2011, at 11:32 AM, William Herrin wrote:

> On Mon, Nov 14, 2011 at 1:50 PM, McCall, Gabriel
> <Gabriel.McCall at thyssenkrupp.com> wrote:
>> Chuck, you're right that this should not happen- but
>> the reason it should not happen is because you have
>> a properly functioning stateful firewall, not because
>> you're using NAT. If your firewall is working properly,
>> then having public addresses behind it is no less secure
>> than private. And if your firewall is not working properly,
>> then having private addresses behind it is no
>> more secure than public. In either case, NAT gains
>> you nothing over what you'd have with a firewalled
>> public-address subnet.
>> 
>> The fact that consumer cpe's typically do both nat
>> and stateful firewalling does not mean that those
>> functions are inseparable.
> 
> Gabriel,
> 
> This is not accurate.
> 
> First, many:1 NAT (sometimes also called PAT) is not separable from a
> stateful firewall. You can build a stateful firewall without
> many-to-one NAT but the reverse is not possible.
> 

Actually, you can. You need a state machine, but, several recent incidents
have proven that the state machine in many of the lower-end consumer
appliances is not, in fact, a firewall. This has been explained earlier in the
thread, so I won't repeat it here.

> Second, while a security benefit from RFC 1918 addressing combined
> with 1:1 NAT is dubious at best, the same is not true for the much
> more commonly implemented many:1 NAT.
> 

Repeating this fallacy still doesn't make it true.

> With RFC1918 plus many:1 NAT, most if not all functions of the
> interior of the network are not addressable from far locations outside
> the network, regardless of the correct or incorrect operation of the
> security apparatus. This is an additional boundary which must be
> bypassed in order to gain access to the network interior. While there
> are a variety of techniques for circumventing this boundary no
> combination of them guarantees successful breach. Hence it provides a
> security benefit all on its own.

If the security apparatus malfunctions, nothing prevents it from malfunctioning
in a way that passes packets to the RFC-1918 addressed hosts.

> 
> You would not rely on NAT+RFC1918 alone to secure a network and
> neither would I. However, that's far from meaning that the use of
> RFC1918 is never (or even rarely) operative in a network's security
> process.

RFC-1918 and NAT as a security measure is, at best, a locking
screen door deployed in front of a vault door. If you take away the
vault door, the screen door really doesn't do much. If the vault door
is still there, the presence or absence of the screen door is largely
irrelevant.

Owen