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

Fernando Gont fgont at si6networks.com
Sat Sep 1 02:01:25 CEST 2012


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: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492






More information about the Ipv6hackers mailing list