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

From: "Ebalard, Arnaud" <[email-masked]>
Date: Mon, 30 Apr 2007 11:10:45 +0200

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

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 30 Apr 2007 12:23:46 +0100

Hi,

First off, my take on this is to disable RH0 and deprecate it.

This has already been done in all the SixXS PoPs to avoid them and their
users to be a source/destination of this problem. Although it would be
fun to see the traffic levels go over 0.1% of IPv4 that kind of traffic
is not the traffic we want to see I guess :)

Also quite a large number of operators are already DROP-ing these
options. Which leads to another question: Should one DROP or REJECT
(icmp admin prohibited) these packets. Pro's/Con's on this anyone?

Ebalard, Arnaud wrote:
[..]

> yet (this is obviously not that simple for them).

I've started collecting ways to disable this at:
http://www.sixxs.net/faq/connectivity/?faq=filters

This also lists Cisco already who made a security announcement quite
some days ago, see the following URL which includes workarounds:
http://www.cisco.com/warp/public/707/cisco-sa-20070124-IOS-IPv6.shtml
Not all platforms are addressed with that of course and most thus
require updates, for some though there are no updates yet.
From Juniper I only know that they are 'working on it' and that was an
unofficial statement from one of their employees.

[..]
> You should also add anycast to the list.

Why Anycast? I guess you are not using any Root DNS servers or any
content distribution network? :) There are a lot of uses for anycast,
which you won't even notice that they are being used. Also Anycast per
se is not a special feature of IPv6, it is also used in IPv4.

Greets,
 Jeroen