[arin-ppml] IPv6 Non-connected networks

[Owen DeLong]

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.

> You may think we're all pretty much brain-dead for thinking so....but there IS a pretty strong consensus there among people who actualy get paid specificaly for IT Security.
> 
Actually, most of the people I know who get paid for IT security, including a number who are responsible for it in environments where physical access is protected by fingerprint and retinal scanners and guards carrying firearms, agree that this is a widespread myth.

> Realisticaly RFC 1918 space (the space people use with NAT in IPv4) tends to fail closed rather then open and that's the botom line. 99.99% of the worlds routers aren't going to have a route in thier routing tables for RFC1918 space that leads to my network. If you hit my external router with a RFC1918 address it's not going to know to send it to my firewall or internal network.... and if you hit my firewalls external interface with a request for an RFC 1918 address, it's going to tell you to get lost because it's got no entry in it's table for an address on that interface that corresponds to it.
> 
RFC-1918 provides some measure of closed failure because the addresses overlap so a leak is contained by virtue of the fact that worst-case it's an anycast candidate destination for a limited scope of the internet. However, that closed failure is far from reliable, thus, providing more of a false sense of security than actual security. ULA-C, however, wouldn't have this overlapping address property, thus further reducing the efficacy of this supposed closed failure.

I'm assuming that if I hit your firewall with a GUA on your internal network, the ruleset wouldn't let the packet in unless it conformed to other properties that specified an intended public service. I don't see a difference between getting an RFC-1918 destination address to your firewall and a GUA that belongs to some other network. Both should and would be rejected. Assuming proper configuration, the same would happen with a packet to a valid GUA on your network that isn't used for providing public services.

> Practicaly speaking.... using that space tends to DECREASE the damage done when a misconfiguration occurs... in my dictionary, we call something that does that a "Security Mechanism".
> 
OK, I'll accept that using address space which is guaranteed to overlap some fraction of other users can be called a "security mechanism", albeit a very weak one.

However, I will say:

Security Mechanism != Security

Security == Security Mechanisms[n] properly applied where n >1 and usually  n>3

> I will agree that ULA-C sounds like a bit of a different animal though, as it would be registered to a particular organization and therefore unique to it. Personaly, I would just end up using what you guys are terming ULA-Random for private space.... but I can see why an organization might want to grab space that is uniquely assigned to it but generaly recognized not to be routed. If you ARE looking for Private space.... you are better off going with something that is indicated it SHOULD NOT be routed (ULA-C).... even if that indication is ignored sometimes then going with something that provides no indication at all (GUA). Not addressing the other aspects of it...like fee's, etc.... just this one aspect.
> 
My proposal was for a block which I've termed "GUA-Tainted" instead of ULA-C only to distinguish the fact that the tainted block is administered under the same allocation policies as GUA so that it does not offer an incentive to (mis)use ULA-C as GUA. Afterall, if the world de facto starts routing ULA-C, then, your purpose for it suffers right along side of the internet addressing policies that it would circumvent.  In other words, I don't think we are disagreeing about substance, but, about form.

> Personaly, I would use split DNS anyways....don't really like the idea of advertising internal host names & IP's in a publicaly accessable zone somewhere....but that's just me.
> 
Exactly.  I'm all for letting those that want to use split DNS do so, but, making it easy for those that do not want to as well. I want to put choice in the hand of the end user and their ISP. 

In summary:

Current situation:

ULA-C	Proposed, previously deprecated RFC which does not conform to current GUA allocation policies
	-	Provides a cost incentive to use this instead of GUA in environments where GUA may be desirable.
	-	Provides a policy incentive (easier to get) vs. GUA in environments where GUA may be desirable.

GUA	Existing, Globally Unique Addresses.  What we're all used to getting from the RIRs already.
		Generally expected to be used for connecting to the internet, limited to organizations meeting
		certain (arbitrary minimum criteria)

Routing Table Size aspects of routing policy
		Abdicated by ISPs to management by the RIRs (sort of)

My proposed alternative:

GUA	Much like GUA in the current situation, but, easier to get and not limited by (arbitrary) minimum
		organization size/topology criteria.

GUA-Tainted
		Much like the ULA-C proposal. Could even come from ULA-C block. A block set aside specifically
		for networks that want addresses known to not be routable on the internet.

Routing Policy
		Entirely the purview of ISPs and their customer(s)/user(s).

The difference:
	A relaxed criteria for GUA and GUA-Tainted allows both types of addresses to be allocated in
	such a way that the only difference between them is the preference of the receiving organization
	as to which type of address they want, thus removing any incentives that would exist for the
	use of ULA-C in a context more appropriate to GUA.

I hope this clarifies that I am not opposed to the concept of private addresses. I am opposed
to creating a situation where private addresses are likely to be (ab)used as global addresses
thus reducing their utility for both purposes.

Owen