[ipv6hackers] my IPv6 insecurity slides

[Owen DeLong]

On Nov 28, 2011, at 12:18 AM, Beat Rubischon wrote:

> Hi Fred!
> 
> On 26.11.11 01:22, Frederic Bovy wrote:
>> Le 25 nov. 2011 à 05:55, Marc Heuse a écrit :
> 
>>> But anybody who introduces IPv6 in the internal network without a
>>> business need should be fired. for a waste of human resource, harder
>>> troubleshooting, more error prone networks - and increased security risks.
>> Do you recommend  Application Layer Proxies,  NAT46 or NAT-PT for these users ?
> 
> It's really a good question. Today we have good rules of thumb how to
> operate a company IPv4 network. Use a NAT firewall, internal DHCP and
> DNS, probably some ActiveDirectory and Exchange. This is the "way to go".
> 

First, there is no such thing as a "NAT firewall".

There are lots of Firewalls with NAT. There are lots of NATs without firewalls.

NAT isn't part of security except in the most arcane and generally harmful
sense of the word. NAT is a potential privacy enabler, except that address
obfuscation really does little for privacy in the modern internet, so, it's really
useless there, too.

DHCP does little for security other than helping to fill in pieces of the log file
associating a Mac address with a name. DNS generally depends on DHCP
for the most part.

I'm really not sure how you can even think that ActiveDirectory or Exchange
help in the security equation. They're at best a necessary evil in some
environments I've dealt with. Ideally, I avoid both of them wherever possible.

> When deploying IPv6 in such an environment you have a bunch of open
> questions:
> 
> - How to convince the management the firewall is working?

I would say pretty much the same way you do with IPv4. Conduct routine pen.
testing and other experiments for validation.

> - How to convince the users their privacy is guaranteed?

If you have convinced your users that this is true in IPv4, then, your users will
believe just about anything, so, I'm not sure why you are worried.

> - How to handle DNS? Expose the internal DNS to the IPv6 world? Fake PTR
> records for the external world? Don't care about name resolution?

Any of these are reasonable answers and you should pick the one that fits
the needs of your organization best. There are also some others:

	Partitioned DNS with Views -- Internal views are different from external
	views. BIND has supported this for years. If you're using Active directory
	or some other DNS, you're on your own, but, I hear many
	of them support views or something like it as well. Worst case, you use
	different authoritative servers for internal vs. external.

	PTR records aren't really necessary unless the machine is expected to
	make connections to external MTAs. Beyond that, they're kind of a nice
	to have when they make sense. I suspect that the long-term norm for
	DNS zones that would normally have $GENERATE in them today
	or address ranges that would today be obfuscated by NAT of a single
	address will have synthesized responses in the near future.
	(The DNS server makes up a PTR record on the fly in response to a
	request that doesn't have an overriding static record in the zone).

> - What about all those Windows 2003 and XP based systems? Run them IPv4
> only and hope the ActiveDirectory won't fail?
> 

Isn't that what you do now? I don't see how IPv6 changes that. XP can actually
deal with IPv6 so long as you don't expect it to work without IPv4 for DNS
resolving.

> I'm running my home network dual stack for more then 6 years. An
> "academic like setup" where most of my boxes have public IPv4/IPv6
> addresses. But the upper questions stops me from deploying IPv6 in my
> employers network...
> 

I'm running dual stack at home and at work. At work, many of the machines
have RFC-1918 IPv4 and NAT, but, many others have public IPv4 addresses.
At home, there's no RFC-1918 space and everything has had public IPv4
addresses for multiple decades. The IPv6 is all NAT free at home and at
work, of course.

The questions above seem pretty rudimentary and the answers above have
worked well in my environments. YMMV.

> The only way I see currently is a deployment in large scale companies
> where the border between the internet and the internal network is
> already realized by proxies. You have a clean separation between the
> internal infrastructure and the world. You may start by enabling the
> proxies to ask for IPv6 content - you may start by enabling RFC4193
> addresses inside. But for the classic small company with one to a few
> hundreds employees? No chance. You will be a trendsetter which will make
> a lot of mistakes and invest a lot of time and money.
> 

If you want to continue crippling your network, go for it. We use straight
stateful inspection between the corporate network and the internet for
our IPv6 and it works just fine. We don't feel the need for RFC4193 addresses
inside, though we don't prevent them either. Frankly, on a corporate
network, I'd be much more likely to set the M bit and go with DHCP
assigned addresses if you feel compelled to obfuscate the MAC address,
but, I hardly see the point in obfuscating MAC addresses when cookies,
spyware javadots, and the like do a perfectly good job of tracking not only
the machine, but, likely the individual using it with much more detail.

> But of course, the main motivation is missing. There is no need to run
> IPv6. No content is IPv6 _only_. Additional there is no longer a need to
> be reachable to provide content to the internet - just post your holiday
> pictures on one of the famous Web2.0 services. The people learned to
> accept to be NATed from their fancy mobile devices. They learned that
> they have to roll out a VPN when accessing their office documents.
> 

Web2.0 is very much limited by NAT. It's definitely not a full-featured
second internet as you describe it. In fact, it's not even that much
of the current internet from where I'm sitting. Yeah, it's the latest
craze and it's the second biggest buzzword de jour (next to "cloud",
whatever foggy notion that has for your mind).

The cloud definitely won't scale as planned without IPv6, so...

> The migration to IPv6 was probably started to late. It is basically
> killed by Web2.0 (the second "new internet") and the smartphones.
> 

No, it really isn't. In fact, more and more smartphones are moving
towards IPv6 and the cellular networks aren't going to be all that
far behind. T-mo is already pushing IPv6 big time, as are some of
the European carriers. Verizon is also planning significant IPv6
dependency in their LTE rollout. Even AT&T will probably figure it out
in a few years (there are signs that they can spell IPv6 now.)

> I assume IPv6 will stay a toy for geeks like us. The 99% will be happy
> when their ISPs annouces "hey, from tomorrow you are firewalled" and
> accept that a public IP will cost some additional $$$. They won't care
> about it and we'll have enough address range for the next years.
> 

I think they will be less happy than you imagine. The average public
won't know what that means or care what a public IP is. All they will
really notice is "Hey, my PS3 stopped being able to host games and
half the shit my X-Box used to do stopped working."

In the access market where a single tech-support call costs at least
6 months of profits from the customer in question, I wouldn't want to
be in the call center dealing with all those customers, let alone in the
accounting department that has to tally up those losses.

> Sounds a bit disaffected? Yes. Hopefully the world will tell me the
> contrary :-)
> 

I'm pretty sure it will, but i'm just a silly American.

Owen