Arguing against using public IP space

-Hammer- bhmccie at gmail.com
Wed Nov 16 21:44:25 UTC 2011


Well argued Owen. I can see both sides.

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 11/16/2011 02:44 PM, Owen DeLong wrote:
> 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."
>>
>> 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.
>>
>>      
> 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.
>>
>>      
> 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.
>>
>>      
> I think in considering this in general, all viewpoints must be considered. From 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
>
>    



More information about the NANOG mailing list