[arin-ppml] IPv6 Non-connected networks

[Michael K. Smith - Adhost]

> 
> On Wed, Mar 24, 2010 at 12:41 PM, Michael K. Smith - Adhost
> <mksmith at adhost.com> wrote:
> > I'm not sure I understand how NAT fixes this any more than properly
> > applied firewall rules would.
> 
> Hi Michael,
> 
> Properly applied firewall rules secure a system regardless of the
> methodology. Dwelling on that misunderstands the nature of security.
> Strength of security lies in depth: people being people, mistakes will
> be made. In the config. In the code. Everywhere. What happens then?
> 
> A firewall is a door with a lock. Unlock the door, forget to re-lock
> it and you're done.
> 
> A NAT firewall is a door with a pneumatic closer, a prox card reader
> and a pin code. This latter is less vulnerable to attack: stealing or
> duplicating the prox card is as hard or harder than picking a lock and
> even once you have the card, you still need the matching pin code for
> entry.
> 
> Either way you're screwed when an authorized entrant politely holds
> the door, but that remaining vulnerability doesn't diminish the
> difference in security between the two.
> 
>
Obviously I don't subscribe to the analogy.  A firewall works in exactly the same way whether or not there is a NAT boundary included.  Personally, I haven't found that the perceived added security of obfuscating inside host information has been of enough benefit to outweigh the issues with NAT.  Forensics are more difficult, IPSec is more difficult, etc.  The configuration for hosts and host-types and their access are exactly the same for NAT and no-NAT.
 
> > The other thing no one is discussing is the outbound complexities of
> NAT
> > and specifically PAT, given that your various models support only
> some
> > hosts with static mappings.  Given that a significant amount of
> problems
> > on the network are initiated from the inside by infected hosts, you
> now
> > have to go through your translation tables to determine which of your
> > multitudinous inside hosts is responsible for sending out cruft.
> 
> NAT has a price tag. In fact, it has several. An increase in
> post-breach forensics complexity is one of those prices. What
> discussion would you like about a fact that isn't disputed?
> 
The point is that proving NAT is valuable based solely upon its perceived benefits for inbound traffic doesn't address the issue with all its complexities.
> 
> > As with any technology NAT is like any
> > other, with good and bad characteristics.
> 
> Of course it is, and I wouldn't suggest otherwise. Nor would I suggest
> that the strongest security always the best choice. Strong security
> tends to come at a usability price that can be inappropriate for the
> situation.
> 
> However, everything else being equal, an address-overloaded NAT
> firewall is stronger security than a non-overloaded NAT firewall which
> is stronger security than a merely stateful firewall which is stronger
> security than a packet filter which is stronger security than relying
> solely on the individual hosts to be resilient to attack.
> 
I don't follow the logic.  All stateful firewalls perform exactly the same function regardless of NAT.  All NAT does is obfuscate the number of internal hosts.  Personally, if I have all the addresses I need, I prefer to use them without NAT.  I control every connection in and out from the IP's and I know exactly where each one is allocated.  

> And I will suggest that for any given firewall configuration, the
> otherwise-identical configuration that also does NAT has implemented
> stronger security.
> 
> I'll also claim that while address-overloaded NAT's conservation
> benefit is more or less pointless in IPv6, its impact on security
> remains significant, no different than in IPv4. Where the decision to
> use NAT did not revolve around address conservation, there is little
> reason to believe a substantially different decision will be reached
> when implementing IPv6.
> 
> 
Actually, RFC 1631 says that NAT is for addressing address conservation specifically.  And, ironically, in Section 3.2, subsection "Privacty, Security and Debugging Considerations," it says "Unfortunately, NAT reduces the number of options for providing security" and "On the other hand, NAT itself can be seen as providing a kind of privacy mechanism."  Privacy equates to obfuscation without the pejoratives overtones of the latter term.

> > Apparently NAT is religion.
> 
> I've seen that before too but I don't see it here. What I see here is
> folks trying to address the forceful ignorance that lies in the claim
> from a certain individual who should know better to the effect that
> the presence of NAT is a security no-op.
> 
How about a topic that engenders passionate debate.

Regards,

Mike

--
Michael K. Smith - CISSP, GSEC, GISP
Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com
w: +1 (206) 404-9500 f: +1 (206) 404-9050
PGP: B49A DDF5 8611 27F3  08B9 84BB E61E 38C0 (Key ID: 0x9A96777D)