After reading draft-ietf-ipv6-deprecate-rh0-00.txt, I found several
problems:
- the draft mentions "serious security implications" that can be
"exploited"
without explaining what those are
- the draft "deprecates" the routing header type 0 without explaining
what deprecation entails
- the document forbids origination or processing of packets with a
routing header type 0, which is contrary to my interpretation of the
meaning of "deprecate"
- although listed as an informative reference, the draft exclusively
relies
on http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf to explain
the problems the draft endeavors to solve
In short: the draft uses undefined terminology, does more than it is
supposed to do, provides no explanation of any kind but rather refers
to an external document that is high on rhetoric ("Type 0 : the evil
mechanism we describe in this presentation") and grandiose claims
("Defeating Root DNS servers anycast architecture") and low on useful
technical description.
To fix this, we should explain the problems that source routing and/
or the routing header type 0 can cause, define what "deprecate" means
and then what deprecation of the routing header type 0 means in
practice, and how this solves the problems explained earlier. Or we
simply forego use of the word "deprecate".
I would also like to see a discussion of source routing in IPv4
included here, contrary to popular belief source routing for IPv4 is
enabled on a good number of routers, and relatively recent software
from one popular vendor still has IPv4 source routing enabled by
default.
See text below.
Both IPv4 and IPv6 provide the option for the source of an IP packet
to influence routing decisions by listing a number of intermediate
hops that the packet must pass through on its way to its ultimate
destination. This is called source routing. In IPv4, two forms of
source routing are defined as IP options that increase the length of
the IPv4 header, see RFC 791. In IPv6, source routing is accomplished
by placing a "routing header" directly behind the IPv6 header.
Multiple forms of source routing are possible, but generic loose
source routing is provided by a routing header type 0 (RH0). The only
other type in use is 2, for Mobile IPv6. See RFC 2460 for a detailed
description of RH0.
Although source routing has been possible with IP for a very long
time, the mechanism is rarely used. The only known use of the
mechanism is for troubleshooting: by having diagnostic packets (such
as those generated by the traceroute utility) flow through a
designated router using the source route mechanism, it is possible to
evaluate connectivity of that router. There are, however, undesirable
uses of the source route mechanism in general and RH0 in particular.
When a router or other device is configured to filter out certain IP
packets, a naive implementation or configuration of such a filter may
let source routed packets through even though otherwise identical
packets that aren't source routed would have been rejected. When a
packet with the routing header type 0 hasn't been processed by the
last source routed hop yet, the destination address in the IPv6
header is different from the the final destination of the packet. So
a filter that ignores the RH0 specification in RFC 2460 and only
evaluates the IPv6 header without considering the RH0 may arrive at
an undesired conclusion. Use of RH0 may also provide reachability to
nodes that have a global IPv6 address but no direct global IPv6
connectivity.
Source routing also allows a single packet to traverse a given link
more than once, using up unnecessary capacity in the process.
Fortunately, this ability is limited by the filtering that is common
on the boundaries between networks, so the impact of potential abuse
of this type is limited. Although the RH0 makes the destination field
in the IPv6 header change after each source routed hop, the source
address remains the same throughout the lifetime of the packet. This
means that when a packet originating at network A with network D, as
its destination and intermediate networks B and C listed several
times as source routed hops, will appear to come from A when it goes
from A to B and from B to C, which is expected and, presumably,
allowed. However, when the packet is then forwarded back from C to B,
BCP38-style ingress filtering will discard the packet. The same
happens if C employs egress filtering by checking whether packets
leaving the network have source addresses that belong to the local
network or its customers. This means that using the source routing
mechanism to use up bandwidth can only be successful on inter-domain
links where no filtering is deployed on either side, or within a
single administrative domain. In other words, a network that faces
malicious source routed packets can limit the flow of these packets
by either implementing ingress or egress filters, and stop it by
disabling source routing on its routers.
With IPv4, the presence of any options in the IP header is
problematic, because this makes efficient processing of the packet in
question impossible. This means that a relatively low number of
source routed packets (or other packets with options) can use up a
much of a router's processing capacity. With IPv6 RH0 is problem is
less pronounced because the option only needs to be evaluated when
the packet arrives at the node indicated by the IPv6 destination
address in the packet.
Since source routing can be used in ways that are undesirable, the
IETF has reached the following consensus:
1. Implementation of source routing as defined in RFCs 791 and 2460
is optional. An IP implementation MAY omit the source routing
capability and is then still considered in full compliance with RFC
791 or 2460, respectively.
2. IP implementations that support source routing, MUST provide an
administrative mechanism for disabling the source routing functionality.
3. IP implementations that support source routing, SHOULD have source
routing administratively disabled by default.
4. IP implementations that do not implement source routing or have
source routing disabled, SHOULD return an ICMP error appropriate for
encountering an unknown option as per RFC 791 and RFC 2460,
respectively.
The IETF does not recommend blanket filtering of all packets that
contain a source routing option; if any filtering of source routed
packets is performed, the filter should only reject packets with the
routing header type 0, in order to avoid breaking the Mobile IPv6
protocol and future protocols that may use similar mechanisms.
IP implementers who want to retain the source routing mechanism are
encouraged to implement additional constraints to avoid misuse of the
mechanism. For instance, the number of source routed hops may be
limited, only a single RH0 option per packet may be allowed, and/or
source routed packets that visit the same hop multiple times may be
rejected.
There has been some confusion over the correct interpretation of some
of the text pertaining to RH0 in RFC 2460. Some implementers have
implemented RH0 such that when a host is listed as an intermediate
hop in a routing header, the host executes the source routing
algorithm and forwards the packet to the next source routed hop. This
interpretation of RFC 2460 should be considered incorrect: if, after
processing a routing header, a host determines that the packet is not
addressed to one of the addresses the host currently holds, the host
MUST NOT forward the packet, but it SHOULD send back the ICMP error
appropriate for encountering an unknown option.
Iljitsch van Beijnum
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
