A feature slipped into the IPv6 protocol because of political, rather
than technical, considerations and has, perhaps unsurprisingly, come back
to haunt the IPv6 working group. It also caused a recent Linux kernel
release that disables
a particular routing 'feature' of IPv6 by default; it also allows
administrators to enable it if they wish. Even a cursory look at the IPv6
routing header type 0 (RH0) might lead one to remember a similar IPv4 feature
that eventually fell out of favor: source routing.
Mostly used as a diagnostic tool, source routing allows a packet to specify
the route, as a list of IP addresses, that should be used to reply to it.
This capability was abused in IP address spoofing attacks by
enabling the spoofer to see responses that normally would be routed
directly to the
spoofed address. Because of this (and other source routing abuses),
most routers are configured to drop packets that have source routing
information and have been since the mid-90s. Ten years or more would
seem to be enough time to ensure that the 'next generation' of IP
(IPv6 was originally billed as 'IPng') missed out on repeating these
mistakes of the past; sadly, that is not the case.
IPv6 introduces something called a 'routing header' into the protocol
as part of the extension headers, which are meant to replace the IPv4
options field. Three types of
routing header are defined, one of which is unused (type 1) and
another which is only used by Mobile IPv6 implementations (type 2).
It is the third (type 0) that is the cause of all the current uproar.
Also known as RH0 headers, they contain a list of hosts to be 'visited' on
the way back to the source address. It should be noted that the IPv6 RFC
mentions IPv4 source routing as part of the description of RH0.
(PDF) at the CanSecWest 2007 conference outlined several vulnerabilities with
RH0 and that led to the kernel changes in 220.127.116.11. The biggest
vulnerability appears to be in the amplification effect that can be
caused by listing hosts multiple times in the 'route'. One packet
can then cause what are essentially multiple copies of itself to be
sent back and forth between the hosts listed in the header. This can
be used to multiply the traffic in a denial of service attack as well as
masking the source of the attack. The BSD operating
systems have also released new versions to address this problem and the
router vendors will not be far behind.
(It should be noted that a bug in the original Linux fix was addressed in
18.104.22.168 and because
2.6.21 had been released in the interim, in
22.214.171.124 as well.)
Given that the problems with source routing are known and that the parallels
between RH0 and source routing are also known, how did we get to the point
where this kind of feature was added into IPv6? The Internet Engineering
Task Force (IETF) IPv6 working group is discussing some of that in a
on their mailing list. A memorable
by Theo de Raadt seems to indicate that 'academics' in the process forced
the inclusion of RH0 through politics. Paul Vixie
and indicates that he sees it as more evidence that the IETF is largely
irrelevant in setting internet standards today. In addition, no one
responding to the thread seems to be able to come up with a particularly
valid use case for the feature.
This would appear to be a classic case of ignoring the past and being
doomed to repeat it, but it would also appear that the politics of
standards bodies played a role. We certainly are not well served
when political considerations trump security (or, really, any technical)
considerations. Hopefully this will be yet another object lesson for those
of a political bent.
to post comments)