Experts scramble to quash IPv6 flaw

Where is the flaw?

Was this ipv6 "feature" really deserving of a headline "Experts scramble to quash IPv6 flaw".

I may have misunderstood, but is the only problem that malicious packets could containing cycles?

I'm a little surprised that the ipv6 spec wouldn't mention this. Non the less here is an obvious fix: have routers short circuit the cycles, or even reject those packets all together.

Source routing is one solution to a real accessibility problem for mobile users. Otherwise mobile users would annoyingly loose IPs while traveling across multiple subnets.

Another solution is to use proxies for mobile users, however proxied traffic multiplies user's bandwidth footprint and increases packet latency. Not to mention expense of maintaining proxy servers.

Someone shed some light please why this is a "flaw"?

Re: Where is the flaw?

The problem is the source routing - you effectively specify which path packets should take, so you can overload intermediate sites as well when doing the nasty. IPv6 has adopted this feature from IPv4, and in the process made room to specify more hops.

Relying on IP addresses to solve "a real accessibility problem for mobile users" is never going to work. The problem for mobile users is how to recognize and authenticate legit users, and there are other, more reliable ways to do that already, even in IPv6. IPSec, which is an integral part of the full IPv6 standard, provides ways of doing just that. Several IPSec implementations give a mobile user a semi-static IP on the target network, eliminating the wandering IP issue.

Using loose source routing just to recognize mobile users makes no sense.

Re: Where is the flaw?

"you effectively specify which path packets should take"

That's the idea.

"so you can overload intermediate sites as well when doing the nasty."

Ok, that's true, but what about a single source route instead of an entire path? That's all that would be needed for mobile users.

The harm caused by attackers would be very similar to the harm caused by malicious ip spoofing today (where one packet can attack two hosts as well as intermediate routers).

"The problem for mobile users is how to recognize and authenticate legit users, and there are other, more reliable ways to do that already, even in IPv6."

Where did you got the idea that source routing should be used to authenticate users? It is intended to take the most efficient route to the user.

Obviously we could move this complexity into the application layer. But ideally we could use any existing application (like ssh) without breaking the connection.

If the harm is too great then we'll have to do without source routing, but I'm still not convinced that this feature causes that much harm.

Of all the small pleasures in life, I like 'nitpicking' best

"Arnaud Ebalard pointed out that RH0 support allows attackers to amplify denial-of-service attacks on IPv6 infrastructure by a factor of at least 80"

"In rough terms, it makes everything we thought was bad, a thousand times worse," Paul Vixie, president of the Internet Systems Consortium, said.

"it can also be used to amplify a denial-of-service attack by a factor of 10"

So which is it 80, 1000 or 10 times as bad as IPv4?

Long live backward compatibility

If one desires to enable source routing within the borders of his/her network, so be it. Telnet and HTTP are still insecure but no one is disabling them just because of that. Instead everyone is having the option to use their secured versions or to use them as they are.

Several points to comment:

1. The title is dull indeed. However we should not blame the messenger for the content of what he have brought. While the source routing might be classified as undesirable feature, and turning it on by default can be unsecure, this is not a flaw of the protocol. A flaw is to assume 640kB memory big enough for the centuries to come, or to assign a whole class A network to a company with 300k employees. But that's the business of news making and getting the message to the customer - if one does not use such a "keyword", (s)he risks losing the attention of already annoyed audience.

2. It is questionable whether this feature had to be caried on from IP v4 to v6 - the set of valid uses is rather limited, and even in those ones there always can be found a better solution. However I have not seen the script of the discussions before setting IPv6 in stone, so cannot comment why the functionality was kept. There is no need for a standard which suits me and me only.

3. The real problem for me is the reaction to the issue with potential malicious usage of <something>! First reaction is the usage of strong words instead of brain activity. The second reaction is just panic - looking at the so called "patch" in OpenBSD (ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.0/common/012_route6.patch) one can see that the code is just commented out using an include statement. A REAL programmer would document the potential security implications instead of disabling a functionality.

Another way?

Why not just include a new condition in the spec: drop a packet if its source routing header contains an address that appears more than once? Keeping the original functionality, right?

nit picking with the best; & other irrelevance

Philip Stott: It's 88.

If we are going to have pointless and excessive exaggeration (that's probably redundant isn't it - I don't suppose insufficient exaggeration is very likely), I for one would prefer a few more 'low tech' comparisons - perhaps some analogy involving football fields, or the head of a pin. Or ball bearings in a swimming pool, that's always good. Something to allow me some understanding of how a factor of 88 can be a thousand times worse. Or just a thousand times anything really. A thousand times bigger than .088 I suppose....

I'm probably just not very sharp.