RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues]

[Pekka Savola <[e-mail]>]

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
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------