On 14/11/2011, Jason Lewis <jlewis@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.