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

[Jim Small]

Security expert Marc Heuse says, "If some network engineer says 'let's make a global company all IPv6', I would fire that guy, because it costs millions and the benefit is zero." "Let's say you're Daimler: in what way does it make your network better?"
See:
http://www.zdnet.com/stick-to-limited-ipv6-deployments-businesses-warned-7000003055/

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. The issues that remain should be addressed or will have solutions from Cisco in the next 6 months. In the mean time, I would respectfully remind you that we have less than 141 million unrestricted IPv4 addresses left globally with a burn rate of over 200 million addresses per year. I have tremendous respect for your work and your contributions but I don't see how publishing statements like this is helping the global community.

I also believe there is tremendous benefit for innovation with IPv6. NAT has become a strangle hold choking off innovation. Consider this analogy - I'm a builder. I go to build a new subdivision. When I go to City Hall, do I worry about optimizing how many homes are on each street? Do I worry about trying to hide all the homes behind one public address? Are street addresses themselves worth money because there is so much demand not for the property but just the address itself? You only have to step outside of IT and ask a typical person if they would be willing to put their neighborhood behind a PBX because there aren't enough phone numbers. They will laugh and say no way. Deploying IPv6 provides virtually limitless address space and makes it far easier for developers to come up with fantastic new applications. How can you say there's no benefit?

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?
--Jim

_______________________________________________
Ipv6hackers mailing list
Ipv6h...@lists.si6networks.com
http://lists.si6networks.com/listinfo/ipv6hackers

[Marc Heuse]

Hi Jim,

> "If some network engineer says 'let's make a global company all
> IPv6', I would fire that guy, because it costs millions and the
> benefit is zero."

several things in the article wrong and I asked to review the article
before it goes online (he told me their technical security article
writer left a week ago), that statemnt is mine however :-)

what I am talking about is enabling IPv6 internally. There is no need
for this. no business need. So anybody wanting to do this without
necessity should be fired.

I also always advice that companies should IPv6 enable the front-end
DMZ. but nothing else.

> That said, in the space I work in Cisco and Microsoft have done IMHO a
pretty good job addressing the issues.

I agree with Cisco, for Microsoft, sorry, no. A company which does not
fix critical local LAN issues because of ego reasons in the IPv6 stack
team - I can't take them seriously.

Greets,
Marc

--
Marc Heuse
www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

[Jim Small]

Marc,

> > "If some network engineer says 'let's make a global company all
> > IPv6', I would fire that guy, because it costs millions and the
> > benefit is zero."
>
> several things in the article wrong and I asked to review the article
> before it goes online (he told me their technical security article
> writer left a week ago), that statemnt is mine however :-)
>
> what I am talking about is enabling IPv6 internally. There is no need
> for this. no business need. So anybody wanting to do this without
> necessity should be fired.

I see it differently. While the urgency is for Internet connectivity and not necessarily for internal use, if the Internet is increasingly IPv6 and my internal users can't access this how is that good/effective? I am not focused on deploying internally per se, but all organizations need to have internal labs setup and should have at least one test/pilot network which has IPv6 Internet access.

> I also always advice that companies should IPv6 enable the front-end
> DMZ. but nothing else.

So how do their internals users, developers, and IT people get at the IPv6 Internet? How do they get operational experience with running and deploying IPv6 if they only do it in one externally facing network? Many companies have older hardware that can't deal with IPv6 which will force things like ISATAP. I agree this isn't desirable but putting your head in the sand and doing the bare minimum is foolish from a security point of view. Did you see this on a panic driven ISP deployment of IPv6 in your own back yard?
http://blog.ioshints.info/2012/07/analyst-driven-ipv6-deployment.html

If companies wait, when they start scrambling to deploy IPv6 how secure will their setup be? It is crucial to act now and deploy IPv6 incrementally and methodically to gain experience and learn how to do it right and securely.

> > That said, in the space I work in Cisco and Microsoft have done IMHO a
> pretty good job addressing the issues.
>
> I agree with Cisco, for Microsoft, sorry, no. A company which does not
> fix critical local LAN issues because of ego reasons in the IPv6 stack
> team - I can't take them seriously.

I agree, that's lame. Windows 8 is available now from MSDN/Technet - have you tested the RTM version?

However, Microsoft has also released what looks to be a pretty nice IPAM solution with Server 2012 and has done a lot to help move IPv6 forward. I will see if I can push for resolution on the RA vulnerability.

--Jim

[Jim Small]

Marc,

> I agree with Cisco, for Microsoft, sorry, no. A company which does not
> fix critical local LAN issues because of ego reasons in the IPv6 stack
> team - I can't take them seriously.

I can't find Microsoft's official response to this (CVE-2010-4669), can't you point me to it? I need to make sure I understand their position before I approach them and push for a solution.

Apologies my Google-Fu is weak today,
--Jim

[Owen DeLong]

On Aug 23, 2012, at 06:55 , Jim Small <jim....@cdw.com> wrote:

> Marc,
>
>>> "If some network engineer says 'let's make a global company all
>>> IPv6', I would fire that guy, because it costs millions and the
>>> benefit is zero."
>>
>> several things in the article wrong and I asked to review the article
>> before it goes online (he told me their technical security article
>> writer left a week ago), that statemnt is mine however :-)
>>
>> what I am talking about is enabling IPv6 internally. There is no need
>> for this. no business need. So anybody wanting to do this without
>> necessity should be fired.
>
> I see it differently. While the urgency is for Internet connectivity and not necessarily for internal use, if the Internet is increasingly IPv6 and my internal users can't access this how is that good/effective? I am not focused on deploying internally per se, but all organizations need to have internal labs setup and should have at least one test/pilot network which has IPv6 Internet access.
>
>

Consider also that the people responsible for maintaining your public facing IPv6 stuff need some way to get to it over IPv6 to make sure it is working properly.

Saying that there is no business case is about as intelligent as saying that everything should move urgently. The reality is somewhere in between.

There are many business cases for internal deployment. In some enterprises, this will be to the entire enterprise. For some enterprises, this will be limited to public facing content. For most, it will be a combination of partial internal rollout and a (nearly) complete rollout of public-facing services and content.

>> I also always advice that companies should IPv6 enable the front-end
>> DMZ. but nothing else.
>
> So how do their internals users, developers, and IT people get at the IPv6 Internet? How do they get operational experience with running and deploying IPv6 if they only do it in one externally facing network? Many companies have older hardware that can't deal with IPv6 which will force things like ISATAP. I agree this isn't desirable but putting your head in the sand and doing the bare minimum is foolish from a security point of view. Did you see this on a panic driven ISP deployment of IPv6 in your own back yard?
> http://blog.ioshints.info/2012/07/analyst-driven-ipv6-deployment.html

Ding!!

Additionally, most of the security issues that Mark (and others) keep harping on in IPv6 aren't any worse than the ones we've lived with for years in IPv4. In some cases, they're different, but the attack surface and risk factors overall are about the same. While I'm all for addressing the security problems in IPv6 (and was all for addressing them in IPv4), I don't think it makes sense to stand in front of the internet and say "stop growing until we fix this." (which is effectively what you say when you say only do limited deployments).

>
> If companies wait, when they start scrambling to deploy IPv6 how secure will their setup be? It is crucial to act now and deploy IPv6 incrementally and methodically to gain experience and learn how to do it right and securely.
>

Exactly correct.

Security, like all things, needs to be considered in the larger context. The most secure server is one with no external connections to network or power. It's also the least useful.

I don't, for one second, agree that it necessarily costs millions to make a global company all IPv6. It certainly can, but that will depend on the organization and how they go about the roll-out. In many cases, an IPv6 roll-out can be accomplished along side other technology refreshes without significant additional cost.

While I wouldn't tell most enterprises "let's deploy IPv6 everywhere today", I would tell most of them "let's stop deploying anything that doesn't include IPv6 today."

I do like that the article thinks IPv6 only provides trillions of addresses. Certainly in that case, it might be hardly worth the effort. ;-)
Fortunately, as you know, it's quite a bit larger than that.

The fake router RA vulnerabilities are well known and relatively well understood. Vendors are working on it and most have reasonable initial solutions with progress being made towards more complete solutions. However, I do not see this as being any worse in most cases than a rogue DHCP server which is a vulnerability in IPv4 that has not been fixed even to this day. In fact, DHCPv4 doesn't even have the equivalent of RA Guard available.

Owen

[Marc Heuse]

a reply to Jim and Owen :-)

>> what I am talking about is enabling IPv6 internally. There is no need
>> for this. no business need. So anybody wanting to do this without
>> necessity should be fired.
>
> I see it differently. While the urgency is for Internet connectivity and
> not necessarily for internal use, if the Internet is increasingly IPv6
> and my internal users can't access this how is that good/effective?

via proxies of course.
do you allow your users to connect to internet services without security
proxies? that would be a very bad call. that would mean your single line
of defense is the office PC for the content that is carried in the
connections.

>> I agree with Cisco, for Microsoft, sorry, no. A company which does >>
not fix critical local LAN issues because of ego reasons in the
>> IPv6 stack team - I can't take them seriously.

> I can't find Microsoft's official response to this (CVE-2010-4669),
> can't you point me to it? I need to make sure I understand their
> position before I approach them and push for a solution.

http://www.networkworld.com/news/2011/050311-microsoft-juniper-ipv6.html

Am 23.08.2012 16:21, schrieb Owen DeLong:
> Saying that there is no business case is about as intelligent as
> saying that everything should move urgently.

yes, maybe. but where is the business case? if you have one, and the
business case makes sense financial wise for the hardware and labor - do
it. But I doubt that any company will have that for the next 2 years.

> Additionally, most of the security issues that Mark (and others) keep
> harping on in IPv6 aren't any worse than the ones we've lived with
> for years in IPv4.

no, thats not the point. the point is that the implementations are not
where they should be for a global productional roleout.
the firewalls do not have all features required (filtering on options in
extension headers), OS implementations at various stages what they
support and what not (any OS beside Ubuntu that can get the DNS server
from something else than DHCP6?) - and the IPv6 stacks are not well
tested enough (see the number of issues found of IPv6 security issues
for example, compared to IPv4 security issues in the top-5 OS used).

thats why things should not be rushed.

but I agree to:

> "let's stop deploying anything that doesn't include IPv6 today."

and finally:

> In fact, DHCPv4 doesn't even have the equivalent of RA Guard
> available.

its called dhcp snooping

Greets,
Marc

--
Marc Heuse

Mobil: +49 177 9611560
Fax: +49 30 37309726
www.mh-sec.de

Marc Heuse - IT-Security Consulting
Winsstr. 68
10405 Berlin

Ust.-Ident.-Nr.: DE244222388

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

[Seth Hall]

On Aug 23, 2012, at 11:01 AM, Marc Heuse <m...@mh-sec.de> wrote:

> via proxies of course.
> do you allow your users to connect to internet services without security
> proxies? that would be a very bad call.

Higher-ed security teams have practically turned this into an art form.

There still seems to be a big disjoint between "business" perspective and higher-ed perspective regarding network security. Are the companies that exclusively use proxies for internet access getting compromised less and seeing less time between compromise and remediation than places with strong network security teams? I'd say no.

.Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/

[Owen DeLong]

> Am 23.08.2012 16:21, schrieb Owen DeLong:
>> Saying that there is no business case is about as intelligent as
>> saying that everything should move urgently.
>
> yes, maybe. but where is the business case? if you have one, and the
> business case makes sense financial wise for the hardware and labor - do
> it. But I doubt that any company will have that for the next 2 years.
>

Bzzt... Thanks for playing, but HE is already fully dual stacked both in terms
of our internal IT and our external networks. Being ahead of the curve didn't
cost us all that much (mostly we included it in planned tech refreshes anyway)
and now we're actually seeing some pretty good benefits from being there.

>> Additionally, most of the security issues that Mark (and others) keep
>> harping on in IPv6 aren't any worse than the ones we've lived with
>> for years in IPv4.
>
> no, thats not the point. the point is that the implementations are not
> where they should be for a global productional roleout.

Neither is IPv4... That _IS_ the point. We rolled IPv4 out without worrying
about it. IPv6 is a rollout to replace IPv4 because IPv4 is dying of several
other horrible problems on top of its security issues. (address shortage,
the overhead of NAT, the unsustainable IPv4 routing table and the additional
fragmentation that will come from ever increasing address density, etc.)

IPv4 has been on life support for more than a decade now. While we can't
pull the plug just yet, we certainly don't have any time left to fiddle around
and pretend we don't need something else ready soon.

> the firewalls do not have all features required (filtering on options in
> extension headers), OS implementations at various stages what they
> support and what not (any OS beside Ubuntu that can get the DNS server
> from something else than DHCP6?) - and the IPv6 stacks are not well
> tested enough (see the number of issues found of IPv6 security issues
> for example, compared to IPv4 security issues in the top-5 OS used).

Yes... MacOS X gets it quite nicely from static and/or DHCP4. :p

Sure, I know that's not what you meant, you meant specifically any other
OS that supports RFC 6106, but that's not what you said.

There is, apparently a source tool (rdnssd-win32) for Win32.

Allegedly it is supported in OSX (10.7+) and iOS (5+). I haven't verified these.

> thats why things should not be rushed.
>

I don't think I said anything about rushing. I believe what I said was that dragging ones feet isn't good advice.

> but I agree to:
>> "let's stop deploying anything that doesn't include IPv6 today."
>
>
> and finally:
>
>> In fact, DHCPv4 doesn't even have the equivalent of RA Guard
>> available.
>
> its called dhcp snooping
>

I can do the equivalent of that today snooping for RAs. Yes, it's slightly harder than DHCP snooping, but if you really want, it is do-able. If you consider that an adequate solution, then it is already completely solved for IPv6, too.

The reality, however, is that snooping doesn't solve the problem, it just tells you that it is happening.

With RA Guard, we have an actual partial solution which, with some improved handling of Extension Headers and Fragments could become a complete solution.

Owen

[daniel....@bt.com]

Great response Owen, and I completely support your view.

I'd be interested in hearing the challenges (if any) you and/or your organisation experienced with such an early adoption and full rollout, maybe off thread?

Kind Regards,

Dan.

[Owen DeLong]

I wasn't actually at HE during most of the rollout. It was mostly done 5 years ago.

I've only been there about 3 years now.

I think the biggest challenges back then had to do with lack of software, lack of
documentation, and lack of library readiness. (All of which are pretty much
solved at this point).

Today, things are running pretty smoothly and we have the features we need from
our router vendors. (Admittedly, our router vendors' IPv6 maturity is largely due to
listening to us).

Owen

[Joe St Sauver]

Seth commented:

#On Aug 23, 2012, at 11:01 AM, Marc Heuse <m...@mh-sec.de> wrote:
#
#> via proxies of course.
#> do you allow your users to connect to internet services without security
#> proxies? that would be a very bad call.
#
#Higher-ed security teams have practically turned this into an art form.

Seth is absolutely correct that most higher ed sites do NOT connect their
users to the Internet through a security proxy, and yet do just fine.

This is a few years old now, but if folks are interested, feel free to see

"Cyberinfrastructure Architectures, Security and Advanced Applications,"
http://pages.uoregon.edu/joe/architectures/architecture.pdf (yeah, I know
it starts out a little slowly to build some foundation, but stick with it)

For those who really have trouble sleeping, given this group's IPv6 focus,
you may also be interested in a couple of other talks:

"IPv6 and the Security of Your Network and Systems"
http://pages.uoregon.edu/joe/i2mm-spring2009/i2mm-spring2009.pdf

"MAAWG IPv6 Training for Senders and Others"
http://pages.uoregon.edu/joe/maawg-senders-ipv6-training/maawg-senders-ipv6-training.pdf

Regards,

Joe

[-Hammer-]

I don't 100% agree. I think it depends on the business. For many
businesses there is no need and I agree with you on that. But businesses
that interact heavily with the government (Financial, Healthcare, etc)
may find they are more pressed to have v6 reach inside their WAN for
extranets/vpns/etc. That is certainly our case. We are trying to avoid
any type of 6to4 6n4 6over4 (say when) implementations that are
contradictive to the true intent of IPv6. The result is that we are
seriously discussing a dual stack rollout over the next 24 months. We're
already deploying on the edge and about to migrate to the core. WAN is
next...

-Hammer-

"I was a normal American nerd"
-Jack Herer

[Fernando Gont]

On 08/23/2012 12:42 PM, Owen DeLong wrote:
>> no, thats not the point. the point is that the implementations are
>> not where they should be for a global productional roleout.
>
> Neither is IPv4... That _IS_ the point. We rolled IPv4 out without
> worrying about it.

The world economy didn't depend on IPv4 when it was rolled out -- there
lies the "subtle" difference.

> The reality, however, is that snooping doesn't solve the problem, it
> just tells you that it is happening.

?? -- It blocks it.

> With RA Guard, we have an actual partial solution which, with some
> improved handling of Extension Headers and Fragments could become a
> complete solution.

Yet it was painful to move draft-ietf-v6ops-ra-guard-implementation forward.

v6 proponents (whatever that means :-) )don't like when v6 problems are
discussed... but they're also apathic when solutions to those problems
are proposed.

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Fernando Gont]

On 08/23/2012 11:21 AM, Owen DeLong wrote:
>
> Additionally, most of the security issues that Mark (and others) keep
> harping on in IPv6 aren't any worse than the ones we've lived with
> for years in IPv4.

Maybe some get frustrated that after 30+ of IPv4, we're going through
all the hassle of deploying a somewhat similar protocol, with no
improvements in areas where its predecessor (IPv4) failed.... just for
the longer addresses.

> addressing them in IPv4), I don't think it makes sense to stand in
> front of the internet and say "stop growing until we fix this."
> (which is effectively what you say when you say only do limited
> deployments).

That depends on who you work for or who you're consulting for. If Mark
(or anyone else) is doing security consulting, they go with "hey, deploy
v6!", and their client gets into trouble with not apparent benefit from
deploying v6, they might be in trouble.

> I do like that the article thinks IPv6 only provides trillions of
> addresses. Certainly in that case, it might be hardly worth the
> effort. ;-) Fortunately, as you know, it's quite a bit larger than
> that.

And of course que also know that we shouldn't cound 2**64 addresses in
each /64, because no one is going to have such a huge number of nodes in
a single subnet.

> The fake router RA vulnerabilities are well known and relatively well
> understood. Vendors are working on it and most have reasonable
> initial solutions with progress being made towards more complete
> solutions.

This is not the message that I got the last time I talk with some
well-known desktop os vendor.

> However, I do not see this as being any worse in most
> cases than a rogue DHCP server which is a vulnerability in IPv4 that
> has not been fixed even to this day.

My understanding is that you cannot crash a host with forged DHCP
responses, but that you *can* do taht with forged RAs.

> In fact, DHCPv4 doesn't even
> have the equivalent of RA Guard available.

As noted already, it's called dhcp snooing.

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Jim Small]

Hi Marc,

> >> what I am talking about is enabling IPv6 internally. There is no need
> >> for this. no business need. So anybody wanting to do this without
> >> necessity should be fired.
> >
> > I see it differently. While the urgency is for Internet connectivity and
> > not necessarily for internal use, if the Internet is increasingly IPv6
> > and my internal users can't access this how is that good/effective?
>
> via proxies of course.

Proxies are acceptable as long as the protocols you need to use can be proxied. This is a great solution for http/https. However, for multimedia and Unified Communications it is not a complete solution. However, it sounds like you agree that there needs to be a way for at least a pilot group of users to be able to access the IPv6 Internet. That's what I'm after right now.

> do you allow your users to connect to internet services without security
> proxies? that would be a very bad call. that would mean your single line
> of defense is the office PC for the content that is carried in the
> connections.
>
> >> I agree with Cisco, for Microsoft, sorry, no. A company which does >>
> not fix critical local LAN issues because of ego reasons in the
> >> IPv6 stack team - I can't take them seriously.
> > I can't find Microsoft's official response to this (CVE-2010-4669),
> > can't you point me to it? I need to make sure I understand their
> > position before I approach them and push for a solution.
>
> http://www.networkworld.com/news/2011/050311-microsoft-juniper-
> ipv6.html

Thank you Marc. I will see if there's anything I can do on this.

> Am 23.08.2012 16:21, schrieb Owen DeLong:
> > Saying that there is no business case is about as intelligent as
> > saying that everything should move urgently.
>
> yes, maybe. but where is the business case? if you have one, and the
> business case makes sense financial wise for the hardware and labor - do
> it. But I doubt that any company will have that for the next 2 years.

This is a great question. At a high level there business case is two fold:
1) Business Continuity. As I said, there are < 141 million IPv4 addresses left at a burn rate of 200 million/year. IPv6 is the only viable solution for the continued use and growth of the Internet.
Please take a moment to review Lee Howard's (The Director of Network Technology at Time Warner Cable, one of the largest residential ISPs in the US) presentation on the TCO for CGN. What's especially interesting to note is that the forced deployment of CGN because of insufficient IPv4 address space is going to come with a cost. Not only will it costs end users and carriers more money but it also results in a degraded user experience:
http://www.rmv6tf.org/2012-IPv6-Summit-Presentations/TCO%20of%20CGN.pdf
You all know about Geoff Huston's site and stats. What's going to happen in the next year or two when IPv4 addresses become both scarce and expensive? How is that helping security or the continued prosperity of the Internet? CGN is a security nightmare.

2) Innovation - while I suspect that we'll have to hit 10% usage of the Internet backbone for IPv6 traffic to see some killer apps; rest assured that they're coming. IP is fundamentally about communication. In fact right now I am most grateful that I am able to converse with some of the most talented people scattered all over the planet from the comfort of my desk. IPv6 allows the possibility of removing NAT and facilitating end to end communication. Things like global voice and video conferencing become cheap free apps. Imagine the communications possibilities with a truly global addressing system.

> > Additionally, most of the security issues that Mark (and others) keep
> > harping on in IPv6 aren't any worse than the ones we've lived with
> > for years in IPv4.
>
> no, thats not the point. the point is that the implementations are not
> where they should be for a global productional roleout.
> the firewalls do not have all features required (filtering on options in
> extension headers),

I can't speak for all firewalls but Cisco's supports this now. I have spent a lot of time working with Cisco and they have been fabulous about supporting IPv6 security. I'm sure you've seen Eric Vynke's posts here - he has been a tireless advocate for state of the art security and for improving the operational robustness of IPv6.

> OS implementations at various stages what they
> support and what not (any OS beside Ubuntu that can get the DNS server
> from something else than DHCP6?) - and the IPv6 stacks are not well
> tested enough (see the number of issues found of IPv6 security issues
> for example, compared to IPv4 security issues in the top-5 OS used).

I think RDNSS would be nice. However, I have been challenged by a major router manufacturer to provide a business case for RDNSS. Everything supports stateless DHCPv6. While I agree that RDNSS is nice for SOHO environments, Linksys, Dlink, and others will provide GUI interfaces that make it easy to use. I still would like to see RDNSS support but I'm having trouble thinking of a strong business case to advocate for it. Can you help me out here? If you can provide the business case I will make sure it's heard.

> thats why things should not be rushed.

I don't get this - how are we going to deal with IPv4 depletion? What's your strategy for sustaining the growth of the Internet?

> but I agree to:
> > "let's stop deploying anything that doesn't include IPv6 today."
>
>
> and finally:
>
> > In fact, DHCPv4 doesn't even have the equivalent of RA Guard
> > available.
>
> its called dhcp snooping

This is an excellent point. IPv6 has not achieved full parity with IPv4 security features but this is coming very soon. However, speaking as someone who deploys networks for a living I can tell you that < 1% of companies actually use any of these features. So I disagree that it's a reason not to deploy IPv6. There are reasonable work arounds available today. I realize these can be bypassed, but Marc I'm sure you'd agree that if you can get network access inside any company you can shortly own their infrastructure today without IPv6. Deploying IPv6 is not going to significantly weaken current business security infrastructure.


Respectfully,
--Jim

[Jim Small]

Fernando,

> > With RA Guard, we have an actual partial solution which, with some
> > improved handling of Extension Headers and Fragments could become a
> > complete solution.
>
> Yet it was painful to move draft-ietf-v6ops-ra-guard-implementation
> forward.

Thank you for doing this. I for one am grateful.

> v6 proponents (whatever that means :-) )don't like when v6 problems are
> discussed... but they're also apathic when solutions to those problems
> are proposed.

I respectfully disagree. I very much value what you and Marc have to say. However I may slightly differ in my opinion because I believe operationally we do not have a viable alternative to IPv6. I also believe that the current level of security needs to be improved but is reasonable for most companies to start at the pilot/testing level.

--Jim

[Jim Small]

Hi Fernando,

> > Additionally, most of the security issues that Mark (and others) keep
> > harping on in IPv6 aren't any worse than the ones we've lived with
> > for years in IPv4.
>
> Maybe some get frustrated that after 30+ of IPv4, we're going through
> all the hassle of deploying a somewhat similar protocol, with no
> improvements in areas where its predecessor (IPv4) failed.... just for
> the longer addresses.

Being a history fan, it is not so easy to achieve consensus on improvements. However, I know I'm preaching to the choir here...

> > addressing them in IPv4), I don't think it makes sense to stand in
> > front of the internet and say "stop growing until we fix this."
> > (which is effectively what you say when you say only do limited
> > deployments).
>
> That depends on who you work for or who you're consulting for. If Mark
> (or anyone else) is doing security consulting, they go with "hey, deploy
> v6!", and their client gets into trouble with not apparent benefit from
> deploying v6, they might be in trouble.

Deploying something just for the sake of doing it is irresponsible. I'm advocating a thoughtful pilot project for organization to learn IPv6.

> > I do like that the article thinks IPv6 only provides trillions of
> > addresses. Certainly in that case, it might be hardly worth the
> > effort. ;-) Fortunately, as you know, it's quite a bit larger than
> > that.
>
> And of course que also know that we shouldn't cound 2**64 addresses in
> each /64, because no one is going to have such a huge number of nodes in
> a single subnet.

But this is addressed beautifully in Radia Perlman's Interconnections book. This talks about how various protocols got developed and compares IPX/IPX+/CLNP/IP/IPv6/AppleTalk. For those that remember IPX it was a great LAN protocol. Fast and easy to roll out. IPv6 was trying to emulate many of these features. Since the IEEE was assigning 48 and 64 bit MACs (even over 10 years ago!), the idea with a 64bit node address was to make IPv6 auto-configuring based on the MAC address just like IPX and CLNP. While you could argue about this now it takes over 10 years to develop and roll out a protocol. If you don't like IPv6 you're welcome to start on the next generation protocol. All you have to do is convince everyone to use and deploy it. :-)

> > The fake router RA vulnerabilities are well known and relatively well
> > understood. Vendors are working on it and most have reasonable
> > initial solutions with progress being made towards more complete
> > solutions.
>
> This is not the message that I got the last time I talk with some
> well-known desktop os vendor.

FWIW I'll see if I can do anything or get a status. I'm praying that this is fixed in Windows 8/Server 2012 RTM but I don't know.

> > However, I do not see this as being any worse in most
> > cases than a rogue DHCP server which is a vulnerability in IPv4 that
> > has not been fixed even to this day.
>
> My understanding is that you cannot crash a host with forged DHCP
> responses, but that you *can* do taht with forged RAs.

--Jim

[Marc Heuse]

> I respectfully disagree.
> I very much value what you and Marc have to say.
> However I may slightly differ in my opinion because
> I believe operationally we do not have a viable alternative
> to IPv6.

I also think that there is no alternative to IPv6, thats why I am
constantly pushing and kicking. Without the pain in the ass Fernando, me
and a few others are, IPv6 would be in a terrible state when widely
deployed.

personally I do not think that security is the most important thing.
Neither do I tell my customers not to do IPv6.
It always depends on their goals, opportunity and risk appetite.

But here I see it as my role to constantly bash - in my 17+ years
experience in security I have learned that otherwise vendors dont move
and clients/users just trust the vendors if they do not find oposing
information ...

Greets,
Marc

--
Marc Heuse

www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

[Doug Barton]

On 8/23/2012 11:35 AM, Fernando Gont wrote:
> Maybe some get frustrated that after 30+ of IPv4, we're going through
> all the hassle of deploying a somewhat similar protocol, with no
> improvements in areas where its predecessor (IPv4) failed.... just for
> the longer addresses.

And some of us are frustrated that in what is quite possibly the worse
case of second system syndrome ever documented in tech history, the
quick and obviously necessary fix of "IPv4 with longer addresses" was
discarded in favor of building a grand edifice that a decade later still
has few residents.

Doug

--

I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)

[Owen DeLong]

On Aug 23, 2012, at 11:28 , Fernando Gont <fg...@si6networks.com> wrote:

> On 08/23/2012 12:42 PM, Owen DeLong wrote:
>>> no, thats not the point. the point is that the implementations are
>>> not where they should be for a global productional roleout.
>>
>> Neither is IPv4... That _IS_ the point. We rolled IPv4 out without
>> worrying about it.
>
> The world economy didn't depend on IPv4 when it was rolled out -- there
> lies the "subtle" difference.
>

However, note that I said "Neither _IS_ IPv4". Not neither "WAS" IPv4.

IPv4 still isn't where it should be for a global production rollout in terms
of security issues.

>
>> The reality, however, is that snooping doesn't solve the problem, it
>> just tells you that it is happening.
>
> ?? -- It blocks it.
>

Oh, you're talking about in the switch. Well, sort-of... But the rogue packet
has to traverse a device that does DHCP snooping which isn't always
implemented on all WAPs.

I was thinking of the DHCPMON thing that takes collects all the responses
and alarms on ones it doesn't expect. (actual snooping).

DHCP snooping sort of works in most environments. Lots of corner cases
where it can fail, though. Sometimes in very interesting ways. I've seen it
block things it shouldn't on more than one network.

>
>
>> With RA Guard, we have an actual partial solution which, with some
>> improved handling of Extension Headers and Fragments could become a
>> complete solution.
>
> Yet it was painful to move draft-ietf-v6ops-ra-guard-implementation forward.
>

I think it's painful to move any ietf draft forward. What's your point? That's the
process.

> v6 proponents (whatever that means :-) )don't like when v6 problems are
> discussed... but they're also apathic when solutions to those problems
> are proposed.

I think I'm about as much of a v6 proponent as anyone. However, I don't
think that I have tried to avoid discussing v6 problems, nor do I think I have
been apathetic (which is what I presume you meant by apathic) about
solutions, either.

I still think that telling people not to deploy or to delay their deployments
is bad advice and I'll still call people on it when I see that.

Owen

[Owen DeLong]

On Aug 23, 2012, at 11:35 , Fernando Gont <fg...@si6networks.com> wrote:

> On 08/23/2012 11:21 AM, Owen DeLong wrote:
>>
>> Additionally, most of the security issues that Mark (and others) keep
>> harping on in IPv6 aren't any worse than the ones we've lived with
>> for years in IPv4.
>
> Maybe some get frustrated that after 30+ of IPv4, we're going through
> all the hassle of deploying a somewhat similar protocol, with no
> improvements in areas where its predecessor (IPv4) failed.... just for
> the longer addresses.
>

Tough... You had 20+ years to propose improvements to IPv6 to resolve
those issues. Somehow that didn't happen. Now, we urgently need
bigger addresses. IPv6 is going to get deployed because without it,
the internet is going to break badly. Get over it and move on. Try to
find the best and most effective ways to deploy IPv6 rather than whining
aout its shortcomings and trying to stall its deployment. Work on fixing
the problems.

>
>> addressing them in IPv4), I don't think it makes sense to stand in
>> front of the internet and say "stop growing until we fix this."
>> (which is effectively what you say when you say only do limited
>> deployments).
>
> That depends on who you work for or who you're consulting for. If Mark
> (or anyone else) is doing security consulting, they go with "hey, deploy
> v6!", and their client gets into trouble with not apparent benefit from
> deploying v6, they might be in trouble.
>

As a consultant, your job is to provide the information to your client
so that they can make an informed decision, not make the decision
for them.

Yes, there are some limited circumstances where it makes sense to
delay IPv6 deployment for security considerations. However, putting
that out as general advice in a magazine article (or online equivalent)
is irresponsible at best.

>
>> I do like that the article thinks IPv6 only provides trillions of
>> addresses. Certainly in that case, it might be hardly worth the
>> effort. ;-) Fortunately, as you know, it's quite a bit larger than
>> that.
>
> And of course que also know that we shouldn't cound 2**64 addresses in
> each /64, because no one is going to have such a huge number of nodes in
> a single subnet.
>

Sure, but there are more than a trillion /64s in IPv6. A few million trillion as
a matter of fact.

>> The fake router RA vulnerabilities are well known and relatively well
>> understood. Vendors are working on it and most have reasonable
>> initial solutions with progress being made towards more complete
>> solutions.
>
> This is not the message that I got the last time I talk with some
> well-known desktop os vendor.
>

If you managed to find an OS vendor that is asleep at the switch, good for you,
you got an opportunity to educate someone. Nonetheless, the data has been
well published and I know most of the switch/router vendors either have running
code to (mostly) solve the problem or are working on it as we speak.

>
>> However, I do not see this as being any worse in most
>> cases than a rogue DHCP server which is a vulnerability in IPv4 that
>> has not been fixed even to this day.
>
> My understanding is that you cannot crash a host with forged DHCP
> responses, but that you *can* do taht with forged RAs.
>

I'm not sure I buy either one of those assertions.

Owen

[Dennis Bohn]

Hello, Two comments to items in the thread:


Jim Small jim....@cdw.com
9:04 AM (10 hours ago)
to ipv6hackers
S<snip>That said, in the space I work in Cisco and Microsoft have done

IMHO a pretty good job addressing the issues.

I respectfully disagree about Cisco (MS too, but not knowledgeable enough
to comment on Microsoft). Recently-purchased Cisco Access-layer switches
(3560) do NOT support RA guard. Unless it has been implemented in past 6
mos, it was only the chassis type switches (6500 & 4500) supporting RA
guard.

The very latest code for the nexus 7K still does not support dhcpv6 relay.
From what I read, dhcpv6 is still solidifying, so perhaps understandable.
The lack of RA guard on the mid-range switches is really disappointing.
Here, students in the dorms don't need to jack into a 6500 to get to
facebook/youtube/gmail (and we don't have the budget for it), but it would
be nice to prevent them from mis-configuring something and advertising
themselves as the router.

On Thu, Aug 23, 2012 at 2:28 PM, Fernando Gont <fg...@si6networks.com>wrote:

> On 08/23/2012 12:42 PM, Owen DeLong wrote:
>
> > The reality, however, is that snooping doesn't solve the problem, it
> > just tells you that it is happening.
>
> ?? -- It blocks it.
>

> So, as I understand it DAI (Dynamic Arp Inspection) provides the blocking
of arp-spoofing MIM attacks; dhcp snooping does the tracking and does block
dhcp replies from non-allowed ports. Hmmm, so as I think about it, RA
Guard will prevent a node from advertising itself as a router, in the same
way that DHCP Snooping prevents an unauthorized node from answering dhcp
requests. Will RA Guard stop a malicious end-point from spoofing the
actual router's mac addr or ipv6 addr?

Started out thinking I knew something, now am confused ;-(.

Or perhaps the Neighbor Discovery process itself prevents that? Or do we
need to do something like DAI, DNDI? Most of the MIM tools (I am thinking
Cain and Abel & ettercap) send out gratuitous arps. Is this kind of thing
possible with IPV6 Neighbor Disovery?

best,
dennis bohn

[Jim Small]

Hi Dennis,

> S<snip>That said, in the space I work in Cisco and Microsoft have done
> IMHO a pretty good job addressing the issues.
>
> I respectfully disagree about Cisco (MS too, but not knowledgeable enough
> to comment on Microsoft). Recently-purchased Cisco Access-layer switches
> (3560) do NOT support RA guard. Unless it has been implemented in past 6
> mos, it was only the chassis type switches (6500 & 4500) supporting RA
> guard.

You're right - that sucks. You can do Port ACLs as shown here:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/whitepaper_c11-602135.html

> The very latest code for the nexus 7K still does not support dhcpv6 relay.
> From what I read, dhcpv6 is still solidifying, so perhaps understandable.

I didn't realize that - that also sucks. I will make a point of harping on this.

> The lack of RA guard on the mid-range switches is really disappointing.
> Here, students in the dorms don't need to jack into a 6500 to get to
> facebook/youtube/gmail (and we don't have the budget for it), but it would
> be nice to prevent them from mis-configuring something and advertising
> themselves as the router.
>
> On Thu, Aug 23, 2012 at 2:28 PM, Fernando Gont
> <fg...@si6networks.com>wrote:
>
> > On 08/23/2012 12:42 PM, Owen DeLong wrote:
> >
> > > The reality, however, is that snooping doesn't solve the problem, it
> > > just tells you that it is happening.
> >
> > ?? -- It blocks it.
> >
> > So, as I understand it DAI (Dynamic Arp Inspection) provides the blocking
> of arp-spoofing MIM attacks; dhcp snooping does the tracking and does
> block
> dhcp replies from non-allowed ports. Hmmm, so as I think about it, RA
> Guard will prevent a node from advertising itself as a router, in the same
> way that DHCP Snooping prevents an unauthorized node from answering
> dhcp
> requests. Will RA Guard stop a malicious end-point from spoofing the
> actual router's mac addr or ipv6 addr?

There are more components for IPv6. The closest equivalent to DAI is NDP inspection. There is also DHCPv6 Snooping. For an overview check out these references:
http://www.cisco.com/web/about/security/intelligence/ipv6_first_hop.html
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6553/aag_c45-707354.pdf

> Started out thinking I knew something, now am confused ;-(.
>
> Or perhaps the Neighbor Discovery process itself prevents that? Or do we
> need to do something like DAI, DNDI? Most of the MIM tools (I am thinking
> Cain and Abel & ettercap) send out gratuitous arps. Is this kind of thing
> possible with IPV6 Neighbor Disovery?

All the IPv4 equivalents are needed. Some additional inspections are also brought to bear. If you use all the first hop security features the level of security is actually better than IPv4. That said, as you pointed out this isn't available on all platforms. And realistically not many people will use these features. They're great features, but a lot of protocols and applications mis-behave and trying to tweak security protocols to allow poorly behaved protocols and applications is often a losing battle...

--Jim

[Owen DeLong]

>> Started out thinking I knew something, now am confused ;-(.
>>
>> Or perhaps the Neighbor Discovery process itself prevents that? Or do we
>> need to do something like DAI, DNDI? Most of the MIM tools (I am thinking
>> Cain and Abel & ettercap) send out gratuitous arps. Is this kind of thing
>> possible with IPV6 Neighbor Disovery?
>
> All the IPv4 equivalents are needed. Some additional inspections are also brought to bear. If you use all the first hop security features the level of security is actually better than IPv4. That said, as you pointed out this isn't available on all platforms. And realistically not many people will use these features. They're great features, but a lot of protocols and applications mis-behave and trying to tweak security protocols to allow poorly behaved protocols and applications is often a losing battle...
>

Realistically, if you're not a university and you can't trust the people on your LAN, you've kind of already lost.

Owen

[Jim Small]

> >> Started out thinking I knew something, now am confused ;-(.
> >>
> >> Or perhaps the Neighbor Discovery process itself prevents that? Or do
> we
> >> need to do something like DAI, DNDI? Most of the MIM tools (I am
> thinking
> >> Cain and Abel & ettercap) send out gratuitous arps. Is this kind of thing
> >> possible with IPV6 Neighbor Disovery?
> >
> > All the IPv4 equivalents are needed. Some additional inspections are also
> brought to bear. If you use all the first hop security features the level of
> security is actually better than IPv4. That said, as you pointed out this isn't
> available on all platforms. And realistically not many people will use these
> features. They're great features, but a lot of protocols and applications mis-
> behave and trying to tweak security protocols to allow poorly behaved
> protocols and applications is often a losing battle...
> >
>
> Realistically, if you're not a university and you can't trust the people on your
> LAN, you've kind of already lost.

Security is an interesting proposition. It is expected to be present but not to interfere with anything useful. It is not appreciated and often bemoaned unless something really bad happens. Then there is fury that there wasn't enough security until the memory of the bad event fades and then there's annoyance and questioning of why all this irritating security is in place. This is compounded by the fact the companies like Apple who are wildly successful at marketing to consumers design things that are neither secure nor scalable but expected to be supported because of popularity. How you balance this all out is something I'm still struggling with. I would love to hear advice on how to do it.

--Jim

[Jim Small]

> >> The fake router RA vulnerabilities are well known and relatively well
> >> understood. Vendors are working on it and most have reasonable
> >> initial solutions with progress being made towards more complete
> >> solutions.
> >
> > This is not the message that I got the last time I talk with some
> > well-known desktop os vendor.
> >
> If you managed to find an OS vendor that is asleep at the switch, good for
> you,
> you got an opportunity to educate someone. Nonetheless, the data has
> been
> well published and I know most of the switch/router vendors either have
> running
> code to (mostly) solve the problem or are working on it as we speak.
>
> >
> >> However, I do not see this as being any worse in most
> >> cases than a rogue DHCP server which is a vulnerability in IPv4 that
> >> has not been fixed even to this day.
> >
> > My understanding is that you cannot crash a host with forged DHCP
> > responses, but that you *can* do taht with forged RAs.
> >
>
> I'm not sure I buy either one of those assertions.

Hi Owen - actually you can. See here:
http://www.networkworld.com/community/blog/known-ipv6-hole-freezes-windows-network-in-minutes

As far as I know, there is no equivalent vulnerability in IPv4. I wholeheartedly agree with Marc that this is unacceptable. Microsoft's position is untenable. I really hope this is fixed in 8/2012. Until Marc brought it up I just assumed this had been fixed. I'm a little stunned that it's gone on this long.

--Jim

[Owen DeLong]

If there isn't, it's because it got fixed a while back. (Ping O' Death anyone?... and that wasn't the only one).

However, I thought we were talking about reputable desktop OS. I hadn't realize that we were measuring an entire protocol by the capabilities of the least proficient development house on the planet. I make no excuses for Juniper on this one, either. However, to the best of my knowledge, they're the only two that still have this problem. If that's the case, I'd consider that a corner case and not an open issue.


Owen

[Marc Heuse]

>>>>> However, I do not see this as being any worse in most
>>>>> cases than a rogue DHCP server which is a vulnerability in IPv4 that
>>>>> has not been fixed even to this day.
>>>>
>>>> My understanding is that you cannot crash a host with forged DHCP
>>>> responses, but that you *can* do taht with forged RAs.
>>>
>>> I'm not sure I buy either one of those assertions.
>>
>> Hi Owen - actually you can. See here:
>> http://www.networkworld.com/community/blog/known-ipv6-hole-freezes-windows-network-in-minutes
>>
>> As far as I know, there is no equivalent vulnerability in IPv4. I wholeheartedly agree with Marc that this is unacceptable. Microsoft's position is untenable. I really hope this is fixed in 8/2012. Until Marc brought it up I just assumed this had been fixed. I'm a little stunned that it's gone on this long.
>
> If there isn't, it's because it got fixed a while back. (Ping O' Death anyone?... and that wasn't the only one).
>
> However, I thought we were talking about reputable desktop OS. I hadn't realize that we were measuring an entire protocol by the capabilities of the least proficient development house on the planet. I make no excuses for Juniper on this one, either. However, to the best of my knowledge, they're the only two that still have this problem. If that's the case, I'd consider that a corner case and not an open issue.

well, if Windows is not a reputable desktop os ... then I think this
discussion makes no sense right? come on, the Internet depends on
Microsoft and Cisco products, we we like it or not. And only one of them
is doing a good job here.

but your argument is still moot because in my list of IPv6 security
issues I found and where most of them still have to be fixed include:
Solaris, FreeBSD, OS X, Freebsd and QNX. But let me guess, these are not
reputable desktop os either.

and its stuff that is really not that hard to find or come up with as an
attack.

IPv6's maturity is not where it should be. Features available are not
where they should be. But thats understandable, because such things take
time and labor. and especially the labor part is the main reason it will
still takes one to two years until the implemenation is done, and then
it takes another year to see if the implementation was good and bugs are
fixed. Even then it will not be en par with IPv4, but at least then it
will be in an acceptable state.

yes, we do not have that time. but that is the reason why I recommend to
wait with IPv6 as much as long as you can, and only do the minimum
necessary.


And for the record: Windows 7 with all currennt updates applied is still
vulnerable to RA flooding, just tried last week.

Greets,
Marc

--
Marc Heuse
www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

[Jim Small]

> IPv6's maturity is not where it should be. Features available are not
> where they should be. But thats understandable, because such things take
> time and labor. and especially the labor part is the main reason it will
> still takes one to two years until the implemenation is done, and then
> it takes another year to see if the implementation was good and bugs are
> fixed. Even then it will not be en par with IPv4, but at least then it
> will be in an acceptable state.
>
> yes, we do not have that time. but that is the reason why I recommend to
> wait with IPv6 as much as long as you can, and only do the minimum
> necessary.

I believe that we are out of time, in fact even behind. I also believe that the best thing we can do to address security issues is to deploy. I'm not saying full scale deployments but pilots. Pilots get vendor products used. Use brings out bugs and awareness. The Internet is a great forum for communication - as vendor's products get used and bugs are found more and more people will talk about them. This is negative publicity that vendors will want to squash and the solution is to fix the bugs. Without deployment, I don't think the vendors are motivated. I agree that this is less than ideal, but from my vantage point that's the reality we live in.

> And for the record: Windows 7 with all currennt updates applied is still
> vulnerable to RA flooding, just tried last week.

This sucks - I will do what I can to apply pressure for a solution. It's tricky though - I don't want to squawk about it too much because then people won't deploy IPv6 and Microsoft won't be motivated to fix it. However, I will keep bringing it up and push for a timeline. The more customers I deploy, the more leverage I have to go back to Microsoft and show them negative publicity risk because of increased exposure (deployments).

--Jim

[Owen DeLong]

This is where we disagree. Yes, IPv6 has its issues, but by and large, those
issues aren't significantly worse than the current state of IPv4.

Yes, there are some IPv4 workarounds that haven't made it into the IPv6
world (or at least not universally) yet, but that's coming along at a fairly
reasonable pace. The wider IPv6 gets deployed, the faster those things
will get corrected.

>
> yes, we do not have that time. but that is the reason why I recommend to
> wait with IPv6 as much as long as you can, and only do the minimum
> necessary.
>

And that is the reason your approach only exacerbates the problem.

>
> And for the record: Windows 7 with all currennt updates applied is still
> vulnerable to RA flooding, just tried last week.
>

Shall we talk about all of the IPv4 vulnerabilities that are still present
in Windows 7 too?

Owen

[Karl Auer]

On Fri, 2012-08-24 at 16:52 +0000, Jim Small wrote:
> > And for the record: Windows 7 with all currennt updates applied
> > is still vulnerable to RA flooding, just tried last week.
>
> This sucks - I will do what I can to apply pressure for a solution.

Let's keep this in perspective too. To get an RA to a host you have to
be on the local link. There may be ways to remotely inject rogue RAs,
but I suspect that takes a lot of effort. And the panoply of attacks
possible if rogue RAs can be remotely injected or a link local host is
compromised go way beyond this one.

In short, how likely is this particular problem, RA flooding, to
actually be a problem in practice?

There are a lot of potential attacks that never turn into actual
attacks. Sure, we should be concerned about them and work to remove even
the theoretical possibilities, but should we let issues like this slow
us down?

I don't think so.

Regards, K.


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

[Marc Heuse]

>>> And for the record: Windows 7 with all currennt updates applied
>>> is still vulnerable to RA flooding, just tried last week.
>>
>> This sucks - I will do what I can to apply pressure for a solution.
>
> Let's keep this in perspective too. To get an RA to a host you have to
> be on the local link. There may be ways to remotely inject rogue RAs,
> but I suspect that takes a lot of effort. And the panoply of attacks
> possible if rogue RAs can be remotely injected or a link local host is
> compromised go way beyond this one.

well, you make the usage of the machine impossible. only a hard shutdown
can be done.
in a "normal" untrusted environment, an attacker can sniff on network
traffic or denial network traffic. but preventing that you can use your
machine is an issue. and having a personal firewall does not protect you.

so how can the average user joe defend himself? he can't, because he
does not know what hits him, and if he knew, he would not know how to
disable/prevent it.

remote injecting should not be possible, unless your have some very bad
tunnel implementation.

> In short, how likely is this particular problem, RA flooding, to
> actually be a problem in practice?

as long as you stay in your home or office, the chance should be pretty
small.
when you go to a conference, the chance rises, and if its a security
conference, it gets pretty high ... its the mobile user who is at risk.

at universities it happens too, gee even when I was at the university 15
years ago we played such DOS games (without ipv6 though) but it can
happen in a lot of other areas as well. airport wlans, hotel wlans ... I
have seen them misconfigured so you could talk ipv6 (even link local) to
other wlan machines where ipv4 was filtered.

Greets,
Marc

--
Marc Heuse
www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

[Karl Auer]

On Fri, 2012-08-24 at 23:39 +0200, Marc Heuse wrote:
> > In short, how likely is this particular problem, RA flooding, to
> > actually be a problem in practice?
> as long as you stay in your home or office, the chance should be
> pretty small.
> when you go to a conference, the chance rises, and if its a security
> conference, it gets pretty high ... its the mobile user who is at
> risk.

It's all about risk assessment - the interplay between the likelihood of
actual loss, the amount of likely actual loss, the cost of preventing
that loss, and the cost of making good that loss.

With this particular attack, the equation seems pretty clear. There is
low risk of the attack occurring, a low amount of loss likely even if
the attack occurs, the attack is limited to a single subnet which must
*already be compromised*, there are likely preventions in development in
the relatively short term, and the cost of repair is low even if the
attack does occur.

So lets NOT hold this one up as a shining example of why not to proceed
with IPv6 implementation and deployment.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

[Doug Barton]

On 8/24/2012 2:20 PM, Karl Auer wrote:
> Let's keep this in perspective too. To get an RA to a host you have to
> be on the local link.

... or have infected a host that IS on the local link with malware.

--

I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)

[Mike Jones]

On 24 August 2012 23:13, Karl Auer <ka...@biplane.com.au> wrote:
> On Fri, 2012-08-24 at 23:39 +0200, Marc Heuse wrote:
>> > In short, how likely is this particular problem, RA flooding, to
>> > actually be a problem in practice?
>> as long as you stay in your home or office, the chance should be
>> pretty small.
>> when you go to a conference, the chance rises, and if its a security
>> conference, it gets pretty high ... its the mobile user who is at
>> risk.
>
> It's all about risk assessment - the interplay between the likelihood of
> actual loss, the amount of likely actual loss, the cost of preventing
> that loss, and the cost of making good that loss.
>
> With this particular attack, the equation seems pretty clear. There is
> low risk of the attack occurring, a low amount of loss likely even if
> the attack occurs, the attack is limited to a single subnet which must
> *already be compromised*, there are likely preventions in development in
> the relatively short term, and the cost of repair is low even if the
> attack does occur.
>
> So lets NOT hold this one up as a shining example of why not to proceed
> with IPv6 implementation and deployment.
>

It's also an attack that the best defence against is to deploy v6
across your entire network. Any areas of your network that are v6
enabled may or may not be vulnerable depending on your
equipment/config, but v4-only equipment that has no idea about IPv6
will always be vulnerable.

how many networks are using that bug as an excuse for not deploying
v6? also how many of them are hiring new staff to replace the idiot
who told them that ignoring IPv6 would make the issue go away? :)

- Mike

[Karl Auer]

On Sat, 2012-08-25 at 01:49 +0100, Mike Jones wrote:
> It's also an attack that the best defence against is to deploy v6
> across your entire network.

I don't see how you arrived at that conclusion. RA flooding has nothing
to do with IPv4.

Regards, K.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (ka...@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

[Mike Jones]

On 25 August 2012 02:24, Karl Auer <ka...@biplane.com.au> wrote:
> On Sat, 2012-08-25 at 01:49 +0100, Mike Jones wrote:
>> It's also an attack that the best defence against is to deploy v6
>> across your entire network.
>
> I don't see how you arrived at that conclusion. RA flooding has nothing
> to do with IPv4.
>

How much IPv4-only equipment provides filtering for IPv6 RA packets?
worst case scenario (no RA filtering switches) you are vulnerable no
matter what you do, and deploying IPv6 will either have no impact on
this or it might possibly make it less of an issue (a lower priority
router etc, but this specific bug you're pretty much screwed either
way).

Another likely scenario is a network with "must fully support IPv6" as
part of its purchasing requirements. This network is more likely to be
able to protect themselves from these issues with RA guarding (i am
counting both this bug and the other issue of being able to MITM
everything, which is mostly related), so if someone really is
concerned about the security impacts of IPv6 on their network then
they would be encouraging v6 capabilities in any new equipment
purchases already, because a v4-only network is vulnerable to pretty
much every attack against v6 networks that is possible, a network that
requires IPv6 support from its vendors is probably going to be able to
protect against at least some of the vulnerabilities if not all of
them (depending on models etc).

I am simplifying things a little (you can get switches that have no
idea about IPv6 to drop RAs, but that typically only works if there
are no extension headers for example), however a network that thinks
these vulnerabilities don't apply to them if they ignore IPv6 is
probably extremely misguided at the very least, and more than likely
is also wide open to attack. I have seen this bug cited as an excuse
for not deploying IPv6 on several occasions, when in fact this
vulnerability already exists on the very networks they are talking
about and the only way to fix this is with some kind of v6 awareness
in the network. (or for microsoft to fix it and get the update applied
to all clients, which even if they changed their minds and tried to do
would probably not be completely effective, and wouldn't help with the
other RA issues).

I'm sure there is probably a network somewhere that filters all
ethernet packets that don't have the IPv4 packet type and filters all
the automatic IPv6 in IPv4 tunnels etc, they may or may not be
vulnerable to these types of issues, but they're also not typical :)

- Mike

[Owen DeLong]

On Aug 24, 2012, at 18:24 , Karl Auer <ka...@biplane.com.au> wrote:

> On Sat, 2012-08-25 at 01:49 +0100, Mike Jones wrote:
>> It's also an attack that the best defence against is to deploy v6
>> across your entire network.
>
> I don't see how you arrived at that conclusion. RA flooding has nothing
> to do with IPv4.
>

My understanding is that windows hosts are vulnerable to the attack
whether or not IPv6 is turned on on the host.

There are other things (like Teredo) where you have a serious security
hole potential with IPv6 turned off on your network, but turning on IPv6
will prevent (or at least make it quite a bit harder) to cause problems.

Owen

[Marc Heuse]

>>> It's also an attack that the best defence against is to deploy v6
>>> across your entire network.
>>
>> I don't see how you arrived at that conclusion. RA flooding has nothing
>> to do with IPv4.
>
> My understanding is that windows hosts are vulnerable to the attack
> whether or not IPv6 is turned on on the host.

well this is not the case. IPv6 has to be enabled, which is the default.

this is similar to the "there is no dhcp protection for ipv4" you said
before.

maybe your opinion why ipv6 deployment should be done now and the risk
is neglectable comes from that you are a good network guy, but you
knowledge of the security issues and impacts are not as deep?

Greets,
Marc

--
Marc Heuse
www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

[Arturo Servin]

If you have one infected machine with access to the link local, then you can do a similar attack using IPv4. So, v4 and v6 are even in this one.

With access to the local link, you probably can do very nasty things completely orthogonal to the L3 protocol. Rogue RA is just one mechanism particular for IPv6.

Regards,
as

On 24 Aug 2012, at 20:25, Doug Barton wrote:

> On 8/24/2012 2:20 PM, Karl Auer wrote:
>> Let's keep this in perspective too. To get an RA to a host you have to
>> be on the local link.
>
> ... or have infected a host that IS on the local link with malware.
>
> --

[Owen DeLong]

On Aug 25, 2012, at 04:47 , Marc Heuse <m...@mh-sec.de> wrote:

>>>> It's also an attack that the best defence against is to deploy v6
>>>> across your entire network.
>>>
>>> I don't see how you arrived at that conclusion. RA flooding has nothing
>>> to do with IPv4.
>>
>> My understanding is that windows hosts are vulnerable to the attack
>> whether or not IPv6 is turned on on the host.
>
> well this is not the case. IPv6 has to be enabled, which is the default.
>

Or perhaps I just mixed up this particular windows vulnerability with one
of the other 50,000 ways to crash a windows box using datagrams.

> this is similar to the "there is no dhcp protection for ipv4" you said
> before.
>

I didn't say there was none, I said that there was nothing better than the
current state of RA Guard.

I did make the mistake of thinking of snooping being snooping instead of
something called snooping that actively blocks packets.

> maybe your opinion why ipv6 deployment should be done now and the risk
> is neglectable comes from that you are a good network guy, but you
> knowledge of the security issues and impacts are not as deep?

Or maybe it's because I work in the real world where we consider not only the
possibility of an exploit, but also measure the likelihood that it will occur, the
benefit to the attacker, the impact if it does occur, and other factors when
considering a risk.

Then, we measure those risks of deployment against the other risks of failing
to deploy and make an informed decision.

Today, the risks of failing to deploy IPv6 far outweigh the risks of deployment.

All of the attacks mentioned so far have some or all of the following properties:

1. Relatively low value to the attacker.
2. Require link local access.
3. Have IPv4 equivalents that still work in 90+% of environments
(care to guess what % of environments actually use dhcp snooping?)
4. Are relatively easy to detect.
5. Are relatively easy to mitigate.
6. Improbable (Largely due to 1 above)

OTOH, the longer you wait to deploy IPv6 at this point, the more of the internet
you will be unable to reach. APNIC has been effectively out of addresses for
more than a year. RIPE will run out very soon. Likely the other RIRs will not be
far behind. Deploying IPv6 in a reasoned and controlled manner takes time and
planning. If you haven't already started that process, especially in an enterprise
of any meaningful size, you likely will not be able to complete it in a controlled
or reasoned manner and will leave yourself in the position of scrambling to
complete the deployment due to user demand.

Scrambling probably creates MUCH larger security risks than any of the IPv6
attacks described to date.

Owen

[Jim Small]

> > Let's keep this in perspective too. To get an RA to a host you have to
> > be on the local link.
>
> ... or have infected a host that IS on the local link with malware.

Doug, this is definitely possible. However, it's improbable. Following the security community the overwhelming trend is to compromise a system surreptitiously and maintain control of it in the same fashion. A Denial Of Service attack that renders the computer unusable until reboot is certainly serious, but it doesn't fit with the current mold of quietly compromise to gain and maintain control.

--Jim

[Jim Small]

> > My understanding is that windows hosts are vulnerable to the attack
> > whether or not IPv6 is turned on on the host.
>
> well this is not the case. IPv6 has to be enabled, which is the default.
>
> this is similar to the "there is no dhcp protection for ipv4" you said
> before.
>
> maybe your opinion why ipv6 deployment should be done now and the risk
> is neglectable comes from that you are a good network guy, but you
> knowledge of the security issues and impacts are not as deep?

Marc, I agree this is a significant risk. I also agree Microsoft needs to fix it. To the best of my knowledge there is a vendor who either has or will have a solution shortly in equipment you can buy which can mitigate this attack. It can block rogue RAs and block fragment attacks as described by Fernando. So this is at least a possible solution although I think we all agree that the ideal solution is for Microsoft to fix the problem.

What do you think about blocking RAs on "user" access ports? Do you see that as a partial solution? I know you can do the fragment attack, but how likely do you think it is that someone will do that? I apologize but I haven't playing with the IPv6 THC toolkit, does this do the fragmentation by default to defeat a simple ACL or do you have to enable this?

--Jim

[Mrs. Y.]

On that note, the Packetpushers podcast team (of which I am a member)
just started a security feed called Healthy Paranoia. I've been trying
to organize an IPv6 security show and am looking for researchers, as
well as engineers who've done some deployments, to appear on an episode.
I think it's important to have healthy, respectful conversations
covering this subject, so that we can continue to improve the quality
and security profile of our IPv6 deployments. Please feel free to
contact me offline if you're interested. You can check out the podcast
and blog site here:

http://packetpushers.net/

Regards,
Michele Chubirka

On 8/23/2012 11:47 AM, daniel....@bt.com wrote:
> Great response Owen, and I completely support your view.
>
> I'd be interested in hearing the challenges (if any) you and/or your organisation experienced with such an early adoption and full rollout, maybe off thread?
>
> Kind Regards,
>
> Dan.
>
> ----- Original Message -----
> From: Owen DeLong [mailto:ow...@he.net]
> Sent: Thursday, August 23, 2012 04:42 PM
> To: IPv6 Hackers Mailing List <ipv6h...@lists.si6networks.com>
> Subject: Re: [ipv6hackers] "Stick to limited IPv6 deployments, businesses warned"
>
>> Am 23.08.2012 16:21, schrieb Owen DeLong:
>>> Saying that there is no business case is about as intelligent as
>>> saying that everything should move urgently.
>>
>> yes, maybe. but where is the business case? if you have one, and the
>> business case makes sense financial wise for the hardware and labor - do
>> it. But I doubt that any company will have that for the next 2 years.
>>
>
> Bzzt... Thanks for playing, but HE is already fully dual stacked both in terms
> of our internal IT and our external networks. Being ahead of the curve didn't
> cost us all that much (mostly we included it in planned tech refreshes anyway)
> and now we're actually seeing some pretty good benefits from being there.

>
>>> Additionally, most of the security issues that Mark (and others) keep
>>> harping on in IPv6 aren't any worse than the ones we've lived with
>>> for years in IPv4.
>>

>> no, thats not the point. the point is that the implementations are not
>> where they should be for a global productional roleout.
>
> Neither is IPv4... That _IS_ the point. We rolled IPv4 out without worrying

> about it. IPv6 is a rollout to replace IPv4 because IPv4 is dying of several
> other horrible problems on top of its security issues. (address shortage,
> the overhead of NAT, the unsustainable IPv4 routing table and the additional
> fragmentation that will come from ever increasing address density, etc.)
>
> IPv4 has been on life support for more than a decade now. While we can't
> pull the plug just yet, we certainly don't have any time left to fiddle around
> and pretend we don't need something else ready soon.
>
>> the firewalls do not have all features required (filtering on options in
>> extension headers), OS implementations at various stages what they
>> support and what not (any OS beside Ubuntu that can get the DNS server
>> from something else than DHCP6?) - and the IPv6 stacks are not well
>> tested enough (see the number of issues found of IPv6 security issues
>> for example, compared to IPv4 security issues in the top-5 OS used).
>
> Yes... MacOS X gets it quite nicely from static and/or DHCP4. :p
>
> Sure, I know that's not what you meant, you meant specifically any other
> OS that supports RFC 6106, but that's not what you said.
>
> There is, apparently a source tool (rdnssd-win32) for Win32.
>
> Allegedly it is supported in OSX (10.7+) and iOS (5+). I haven't verified these.
>
>> thats why things should not be rushed.
>>
>
> I don't think I said anything about rushing. I believe what I said was that dragging ones feet isn't good advice.
>
>> but I agree to:
>>> "let's stop deploying anything that doesn't include IPv6 today."
>>
>>
>> and finally:
>>
>>> In fact, DHCPv4 doesn't even have the equivalent of RA Guard
>>> available.
>>
>> its called dhcp snooping
>>
>
> I can do the equivalent of that today snooping for RAs. Yes, it's slightly harder than DHCP snooping, but if you really want, it is do-able. If you consider that an adequate solution, then it is already completely solved for IPv6, too.

>
> The reality, however, is that snooping doesn't solve the problem, it just tells you that it is happening.
>

> With RA Guard, we have an actual partial solution which, with some improved handling of Extension Headers and Fragments could become a complete solution.
>

> Owen

[Dave Tingling]

Greetings IPv6 Community,

Please pardon this weird intrusion...I'll introduce myself in a
minute. This thread just grabbed my attention. I'm on an
awkward-to-use iPad and rushing into a meeting. But someone's
signature about 'being just one person and making a difference'
motivated me to chime in.

I haven't been closely following this discussion, but want to share a
few IMHO critical perspectives that I think have been glaringly
missing up until now. Please bear with me while I get through a
meeting then get properly caught up...more shortly.

I agree with Marc, (although I have to respectfully disagree with his
sharing his public key fingerprint with the world. This is not meant
to be a red herring or an argument against the man. For the curious or
uninitiated, the public key fingerprint in PKI / PGP trust webs should
be used for human, interpersonal identity verification. IMO, one
should obtain a person's public key then compute someone's his/her key
fingerprint yourself, verify it by personal conversation with the
human who is either (1) known personally and recognized by you OR who
proves his/her identity to you by showing a mutually trusted
certifying body (passport, driver's license, etc).

Believe it or not, this extremely relevant to an IPv6 "readiness"
discussion, and again -- I'm not arguing against anyone's competence.
Some of you may already see where I'm going, but If you haven't caught
it yet, I'll explain in my next post.

I'm synthesizing about 19+ years in IT "practice" with a security
focus. But you really shouldn't simply trust ME, just because I say so
:-) More when I get some minutes. Thank you for reading this far.


--
Dave Tingling
Information Systems Engineer, Streamlines LLC
http://www.streamlines.biz
v: 352-505-7885
f: 352-505-7886
tweet: @davetingling
skype: dave.tingling
GnuPG: 0x2A4B3573

This email may contain confidential information, the use of which by
any unintended recipient is unauthorized. This email may also contain
important disclosure information for the records of the intended
recipient(s). For details please visit
http://www.streamlines.biz/english_email_advisory

On Aug 23, 2012, at 6:49 PM, Doug Barton <do...@dougbarton.us> wrote:

> On 8/23/2012 11:35 AM, Fernando Gont wrote:
>> Maybe some get frustrated that after 30+ of IPv4, we're going through
>> all the hassle of deploying a somewhat similar protocol, with no
>> improvements in areas where its predecessor (IPv4) failed.... just for
>> the longer addresses.
>

> And some of us are frustrated that in what is quite possibly the worse
> case of second system syndrome ever documented in tech history, the
> quick and obviously necessary fix of "IPv4 with longer addresses" was
> discarded in favor of building a grand edifice that a decade later still
> has few residents.
>
> Doug

>
> --
>
> I am only one, but I am one. I cannot do everything, but I can do
> something. And I will not let what I cannot do interfere with what
> I can do.
> -- Edward Everett Hale, (1822 - 1909)

[Fernando Gont]

Hi, Jim,

On 08/23/2012 06:08 PM, Jim Small wrote:
>>> addressing them in IPv4), I don't think it makes sense to stand
>>> in front of the internet and say "stop growing until we fix
>>> this." (which is effectively what you say when you say only do
>>> limited deployments).
>>
>> That depends on who you work for or who you're consulting for. If
>> Mark (or anyone else) is doing security consulting, they go with
>> "hey, deploy v6!", and their client gets into trouble with not
>> apparent benefit from deploying v6, they might be in trouble.
>

> Deploying something just for the sake of doing it is irresponsible.
> I'm advocating a thoughtful pilot project for organization to learn
> IPv6.

Agreed -- but I don't think anyone has argued against *this*. Some folks
were just arguing against v6 deploying in production LAN environments.



> MAC address just like IPX and CLNP. While you could argue about this
> now it takes over 10 years to develop and roll out a protocol. If
> you don't like IPv6 you're welcome to start on the next generation
> protocol.

My job is not to like or dislike protocols, but to improve them where
possible. That's what I've tried to do so far.

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Fernando Gont]

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.



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


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


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


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

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

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

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.

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.

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

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.

[Marc Heuse]

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

word!!

Greets,
Marc

--
Marc Heuse
www.mh-sec.de

PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A

[Eric Vyncke (evyncke)]

Dennis and others,

[Sorry for such a late reply]

With my Cisco hat, I would like to add that 15.0(2)SE does bring RA-guard to Cat 3560 since 10 days or so. Late, very late but at least it is there. Other Cisco switches should follow in the coming months. The caveat is that some old switches do not have the hardware required to do it... So, an forklift upgrade will be required. And, I share your pain about Nx7K (and you could find others)

Without my Cisco hat...

IETF has now several 'SAVI' (source address validation improvement) RFC/I-D and we can expect that all vendors will implement those RFC. BTW, I still see a lot of networks running IPv4 without any security at the layer-2: no DHCP snooping, no dynamic ARP inspection, ... And do not get me started on the security of most of the WiFi hotspot...

I have hope that the IETF will adopt Fernando's I-D of making illegal all fragmented packets where the layer-4 header is not in first fragment. Then stateless devices (switches & routers) will be allowed to drop 'undetermined-transport' packets.

Also, IPv6 is here on the Internet, will be here on the intranet (actually is ALREADY there as we all know). Just do education, make a conscious decision about IPv6 in the intranet (good to deploy to get visibility and control IMHO).

Regards

-éric

> -----Original Message-----
> From: ipv6hacke...@lists.si6networks.com [mailto:ipv6hackers-
> bou...@lists.si6networks.com] On Behalf Of Dennis Bohn
> Sent: vendredi 24 août 2012 01:58
> To: IPv6 Hackers Mailing List
> Subject: Re: [ipv6hackers] "Stick to limited IPv6 deployments,
> businesses warned"
>

> Hello, Two comments to items in the thread:
>
>
> Jim Small jim....@cdw.com
> 9:04 AM (10 hours ago)
> to ipv6hackers
> S<snip>That said, in the space I work in Cisco and Microsoft have done

> IMHO a pretty good job addressing the issues.
>

> I respectfully disagree about Cisco (MS too, but not knowledgeable
> enough to comment on Microsoft). Recently-purchased Cisco Access-layer
> switches
> (3560) do NOT support RA guard. Unless it has been implemented in past
> 6 mos, it was only the chassis type switches (6500 & 4500) supporting RA
> guard.
>
> The very latest code for the nexus 7K still does not support dhcpv6
> relay.
> From what I read, dhcpv6 is still solidifying, so perhaps
> understandable.
> The lack of RA guard on the mid-range switches is really disappointing.
> Here, students in the dorms don't need to jack into a 6500 to get to
> facebook/youtube/gmail (and we don't have the budget for it), but it
> would be nice to prevent them from mis-configuring something and
> advertising themselves as the router.
>
> On Thu, Aug 23, 2012 at 2:28 PM, Fernando Gont
> <fg...@si6networks.com>wrote:

>
> > On 08/23/2012 12:42 PM, Owen DeLong wrote:
> >
> > > The reality, however, is that snooping doesn't solve the problem, it
> > > just tells you that it is happening.
> >

> > ?? -- It blocks it.
> >
> > So, as I understand it DAI (Dynamic Arp Inspection) provides the
> > blocking
> of arp-spoofing MIM attacks; dhcp snooping does the tracking and does
> block dhcp replies from non-allowed ports. Hmmm, so as I think about
> it, RA Guard will prevent a node from advertising itself as a router, in
> the same way that DHCP Snooping prevents an unauthorized node from
> answering dhcp requests. Will RA Guard stop a malicious end-point from
> spoofing the actual router's mac addr or ipv6 addr?

>
> Started out thinking I knew something, now am confused ;-(.
>
> Or perhaps the Neighbor Discovery process itself prevents that? Or do
> we need to do something like DAI, DNDI? Most of the MIM tools (I am
> thinking Cain and Abel & ettercap) send out gratuitous arps. Is this
> kind of thing possible with IPV6 Neighbor Disovery?
>

> best,
> dennis bohn

[Eric Vyncke (evyncke)]

Or move to an 'open' hotspot :-)

> -----Original Message-----
> From: ipv6hacke...@lists.si6networks.com [mailto:ipv6hackers-
> bou...@lists.si6networks.com] On Behalf Of Doug Barton
> Sent: samedi 25 août 2012 01:25
> To: IPv6 Hackers Mailing List
> Subject: Re: [ipv6hackers] "Stick to limited IPv6 deployments,
> businesses warned"
>

[Owen DeLong]

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.

Owen

[Fernando Gont]

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.

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

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Fernando Gont]

Hi, Eric,

On 08/28/2012 11:15 AM, Eric Vyncke (evyncke) wrote:
>
> With my Cisco hat, I would like to add that 15.0(2)SE does bring
> RA-guard to Cat 3560 since 10 days or so.

Key question: "Traditional" RA-Guard, or something along the lines of
draft-ietf-v6ops-ra-guard-implementation?

Thanks!

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Jim Small]

> 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?

--Jim

[Jim Small]

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


--Jim

[Owen DeLong]

On Aug 28, 2012, at 21:42 , Jim Small <jim....@cdw.com> wrote:

>> 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?
>

Sounds good.

Owen

[Eric Vyncke (evyncke)]

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)

-éric

> -----Original Message-----
> From: Fernando Gont [mailto:fg...@si6networks.com]
> Sent: mardi 28 août 2012 19:44
> To: IPv6 Hackers Mailing List
> Cc: Eric Vyncke (evyncke)
> Subject: Re: [ipv6hackers] "Stick to limited IPv6 deployments,
> businesses warned"
>

[Tomas Podermanski]

On 8/28/12 2:13 PM, Fernando Gont wrote:
> 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_slides_TncPresentation.pdf).

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.

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.

Cheers,

Tomas

[Owen DeLong]

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

[Tim Chown]

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.

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

These are excellent... good writeups.

I share Owen's view - there are tradeoffs in deployment, and those vary with the scenario. And similar tradeoffs happen with IPv4.

Tim

[SM]

Hi Tomas,

At 03:27 29-08-2012, Tomas Podermanski wrote:
>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/

I suggest formatting the above as an Internet-Draft and submitting it.

Regards,
-sm

[Tim Chown]

On 29 Aug 2012, at 22:09, SM <s...@resistor.net> wrote:

> Hi Tomas,
> At 03:27 29-08-2012, Tomas Podermanski wrote:
>> 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/
>
> 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.

This is a useful draft for people to contribute into:
http://www.ietf.org/id/draft-matthews-v6ops-design-guidelines-00.txt

And there's also:
http://tools.ietf.org/id/draft-vyncke-opsec-v6-01.txt

The resulting informational RFCs will only be as good as the material people contribute.

Tim

[Fernando Gont]

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.

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

You may want to refer to: http://www.rfc-editor.org/rfc/rfc1669.txt
-- how IPv6 deployment turned out should not be a "surprise" after
reading RFC1669.

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

Cheers,
--
Fernando Gont
e-mail: fern...@gont.com.ar || fg...@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Owen DeLong]

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

I beg to differ...

http://www.signedness.org/advisories/sps-0x1.txt

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

Your local "good" is also impacted.

>
>
>>>> 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?

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

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.

As a general rule, when a CFO is faced with a decision that looks like $100 today
for business continuity or wait until it breaks, spend $200 and lose a year of revenue,
it's what the CFO calls a no-brainer. IPv6 is, at this point, financially a no-brainer.

> You may want to refer to: http://www.rfc-editor.org/rfc/rfc1669.txt
> -- how IPv6 deployment turned out should not be a "surprise" after
> reading RFC1669.
>

How the IPv6 deployment is turning out is not a surprise to me.

Doesn't mean I'm going to stop trying to improve the situation and doesn't
mean that I"m going to stop capitalizing on the opportunities it creates.

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

Not as much as you seem to think (IMHO).

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

If it looked like your draft was going to face defeat in a last call, expire, or get abandoned, I'd jump in. It looks like it's progressing, so bad article headlines are more important use of my time right now.

I guess the importance varies from person to person. ;-)

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

You could have made that argument about IPv4. Indeed, I think NAT and the current state of the IPv4 network could be held up as proof of the validity of the argument as applied to IPv4. Likely it will be proven again with IPv6.

We are on the runway. The runway behind us is on fire and the fire is moving rapidly towards the tail of the IPv6 airplane.

We can either take off or be consumed by the fire.

Owen

[Tomas Podermanski]

On 8/29/12 11:09 PM, SM wrote:
> Hi Tomas,
> At 03:27 29-08-2012, Tomas Podermanski wrote:
>> 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/
>>
>
> 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.

Thanks
Tomas

[Fernando Gont]

Hi, Owen,

On 08/31/2012 12:17 AM, Owen DeLong wrote:
>
>> 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.
>
> I beg to differ...
>
> http://www.signedness.org/advisories/sps-0x1.txt
>
> 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.

Fix the underlying problem: improve the protocol, and slap the lazy vendors.

For instance: how come that you bought gear from a vendor that did not
even bother to deploy v6 in their own web site? (at the time)

Cheers,

--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Jim Small]

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

--Jim

[Jim Small]

> 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?

What do you think?
--Jim

[Fernando Gont]

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>

Cheers,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

[Jim Small]

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.

--Jim

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

[Jim Small]

Hi Tomas,

> 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?

--Jim

[Jim Small]

Hi Tomas,

> 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/

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-vista-7000003591/

Of course it may be different on Brno's campus, but globally XP's usage is steadily declining.

--Jim

[Tim Chown]

On 2 Sep 2012, at 20:15, Jim Small <jim....@cdw.com> wrote:

> Hi Tomas,
>
>> 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/
>
> 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-vista-7000003591/
>
> 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.

Tim

PS. I am reminded of http://www.kulfoto.com/funny-pictures/28099/still-love-vista-baby ;)

[Eric Vyncke (evyncke)]

Good point regarding Windows XP. End of support is April 2014, this means that enterprises/Govt are actively moving away from XP.

Point taken though that consumers will take longer...

See also:
http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173

-éric

> -----Original Message-----
> From: ipv6hacke...@lists.si6networks.com [mailto:ipv6hackers-

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

[Eric Vyncke (evyncke)]

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

Hope this helps

-éric

[Tore Anderson]

* Marc Heuse

> what I am talking about is enabling IPv6 internally. There is no need
> for this. no business need. So anybody wanting to do this without
> necessity should be fired.

http://static.usenix.org/events/lisa11/tech/full_papers/Babiker.pdf

(I met Irena earlier this year. She wasn't looking for a job.)

> I also always advice that companies should IPv6 enable the front-end
> DMZ. but nothing else.

So how can exactly will your ops staff be able to know the IPv6-enabled
front-end service actually work, and debug them if they don't, if they
don't have IPv6 connectivity internally?

For us, being able to do so is of utmost importance. That's why we had
IPv6 on our office LANs long before we deployed it on any
customer-facing production service.

--
Tore Anderson

[Tor Houghton]

List,

Looks like I failed to set my To:, so my previous attempt at posting may
have been been caught by the list's filter. This is therefore a slightly
modified edition of that post. I feel it's important enough to warrant a
comment, as there has been numerous posts here on countermeasures on the LAN
side (DHCP Guard, RA Guard).

Pardon me if the thread has covered this by now, but deploying IPv6
involves more than securing the clients from each other, although
certainly it is a nice (and necessary) feature to have (if it works).

Network monitoring (using NetFlow) is a personal bugbear for me. Where
support exists for IPv4, some vendors' models that purportedly are "fully
dual stack" may (often) lack NetFlow support for IPv6; this is especially
true for LAN equipment.

So, by enabling IPv6 one could possibly lose IPv6 visibility in ones network
unless either the switch (or supervisor module) was upgraded (or additional
flow generating equipment is installed); enabling v6 therefore becomes a
slightly more expensive option than perhaps originally thought.

(Experience has thus far told us that answers to questions about whether or
not equipment has "dual stack support" often are incomplete.)

Just my 2c.

Kind regards,

Tor

[Tomas Podermanski]

Hi Jim,
tanks a lot for comments.

On 9/2/12 8:06 PM, Jim Small wrote:
> Hi Tomas,
>
>> 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.

I share your view. Personally I don't like SLAAC at all. However it is
very "explosive" topic where different people have very differed opinion
about that. Observing the current situation all important vendors (MS,
Apple) started supporting DHCPv6, so I expect that DHCPv6 will be a
dominant method of autoconfiguration.

> 2) For privacy addresses, isn't stateful DHCPv6 the solution?

Yes. It is. But not all platforms supports DHCPv6 today. As I said
before - i hope that DHCPv6 will be widely used in the future.

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

Not at all. 802.1X is the layer 2 authentication. That says nothing
about IP address used for communication. You have to deploy some
mechanism that allows somehow tie L2 information obtained from 802.1X
authentication process (user, MAC address) with a L3 IP address. What is
pretty difficult since DHCPv6 don't have MAC in the requests and it is
impossible to tie 802.1x authentication requests with DUIDs from DHCPv6.
As such some extra system that gathers neighbor cache on the router have
to be deployed. The absence of MAC address in DHCPv6 is really tragic
issue.

Some more about that is on
http://ipv6.vutbr.cz/article/flow-based-monitoring-of-ipv6/ (slide 6)
and more detailed description in the article
http://ipv6.vutbr.cz/article/design-of-data-retention-system-in-ipv6-network/.

> 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?

You are right. The support for IPv6 in Win XP is in a minimal form.
However I expect that Win XP will disappear in a few next years. It is
one of the reason why we are just considering redesigning our SLAAC
environment to pure DHCPv6. Devices that doesn't support DHCPv6 won't
have access to IPv6 network. Users will have to either upgrade their
system or install additional software with a DHCPv6 client.

>
> 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)

Many vendors have some solution for this kind of threads (at least some
of them), however the price of those devices is much bigger comparing to
the devices that have similar security features for IPv4. For example
Cisco have this features only in the "big boxes" (6xxx, 49xx, 45xx) that
are no suitable as the access switches. Wen we building a new
installations we are in very difficult position. It is tough decision
whether to buy much more expensive switches that supports IPv6 security
features. Another option is to buy cheaper switches that have this
features only for IPv4 and in case of massive attack just block whole
IPv6 traffic on the access ports.

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

The support for IPv6 ACLs is related to support for filtering functions
in hardware. Switches that support IPv6 ACLs/PACLs usually have
implemented some kind of RA-Guard and related security features. So the
result - today, there are just no access switches on the market with
support IPv6 filtering (PACL, RA-Guard) for a good price.

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

I can't agree that features like DHCP snooping are used very rare. In
our environment it is basic requirement and every switch that is bought
must support it. In a past few years the worms like Flush.M or
DNSChanger has appeared quite often. Specially within environment where
users connects their own devices (computer, laptops). Agree that this
features are not necessary, lets say, in the office network or within
the network where you have control over the devices that are connected
to. But is not always the case. At the beginning we started without this
features as well. But as the network connectivity is essential for every
staff and worms are more aggressive the requirements for this features
are more often. I expect that importance of first hop security will grow
up in the future.

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

I have doubts that anybody would use RA-Guard based on SeND. From my
point configuring one command (to enable RA-Guard) is much easier them
configuring RA-Guard to work with send an periodically replace
certificates on the router switches etc. I personally don't expect that
send will by widely developed or used.

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

I didn't want to implicate that message. That slide just says the there
is always something more important than IPv6 in many organizations That
is the reason why IPv6 deployment is going so slow. I completely agree
that CGN as any kind of NAT sucks, but I also can see many ISPs having
no other choice than deploy CGN. NATs are used by many smaller providers
for years, so it is not a brand new technology comparing to IPv6. Btw.
you hit some interesting topic. Do you have some statistics or documents
proving that IPv6 is cheaper then deploying CGN ? I am not sure about that.

The fact is that less than 0.7% of clients are able to use IPv6 today
and less that 4% of content providers have content available over IPv6.
Such numbers also means that there are approximately 99.6% of clients
that are not able to reach IPv6 content and 94% of content (lets say web
sites) is not available for IPv6 only clients. It doesn't look good on
both sides and I really don't know what to do about it.

> 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 u
p.

I hope it will happen. We will see in next 10 years :-).

> 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?

Maybe it is something to think about. However it seem that process is a
"log distance run". Having practical experience the problems that we
tried to solve 4-5 years ago aren't solved yet or a very little progress
has been done. But there is still hope that progress will speed up
before all ISPs deploy CGNs.



Thanks a lot for your comments. I really appreciated it.

Tomas

[Tim Chown]

On 4 Sep 2012, at 22:02, Tomas Podermanski <tpo...@cis.vutbr.cz> wrote:
>
> Not at all. 802.1X is the layer 2 authentication. That says nothing
> about IP address used for communication. You have to deploy some
> mechanism that allows somehow tie L2 information obtained from 802.1X
> authentication process (user, MAC address) with a L3 IP address. What is
> pretty difficult since DHCPv6 don't have MAC in the requests and it is
> impossible to tie 802.1x authentication requests with DUIDs from DHCPv6.
> As such some extra system that gathers neighbor cache on the router have
> to be deployed. The absence of MAC address in DHCPv6 is really tragic
> issue.

There is this, which is about adding the link layer address in relays. So this gives you what you want if you're in an environment where all DCHPv6 requests are relayed.

http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt

> Some more about that is on
> http://ipv6.vutbr.cz/article/flow-based-monitoring-of-ipv6/ (slide 6)
> and more detailed description in the article
> http://ipv6.vutbr.cz/article/design-of-data-retention-system-in-ipv6-network/.

We harvest the necessary information from switch/router devices. There's a few open source packages that do this.

> You are right. The support for IPv6 in Win XP is in a minimal form.
> However I expect that Win XP will disappear in a few next years. It is
> one of the reason why we are just considering redesigning our SLAAC
> environment to pure DHCPv6. Devices that doesn't support DHCPv6 won't
> have access to IPv6 network. Users will have to either upgrade their
> system or install additional software with a DHCPv6 client.

Personally I think it's equally valid to take the view that IPv6 devices will pick their own addresses, and take account of that. In a campus style environment anyway.

>> 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)
>
> Many vendors have some solution for this kind of threads (at least some
> of them), however the price of those devices is much bigger comparing to
> the devices that have similar security features for IPv4. For example
> Cisco have this features only in the "big boxes" (6xxx, 49xx, 45xx) that
> are no suitable as the access switches. Wen we building a new
> installations we are in very difficult position. It is tough decision
> whether to buy much more expensive switches that supports IPv6 security
> features. Another option is to buy cheaper switches that have this
> features only for IPv4 and in case of massive attack just block whole
> IPv6 traffic on the access ports.

We've found the Cisco first hop security implementation in their WLCs problematic. Hopefully the new 7.3 builds just released will fix this.

>> 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.
>
> I can't agree that features like DHCP snooping are used very rare.

When I poll audiences of university network people, about half the hands go up when I ask who uses DHCP snooping.

> I didn't want to implicate that message. That slide just says the there
> is always something more important than IPv6 in many organizations That
> is the reason why IPv6 deployment is going so slow.

Which is the main reason that while 100+ UK universities have an IPv6 allocation, only 10 or so have any significant deployment.

The other arguments of managing IPv6 for security benefit, deploying to support teaching/research, etc haven't yet worked through. Other priorities are higher, and most universities in the UK have old Class B IPv4 allocations.

> The fact is that less than 0.7% of clients are able to use IPv6 today
> and less that 4% of content providers have content available over IPv6.
> Such numbers also means that there are approximately 99.6% of clients
> that are not able to reach IPv6 content and 94% of content (lets say web
> sites) is not available for IPv6 only clients. It doesn't look good on
> both sides and I really don't know what to do about it.

It depends which countries you look at. France and Romania are much higher. And while 4% of content providers have IPv6 by number, by traffic volume from a typical residential network, the figure is much higher, even approaching 50%. See http://6lab.cisco.com/stats. Google, FB, Youtube, etc represent a lot of traffic for home networks.

> Maybe it is something to think about. However it seem that process is a
> "log distance run". Having practical experience the problems that we
> tried to solve 4-5 years ago aren't solved yet or a very little progress
> has been done. But there is still hope that progress will speed up
> before all ISPs deploy CGNs.

I fear that once the expensive CGNs go in, ISPs may not thrown them away in a hurry.

> Thanks a lot for your comments. I really appreciated it.

Your slides are very good :)

Tim

[Tomas Podermanski]

Hi,

only a few comments

On 9/4/12 11:41 PM, Tim Chown wrote:
> On 4 Sep 2012, at 22:02, Tomas Podermanski <tpo...@cis.vutbr.cz> wrote:
>> Not at all. 802.1X is the layer 2 authentication. That says nothing
>> about IP address used for communication. You have to deploy some
>> mechanism that allows somehow tie L2 information obtained from 802.1X
>> authentication process (user, MAC address) with a L3 IP address. What is
>> pretty difficult since DHCPv6 don't have MAC in the requests and it is
>> impossible to tie 802.1x authentication requests with DUIDs from DHCPv6.
>> As such some extra system that gathers neighbor cache on the router have
>> to be deployed. The absence of MAC address in DHCPv6 is really tragic
>> issue.
> There is this, which is about adding the link layer address in relays. So this gives you what you want if you're in an environment where all DCHPv6 requests are relayed.
>
> http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt

I know about that. Another very similar draft
http://tools.ietf.org/html/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01.
However I haven't found any implementation of this yet. Neither hw
devices nor sw packages like ISC DHCP supports it. So it isn't still
option for today.

>
>> Some more about that is on
>> http://ipv6.vutbr.cz/article/flow-based-monitoring-of-ipv6/ (slide 6)
>> and more detailed description in the article
>> http://ipv6.vutbr.cz/article/design-of-data-retention-system-in-ipv6-network/.
> We harvest the necessary information from switch/router devices. There's a few open source packages that do this.

What specific packages do you use? We currently use MetNAV
(http://metanav.uninett.no/) for this purpose, but there are some
disadvantages here. Similar project netdisco (http://www.netdisco.org/)
have some supports for gathering neighbor cache from local network, but
not from MIBs.


Tomas

[Jim Small]

Hi Tim,

> >> 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)
> >
> > Many vendors have some solution for this kind of threads (at least some
> > of them), however the price of those devices is much bigger comparing to
> > the devices that have similar security features for IPv4. For example
> > Cisco have this features only in the "big boxes" (6xxx, 49xx, 45xx) that
> > are no suitable as the access switches. Wen we building a new
> > installations we are in very difficult position. It is tough decision
> > whether to buy much more expensive switches that supports IPv6 security
> > features. Another option is to buy cheaper switches that have this
> > features only for IPv4 and in case of massive attack just block whole
> > IPv6 traffic on the access ports.
>
> We've found the Cisco first hop security implementation in their WLCs
> problematic. Hopefully the new 7.3 builds just released will fix this.

Just curious, can you share specifics?

> >> 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.
> >
> > I can't agree that features like DHCP snooping are used very rare.
>
> When I poll audiences of university network people, about half the hands go
> up when I ask who uses DHCP snooping.

I'm actually very happy to hear that. I am a fan of L2 security as it prevents a lot of threats and problems. Lately I have experienced a resurgence of interest on the LAN side for 802.1X which I think is great. The challenge specifically with DHCP snooping/DAI/IPSG is I two fold:
1) I have seen it break some applications. For example, I believe we had problems with Bonjour of some Apple protocol/application. In fact, this was in a large school campus. The school just wanted to disable the security in favor of all Apple Apps working. I'm not trying to pick on Apple alone, but this is a common problem. Convincing customers to dig in and find a solution can be a challenge as sometimes the solutions take a fair amount of time. How do you deal with protocol/application incompatibilities?
2) Education - Using things like DHCP snooping/DAI/IPSG requires a better understanding of the network and how things work. You need to understand DHCP snooping for example if you want to move your DHCP server. While I can walk someone through how to do this, 6 months later they forgot, lost the documentation and are furious that they're taking an outage because for some reason DHCP doesn't work.

This gets back to the age old question of how do you inspire people to take their game to the next level with their network expertise and to proactively monitor their networks to mitigate security threats. Any takers? :-)


--Jim

[Jim Small]

Hi Tomas,

> > 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.
> I share your view. Personally I don't like SLAAC at all. However it is
> very "explosive" topic where different people have very differed opinion
> about that. Observing the current situation all important vendors (MS,
> Apple) started supporting DHCPv6, so I expect that DHCPv6 will be a
> dominant method of autoconfiguration.

So we're pretty much writing off RDNSS? That what it seems like to me, but just confirming.

> > 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.
>
> Not at all. 802.1X is the layer 2 authentication. That says nothing
> about IP address used for communication. You have to deploy some
> mechanism that allows somehow tie L2 information obtained from 802.1X
> authentication process (user, MAC address) with a L3 IP address. What is
> pretty difficult since DHCPv6 don't have MAC in the requests and it is
> impossible to tie 802.1x authentication requests with DUIDs from DHCPv6.
> As such some extra system that gathers neighbor cache on the router have
> to be deployed. The absence of MAC address in DHCPv6 is really tragic
> issue.

This is very interesting to me - so there may not be a solution yet, but one is coming. I will file this away and let you know (via the list) when I have more.

> Some more about that is on
> http://ipv6.vutbr.cz/article/flow-based-monitoring-of-ipv6/ (slide 6)
> and more detailed description in the article
> http://ipv6.vutbr.cz/article/design-of-data-retention-system-in-ipv6-
> network/.

Nice write up - seems like the hardest part is supporting older devices that don't do stateful DHCP. Did you ever consider trying to split up the clients or just do stateful DHCPv6 for example on the LAN with older clients being relegated to IPv4 only? Sounds like that's where you're going based on your next comment.

> > 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.
>
> I can't agree that features like DHCP snooping are used very rare. In
> our environment it is basic requirement and every switch that is bought
> must support it. In a past few years the worms like Flush.M or
> DNSChanger has appeared quite often. Specially within environment where
> users connects their own devices (computer, laptops). Agree that this
> features are not necessary, lets say, in the office network or within
> the network where you have control over the devices that are connected
> to. But is not always the case. At the beginning we started without this
> features as well. But as the network connectivity is essential for every
> staff and worms are more aggressive the requirements for this features
> are more often. I expect that importance of first hop security will grow
> up in the future.

I'm glad to hear that - see what I wrote Tim. Curious what your thoughts/experiences with this are.

> > 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.
>
> I didn't want to implicate that message. That slide just says the there
> is always something more important than IPv6 in many organizations That
> is the reason why IPv6 deployment is going so slow. I completely agree
> that CGN as any kind of NAT sucks, but I also can see many ISPs having
> no other choice than deploy CGN. NATs are used by many smaller providers
> for years, so it is not a brand new technology comparing to IPv6. Btw.
> you hit some interesting topic. Do you have some statistics or documents
> proving that IPv6 is cheaper then deploying CGN ? I am not sure about that.
>
> The fact is that less than 0.7% of clients are able to use IPv6 today
> and less that 4% of content providers have content available over IPv6.
> Such numbers also means that there are approximately 99.6% of clients
> that are not able to reach IPv6 content and 94% of content (lets say web
> sites) is not available for IPv6 only clients. It doesn't look good on
> both sides and I really don't know what to do about it.

This is climbing steadily. Overall Google's IPv6 traffic is up to .78%. In my neck of the woods it's at 1.34%. I've done a lot of research on this - unfortunately this is somewhat US Centric, but hopefully this will be encouraging:
In the US there are 10 residential ISPs with over a million subscribers. Of these, 6 are deploying IPv6 including the top 4. The largest residential ISPs have all exceeded 1% IPv6 usage for end users before June (part of World IPv6 Launch). The 7th is deploying next year, the 8th is currently testing, and only the 9th and 10th (the smallest ones) are quiet on their plans. However, even with these on the business side they have rolled out IPv6 offerings.
I don't mention the core/Tier 1 ISPs but just for the record they are all fully deployed across their core with IPv6, in fact this is true for the top 20 global ISPs.

From an AT&T study, where IPv6 is enabled all the way to the home user, up to 40%+ of their traffic switches to IPv6. As IPv6 keeps getting steadily deployed in the US expect these numbers to rise rapidly. I already mentioned LTE/4G and IPv6 surging this fall.

From a Content Provider vantage point:
Of the top 10 US Web Sites visited, 5 have IPv6 enabled:
1) Google 2) Facebook
3) YouTube 4) Yahoo
6) Wikipedia (Wikipedia is ranked #6, #5 doesn't do IPv6 yet)
Netflix which peaks at up to almost a third of US backbone traffic is fully IPv6 deployed
10% of the Alexa 1000 sites including Bing, AOL, XBOX, WebEx, US News, USDA, NYU, and many others are IPv6 enabled.
10% of US AS' have IPv6 prefixes
BYOD and mobile growth has caused several large American companies to deplete all RFC 1918 address space and take a hard look at IPv6
The US Federal mandate to have all public facing services on IPv6 by this month has spurred lots of action:
http://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov
While there's still more red than green this has had a tremendously positive impact on IPv6 interest an adoption - as the Feds role out IPv6, all the companies that work with them starting deploying, then the companies that work with them start deploying, etc...
The next US Federal mandate is complete IPv6 deployment by this time 2014. In response, several Federal agencies including the massive Veterans Affairs division have announced the elimination of IPv4 from their networks by this date.
The Cisco Visual Network Index estimates over 19 billion unique nodes on the Internet by 2016 - that would surely be joyous to do in IPv4.
Time Warner also did a study and concludes that CGN pricing pressures (it's very expensive to deploy and maintain) will result in universal deployment of IPv6 by the end of 2014. Still sound far off? :-)

--Jim

[Jim Small]

> > 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.
>
> I didn't want to implicate that message. That slide just says the there
> is always something more important than IPv6 in many organizations That
> is the reason why IPv6 deployment is going so slow. I completely agree
> that CGN as any kind of NAT sucks, but I also can see many ISPs having
> no other choice than deploy CGN. NATs are used by many smaller providers
> for years, so it is not a brand new technology comparing to IPv6. Btw.
> you hit some interesting topic. Do you have some statistics or documents
> proving that IPv6 is cheaper then deploying CGN ? I am not sure about that.

Here's what I have on CGN costs:
A fantastic overview from Lee Howard of Time Warner:
http://www.rmv6tf.org/2012-IPv6-Summit-Presentations/TCO%20of%20CGN.pdf

There's also an IDC study that shows it's cheaper for carrier's to deploy 6rd in addition to CGN (which is inevitable since there aren't enough IPv4 addresses left) and to eventually transition to IPv6:
http://www.ciscoknowledgenetwork.com/files/259_07-17-2012-IPv6_TCO_Analysis_EMEAR_CKN.pdf?utm_source=&utm_medium=&utm_campaign=&PRIORITY_CODE=

I know there are actual studies and more info but I always forget what I did with the links... :-(

Anyway - that's a good start, take a look and let me know what you think,
--Jim

[Owen DeLong]

On Sep 5, 2012, at 20:22 , Jim Small <jim....@cdw.com> wrote:

> Hi Tomas,
>
>>> 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.
>> I share your view. Personally I don't like SLAAC at all. However it is
>> very "explosive" topic where different people have very differed opinion
>> about that. Observing the current situation all important vendors (MS,
>> Apple) started supporting DHCPv6, so I expect that DHCPv6 will be a
>> dominant method of autoconfiguration.
>
> So we're pretty much writing off RDNSS? That what it seems like to me, but just confirming.
>

That's essentially writing off SLAAC which is, IMHO, a pretty bad thing.

Owen

[Jim Small]

Hi Owen,

> >>> 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.
> >> I share your view. Personally I don't like SLAAC at all. However it is
> >> very "explosive" topic where different people have very differed opinion
> >> about that. Observing the current situation all important vendors (MS,
> >> Apple) started supporting DHCPv6, so I expect that DHCPv6 will be a
> >> dominant method of autoconfiguration.
> >
> > So we're pretty much writing off RDNSS? That what it seems like to me,
> but just confirming.
> >
>
> That's essentially writing off SLAAC which is, IMHO, a pretty bad thing.

SLAAC is a done deal. The question is, will network and OS vendors extend their SLAAC implementations to support RDNSS. From what I can see, it seems like the answer is no. RDNSS is cool, it's nice for labs and other setup types, and it's a published standard. However, it's pretty much worthless if routers and mainstream O/S (e.g. Microsoft/Apple) don't support it. When inquiring about support I found some enthusiasm from developers but they couldn't come up with a business case to justify implementation. At first I thought there was a case, but the more I dig I'm sorry to say that it doesn't seem like there is one or at least not a strong case.

However, I would be very grateful to be proven wrong.

--Jim

[sth...@nethelp.no]

> > I share your view. Personally I don't like SLAAC at all. However it is
> > very "explosive" topic where different people have very differed opinion
> > about that. Observing the current situation all important vendors (MS,
> > Apple) started supporting DHCPv6, so I expect that DHCPv6 will be a
> > dominant method of autoconfiguration.
>
> So we're pretty much writing off RDNSS? That what it seems like to me, but just confirming.

Working for an ISP here - we are definitely asking our router vendors
about lots of IPv6 features, but RDNSS is *not* on the list so far.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

[Owen DeLong]

On Sep 5, 2012, at 22:01 , Jim Small <jim....@cdw.com> wrote:

> Hi Owen,
>
>>>>> 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.
>>>> I share your view. Personally I don't like SLAAC at all. However it is
>>>> very "explosive" topic where different people have very differed opinion
>>>> about that. Observing the current situation all important vendors (MS,
>>>> Apple) started supporting DHCPv6, so I expect that DHCPv6 will be a
>>>> dominant method of autoconfiguration.
>>>
>>> So we're pretty much writing off RDNSS? That what it seems like to me,
>> but just confirming.
>>>
>>
>> That's essentially writing off SLAAC which is, IMHO, a pretty bad thing.
>
> SLAAC is a done deal. The question is, will network and OS vendors extend their SLAAC implementations to support RDNSS. From what I

SLAAC is useless in 99% of cases without RDNSS. If you have to implement DHCP, you might as well go all the way.

> can see, it seems like the answer is no. RDNSS is cool, it's nice for labs and other setup types, and it's a published standard. However, it's pretty much worthless if routers and mainstream O/S (e.g. Microsoft/Apple) don't support it. When inquiring about support I found some enthusiasm from developers but they couldn't come up with a business case to justify implementation. At first I thought there was a case, but the more I dig I'm sorry to say that it doesn't seem like there is one or at least not a strong case.

At this point, looking for a business case for an IPv6 feature is probably not going to yield much more accurate results than many of the people searching for a business case for deploying IPv6.

SLAAC+RDNSS is very useful. SLAAC without RDNSS not so much since you then have to deploy DHCP anyway just to get the basic functionality SLAAC should have originally included.

Yes, lots of enterprises want DHCP for a variety of reasons (though I think that if they had SLAAC+RDNSS, many of the ones that currently think they need DHCP would realize they don't).

> However, I would be very grateful to be proven wrong.

It's hard to prove anything in this area. There isn't enough uptake of either one as yet to really establish good data, unfortunately.

Owen

[sth...@nethelp.no]

> > So we're pretty much writing off RDNSS? That what it seems like to me, but just confirming.
> >
>
> That's essentially writing off SLAAC which is, IMHO, a pretty bad thing.

Disagree completely. SLAAC works today, without RDNSS. We don't see a
compelling need for RDNSS here - and thus we're not asking our router
vendors for such support.

Steinar Haug, Nethelp consulting, sth...@nethelp.no

[Owen DeLong]

This might be helpful:

http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems

According to it, RDNSS is supported in Linux, BSD, JunOS, MacOS, MeeGo (whatever that is), and available as an addon for Vista and 7.

FWIW, the number of OS implementing RDNSS isn't much less than the number with DHCPv6 support in the table (10 RDNSS and 13 DHCP).

Owen

[sth...@nethelp.no]

> This might be helpful:
>
> http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems
>
> According to it, RDNSS is supported in Linux, BSD, JunOS, MacOS, MeeGo (whatever that is), and available as an addon for Vista and 7.

That table has ND and RDNSS in the same column. I haven't checked other
systems - but for JunOS it should be ND Yes, RDNSS No. See JunOS 12.2
documentation here:

http://www.juniper.net/techpubs/en_US/junos12.2/topics/reference/statement-hierarchy/protocols-router-advertisement.html

[Sander Steffann]

Hi Owen,

> SLAAC is useless in 99% of cases without RDNSS. If you have to implement DHCP, you might as well go all the way.

I don't agree at all here. SLAAC+Stateless DHCPv6 works fine. With RDNSS you can optimize a bit and avoid a few extra packets and a little bit of software (stateless DHCPv6 does not require that much code), but SLAAC+Stateless DHCPv6 is certainly not useless. It's what I use on most unmanaged networks.

- Sander

[Owen DeLong]

On Sep 6, 2012, at 00:03 , Sander Steffann <san...@steffann.nl> wrote:

> Hi Owen,
>
>> SLAAC is useless in 99% of cases without RDNSS. If you have to implement DHCP, you might as well go all the way.
>
> I don't agree at all here. SLAAC+Stateless DHCPv6 works fine. With RDNSS you can optimize a bit and avoid a few extra packets and a little bit of software (stateless DHCPv6 does not require that much code), but SLAAC+Stateless DHCPv6 is certainly not useless. It's what I use on most unmanaged networks.
>

If I'm going to the trouble of configuring DHCP on my server/router/etc., then I might as well just configure DHCP and skip SLAAC.

Who cares how much code it is or isn't, it's already written and it's already part of the OS. What I care about is how much I have to configure.
Having to configure in multiple places just to get complete autoconf information working sucks. I'd like to be able to configure SLAAC+RDNSS on the interface of the router and be done in a lot of cases.

Yes, I can make DHCP work, but I'd rather not have to just to get DNS servers, especially since it DOESN'T work even for that with MacOS prior to Lion or Windows prior to Vista or default installs of most deployed versions of Linux/BSD, etc. on the client side. (Admittedly, neither does RDNSS, so this totally sucks no matter what).

All of this is the unfortunate result of the fact that instead of developing complete solutions, various factions in the IETF spent all their time making sure that the other side couldn't get to consensus on anything complete.

As a result, we have half-assed DHCP with no routing. We have half-assed stateless autoconf with DNS servers as an afterthought and we have this hybrid approach of using partial implementation of DHCP to overcome the shortcomings inherent in SLAAC without RDNSS.

What we need is to complete these solutions on all sides so operators can choose the set that best fits their environment.

Owen

[sth...@nethelp.no]

> > I don't agree at all here. SLAAC+Stateless DHCPv6 works fine. With RDNSS you can optimize a bit and avoid a few extra packets and a little bit of software (stateless DHCPv6 does not require that much code), but SLAAC+Stateless DHCPv6 is certainly not useless. It's what I use on most unmanaged networks.
> >
>
> If I'm going to the trouble of configuring DHCP on my server/router/etc., then I might as well just configure DHCP and skip SLAAC.

Didn't really want to reopen that discussion. But since you mentioned
it - yes, some of us would indeed prefer to use DHCP only, no SLAAC.
We *may* get there some day...

Steinar Haug, Nethelp consulting, sth...@nethelp.no

[Tim Chown]

On 5 Sep 2012, at 20:59, Tomas Podermanski <tpo...@cis.vutbr.cz> wrote:

> On 9/4/12 11:41 PM, Tim Chown wrote:
>>
>> http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt
>
> I know about that. Another very similar draft
> http://tools.ietf.org/html/draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01.
> However I haven't found any implementation of this yet. Neither hw
> devices nor sw packages like ISC DHCP supports it. So it isn't still
> option for today.

Not yet, but it seems to have support to move forward. As you say, the big test is whether ISC implements it. Based on the author list, I'm guessing Cisco will.

>>> Some more about that is on
>>> http://ipv6.vutbr.cz/article/flow-based-monitoring-of-ipv6/ (slide 6)
>>> and more detailed description in the article
>>> http://ipv6.vutbr.cz/article/design-of-data-retention-system-in-ipv6-network/.
>> We harvest the necessary information from switch/router devices. There's a few open source packages that do this.
>
> What specific packages do you use? We currently use MetNAV
> (http://metanav.uninett.no/) for this purpose, but there are some
> disadvantages here. Similar project netdisco (http://www.netdisco.org/)
> have some supports for gathering neighbor cache from local network, but
> not from MIBs.

Ah, NAV, yes we use that along with some other customised stuff. The NAV support team is very good; they've just taken on a full-time developer to push it forward, so may be even more amenable to new feature requests now.

I understand Cisco are working on something too, based on a discussion a couple of IETFs ago.

I just feel in a campus environment expecting to lock everything down to DHCPv6 is not realistic; hence, if you want accountability, you need to deploy harvesting/monitoring tools that do that job for you.

Tim

[Tim Chown]

On 6 Sep 2012, at 03:47, Jim Small <jim....@cdw.com> wrote:

> Hi Tim,

>>
>> We've found the Cisco first hop security implementation in their WLCs
>> problematic. Hopefully the new 7.3 builds just released will fix this.
>
> Just curious, can you share specifics?

I will try to dig them out. We're deploying 7.3 very soon, so can see what changes that brings (from 7.2.x). I think the general issue was with RAs not getting where they should, if you have SSIDs built from multiple VLANs. Going to 7.3 will also fix a significant Windows 8 driver issue for their WLC/APs.

>>
>> When I poll audiences of university network people, about half the hands go
>> up when I ask who uses DHCP snooping.
>
> I'm actually very happy to hear that. I am a fan of L2 security as it prevents a lot of threats and problems. Lately I have experienced a resurgence of interest on the LAN side for 802.1X which I think is great. The challenge specifically with DHCP snooping/DAI/IPSG is I two fold:
> 1) I have seen it break some applications. For example, I believe we had problems with Bonjour of some Apple protocol/application. In fact, this was in a large school campus. The school just wanted to disable the security in favor of all Apple Apps working. I'm not trying to pick on Apple alone, but this is a common problem. Convincing customers to dig in and find a solution can be a challenge as sometimes the solutions take a fair amount of time. How do you deal with protocol/application incompatibilities?
> 2) Education - Using things like DHCP snooping/DAI/IPSG requires a better understanding of the network and how things work. You need to understand DHCP snooping for example if you want to move your DHCP server. While I can walk someone through how to do this, 6 months later they forgot, lost the documentation and are furious that they're taking an outage because for some reason DHCP doesn't work.

At least in the UK academic sites, eduroam is quite widespread, in maybe 150-200 sites, so admins are used to 802.1X, and some are (or have already) extending it to wired points.

> This gets back to the age old question of how do you inspire people to take their game to the next level with their network expertise and to proactively monitor their networks to mitigate security threats. Any takers? :-)

Well, yes :)

Tim

[Jim Small]

Hi Owen,

> >>> I share your view. Personally I don't like SLAAC at all. However it is
> >>> very "explosive" topic where different people have very differed
> opinion
> >>> about that. Observing the current situation all important vendors (MS,
> >>> Apple) started supporting DHCPv6, so I expect that DHCPv6 will be a
> >>> dominant method of autoconfiguration.
> >>
> >> So we're pretty much writing off RDNSS? That what it seems like to me,
> but just confirming.
> >
> > Working for an ISP here - we are definitely asking our router vendors
> > about lots of IPv6 features, but RDNSS is *not* on the list so far.
> >

> This might be helpful:
>
> http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_s
> ystems
>
> According to it, RDNSS is supported in Linux, BSD, JunOS, MacOS, MeeGo
> (whatever that is), and available as an addon for Vista and 7.
>
> FWIW, the number of OS implementing RDNSS isn't much less than the
> number with DHCPv6 support in the table (10 RDNSS and 13 DHCP).

That's good, but I'm a little skeptical. I have seen things reported here that turn out not to be true. Can someone who has OS 10.7 or 10.8 confirm that RDNSS actually works?

Thanks,
--Jim

[Owen DeLong]

On Sep 6, 2012, at 06:56 , Jim Small <jim....@cdw.com> wrote:

> Hi Owen,
>
>>>>> I share your view. Personally I don't like SLAAC at all. However it is
>>>>> very "explosive" topic where different people have very differed
>> opinion
>>>>> about that. Observing the current situation all important vendors (MS,
>>>>> Apple) started supporting DHCPv6, so I expect that DHCPv6 will be a
>>>>> dominant method of autoconfiguration.
>>>>
>>>> So we're pretty much writing off RDNSS? That what it seems like to me,
>> but just confirming.
>>>
>>> Working for an ISP here - we are definitely asking our router vendors
>>> about lots of IPv6 features, but RDNSS is *not* on the list so far.
>>>
>> This might be helpful:
>>
>> http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_s
>> ystems
>>
>> According to it, RDNSS is supported in Linux, BSD, JunOS, MacOS, MeeGo
>> (whatever that is), and available as an addon for Vista and 7.
>>
>> FWIW, the number of OS implementing RDNSS isn't much less than the
>> number with DHCPv6 support in the table (10 RDNSS and 13 DHCP).
>
> That's good, but I'm a little skeptical. I have seen things reported here that turn out not to be true. Can someone who has OS 10.7 or 10.8 confirm that RDNSS actually works?

Confirmed... I got RDNSS working on my Mikrotik router and my Mac (10.8) did, in fact, learn the DNS servers advertised.

Now, if only my Juniper router supported RDNSS.

Owen

[Alastair Johnson]

On 5/09/2012, at 11:43 PM, sth...@nethelp.no wrote:

>>> So we're pretty much writing off RDNSS? That what it seems like to me, but just confirming.
>>>
>>
>> That's essentially writing off SLAAC which is, IMHO, a pretty bad thing.
>
> Disagree completely. SLAAC works today, without RDNSS. We don't see a
> compelling need for RDNSS here - and thus we're not asking our router
> vendors for such support.

As a router vendor, I am being asked for RDNSS support and it is on my roadmap.

aj

[Alastair Johnson]

On 6/09/2012, at 12:25 AM, Owen DeLong <ow...@he.net> wrote:

> What we need is to complete these solutions on all sides so operators can choose the set that best fits their environment.

More or less agreed. As a vendor I'm not happy about doing 2x work, but religious and architectural beliefs are pushing that approach for now. I'm trying to be as complete as possible with both approaches, although it is always a juggling game.

aj

[Jim Small]

> >>> So we're pretty much writing off RDNSS? That what it seems like to me,
> but just confirming.
> >>>
> >> That's essentially writing off SLAAC which is, IMHO, a pretty bad thing.
> >
> > Disagree completely. SLAAC works today, without RDNSS. We don't see a
> > compelling need for RDNSS here - and thus we're not asking our router
> > vendors for such support.
>
> As a router vendor, I am being asked for RDNSS support and it is on my
> roadmap.

What are the most compelling cases you've heard?

--Jim