[arin-ppml] IPv6 Non-connected networks

[Michael K. Smith - Adhost]

> On Tue, Mar 23, 2010 at 5:04 PM, Chris Engel
<cengel at sponsordirect.com>
> wrote:
> > Owen Delong wrote:
> >> Sorry, I can't figure out what particular scenario is
> >> envisioned in all the missing steps there...
> >
> > Not trying to speak for Bill here...
> 
> Chris,
> 
> Feel free. Owen needs as much help understanding the network security
> process as he can get.
> 
> > However here is where NAT comes in to help save
> > your butt. You have no address mapping to any of
> > those internal only devices on your firewalls
> > EXTERNAL interface. So an external user has
> > no way to address them. Even if that user was able
> > to route a packet destined to an internal IP address
> > to your Firewalls EXTERNAL interface.... that interface
> > wouldn't pick it up...because as far as it's concerned
> > no such IP address is bound to that interface.
> 
> Exactamundo.
> 
I'm not sure I understand how NAT fixes this any more than properly
applied firewall rules would.  If I want to block incoming traffic or,
more specifically, only allow specific traffic to and through an IP
address, I can do that as readily with an ACL as I can with the
inclusion of a static mapping.  I appreciate your belief that NAT helps
limit operator error, but using any technology in replacement of proper
policies in procedures is not a good idea, security or no.

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.

Me: "Hi, we just got scanned/DDOS'd/spammed from <your PAT address> at
1:00 local"
You: "Wow, that's when everybody got back from lunch, so it will take me
a month to go through the translation logs to       find out how sent
that traffic."
Me: Plonk
 
> > However, in this case there is no NAT, no
> > "compensating control" to account for the single
> > point of failure. An external user sends a packet destined
> > for one of your "internal only" devices. In this case,
> > since all devices use public address space...it's
> > entirely addressable to that external user. The firewalls
> > external interface picks up the packet... see's that it's
> > allowed by the filtering rules...and passes it through
> > to the destination address. Just as it thinks it's supposed to.
> 
> Another win.
> 
>
No, that would be an improperly applied ACL.  If you want to block
traffic to an address, block that traffic.  Again, it's a matter of
proper procedure.  Your compensating control is in the verification that
a policy was applied correctly.
 
> > Am I wrong?
> 
> No, you're spot on.
> 
That's certainly one opinion.  As with any technology NAT is like any
other, with good and bad characteristics.  One of the main issues is
that NAT is used ubiquitously in almost all consumer devices and touted
as a panacea for keeping out the bad guys.  The number of bad guys that
get in due to uninitiated outside traffic pales in comparison to the
number who are invited in by the user through an application-based
vector.

Apparently NAT is religion.  The one thing Chris has spot on is the
mistake of not having feature parity between IPv4 and IPv6.  If we're
going to get all of the enterprises on board with v6 we're going to have
to have some sort of protected space, or a sound methodology for
splitting your assigned space into public/non-public addresses.  It
seems to me the latter is doable given the huge number of addresses that
are assigned, even with "only" a /48.

Regards,

Mike