[arin-ppml] IPv6 Non-connected networks

[Owen DeLong]

On Mar 23, 2010, at 11:24 AM, William Herrin wrote:

> On Mon, Mar 22, 2010 at 7:01 PM, Owen DeLong <owen at delong.com> wrote:
>> On Mar 22, 2010, at 3:34 PM, Chris Engel wrote:
>>> Owen Delong wrote:
>>> # ULA-C isn't going to be blocks which don't work on the internet. It's
>>> # going to be blocks which people expect not to work on the internet, but,
>>> # really they do under some circumstances.  End result, a false sense of security which is
>>> # worse than no security.
>>> 
>>> # NAT != Security
>>> # Address Obfuscation != Security
>>> # Misconfiguration == Insecurity
>>> 
>>> # Belief otherwise merely increases risk.
>>> 
>>> 
>>> I've got to take some issue with your above statements Owen. NAT and Address Obfuscation ARE security mechanisms (albiet not fool-proof ones, but I've yet to see a fool-proof mechanism). Most Enterprise Admins I know commonly regard them as such...MOST dedicated IT Security people I've talked to regard them as such. PCI reg's require them as such... and pretty much every security audit I've been through that involves a regulated industry (Financial, Health, etc) has included them as such.
>>> 
>> Nope... Stateful inspection is a security mechanism.  NAT and Address Obfuscation are crutches which most people use to make sure that Stateful Inspection is working because they cannot work without it.
>> 
>> The mere fact that this myth is wide spread among things like PCI does not make it any more accurate.
> 
> 
> No offense Owen, but you're talking out the wrong hole on this one.

My level of offense is irrelevant to the discussion.

> Security devices which tend to fail closed are more secure than
> devices which tend to fail open. Firewalls fail towards being routers.

While that is a true statement, NAT has nothing to do with it.  A properly
constructed stateful inspection firewall can fail just as closed without NAT
as it does with it.  No entry in the flow table = no forwarding.

> It's the nature of TCP/IP - all but the most trivial of hosts are also
> capable of being routers. With translation in effect, that failure
> process renders the system non-operational and is immediately
> noticeable. Without translation the failure process renders the system
> open to attack and won't be promptly noticed since everything expected
> to work still does.
> 
Sorry, I can't figure out what particular scenario is envisioned in all
the missing steps there...

If you're talking about a scenario where you have hosts that should
not be routers connected to networks on both sides of a firewall, then,
that's a generally bad design to begin with.  No host that is not a
security boundary device should ever be directly connected to more
than one security zone.

Doing so isn't a failure of a security device, it's a deliberate effort to
bypass it. If someone is allowed to bypass your security at this level,
the mode in which it tends to fail is the least of your concerns.
If the host is connected by accident, then, the upstream router
shouldn't be likely to ask it to forward packets towards your interior,
so, things still fail closed. If your forward interior-bound packets to
something which isn't a defined security device, then, you have
a second failure in your security policy already. Still, when the
outbound firewall gets a non-initiation packet for an unestablished
session, it should block the outbound reply. In other words, without
NAT, we've already seen a need for 3 failures in your security policy
to make things work.

I suppose it could be argued that requiring the host in question to
implement NAT in order to function makes for a 4th failure, but,
I'll point out that if the undesired forward does implement NAT, it
makes it easier for it to completely bypass the firewall by substituting
it's own interior address for the outbound destination in all the packets.

So, in the scenario I think you are most likely referring to, NAT giveth
one additional layer and NAT removeth one additional layer of
security, making NAT roughly a zero-sum game at best. Given the
high cost to NAT in terms of application development time wasted
on constructing and maintaining NAT traversal schemes and the
high degree of incompatibility of various NAT traversal solutions,
that's an awful lot of capital for something that is a wash at best
in terms of security.

> It's part and parcel to TCP/IP's basic architecture, an architecture
> that hasn't appreciably changed in IPv6.
> 
Sure. If you're building a TCP/IP network with security, no host should
straddle a security boundary that is not a security border device.
That's true in IPv4. It's true in IPv6. It doesn't change with or without
NAT and NAT doesn't do anything for you or against you if you don't
have such a host. If you do have such a host, NAT can represent
the fourth required failure on the intentional security device, but, if
said host is configured with NAT, it can bypass the third required
failure on the same device.

> 
>> not valid. As such, I would rather see us implement a one-policy, one-
>> price strategy for both tainted and non-tainted addresses and have
>> the RIRs issuing both types than have some other system outside of
>> the RIRs develop for the administration of tainted addresses.
> 
> Because "one size fits all" works so well in general and the needs of
> the non-connected or privately interconnected network are so obviously
> identical to the needs of the Internet-connected network.
> 
Because having disparate policies for the two classes of address space
will create an incentive for the one that is easier to get to be (mis)used
in environments where the other would be more appropriate.

If it's easy to get the addresses you need of whichever type you need,
why is that a bad thing?

Owen