Hi,
On Fri, 27 Apr 2007, Dave Thaler wrote:
Two scenarios that are much less harmful are
when there is only 1 address in only one RH0:
1) when the intermediate destination address and the final
destination address are addresses of the same node.
2) when the final destination address is equal to the
source address.
In both cases, the intermediate destination isn't being
used as transit between two other nodes. A sample use
case of the second scenario is for a round-trip
traceroute.
FWIW, I personally think 2) [turn off by default everywhere] seems
like the best choice, but I think 1) [deprecate] would also be OK. I
wouldn't mind 4) but I wonder if it's worth the trouble.
Some IPv4 perspective:
----------------------
IPv4 specifications (RFC 1812) require source routing to be enabled on
routers by default (a MUST). IPv4 hosts MAY process routing headers
(RFC 1122) and there are some specifications what should happen. It
seems that -- specification-wise -- the same attacks as exist for IPv6
(multiple routing headers, multiple waypoints) are possible with IPv4
as well.
IPv4 specifications also require that a host MUST reverse the routing
header if they're a final recipient (leading to a symmetric return
path). (IPv6 specs allow reversing only if RT header was
authenticated)
Because attacks would likely be possible using v4 source routing as
well -- unless implementation defaults differ significantly here --
we should be able to walk, not run, to a decision.
Similarly, a decision should likely affect IPv4 as well.
Some operations perspective:
----------------------------
Please remember that using source routing for 'reverse path
traceroute' is only possible if networks don't implement
ingress/egress filtering.
As such, I cannot support the 'reverse path traceroute' usage scenario
for source routing, because doing so shouldn't work in the first place
in well-operated networks, and could be yet another roadblock to
appropriate filtering.
The other scenario Dave mentions is AFAICS the one where type 2
routing header was designed for, and could probably be used in that
scenario as well, even if MIPv6 was not used.
A couple of folks mentioned using routing header for traffic path
selection (in the middle of the network). That also interferes with
ingress/egress filtering, but not quite as badly. This is probably
mostly useful for research purposes and I'm having difficulty seeing a
business case for doing this in production.
The reason why I'd prefer disabling instead of complete deprecation is
that I can imagine use cases where source routing can be a useful
diagnostics tool inside one administrative domain, and if we deprecate
it, it's gone for good (unless we define a new type, and transition to
it would take a long time).
On the other hand, given that these usage cases are rather limited, I
don't think they're in wide use, and still cause problems for
ingress/egress filters, I'm also ok with deprecation.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
