Re: misunderstanding scale

[Mike Hale <eyeronic.design () gmail com>]

"then there aren't any inherent security weaknesses preventing its
adoption by enterprises."
You're right.  There's not an inherent security weakness in the
protocol.  The increased risk is due to the increase in your attack
surface (IMHO).

"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.

"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.

"My organization is particularly strict at our perimeter"
Then sir, you're in a fortunate and small group.

"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.

"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.

Mark:
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.

Again...I'm not saying these considerations are insurmountable.  I'm
not saying you shouldn't deploy v6 because of potential security
holes.  But to sound dismissive of those security considerations
involved with deploying v6 is very counterproductive.


On Sun, Mar 23, 2014 at 6:25 PM, Timothy Morizot <tmorizot () gmail com> wrote:
> On Mar 23, 2014 7:54 PM, "Mike Hale" <eyeronic.design () gmail com> wrote:
> > "unless by few you simply mean a minority"
> > Which I do.
>
> Then that's fine. But there are numerous enterprises in that minority and it
> includes some pretty large enterprises. My own enterprise organization has
> more than 600 sites, 100k employees, and thousands of contractors.
>
> > "appropriately mitigating the security risks shows the claim that
> > there are security weaknesses in IPv6 preventing its adoption is
> > false."
> > No.  It doesn't.  It's not the sole reason, but it's a huge factor to
> > consider.
>
> Logic 101? If security-conscious enterprises have successfully implemented
> IPv6 while mitigating the security risks, then there aren't any inherent
> security weaknesses preventing its adoption by enterprises. A non-FUD
> statement would be that we've assessed our infrastructure and preparedness
> for IPv6 and aren't yet in a position where we can safely deploy IPv6. A FUD
> statement is the assertion that there are inherent security weaknesses in
> the protocol preventing enterprises from deploying it.
>
> > There is because it doubles your attack surface at the very least.  At
> > the worst, it increases it exponentially since suddenly all your
> > internal devices (that were never configured to be public-facing) are
> > suddenly accessible from everywhere.
>
> It's an IPv6 world. Your attack surface has already expanded whether or not
> you deploy IPv6. In fact, an enterprise will be making itself increasingly
> vulnerable to IPv6 attacks by refusing to deploy it than by securely
> enabling and controlling the protocol.
>
> And if an enterprise doesn't have firewalls in place, then their devices are
> already accessible. NAT44 doesn't provide any meaningful security
> protection. If you have firewalls with appropriate policies, then it's silly
> to claim your internal devices are suddenly accessible from everywhere. My
> organization is particularly strict at our perimeter. Everything is default
> deny in both directions for both protocols and we very carefully open holes.
> We also allow very little unproxied access to the Internet. (DNS, SMTP, and
> HTTP/HTTPS being the most common services provided in our Internet access
> points.)
>
> > None of this isn't preventable, by the way.  There are a myriad of
> > solutions that can and do mitigate these risks.  But to simply dismiss
> > the security considerations is, I think, incredibly naïve and
> > unrealistic.
>
> Nowhere have I dismissed security considerations for either IPv4 or IPv6.
> I've simply pointed out that it really isn't any harder to plan and manage
> for v6 than for v4. And we currently live in a dual-protocol Internet.
> Simply pretending that if you don't enable IPv6, you're somehow immune from
> IPv6 threats is naive.
>
> Scott



-- 
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0