Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissu es]

["Ebalard, Arnaud" <[e-mail]>]

Hi *,

Le 30 avr. 07 à 09:43, Pekka Savola a écrit :

> 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.

Size of IPv4 options is limited to 44 bytes, which leaves room for at  
most 10 addresses in the LSRR/SSRR options. With IPv6 Type 0 Routing  
Header, the only limitation is the MTU, which allow *at least* 77  
addresses in the RH0 (1280 bytes MTU. In real life networks, 87 or 88  
is closer to what you can really do.

In RFC 1883, the format of RH0 was different, and closer to IPv4 LSRR  
one. The number of addresses was limited to 23. This has been removed  
in RFC 2460. Wasn't there during the discussions, so I don't know why  
but this would be interesting to dig in the list archives.

> 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.

AFAIK, the processing of IPv4 options is deactivated by all network  
maintainers (soft path processing, attack surface). This is also the  
default on most (if not all) IPv4 stacks.

For IPv6, since last week, all major stacks are already no more IPv6  
compliant regarding RH0 processing :

FreeBSD : http://security.freebsd.org/advisories/FreeBSD- 
SA-07:03.ipv6.asc
OpenBSD : http://openbsd.org/errata40.html#012_route6
NetBSD  : http://www.nabble.com/heads-up:-IPv6-routing-header-0- 
issues-t3643494.html
Linux   : http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.20.9

Apple is aware of the issue, but has more latency.
Cisco and Juniper too, but no public statement/decision is available  
yet (this is obviously not that simple for them).

> Similarly, a decision should likely affect IPv4 as well.

Interesting.

> Some operations perspective:
> ----------------------------
>
> Please remember that using source routing for 'reverse path
> traceroute' is only possible if networks don't implement
> ingress/egress filtering.

 From tests I performed, this is not that much implemented (this was  
at least valid 10 days ago :-)).

> 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).

If it is kept in the specification (i.e. not deprecated), all IPv6  
stacks will be required to have it, even if they will (obviously)  
deactivate by default. One question is : is it worth having  
associated code in the stacks (cell phones, PDA, other portables  
devices) if there is no expected use.

As the amount of code has impact on stability/maintenance/security/ 
costs, IMHO, keeping the mechanism should be a motivated decision.

> 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.

You should also add anycast to the list.

a+

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------