[146593] in North American Network Operators' Group
Re: Arguing against using public IP space
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Nov 16 15:52:27 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4EC3EF2E.2040408@gmail.com>
Date: Wed, 16 Nov 2011 12:44:34 -0800
To: -Hammer- <bhmccie@gmail.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Nov 16, 2011, at 9:13 AM, -Hammer- wrote:
> "NAT neither provides nor contributes to security.
> NAT detracts from security by destroying audit trails and =
interrupting/obfuscating
> attack source identification, forensics, etc."
>=20
> Respectfully, I'm really struggling with this. Sentence one is an =
opinion. It's all a matter of the designers viewpoint. Step 1 in most =
security books is to not reveal ANYTHING to ANYONE that you don't have =
to. Taken to the extreme, that could include your network layout and =
native addressing schema.
>=20
Actually, the first rule of security in many texts I have read is =
"Security through obscurity
is no security.". While you don't reveal anything to anyone that you =
don't have to, it is
arguable that you need to reveal enough for security threats (abusers, =
attackers, etc.)
to be identified as part of being a good network citizen. As with most =
things, taken
to extreme, you reach a point of reductio ad absurdum.
> Sentence two is wrong. If employing NAT breaks your audit trail or =
interferes with your forensics then you need to address your =
audit/forensics method. We have correlation engines that track the =
"state" of a conversation (defined as multiple TCP sessions in series) =
thru our secure architecture. We can 100% tell you the public IP of a =
session whether it's the destination or source and whether it's been =
NATted once or three or four times. We have =
cookies/sessionIDs/JSessionIDs/ and Xforwarders we manipulate to allow =
the application layer to manage the proper source of the client as well. =
These are proven technologies that have been around for a decade. They =
have stood up in court and been used against bad guys w/o question. =
While I agree that this is an extra layer of complexity, the focus is to =
make in manageable.
>=20
It may not break your own, but, it certainly breaks that of your user's =
victims.
Most people don't store port information in their webserver logs, for =
example. They may not have
that data to come back at you to identify the internal host in question. =
All they have is the public
IP address of your NAT box and the date/time the event occurred.
Ignoring for a moment the fact that if your clocks aren't perfectly =
synchronized, that may not
necessarily provide the needed identification, even if they do have the =
port number, without
the source port number from your side, they don't have enough for you to =
find the attacker.
> I'm not saying you are flat out wrong Owen. I am saying that it's all =
a matter of your viewpoint.
>=20
I think in considering this in general, all viewpoints must be =
considered. =46rom the global
viewpoint, overall, I think that the case is well made that the security =
negatives associated
with NAT and the cost/impact imposed on everyone, including those =
outside of the NAT-
using organization far outweigh the (very minuscule) possible positives =
that have been
argued so far.
This leaves one and only one key benefit to NAT, which is address =
sharing (conservation).
Since we don't have a shortage of IPv6 addresses, bringing a technology =
forward into
IPv6 solely for the purpose of address sharing (conservation) makes =
little sense.
Owen
