[ipv6hackers] "Stick to limited IPv6 deployments, businesses warned"

[Owen DeLong]

On Aug 28, 2012, at 09:01 , Fernando Gont <fgont at si6networks.com> wrote:

> Hi, Owen,
> 
> On 08/28/2012 11:33 AM, Owen DeLong wrote:
>>>> I also believe there is tremendous benefit for innovation with IPv6.
>>> 
>>> This has been claimed for ages -- yet we have not had a single killer
>>> application.
>> 
>> You can't have a killer app for an internet that doesn't exist yet. 
> 
> And many people might argue that they won't put money for the alleged
> *potential* for innovation.
> 

Sure... So ignore that potential and consider just basic business continuity.

Like it or not, IPv4 has been on life-support for years and is rapidly approaching the network equivalent of Diverse Intravascular coagulopathy. (look it up if you need to).

IPv4 is already dysfunctional and severely degraded from its original design and continuing to get worse. When we actually have no more IPv4 addresses to give out (which is coming sooner than a lot of people realize), the progression of that degradation will accelerate sharply. (much like the progression of a patient entering DIC).

If you like having a ubiquitous internet, the best way to preserve it is to deploy IPv6 sooner rather than waiting.

> 
> 
>>>> NAT has become a strangle hold choking off innovation.  
>>> 
>>> At least half of the problems "introduced" by NATs are also introduced
>>> by firewalls that "only allow return traffic"  -- So I don't necessarily
>>> buy the "IPv6 fosters innovation" thing...
>> 
>> Except that the firewalls _CAN_ be told to pass what you want. There is
>> no such possibility with NAT.
> 
> I doubt any regular home user will tell his home firewall to pass this
> or that.
> 

They do today in IPv4, why wouldn't they do so in IPv6?

What do you think uPNP/NAT-PMP are?

What do you think "DMZ Host" features, etc. are?

> 
> 
>>>> no way.  Deploying IPv6 provides virtually limitless address space
>>>> and makes it far easier for developers to come up with fantastic new
>>>> applications.  
>>> 
>>> Some might argue "gimme the IPv6 killer app, and I'll do the ipv6
>>> roll-out if the app is good enough".
>> 
>> That's like saying "Give me the web and I'll consider rolling out IPv4."
> 
> Another way to see it is that the world got online because they had the
> web -- as opposed to the world coming online just to se "what might happen".
> 

But the web would never have been developed if CERN didn't already have IPv4.

>>> Quoting Bertrand Russell:
>>> 
>>> "When you are studying any matter, or considering any philosophy, ask
>>> yourself only what are the facts and what is the truth that the facts
>>> bear out. Never let yourself be diverted either by what you wish to
>>> believe, or by what you think would have beneficent social effects if it
>>> were believed. But look only, and solely, at what are the facts."
>> 
>> Yes... This applies very much to things you and Marc tend to say...
> 
> I'd argue that 99% of what I've said on the subject has been about
> technical aspects of the protocol.
> 

I would argue that what you have said about what is wrong with the protocol (which is about 50% of what you have said) fits into that description. The other part, where you start telling people not to deploy or to delay deployment, OTOH, is fear mongering and ignores the very real risks inherent in those actions.

Let's consider this in context...

What is the relative risk to the global internet in general from the sum of all of the attacks you've described so far (ND exhaustion, RA, RA Guard circumvention, etc.) when compared to the relative risks inherent in running IPv4 today?

Further, what is the relative risk to the global internet in general from the sum of all of those attacks compared to the risks inherent in attempting to continue running IPv4 with another billion or so people connected? How does the risk inherent in IPv6 today compare to the risk inherent in things like CGN?

>> Do not ignore the fact that we are running out of IPv4 addresses.
>> Do not ignore the fact that no matter how problematic the security issues
> [...]
> 
> The real reason for deploying v6 is that we are running out of v4
> addresses -- that's enough of a reason, and nobody is arguing against that.
> 

But when you get headlines like "Do only limited IPv6 deployments", the people behind those headlines _ARE_ effectively arguing against that, whether they intend to or not.

>> Consider when evaluating IPv6 deployment, not only the facts of the
>> security issues raised, but also the facts and implications and
>> consequences of failing to deploy IPv6 in a timely manner.
> 
> These tends to vary from one case to another.
> 

Not really... I'm talking about the internet-systemic consequences, not just the local consequences.

I'm talking about the global consequences of large scale CGN deployment. The global consequences of an internet where we must maintain support for an ever-increasing number of IPv4 eyeballs that cannot get useful IPv4 addresses and are subjected to increasing layers of hackery just to get basic web functionality while allowing all other services to be sacrificed to do so (including advanced web functionality and VOIP).

>>> Most of the time I get the impression that IPv6 proponents essentially
>>> try to squelch any discussions about IPv6
>>> drawbacks/vulnerabilities/problems, yet they fail to support any efforts
>>> in improving the current state of affairs.
>> 
>> I don't think you've ever seen me attempt to squelch such a discussion.
>> I simply draw the line when you start saying that the drawbacks you
>> have mentioned to date should be given enough weight to delay or
>> avoid deploying IPv6 in general.
> 
> I never made such a claim -- fwiw, the decision of where and when to
> deploy v6 varies from one case to another.

But this thread started not from what you said, but in response to an article quoting Marc Heuse. You jumped in to defend his position and, thus, you get tarred with the same brush.

If that article had read "IPv6 has the following flaws, but we have to deploy it anyway and fix the flaws ASAP", I'd have been in full agreement. But that's not what it said. It advocated dragging your feet on IPv6 deployment in the enterprise and that's an untenable and utterly indefensible position.

>>> As a data-point, look at the lengthy discussions we have had about
>>> RA-Guard, how trivial it is to evade current implementations, and
>>> whether that makes the IPv6 world any worse (or not) than the IPv4 world.
>> 
>> Consider this... What fraction of IPv4 networks with DHCP run DHCP
>> snooping? 
> 
> The you might also argue "what fraction of the end-user Internet runs
> without a NAT" and argue in favour of IPv6 NAT, too...

You might argue anything you like. You could argue that some percentage of each 24 hour cycle is dark, so we should look for ways to make the dark last longer, but it would be equally daft.

What actual benefit would come from carrying the dysfunction currently inflicted on most IPv4 end-users over to IPv6?

My point is that the only way you can claim the IPv4 DHCP situation is better than the situation with RAs today is _IF_ you have widespread deployment and use of DHCP snooping. Since that is not the real-world case, apparently these risks are deemed acceptable by the majority of operators.

NAT, OTOH, isn't so much a choice as a necessity for address conservation. The whole point of IPv6 is to eliminate the need for that kind of drastic address conservation.

>> If you can show me that it is even 10%, then, you might
>> have a real world case. My observation in the real world is that it is
>> less than 5%. As such, I don't think that RA without RA Guard is
>> necessarily much worse than the current deployed state of IPv4.
> 
> Agreed. Although the RAs might have implications on IPv4 in unexpected
> ways...
> 

You'd need to elaborate on that one as it currently seems nonsensical to me.

>>> Yet when there was time to support a proposal to fix RA-Guard (now
>>> draft-ietf-v6ops-ra-guard-implementation), there were only a few folks
>>> there...
>> 
>> It seems to be making its way forward.
> 
> Yes -- with the investment of way too much energy, way too many
> discussions, and fewer people supporting it than I would have expected.
> 

Welcome to the real world. Most of us recognize that the problem you are describing is factual, but most likely more theoretical than realized. Evaluating risks in the real world, rather than from the security zealot perspective requires incorporating not only the possibility of something occurring, but also the difficulty of mitigation, the probability of it occurring, the value to the would-be attacker, etc.

The reality is that all of the flaws you have described are:
	1.	Relatively low impact (yes, they can have instantaneous high impact, but not sustained).
	2.	Very low gain for the attacker in most cases.
	3.	Generally have equivalent vulnerabilities in IPv4.

You don't get a lot of support from operators because they're too busy trying to cope with running their networks to pay much attention:
	1.	They still perceive IPv6 as a problem for the future and hope these will be solved by the time they get there.
	2.	They look at the above list and figure "Meh, hope they solve some of these soon, but it's not really worse than IPv4"
	3.	You may have noticed operators don't tend to participate in IETF much in general... They're too busy running networks.

As a result, IETF consists mostly of academics and vendors.

You don't get much support from academics because they love to take devil's advocate positions on anything presented.

You don't get much support from vendors because they don't want to add to their already full plates.

I bet you're not getting much opposition, either (except for the academics as described above). ;-)

> 
> [....]
>> I've never claimed there are no problems with IPv6. I have, however, claimed
>> that the problems created by failing to deploy IPv6 in a timely manner
>> massively outweigh the problems mentioned in IPv6 to date.
> 
> That varies from one case to another, and also varies depending whether
> you mean "collective problems" to "individual problems". In some cases,
> you need collective "help" for the benefits, while individual action for
> the drawbacks.
> 

I don't think it does... I see failure to deploy IPv6 at the enterprise level as a toxic-polluter model of problem for the internet as a whole.

> Again, whether and where to deploy varies from one case to another --
> and in all cases, should all cases, deployment should be done only after
> proper training.

While I agree that would be ideal, the reality is that deployment has to move forward and deploying IPv6 without proper training isn't actually going to be much worse than where we are today with IPv4 being deployed mostly by people who lack proper training. We need to accept that reality and make the best of it. Creating articles urging enterprises to delay or avoid IPv6 deployment does not improve that situation.

I'm all for encouraging enterprises to get proper training... I make money from them doing so. ;-)

Owen