misunderstanding scale

Tue Mar 25 01:41:03 UTC 2014

> "Your attack surface has already expanded whether or not you deploy IPv6."
> Not so.  If I don't enable IPv6 on my hosts, the attacker can yammer
> away via IPv6 all day long with no result.

If that were true, yes. The reality is that to make that a true statement,
you would have to modify it to:

“If I specifically disable IPv6 on every single one of my hosts well enough
that a compromised host cannot have IPv6 turned back on, the attacker
can yammer away via IPv6 all day long with no result.”

Best of luck achieving that with any operating system newer than, say,
Windows ME.

> "And if an enterprise doesn't have firewalls in place, then their
> devices are already accessible."
> For those devices that have publicly routable IP addresses, sure.

Even for those that do not. It’s actually not that hard to craft a sequence
of packets that can get past a NAT if you have even one compromised
host somewhere behind the NAT.

> "I've simply pointed out that it really isn't any harder to plan and
> manage for v6 than for v4"
> Except it is.  I get your point that there aren't any additional
> vulnerabilities in v6 than they are in v4.  My point is that it's a
> lot more work.  And as someone who's facing this issue right now, I
> promise you...it's a lot more work.  I'm not saying it's not worth the
> effort nor that it's unnecessary...but to imply that securing v6 is an
> easy step up from securing v4 is inaccurate.

It’s a little more work, but it doesn’t have to be a lot more work to achieve
roughly the same security posture in IPv6 that you have in IPv4.

It is, actually, a fairly easy step up in most cases. A little bit of a learning
curve, but otherwise, most of the mitigation strategies are very similar and
take about the same amount of effort. The difference comes from the fact
that you’re facing all of the IPv6 stuff at once where you built the IPv4
mitigations over many years as vulnerabilities were discovered.

> "Simply pretending that if you don't enable IPv6, you're somehow
> immune from IPv6 threats is naïve."
> No.  If I turn off v6 in my kernel, I am absolutely immune from native
> v6 threats.  I'm happy to be proven wrong if you can show me a case
> where this isn't so.

Is it so thoroughly turned off that a compromised host can’t modprobe it back on?

If not, then absolutely immune is an interesting statement.

Are you sure you have done that on every single host that has any ability whatsoever
to get onto your network, including whatever laptop a vendor might bring into a wireless
network or conference room? Whatever networks service technicians might plug their
devices into? etc.?

You can’t just not turn on IPv6… You have to actively turn it off on absolutely every single
device everywhere in order to achieve what you claim.

> Everything you've said is correct.  But my point is simply that there
> *are* security considerations when deploying v6, and they're bigger
> than some rare and esoteric bug that's only exploitable when all the
> stars align.  With v6, a simple misconfiguration can open up every
> single host directly to the outside.  The same simply isn't true with
> NAT where you have to explicitly define inbound rules.

It is, actually… You don’t have to explicitly define inbound rules to open up
all the hosts. True, the attacker doesn’t have quite the easy ability to target
each host specifically, but there are lots of ways to attack hosts behind a NAT
that happen to be kind enough to initiate outbound sessions. With many firewalls,
there are even ways to exploit interesting artifacts of the way certain “savings”
are implemented in the NAT table process that allow you to create sessions that
don’t exactly match the outbound traffic.

Owen