Arguing against using public IP space

Sun Nov 13 17:21:38 UTC 2011

On 14/11/2011, Jason Lewis <jlewis at packetnexus.com> wrote:
> I don't want to start a flame war,

If you didn't write it I wouldn't stress about that.

> but this article seems flawed to
> me.

Me too.

>  It seems an IP is an IP.

Yes but in IPv4 land there is a difference although probably not in
the way the author "suggests".
The non-routability of the private address space is dependent on the
good sense of router manufacturers and although these days that's
probably guaranteed the impression I get is some dumb SCADA network
guy is expected to go "oh, private address, intrinsically secure" or
"oh, public address, intrinsically insecure, hmm, all my edge devices
are owned and beyond help".
Hehe.

> I think I could announce private IP space,

Exactly but it would never get legs.

> so doesn't that make this
> argument invalid?

I think there are much better reasons why the article is invalid and
ultimately irrelevant and weird.

I know this is contentious so I'll clarify it  ...
NAT is not a security feature.
Any perceived benefit is from the state table ... which any packet
filter can duplicate.
NATting is not the issue but the allow/deny situation based on the state table.
More importantly though, other than DOS (presuming less bandwidth
inside than out) or attacks on a host's TCP/IP stack (maybe SCADA
suffers here), what's important is services hanging on ports and any
vulnerabilities they have - which, by design are passed whether you
NAT or not (we want people to talk to our web server).
Has any one ever been cracked on their web browser or email client or
whatever by something that was preventable at the lower layers with a
default deny all in rule ...
Never.
The only issue for clients in that respect is spoofing and so on ...
which NAT passes as well as (or more openly than) any packet filter
...
Any good packet filter can help there but that's strictly a packet
filtering feature and nothing to do with NAT.
By definition alone, NAT is useless here.
Some of the finer points argue against NAT entirely.
http://www.ietf.org/rfc/rfc4966.txt (security considerations)

Extending that, there could be some filtering somewhere.
On the host, on the edge.
A packet filter (ipso facto more relevant than a network address
translator) is the tool of choice.
Regardless, all that matters is vulnerability in services.
I could never imagine writing an article about NAT (or translation) in
a security context other than to say "focus on the real issues".

It's all kind of backward too.
IPv6 anyone?
Surely SCADA is the prima facie example of "everyone's light bulb
connected to the internet".
Where's Vint Cerf when you need him ...

Besides ...
... who uses Classes any more?

:]

>  I've always looked at private IP space as more of a
> resource and management choice and not a security feature.
>
>

Right on ...

... and those SCADA guys have got important issues to worry about.

Best wishes.