On Aug 28, 2012, at 05:13 , Fernando Gont <fg...@si6networks.com> wrote:
> On 08/23/2012 10:04 AM, Jim Small wrote:
>> Marc - I agree that security could be better and there are still
>> some things that need to be addressed. That said, in the space I
>> work in Cisco and Microsoft have done IMHO a pretty good job
>> addressing the issues.
> FWIW, in mine, they haven't.
Here, I mostly agree with Fernando.
>> 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. There's
room for tremendous innovation once IPv6 is deployed. Until it's deployed,
developers can't even begin to notice it, let alone take advantage of it.
(The potential for innovation, not IPv6).
>> 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.
>> 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."
The web came into existence because IPv4 was already deployed,
not the other way around. The moon existed before we developed
spacecraft, not the other way around.
>> I know you're a great guy and I agree the security issues need to be
>> fixed, but how is this helping us move forward?
> Without necessarily agreeing with eveything that Marc said (or
> "allegedly said"), I'd note that opinions should not be judged on the
> basis of how happy the make us feel.
True, but...
> 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...
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
you have raised with IPv6 (which I think in a real-world evaluation
are relatively low risk) may be, the bigger risk to the functionality
of the internet in general is widespread NAT444/CGN.
Do not ignore the fact that just the geolocation implications of NAT444
are nearly enough to give one pause.
Do not ignore the security implications from an audit and event correlation
perspective that are inherent in CGN.
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.
> Clearly, if we find any problems, we shouldn't stop there, but that
> should be our starting point for engineering solutions. But that
> starting point is *needed*.
Agreed. I don't think anyone is saying that you shouldn't call attention
to the security problems or that vendors should not work diligently
to solve them.
However, claiming that they should delay or derail an IPv6 rollout at
this point can only be accepted if one utterly and completely ignores
the truly heinous consequences of keeping IPv4 on life support for
another 5-10 years, if that is even possible.
> 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.
Any such advice is, IMHO, a disservice to the community due to the
extreme consequences inherent in following it.
> 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? 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.
RA Guard improves this situation (if people use it). Fixed RA-Guard
as you have proposed will improve it even more (if people use it).
> 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.
> If half of the energy spent on convincing people (or pretending) that
> there are no problems with v6 was spent in producing tools (such as
> THC-IPv6), discussing the problems (to eventually engineer workarounds),
> producing proposals for improvements, supporting existing proposals for
> improvements, or slapping vendors that essentially refrain from fixing
> their own vulnerable stacks, the IPv6 world would certainly be a much
> better place.
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.
>>> 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.
>>> 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.
>>> 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".
>> 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.
> 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.
> 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.
>> 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.
>> 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...
> 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...
>> 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.
[....]
> 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.
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.
> 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
> you have raised with IPv6 (which I think in a real-world evaluation
> are relatively low risk) may be, the bigger risk to the functionality
> of the internet in general is widespread NAT444/CGN.
> Do not ignore the fact that just the geolocation implications of NAT444
> are nearly enough to give one pause.
> Do not ignore the security implications from an audit and event correlation
> perspective that are inherent in CGN.
Amen. The only solution going forward is to deploy IPv6. I think its important to discuss the risks and mitigations but to tell people they need to move forward. Telling them to start with a pilot before moving to production is prudent and arguably common sense. Telling them they should hold off or delay is unwise at best. How is this helping improve security or addressing IPv4 depletion?
> > 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? 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.
> RA Guard improves this situation (if people use it). Fixed RA-Guard
> as you have proposed will improve it even more (if people use it).
I'm sorry to say my broad view of this as a consultant who deploys networks for a living at companies is far lower. I would be surprised if it's even 1%. I think perhaps 5% may start with trying to enable it, but as soon as it breaks something (which it frequently does) then the extra security features are disabled. There are always good intentions to circle back and dig in which unfortunately rarely happen.
> > If half of the energy spent on convincing people (or pretending) that
> > there are no problems with v6 was spent in producing tools (such as
> > THC-IPv6), discussing the problems (to eventually engineer workarounds),
> > producing proposals for improvements, supporting existing proposals for
> > improvements, or slapping vendors that essentially refrain from fixing
> > their own vulnerable stacks, the IPv6 world would certainly be a much
> > better place.
> 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.
Agreed - we need to discuss the risks and mitigations without delaying forward progress. Perhaps we should work on a check list(s) for issues/solutions to firewalls, routers, switches, O/S, etc?
> > 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.
Of course not. Based on history I would expect a killer application to appear when we hit 10% Internet traffic penetration. That will constitute enough of an audience to attract developer attention. I'm guessing this is around 2014.
> > 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...
True, but firewalls are much easier to configure than NAT. As someone who does network/security consulting and teaching for a living I can tell you that most people struggle with NAT but not with firewall rules.
> > 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".
It is a little bit of the chicken and egg problem, but really IPv6 is the area code problem. What do you do in the telephone system when a region/country runs out of area codes? You have to expand the address system. Ask anyone outside of IT if they would be willing to put their neighborhood behind a PBX to preclude expanding the addressing system and they'll laugh at you. They would never accept such a change. In order to support Internet growth and facilitate easy communication (the point of networking and IP!) we need IPv6.
>> 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
>> you have raised with IPv6 (which I think in a real-world evaluation
>> are relatively low risk) may be, the bigger risk to the functionality
>> of the internet in general is widespread NAT444/CGN.
>> Do not ignore the fact that just the geolocation implications of NAT444
>> are nearly enough to give one pause.
>> Do not ignore the security implications from an audit and event correlation
>> perspective that are inherent in CGN.
> Amen. The only solution going forward is to deploy IPv6. I think its important to discuss the risks and mitigations but to tell people they need to move forward. Telling them to start with a pilot before moving to production is prudent and arguably common sense. Telling them they should hold off or delay is unwise at best. How is this helping improve security or addressing IPv4 depletion?
>>> 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? 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.
>> RA Guard improves this situation (if people use it). Fixed RA-Guard
>> as you have proposed will improve it even more (if people use it).
> I'm sorry to say my broad view of this as a consultant who deploys networks for a living at companies is far lower. I would be surprised if it's even 1%. I think perhaps 5% may start with trying to enable it, but as soon as it breaks something (which it frequently does) then the extra security features are disabled. There are always good intentions to circle back and dig in which unfortunately rarely happen.
I was trying to be somewhat generous and use numbers that were sure to be an overestimation of what the more security zealous among this list would likely see in the environments that they are aware of.
I didn't want one of them to be able to come back and say my estimate was way too low. ;-)
>>> If half of the energy spent on convincing people (or pretending) that
>>> there are no problems with v6 was spent in producing tools (such as
>>> THC-IPv6), discussing the problems (to eventually engineer workarounds),
>>> producing proposals for improvements, supporting existing proposals for
>>> improvements, or slapping vendors that essentially refrain from fixing
>>> their own vulnerable stacks, the IPv6 world would certainly be a much
>>> better place.
>> 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.
> Agreed - we need to discuss the risks and mitigations without delaying forward progress. Perhaps we should work on a check list(s) for issues/solutions to firewalls, routers, switches, O/S, etc?
Generally (based on the HW), Cisco switches have the option of dropping 'undertermined-transport' packets (= first fragment where there is no layer 4 information) which, when combined with RA-guard, then does the job.
Specifically about Cat 3560-X, the HW cannot do it but can drop all fragments sent from a LLA (in addition to RA-guard). Which is the best it can do, this would prevent the fragmented rogue RA attack but could also have some false positive (which is why I am a strong supporter of your other I-D about those packets)
> If half of the energy spent on convincing people (or pretending) that
> there are no problems with v6 was spent in producing tools (such as
> THC-IPv6), discussing the problems (to eventually engineer
> workarounds), producing proposals for improvements, supporting
> existing proposals for improvements, or slapping vendors that
> essentially refrain from fixing their own vulnerable stacks, the IPv6
> world would certainly be a much better place. Cheers,
Completely agree with that view. It seems to me that IPv6 community
don't want to hear anything wrong about IPv6, specially from operational
guys. It is not only about RA-Guard. Just same story we can see in cases
like ND cache exhaustion, default route in DHCPv6, MAC address in DHCPv6
etc. We can observe endless discusses in IETF, nanog or this list,
however with very small impact on standardization and in the result on
implementation in the devices.
For example today, I am not able to buy device that supports either
RA-Guard or PACL for a good price. Devices that support that features
are usually about 40% (or in same cases 160%) more expensive comparing
the devices that supports that features for IPv4 (see slide 45 on
http://ipv6.vutbr.cz/wordpress/wp-content/uploads/2012/05/tnc2012_sli...).
Having practical experience with IPv6 deploying I can frankly said that
is all about big compromises, disappointments and lot of effort put into
IPv6. Problems that we had 4-5 years ago (for example rogue routers) are
just the same today. From the operational perspective nothing has
happened. We then can't be surprised that IPv6 adoption is so slow. I
am asking myself - is there any chance that something that something
change in the future? I am starting to have doubts about it. But maybe
I am wrong.
On Aug 28, 2012, at 09:01 , Fernando Gont <fg...@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
...
On 29 Aug 2012, at 11:27, Tomas Podermanski <tpo...@cis.vutbr.cz> wrote:
> Completely agree with that view. It seems to me that IPv6 community
> don't want to hear anything wrong about IPv6, specially from operational
> guys. It is not only about RA-Guard. Just same story we can see in cases
> like ND cache exhaustion, default route in DHCPv6, MAC address in DHCPv6
> etc. We can observe endless discusses in IETF, nanog or this list,
> however with very small impact on standardization and in the result on
> implementation in the devices.
Well, each of the three issues you describe above have IETF drafts that are edging towards publication. These issues have been raised for some time. Some, e.g. DHCPv6 route option, invoke quite strong views, while others, e.g. ND cache exhaustion, are much simpler to address.
> I suggest formatting the above as an Internet-Draft and submitting it.
Certainly worth running through to extract any protocol issues that as yet have not been covered elsewhere, and identifying if protocol changes are required or whether the issue is operational (best practice). Lack of vendor implementation isn't in itself an IETF issue.
>> 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
Agreed. -- the problem is that when the wrong argument is used to "sell"
v6, the important one is lost.
> IPv4 is already dysfunctional and severely degraded from its original
> design and continuing to get worse.
A large part of this will likely be replicated in v6: -- e.g., replace
the border NAT with an actual firewall.
What will certainly be a great degradation is the use of CGNs and the
like. -- and yes, we need IPv6 to avoid that in the near7long term.
>> 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?
Does "uncle Joe" know what a DMZ is in the first place?
Regular users just buy a wireless router at Walmart that just works
auto-magically.
>>> 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,
I haven't said that -- although I have noted that "what to do" varies
from one case to another.
> OTOH, is fear mongering and ignores
> the very real risks inherent in those actions.
Let me give you a data-point:
OpenBSD has had a reputable history of only a couple of
remotely-exploitable vulnerabilities in the default install for years.
Last one (?), in more than 8 years, was IPv6-based. A server with v6
enabled could have had its super-secure server hacked because of that.
If the oraganization had a good reason for having v6 there, good. If
not, they guy that recommended to have v6 there could be in trouble. --
This is probably where Marc was coming from.
> 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?
You should d such risk analysis for the organization that is going to
deploy v6, not for "the global internet".
> 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?
I'd certainly *not* go with CGNs.
>> 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.
1) The press is the press, and its not uncommon for reports to come up
with catchy or controversial headlines.
2) Where and when to deploy v6 varies from one case from another.
3) You should not be surprised to hear from a security guy things like
"you should only use/install/deploy this if you really need it" -- KISS
principle.
>>> 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.
Humans re generally selfish. Don't be frustrated if people do't do
things for "the common good" -- most companies are there to make money..
not to make the "world" a better place.
> I'm talking about the global consequences of large scale CGN
> deployment.
I fully agree with this -- but please see my note about the "common good".
>>> 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.
I jumped to say that there's a valid/understandable point in what Marc
said -- even if such point doesn't make the ipv6 world happy.
> If that article had read "IPv6 has the following flaws, but we have
> to deploy it anyway and fix the flaws ASAP",
I'd argue that a security guy arguing that should probably be fired. :-)
> 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.
No. The DHCP situation is worse in v6 than in v4 because in v4, if you
want to mitigate it, you can. In v6, if you want to mitigate it, you can't.
>> 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.
I will, in a separate e-mail.
>> 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.
Welcome to the real world: companies will deploy stuff if it not doing
so will prevent to make money *today*, and not for the "common good".
> 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.
Exactly. And that varies from organization to organization.
> As a result, IETF consists mostly of academics and vendors.
[...]
I'd would expect the ones voicing their irritation about article
headlines to invest that energy in supporting mitigation proposals.
Other than that, I do agree with your assessment about the IETF. :-)
>> 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
Deploying v6 without proper training is simply insane. It sounds pretty
much like "let's get on this plane that none knows how to pilot" -- most
likely with similar expected consequences.
On Aug 30, 2012, at 12:58 , Fernando Gont <fg...@si6networks.com> wrote:
> On 08/29/2012 11:46 AM, Owen DeLong wrote:
>>> 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
> Agreed. -- the problem is that when the wrong argument is used to "sell"
> v6, the important one is lost.
I disagree... All of the arguments for IPv6 migration are valid. The fact that IPv4 will descend rapidly into madness over the next few years is merely the most compelling of all of them.
>> IPv4 is already dysfunctional and severely degraded from its original
>> design and continuing to get worse.
> A large part of this will likely be replicated in v6: -- e.g., replace
> the border NAT with an actual firewall.
An actual firewall is not as harmful as NAT and is much more easily corrected if we don't make the addressing mistakes made in IPv4 to support "address compression".
> What will certainly be a great degradation is the use of CGNs and the
> like. -- and yes, we need IPv6 to avoid that in the near7long term.
Yep.
>>> 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?
> Does "uncle Joe" know what a DMZ is in the first place?
Depends on whose uncle Joe. However, in actual fact, the vast majority of home routers are not administered by uncle Joe. Uncle Joe usually knows to call nephew Billy, 'cause he understands that thar techknowledgey [sic] stuff.
> Regular users just buy a wireless router at Walmart that just works
> auto-magically.
Some yes, some no. Lots of users have X-Boxes and the like that end up providing users with detailed instructions on how to open up port forwarding or the like to make their games work. It's _ALOT_ more common than you may think.
>>>> 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,
> I haven't said that -- although I have noted that "what to do" varies
> from one case to another.
You came out in support of Marc Heuse saying it. To me, that's effectively
you repeating it.
>> OTOH, is fear mongering and ignores
>> the very real risks inherent in those actions.
> Let me give you a data-point:
> OpenBSD has had a reputable history of only a couple of
> remotely-exploitable vulnerabilities in the default install for years.
> Last one (?), in more than 8 years, was IPv6-based. A server with v6
> enabled could have had its super-secure server hacked because of that.
> If the oraganization had a good reason for having v6 there, good. If
> not, they guy that recommended to have v6 there could be in trouble. --
> This is probably where Marc was coming from.
2005 -- 7 years ago, 802.11 protocol stack regardless of IP version
Yes, the IPv6 mbuf hole was more recent that that. Most likely because BSD did some modification to the IPv6 code.
In reality it's not significantly less likely that some future IPv4 patch could introduce a similar vulnerability in IPv4 and merely a coincidence that this happened to occur in IPv6.
I really don't think it's anything to hang a "IPv6 is more dangerous" hat on. It could very easily have gone the other direction and you wouldn't be willing to accept that as evidence that IPv4 was less secure.
>> 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?
> You should d such risk analysis for the organization that is going to
> deploy v6, not for "the global internet".
I disagree. There is an important element of risk to the global internet if enough
organizations fail to deploy IPv6. The more organizations fail to deploy IPv6, the
more inevitable CGN becomes at other places on the internet. That's why I refer
to IPv6 resistance as toxic polluter... An organization choosing not to implement
IPv6 has impact on organizations well outside their borders, even if they do not
feel that impact. Just like dumping toxic sludge into the stream at the edge of
your property affects the people downstream while your cattle don't even get sick.
>> 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?
> I'd certainly *not* go with CGNs.
Then you, sir, have made my argument for the need to consider the global
risk to the internet as a factor in your decision to implement IPv6 or not.
>>> 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.
> 1) The press is the press, and its not uncommon for reports to come up
> with catchy or controversial headlines.
It's not that hard to steer the headlines in most cases. It's not like I'm not
quoted in my share of press interviews.
> 2) Where and when to deploy v6 varies from one case from another.
To some extent, but, if you don't like CGN, there are a lot more places where
IPv6 is really needed than you seem to realize.
> 3) You should not be surprised to hear from a security guy things like
> "you should only use/install/deploy this if you really need it" -- KISS
> principle.
I'm all for the KISS principle. The sooner we stop farting around with this broken
IPv4 crap and move on, the sooner we can have a simple ubiquitous functional
internet that we can focus on improving.
All this energy we are expending trying to avoid deploying IPv6 and keep IPv4
on life support is really complicating the world.
KISS says you should deploy IPv6 everywhere as soon as practicable.
You cannot make a valid argument that IPv4 on life support and/or dual
stack is simpler than IPv6.
>>>> 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.
> Humans re generally selfish. Don't be frustrated if people do't do
> things for "the common good" -- most companies are there to make money..
> not to make the "world" a better place.
Yes, I'm well aware of this. However, failing to deploy IPv6 is both toxic
pollution _AND_ self-destructive in the long run.
>> I'm talking about the global consequences of large scale CGN
>> deployment.
> I fully agree with this -- but please see my note about the "common good".
>>>> 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.
> I jumped to say that there's a valid/understandable point in what Marc
> said -- even if such point doesn't make the ipv6 world happy.
I understand Marc's point, so, in that sense, yes, it's understandable. However,
he's still flat out wrong.
>> If that article had read "IPv6 has the following flaws, but we have
>> to deploy it anyway and fix the flaws ASAP",
> I'd argue that a security guy arguing that should probably be fired. :-)
If you made that argument to me, it wouldn't be the security guy that I fired.
>> 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.
> No. The DHCP situation is worse in v6 than in v4 because in v4, if you
> want to mitigate it, you can. In v6, if you want to mitigate it, you can't.
Huh? What can't you mitigate about DHCP in IPv6 that you can mitigate
in IPv4?
> I suggest formatting the above as an Internet-Draft and submitting it.
Never thought about it. However, I've got a good feedback from a few
people, so maybe it is something to thing about. It seems that it might
be useful for somebody.
>> Agreed. -- the problem is that when the wrong argument is used to
>> "sell" v6, the important one is lost.
> I disagree... All of the arguments for IPv6 migration are valid. The
> fact that IPv4 will descend rapidly into madness over the next few
> years is merely the most compelling of all of them.
The only argument for migration is that we're running out of IPv4
address space, and IPv6 is the only thing we have on the table to
address that problem.
>>> IPv4 is already dysfunctional and severely degraded from its
>>> original design and continuing to get worse.
>> A large part of this will likely be replicated in v6: -- e.g.,
>> replace the border NAT with an actual firewall.
> An actual firewall is not as harmful as NAT and is much more easily
> corrected if we don't make the addressing mistakes made in IPv4 to
> support "address compression".
For the most part, it is as painful as a NAT. NAT essentially make
broken application designs evident (e.g., passing addresses in the app
protocol).
Of course, CGns, and multilevel NAT is a different thing.
>> Regular users just buy a wireless router at Walmart that just
>> works auto-magically.
> Some yes, some no. Lots of users have X-Boxes and the like that end
> up providing users with detailed instructions on how to open up port
> forwarding or the like to make their games work. It's _ALOT_ more
> common than you may think.
Most of the non-technical users I know of have never configured their
home router.
>> I haven't said that -- although I have noted that "what to do"
>> varies from one case to another.
> You came out in support of Marc Heuse saying it. To me, that's
> effectively you repeating it.
I came in support of a guy that, after having done his good share of
IPv6 security, made a very understandable comment. And yes, from a
security standpoint, you deploy stuff only if you *need* it.
>> OpenBSD has had a reputable history of only a couple of >> remotely-exploitable vulnerabilities in the default install for
>> years. Last one (?), in more than 8 years, was IPv6-based. A server
>> with v6 enabled could have had its super-secure server hacked
>> because of that. If the oraganization had a good reason for having
>> v6 there, good. If not, they guy that recommended to have v6 there
>> could be in trouble. -- This is probably where Marc was coming
>> from.
> 2005 -- 7 years ago, 802.11 protocol stack regardless of IP version
Oh, come on.. there not even PoC code. That aside, I'm not sure what
you're trying to prove.
Even if the vulnerability you're referring to was legitimate, that
doesn't invalidate my point.
> Yes, the IPv6 mbuf hole was more recent that that. Most likely
> because BSD did some modification to the IPv6 code.
> In reality it's not significantly less likely that some future IPv4
> patch could introduce a similar vulnerability in IPv4 and merely a
> coincidence that this happened to occur in IPv6.
Futurology? :-)
Simple: programs have bugs. Less-tested code has even more bugs. IPv6
results in additional code, which is less tested than IPv4. Obviously,
having it there increases the chances of being vulnerable. -- and *this*
doesn't have anything to do with the IPv6 design, but rather with IPv6
implying new and less-tested code.
> I really don't think it's anything to hang a "IPv6 is more dangerous"
> hat on. It could very easily have gone the other direction and you
> wouldn't be willing to accept that as evidence that IPv4 was less
> secure.
IPv4 went exactly on the same direction. Look at the number of bugs in
IPv4 implementations that were found over the years. Now look at the
number of bugs found on IPv6 implementations. Substract the later from
the former, and that should give you an indication of the number of
bugs/vulnerabilities we still need to find in IPv6 implementations.
>>> 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?
>> You should d such risk analysis for the organization that is going
>> to deploy v6, not for "the global internet".
> I disagree. There is an important element of risk to the global
> internet if enough organizations fail to deploy IPv6.
Again: You suffer the pain yourself for deploying v6, but you need
cooperation from others to get the benefits.
Regarding the risk to the global internet: the guys you expect to take
care of the Internet are humans.
> The more
> organizations fail to deploy IPv6, the more inevitable CGN becomes at
> other places on the internet.
Exactly. And since this process involves selfish and greedy individuals,
CGNs will be inevitable.
For the same reason, this world has rich and poor people, people that
die from diseases that are possible to cure with proper medication, etc.
To be quite honest, if we're going to start a debate about "common
good", we have much more important problems than whether the Internet
will deploy IPv6 and/or CGNs.
>>>> 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.
>> 1) The press is the press, and its not uncommon for reports to come
>> up with catchy or controversial headlines.
> It's not that hard to steer the headlines in most cases. It's not
> like I'm not quoted in my share of press interviews.
Who cares? The value of the article is in the article, not the headline.
It's pretty usual for reporters to pick controversial or incorrect
headlines, just to catch more eyes.
If someone is just going to read the headline and not the article, it's
his fault.
>> 2) Where and when to deploy v6 varies from one case from another.
> To some extent, but, if you don't like CGN, there are a lot more
> places where IPv6 is really needed than you seem to realize.
The point is that some organizations might deploy v6 when they have no
other option than v6 vs CGNs, but not earlier than that.
Marc never said "you should never deploy v6".
> All this energy we are expending trying to avoid deploying IPv6 and
> keep IPv4 on life support is really complicating the world.
> KISS says you should deploy IPv6 everywhere as soon as practicable.
KISS says "keep it simple". Running two stacks in scenarios in which you
may live with only one of them is not making things "simpler".
Not to mention lack of well-trained technical staff, lack of ipv6
support in applications and devices, etc., etc., etc.
>>> Not really... I'm talking about the internet-systemic
>>> consequences, not just the local consequences.
>> Humans re generally selfish. Don't be frustrated if people do't do >> things for "the common good" -- most companies are there to make
>> money.. not to make the "world" a better place.
> Yes, I'm well aware of this. However, failing to deploy IPv6 is both
> toxic pollution _AND_ self-destructive in the long run.
That's a core part of human nature.
>>> 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.
>> No. The DHCP situation is worse in v6 than in v4 because in v4, if
>> you want to mitigate it, you can. In v6, if you want to mitigate
>> it, you can't.
> Huh? What can't you mitigate about DHCP in IPv6 that you can
> mitigate in IPv4?
DHCP snooping -- we've been there, already.
> I'm well aware of this. Unfortunately, that's short sighted even for
> the company in question because by the time it's preventing them from
> making money, they will need a year of not making money to get their
> IPv6 roll-out done, the roll-out will be less controlled, less
> planned, and as a result WAY less secure, and will cost somewhere
> between 2 and 10 times as much.
It's probably the first time in history in which companies are concerned
about competitors not making money.
>>> As a result, IETF consists mostly of academics and vendors.
>> [...]
>> I'd would expect the ones voicing their irritation about article >> headlines to invest that energy in supporting mitigation
>> proposals.
>> Other than that, I do agree with your assessment about the IETF.
>> :-)
> Why? The article headline has a far more negative impact to IPv6
> deployment than anything the IETF is doing or failing to do.
I personally don't care about its impact, but rather about whether the
headline is based on facts or not.
> If it looked like your draft was going to face defeat in a last call,
> expire, or get abandoned, I'd jump in.
Oh, that sound pretty much like the "wait till something breaks" you
were arguing against above. ;-)
When you don't jump in, there's the risk that the call for consensus
fails, and the chairs are not going to start successive calls for
consensus one after another, till the I-D gets adopted.
If you support a proposal, you should voice your opinion. That even
helps progress, even if there's consensus on adoption, etc. And it's
also a sign to vendors that operators are interested in ahving that
feature in.
> It looks like it's
> progressing, so bad article headlines are more important use of my
> time right now.
> >>> 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.
> >> No. The DHCP situation is worse in v6 than in v4 because in v4, if
> >> you want to mitigate it, you can. In v6, if you want to mitigate
> >> it, you can't.
> > Huh? What can't you mitigate about DHCP in IPv6 that you can
> > mitigate in IPv4?
> DHCP snooping -- we've been there, already.
FYI - DHCPv6 Guard is available in IOS 15.2(4)S on the 7600s today. Granted it's not pervasive, but it does exist and will come to more platforms.
> Fix the underlying problem: improve the protocol, and slap the lazy vendors.
Vendors are very practical - they focus their efforts where people are willing to pay for them. However, if we look at the US Federal Government - they worked to come up with a list of reasonable security requirements (USGv6, NIST SP800-119, and others) for IPv6. The result? Vendors have implemented code and products that meet these standards. In fact, when I do my testing I heavily rely on NIST SP800-119.
Perhaps a more fruitful tactic for improving the security of IPv6 would be to work with governments, periodicals/publications, enterprises, etc. to come up with a list of required features. If you want to roll out IPv6 to your organization you should look for the following security features... Wouldn't that achieve the result of moving security forward while also letting us address IPv4 exhaustion?
I don't have access to a 7600 for testing, but when the feature comes to other platforms I would be willing to test and report back. And I also think it's a fair question.
> -----Original Message-----
> From: Fernando Gont [mailto:fg...@si6networks.com]
> Sent: Saturday, September 01, 2012 5:43 PM
> To: IPv6 Hackers Mailing List
> Cc: Jim Small; Owen DeLong
> Subject: Re: [ipv6hackers] "Stick to limited IPv6 deployments, businesses
> warned"
> On 09/01/2012 06:33 PM, Jim Small wrote:
> >>> Huh? What can't you mitigate about DHCP in IPv6 that you can
> >>> mitigate in IPv4?
> >> DHCP snooping -- we've been there, already.
> > FYI - DHCPv6 Guard is available in IOS 15.2(4)S on the 7600s today. Granted
> it's not pervasive, but it does exist and will come to more platforms.
> <politically_incorrect>
> Does it actually work, or is it more like the RA-Guard implementation?
> </politically_incorrect>
> Fore those who might be interested in our experience with deploying
> IPv6 within university campus we sum upt it in
> http://ipv6.vutbr.cz/article/deploying-ipv6-practical-problems-from-the- > campus-perspective/
> (and related presentation:
> http://ipv6.vutbr.cz/wordpress/wp- > content/uploads/2012/05/tnc2012_slides_TncPresentation.pdf).
> There are described some of the biggest troubles that we had during
> deploying IPv6.
I looked at your presentation, thanks for sharing. A few questions/comments:
1) Do you believe there is a compelling case for RDNSS/RFC 6106? I personally like it but when I have spoken to vendors they pointed out that most things do or will support stateless DHCPv6 and they don't see any reason to add RDNSS support. Can you give me some strong cases I can take back to vendors for RDNSS? I want to emphasize that this is not an idle promise - any strong case will go straight to the parties who can effect change at the vendors.
2) For privacy addresses, isn't stateful DHCPv6 the solution?
3) For end user accountability/host tracking the best solution is probably 802.1X, granted that likely is not workable in your situation. That said there have been tremendous strides in this space and I have deployed some nice solutions that go a long way in facilitating this.
4) For stateless DHCPv6 support (slide 8), current Apple iOS versions support it. It is still missing in Android as per this specific feature request: http://code.google.com/p/android/issues/detail?id=32621 That is pretty sad, especially since Google has some major IPv6 advocates. That said, as you know Apple iOS 6 will and Android 4.0+ does support IPv6 for cellular connections. Expect some major progress in this area this fall. T-Mobile USA for example has fully deployed IPv6 within their network and is looking to go IPv6 only. This will bring a resurgence in interest to the mobile space.
You're in a tough situation as you are almost stuck having to support everything - an impossible situation. In general I advise people to try to support Apple iOS and Android. That's the overwhelming majority of the mobile space. You could also make an argument for RIM although I rarely hear one. Anyone else (e.g. Windows Mobile) is insignificant in terms of Market share. Can you put in your network support policy that we support this and this and anything else is limited best effort support?
As for XP even Microsoft seems to have given up here for IPv6. If you look at their latest Microsoft Press book, Understanding IPv6 3e, it discounts anything before Vista. XP is totally unsupported in April of 2014, so if you have to support it for now it will be dual stack. Not only does it not support DHCPv6, but I thought it wasn't capable of doing IPv6 DNS either?
5) First Hop Security Threats - there are some vendors who have solutions to all of these (though limited availability for some of them to a few high end products for now)
6) Slide 19 - I agree, this is very sad
7) Slide 21 - rogue IPv6 routers (Vista ICS), can't you use port ACLs to deal with this or RA guard if available? I thought every decent switch at least supports port ACLs - not the case? You seem to imply this later but wondering why you don't mention here.
8) Slide 27 - first hop security countermeasures:
SeND - will probably never happen. Microsoft and Apple have no interest in doing this and that pretty much kills it.
RA-Guard/PACLs - these work. It's true you can use a tool to defeat these with fragmentation but that requires actively attacking the infrastructure with an attack tool (would never be by accident which is mostly what you run into). If I look at the IPv4 world, it is rare that people deploy DHCP snooping/DAI/IPSG because it can break protocols that can't deal with security (e.g. Apple's). Therefore while I would like to see a solution to this I wonder how many people will actually use it.
9) slide 28 - SeND is not the only way to deal with malicious RAs. There will be improved versions of RA Guard coming thanks to Fernando and there are ways to block the fragmentation attacks now. That said, I'm not sure if blocking the fragmentation attacks breaks other things - it may.
10) Slide 38 - Implied message is no business case for IPv6. I think this is leaving out some important details. Since this is a very technical list I will get to the point - we have < 141 million IPv4 addresses left at a burn rate of around 200 million IPv4 addresses/year. Everyone on this list agrees CGN sucks. In addition, it has been clearly shown that it is cheaper for an ISP to deploy IPv6 then CGN. Therefore the future of the Internet is clearly IPv6. So let's ask this question - how many of your users value having Internet connectivity? If you look at it from this vantage point I think everything else on that list pales in comparison. In Europe RIPE enters depletion this month or next - this is not some far off event. It's here now.
11) Slide 41 - IPv6 is a massive topic. We're talking about the underpinnings of global communication. I think it's important to split IPv6 up into different areas such as Internet of Things, Internet connectivity, Business/Organization Internal, Consumer Internal. For some things like the Internet of Things, SmartGrid and other solutions in this category there is no IPv4, but only IPv6. So even with saying IPv6 is something for the future is only true in certain contexts. If you're an ISP for example and haven't started deploying IPv6 you're in trouble. Specifically for the Internet connectivity area, the compelling case is business continuity. Most of your users probably don't understand IPv4/IPv6 and don't want to. But if they need to get somewhere on the Internet and have poor performance (CGN) or can't reach it (IPv6 only) they will be incensed. There are some Internet applications that are IPv4 only but this will change in the next few years as usage ramps up.
As for internal applications that don't use the Internet, I agree with you that support is lacking. However, for this area I don't see a big demand or need yet.
12) Slide 44 - this is awesome. There has to be a better way to track issues. What about a Wiki page to track IPv6 operational and security issues along with progress in the IETF and with vendors. What gets measured gets done - what do you think?
A fabulous write up. In your conclusion though you seem to imply that Windows XP is widespread and "next-generation" versions of Windows will accelerate IPv6 deployment. Windows Vista was released on November 8, 2006 and Windows 7 on July 22, 2009. Windows Vista and Windows 7 combined have had a greater market share than XP for quite a while and very recently Windows 7 has overtaken XP as the dominant O/S for web page views:
http://www.zdnet.com/windows-7-overtakes-xp-mac-os-x-steams-ahead-of-...
Of course it may be different on Brno's campus, but globally XP's usage is steadily declining.
> A fabulous write up. In your conclusion though you seem to imply that Windows XP is widespread and "next-generation" versions of Windows will accelerate IPv6 deployment. Windows Vista was released on November 8, 2006 and Windows 7 on July 22, 2009. Windows Vista and Windows 7 combined have had a greater market share than XP for quite a while and very recently Windows 7 has overtaken XP as the dominant O/S for web page views:
> http://www.zdnet.com/windows-7-overtakes-xp-mac-os-x-steams-ahead-of-...
> Of course it may be different on Brno's campus, but globally XP's usage is steadily declining.
I'd assume most campuses upgrade the platforms they provide quite regularly. Ours is now pretty much all Win7.
The bigger issue is user-owned devices, and they outnumber the 'managed' systems, in our department by about 3 to 1. Those could be running anything, and not join management domains. Which is also the reason you need to embrace devices picking their own IPv6 addresses and using appropriate tools for address accountability.
> -----Original Message-----
> From: ipv6hackers-boun...@lists.si6networks.com [mailto:ipv6hackers-
> boun...@lists.si6networks.com] On Behalf Of Jim Small
> Sent: dimanche 2 septembre 2012 21:15
> To: IPv6 Hackers Mailing List
> Subject: Re: [ipv6hackers] "Stick to limited IPv6 deployments, businesses
> warned"
> A fabulous write up. In your conclusion though you seem to imply that
> Windows XP is widespread and "next-generation" versions of Windows will
> accelerate IPv6 deployment. Windows Vista was released on November 8, 2006
> and Windows 7 on July 22, 2009. Windows Vista and Windows 7 combined have
> had a greater market share than XP for quite a while and very recently
> Windows 7 has overtaken XP as the dominant O/S for web page views:
> http://www.zdnet.com/windows-7-overtakes-xp-mac-os-x-steams-ahead-of-... > 7000003591/
> Of course it may be different on Brno's campus, but globally XP's usage is
> steadily declining.
> > FYI - DHCPv6 Guard is available in IOS 15.2(4)S on the 7600s today.
> Granted it's not pervasive, but it does exist and will come to more
> platforms.
> <politically_incorrect>
> Does it actually work, or is it more like the RA-Guard implementation?
> </politically_incorrect>
Nice HTML tag ;-)
It is also available on 15.0(2)SE BTW (Cat 3560-x and others).
DHCP-guard has two functions (please note in mind that even if I work for Cisco and talk to engineers, I did not develop the feature :-) so it is just an educated guess):
- learn the 'official' bindings, and, it this case it does reassembly by listening to the DHCP mcast addresses
- block all rogue DHCP packets (pretty much like RA guard) and indeed the wirespeed stateless ACL can be evaded by fragmenting the rogue DHCP packet in such a way that UDP header is in the second fragment.
The obvious counter-measure for this issue is simply to drop all fragments sent to a link-local address... Could also use 'undetermined-transport' on switches supporting it
