Subject: IPv6 Type 0 Routing Header issues

From: Jeroen Massar <[email-masked]>
Date: Tue, 24 Apr 2007 00:53:42 +0100

Just in case folks are missing out on this, find below a rather nasty
security issue.

Please use "IPv6 Ops list <[email-masked]>" for discussion,
see also: http://lists.cluenet.de/pipermail/ipv6-ops/

Greets,
 Jeroen

-------- Original Message --------
Subject: [dns-operations] IPv6 Type 0 Routing Header issues
Date: Mon, 23 Apr 2007 17:07:57 +0200
From: Nicolas FISCHBACH <[email-masked]>
To: [email-masked]

Very interesting presentation by Arnaud and Phil:

http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf

If you only care about the DNS related bits, start on page 29.

Nico.
-- 
Nicolas FISCHBACH
Senior Manager - Network Engineering/Security - COLT Telecom
e:([email-masked]) w:<http://www.securite.org/nico/>

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Apr 2007 00:46:28 +0300

> Just in case folks are missing out on this, find below a rather nasty

I cannot say that this is a big surprise, even if the specific attack
is news to me and it has a major impact. Some issues with Type 0
have been known for years; I think draft-savola-ipv6-rh-ha was the
first to report these. RFC 4294 warns of the issues and RFC 3775
design was based on the idea of avoiding Type 0 because it
was felt that at some point Type 0 would likely be filtered due
to its problems. Also, draft-ietf-v6ops-security-overview was recently
approved. It notes, among other things that "it may be desirable
to forbid or limit the processing of Type 0 Routing Headers
in hosts and some routers."

So I think we should take that advice and modify the stacks that
do not do the right thing today. A good first approximation is
to add a configuration knob for processing Type 0 headers
in both hosts and routers, with default set to off. Better
firewall support for doing this would also be needed (without
disabling use of Type 2, of course).

But we at the IETF also need to draw a conclusion about the
state of Type 0. This feature needs to be retired.

Jari

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Wed, 25 Apr 2007 10:49:25 +0900

At Wed, 25 Apr 2007 00:46:28 +0300,
> disabling use of Type 2, of course).

FreeBSD has already committed patches disabling the processing of
route header option 0 by default in all 3 of the currently shipping
branches (HEAD, 6-STABLE and 5-STABLE).

> state of Type 0. This feature needs to be retired.

The sooner that decision is made the better.  Those of us working on
the stacks would like to remove this processing if the feature is
retired.

Best,
George Neville-Neil
(FreeBSD Security Team and Core Member)

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 25 Apr 2007 09:41:09 +0200 (CEST)

Hi All,

I think this is not a solution. The problems of routing header type 0 well 
know by the community since long time. This has been documented for more 
than 2-3 years know (raised 4 years ago). Are there any consensus, that 
type 0 routing header should be deprecated? Until that it is documented to
  be filtered if there is no need for it. The current patch provided by 
OpenBSD/FreeBSD makes *BSD IPv6 implemenation non-conformant to standard. 
I would rather focus on pf changes - allow filtering based on the routing 
header type. Currently you can filter based existence/non-existence of 
routing header type. This is currently clearly not enough....

Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: David Malone <[email-masked]>
Date: Wed, 25 Apr 2007 09:31:12 +0100

On Wed, Apr 25, 2007 at 09:41:09AM +0200, Mohacsi Janos wrote:
> routing header type.

It seems to me that there are at least two questions here. One is,
"Should IPv6 nodes process type 0 routing headers by default?" The
second is, "should the network allow type 0 routing headers to pass?"

This is a bit like they choice you have for blocking a smurf attack.
You can block it by turning off directed broadcasts (on the edge)
or you can block it by blocking ICMP packets throughout the network.

I think it may actually be that we do not want nodes to process
type 0 routing headers by default, but the network should pass them.
The reason for this is that the type 0 headers have useful applications
which could be secured by end hosts without getting the network
involved at all. Then end hosts that want to use the routing header
can, and those that don't are secure by default.

I could easily be wrong though...

	David.

---

From: Remi Denis-Courmont <[email-masked]>
Date: Wed, 25 Apr 2007 10:46:54 +0200

On Wed, 25 Apr 2007 10:24:08 +0200, Gert Doering <[email-masked]> wrote:
> Well, one could argue that the standard isn't very well-written then - a
> machine that is a *host* should NEVER forward packets, period.

That's a BSD bug, not a standard bug.

The IPv6 specification says host must process RT0. It does not say they must
forward packets as if they were routers on the sole basis of RT0 presence.

By the current spec (as far as I understand), if a host receives a RT0, it
must process it. Then it must apply the same rules to the "new" packet
destination as it would do to any packet it receives; in particular, if the
packet cannot be delivered locally, it is dropped. You do the exact same
thing when you receive a packet from link-layer while you are not the
destination at network-layer.

Whether RT0 is evil and it should be deprecated so routers do not handle it
anymore is the real problem.

--
Rémi Denis-Courmont
http://www.remlab.net/

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Apr 2007 22:03:20 +0900 (JST)

> > machine that is a *host* should NEVER forward packets, period.

	bzzzt.  with IPv6 spec NODE (host + router) has to handle routing
	header type 0 and forward *even if ip6.forwarding is 0.  that's the
	steve deering's last word before he left to Canada for retirement.

itojun

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Apr 2007 13:31:23 +0000

> ... The problems of routing header type 0 well know by the community since
> long time. This has been documented for more than 2-3 years know (raised 4
> years ago). Are there any consensus, that type 0 routing header should be
> deprecated? ...

yes.  nobody anywhere still thinks that this is necessary for any purpose.
(if noone within the sound of my voice disagrees, then you have your proof.)

((i just wish i'd had the guts to turn it off on f-root BEFORE the cansecwest
presentation, so that we would not have been such a convenient example.))

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 25 Apr 2007 22:44:19 +0900 (JST)

> presentation, so that we would not have been such a convenient example.))

	i heard that, in some of peering agreement contract, traceroute -g
	(something that works like routing header type 0) is needed (for
	debugging or make sure the peer is not cheating.

	to make them happy, we need secure version of rthdr0 which supports
	such use and no bad sideeffect (with new type, like routing header
	type 7).

itojun

---

From: Rob Austein <[email-masked]>
Date: Wed, 25 Apr 2007 10:13:36 -0400

At Wed, 25 Apr 2007 09:41:09 +0200 (CEST), Mohacsi Janos wrote:
>
> The current patch provided by OpenBSD/FreeBSD makes *BSD IPv6
> implemenation non-conformant to standard.

Sometimes violating the standard is the only reasonable thing for an
implementor to do.  The (IPv4) stack I worked on back in the '90s
shipped with forwarding of directed broadcast disabled by default,
long before anybody had heard of a "smurf attack".  The stack had a
compile-time option to enable forwarding of directed broadcast; from
memory, the documentation for that option went something like this:

  "This option exists solely to allow this software to comply with RFC
  1812.  Directed broadcast is dangerous, no matter what RFC 1812
  says.  Never enable this option under any circumstances."

Eventually the IETF gathered the collective will to update the
standard, but as implementors we would have been derelict in our duty
to our customers had we waited for the IETF.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 25 Apr 2007 17:39:40 -0700

[trimming this to just the IPv6 w.g.]

We think the question for the IPv6 working group on this topic is  
does the working group want to do anything to address the issues  
raised about the Type 0 routing header.  Possible actions include:

  1) Deprecate all usage of RH0
  2) Recommend that RH0 support be off by default in hosts and routers
  3) Recommend that RH0 support be off by default in hosts
  4) Limit it's usage to one RH0 per IPv6 packet and limit the number  
of addresses in one RH0.

These examples are not all mutually exclusive.

Please respond to the list with your preference and justifications.

Thanks,
Bob Hinden / Brian Haberman
IPv6 W.G. Chairs

p.s. We will send a note to the other lists that the IPv6 w.g. will  
be discussing this issue.

---

From: Perry Lorier <[email-masked]>
Date: Thu, 26 Apr 2007 15:01:24 +1200

Bob Hinden wrote:
> We think the question for the IPv6 working group on this topic is does 
> the working group want to do anything to address the issues raised about 
> the Type 0 routing header.  Possible actions include:
> 

I see these two as being equivalent.  If RH0 is going to be off by 
default in routers, then it's for all intents and purposes unusable and 
should be fully deprecated.

>  3) Recommend that RH0 support be off by default in hosts

This is what everyone already expects the behavior to be, and even 
people on this list have shown surprise when they have discovered that 
this is not the case.  I'd completely agree with this.

>  4) Limit it's usage to one RH0 per IPv6 packet and limit the number of 
> addresses in one RH0.

The use case that I would want to use is allowing trace routes from a->b 
when you don't have access to either end, or for asking for a reverse 
trace route from a host back to yourself.  These don't require multiple 
RH0's.

If it's not done already (I've not had time to read the spec carefully), 
you should also check that the scope is the same (or possibly greater) 
to prevent people for example using RH0 to talk to hosts that only have 
link local addresses via a router that has a globally routable address.

So, I'd prefer disabling it for end hosts, enabling it by default on 
routers but limiting it to only one RH0 header with the same scope.

If that is not acceptable, then deprecate the entire feature.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Apr 2007 12:16:46 +0200

>  4) Limit it's usage to one RH0 per IPv6 packet and limit the number of 

Excuse my ignorance, but have the following three rules ever been
considered?

1. The list of addresses in an RH0 MUST NOT include the packet's source address.
2. The same address MUST NOT occur more than once in an RH0.
3. A node processing an RH0 MUST discard any packet breaking these two rules.

I'd be interested in whether this would eliminate the various attacks.

(I'm not really advocating this, since it is added complexity for
a feature that we don't obviously need anyway. But if we don't deprecate
it, all the other options seem to leave the threats in place.)

      Brian

---

From: David Malone <[email-masked]>
Date: Thu, 26 Apr 2007 11:58:36 +0100

> Please respond to the list with your preference and justifications.

I wonder if it might be good to have a knob that controls how many
_remaining_ hops you are willing to consider. This can then be used
to used to implement (2) or (3). For example, the default could be
set this knob to zero on end hosts by default, so we only process
RH0 where we are the last hop. We could also set this knob to one
on routers by default.

This would mean you can do things like intermediate-point-traceroute
on the IPv6 Internet, which is useful for diagnosing all sorts of
things (e.g.  is my current route to a praticular host dead, or is
the problem elsewhere?).

The choice to limit the remaining hops (rather than total number
of hops) means that an organisation could use RH0 internally as
much as it liked, just as long as only one intermediate hop remained
by the time it left the organisation. An attacker might still be
able to bounce packets between two organisations that had configured
a higher limit, providing that they weren't already doing ingress/egress
filtering.

	David.

---

From: David Malone <[email-masked]>
Date: Thu, 26 Apr 2007 12:11:13 +0100

> I'd be interested in whether this would eliminate the various attacks.

I think we did talk about some rules like this before, maybe about
the time of the security considerations draft. I think these rules
make the attack only slightly more difficult, while at the same
time making some possibly valid uses of RH0 require trickery.

For example, these rules make it hard to use traceroute to find a
round-trip route from me to you. The obvious thing to do here is
do a traceroute where SRC=me, RH0[0]=you, RH0[1]=me. Of course, I
can always get almost the same information by doing SRC=me, RH0[0]=you
RH0[1]=someone_in_my_subnet.

You can use the same idea to make the attacks work even with the
restrictions above. If I want to flood a link, I find hosts X1 ...
XN on one side of the link and Y1 ... YN on the other side. Then I
send lots of packets with RH0[0] = X1, RH0[1] = Y1, RH0[2] = X2,
RH0[3] = Y2, ...

	David.

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 25 Apr 2007 11:13:09 -0400

I am facing a similar dilemma.  Currently editing version 2.0 draft of 
the US DoD "DISR Product Profiles for IPv6" and considering adding a 
THOU SHALT NOT or at least "it would be a great idea if you didn't" 
forward based on RH0 due to this vulnerability.  At the very least I 
will note this risk, suggesting that vendors SHOULD provide a means of 
disabling RH0, and also consider disabling by default.

Especially interested in strong opinions from vendors about difficulty 
in complying if that were the case.  Cross posting to NAv6TF as well, 
but please reply directly to [email-masked] and avoid cluttering 
up the lists with specific objections and suggestions.  I will summarize 
back to the lists.

Thanks
Ed J.

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: Tim <[email-masked]>
Date: Wed, 25 Apr 2007 07:22:00 -0400

> can, and those that don't are secure by default.

Then how would one deal with the "flux capacitor" attacks as described
at CanSecWest?  Eventually the bot herders will figure out how to use
this and flatten a few networks with little effort.

Also, combining ping-pong style RH0 attack with TCP handshake
amplification (or any other reflected amplification attacks that reverse
the source routing headers on reply and double or triple the number of
packets) gives you an even bigger amplification, which could target the
upstream routers of a victim network.  This would probably work even
better than smurf attaFrom [email-masked] Thu Apr 26 08:50:50 2007
Date: Wed, 25 Apr 2007 11:13:09 -0400
From: Ed Jankiewicz <[email-masked]>
To: [email-masked]
Cc: Rob Austein <[email-masked]>, "[email-masked]" <[email-masked]>,
	[email-masked], [email-masked]
Subject: Re: IPv6 Type 0 Routing Header issues

Thanks
Ed J.

Rob Austein wrote:
>   says.  Never enable thicks did "back in the day" when one could still use
them.

Loose source routing is just a bad idea.  Yeah, great for testing, but
should be off by default on everything.  This lesson was learned long
ago, why are we repeating the same mistakes?  

That's my $0.02.
(Take it with a grain of salt, since I'm no networking expert.)

cheers,
tim

s option under any circumstances."

---

From: Tim <[email-masked]>
Date: Wed, 25 Apr 2007 07:22:00 -0400

better than smurf attacks did "back in the day" when one could still use
them.

That's my $0.02.

cheers,
tim

---

From: Gert Doering <[email-masked]>
Date: Wed, 25 Apr 2007 10:24:08 +0200

Hi,

That's what we have routers for, and there is a well-defined way to 
change a *BSD machine from a "host" to a "router" (turn on ip6.forwarding).

> routing header type. This is currently clearly not enough....

Extending pf(4) accordingly would certainly be a good thing, as it could
help other machines behind a NetBSD firewall.

(BTW - what's pf(4) doing if a packet comes with with RH0?  Which address
does it use for ACL checking, and which address is used for state setup?)

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Wed, 25 Apr 2007 12:10:01 +0200

Hi,

> destination at network-layer.

Thanks for the clarification.  Indeed, this explains the necessity to
process the RH0 header locally (it might point to a different address on the 
*same host*).

Gert Doering
        -- NetMaster

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 26 Apr 2007 11:02:50 -0400

> -----Original Message-----
> From: Gert Doering [mailto:[email-masked]] 

> process the RH0 header locally (it might point to a different 

Which would be a good tool for anyone intending a DOS attack on that
single host.

I've been trying to figure out why Steve Deering wanted RHO to be
supported in hosts and routers. Maybe this was the reason. Multiple IP
addresses in a host.

Bert

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Fri, 27 Apr 2007 01:14:08 +0900 (JST)

> should be fully deprecated.

	no, do not place sysctl.  devote time to develop new type 'routing
	header type 123' instead.
	it does not have bad sideffect but can perform something like rthdr0.

	in this doomsday story and samurais saving the planet, we were extremely
	lucky beacause:
	- iPv6-haters still didn't get it (or did they changed their mind?)
	- MIP6 was NOT using rthdr0
	it's a message from god.

itojun

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 26 Apr 2007 15:44:50 -0700

Before you kill this off too quickly, James Woodyatt's proxy redirection is
a perfect example of a use for Type 0 Routing Headers. He wants the firewall
to redirect traffic through a designated point (what this header was
designed to do), and the only hammer at his immediate disposal was IPv6/IPv6
nat. 

It is certainly reasonable to have a BCP that says 'these should be filtered
at policy boundaries unless there is a good reason to do otherwise', but
they are a tool to solve some very specific corner cases. 

Tony

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ed Jankiewicz
> Sent: Wednesday, April 25, 2007 8:13 AM
> To: [email-masked]
> Cc: Rob Austein; [email-masked]; [email-masked];
> [email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 26 Apr 2007 15:52:07 -0700

As I recall the primary goal was to allow a system to state a specific
transit path because it was the one that the subscriber had a contract with.
Think dialing a local number to get a specific long-distance carrier's
presence, rather than paying the extortion rate that the local provider
charges for their random selection of long-distance.

Tony

> From: Manfredi, Albert E [mailto:[email-masked]]
> Sent: Thursday, April 26, 2007 8:03 AM
> To: Gert Doering
> Cc: [email-masked]
> Subject: RE: IPv6 Type 0 Routing Header issues
>

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 26 Apr 2007 15:58:37 -0700

I thought we already limited to 1 RH0 per packet, but I will have to go back and take a closer look. 

As I said on V6ops, before you kill this off too quickly, James Woodyatt's proxy redirection is a perfect example of a valid use for Type 0 Routing Headers. He wants the firewall to redirect traffic through a designated point (what this header was designed to do), and the only hammer at his immediate disposal was IPv6/IPv6 nat. What I don't know is if the firewall can insert one that did not exist, because the source wouldn't know about his 'transparent' proxy. 

It is certainly reasonable to have a BCP that says 'these should be filtered at policy boundaries unless there is a good reason to do otherwise', but they are a tool to solve some very specific corner cases. I would say that firewalls should drop these by default, but the rest of the system should recognize them as normal.

Tony

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, April 26, 2007 3:17 AM
> To: IETF IPv6 Mailing List
> Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Header
> issues]
> 
> of

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 Apr 2007 17:17:54 -0700

On Apr 26, 2007, at 15:58, Tony Hain wrote:
>
> As I said on V6ops, before you kill this off too quickly, James  
> Woodyatt's proxy redirection is a perfect example of a valid use  
> for Type 0 Routing Headers. He wants the firewall to redirect  
> traffic through a designated point (what this header was designed  
> to do), and the only hammer at his immediate disposal was IPv6/IPv6  
> nat. What I don't know is if the firewall can insert one that did  
> not exist, because the source wouldn't know about his 'transparent'  
> proxy.

I should make clear that I'm not persuaded that use of the routing  
extension header gives me a way to do what I've been talking about in  
both V6OPS and BEHAVE.  Moreover, I *really* don't think RH type code  
**ZERO** is a better hammer than simple IPv6 NAT.  (Oh boy... I've  
just whacked another beehive, haven't I?)

For my immediate purposes, where I only need to redirect inside the  
routing node between the packet filter and the node's own stack, I  
can probably define my own internal routing extension header type  
code.  In fact, since the packets aren't going anywhere on the wire,  
I could just dispense with the extension header altogether and just  
overwrite the destination address in the IPv6 header while inserting  
an appropriate state record into the packet filter for the proxy to  
find.  This will be functionally equivalent to using IPv6 NAT, and  
I'll be doing this in the code that implements the IPv4 NAT and SPI  
filter, but if it makes everyone feel more warm and fuzzy that no  
actual NAT is going on, I'll use another word for it.  I wouldn't  
want anybody to lose more sleep.

Where the situation gets a lot more interesting is when the  
transparent application proxy is not resident on the same node as the  
filter where the diversion happens.  That's where the routing  
extension header could be necessary.  In that case, I still don't  
think type code *ZERO* is the wrong choice, because something must  
*remove* the extension header on the return path for the proxy to  
remain transparent.

--
j h woodyatt <[email-masked]>

---

From: james woodyatt <[email-masked]>
Date: Thu, 26 Apr 2007 17:36:26 -0700

On Apr 26, 2007, at 17:17, james woodyatt wrote:
>
> [...] I still don't think type code *ZERO* is the wrong choice [...].

Oops.  This should have read, "I still think type code *ZERO* is the  
wrong choice..." Sorry for any confusion.

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Fri, 27 Apr 2007 10:06:01 +0900

Hi,

I would be interested in a list of cases FOR the Type 0 Routing
Header.  If there are no good cases for it, it seems to me that
removing it is the best thing to do.

Best,
George

---

From: Alun Evans <[email-masked]>
Date: Fri, 27 Apr 2007 10:04:17 +0100

> removing it is the best thing to do.

I quite like traceroute for the return path.

Which would also explain why Hosts are meant to process the routing header.

A.

-- 
Alun Evans
IOS Software Engineer, cisco Systems.
http://www.cisco.com/go/ipv6/

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 27 Apr 2007 10:19:01 +0100

> I quite like traceroute for the return path.

This 'problem' can be solved with looking glass websites, not which such
an obvious security problem as RH0.

That said, there should be a well defined system for Looking Glasses.
Please see the proposal I made to the RIPE Database WG to define these:
http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00040.html

As there where at least no negative comments, I guess I should make a
more formal proposal soon to solve this, for both IPv4 and IPv6 and in a
standard way (hoping that the other RIR's will follow in providing this
data too, but as some RIR's don't have a real IRR yet that might take time).

Greets,
 Jeroen

---

From: David Malone <[email-masked]>
Date: Fri, 27 Apr 2007 10:26:45 +0100

> an obvious security problem as RH0.

Surely the number of looking glass websites are a clear sign of a
difficency in IPv4? (Also, having to parse input to web pages and
pass information to command line tools has had more than its fair
share of security problems ;-)

	David

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Fri, 27 Apr 2007 20:01:32 +0900 (JST)

> wrong choice..." Sorry for any confusion.

	don't worry, the world is in panic like 1912.  everybody is in panic().

itojun

---

From: Ignatios Souvatzis <[email-masked]>
Date: Fri, 27 Apr 2007 14:53:22 +0200

> Please respond to the list with your preference and justifications.

It seems to me 2, maybe combined with 4, would be appropriate for now.

I've read or thought about two theoretical uses:

- use it to enforce a specific path that's less costly (commercially)
  than the default, or to avoid crossing a hostile part of the network.

  It occurs to me that access to such a path would probably be secured
  by IPSec or similar; naked, unsecured redirection would be useless in
  this context.

- use it to access otherwise unrouted to the public networks
  Again, those would either be guarded by IPsec or some other VPN
  technology, or not really useful.

Anyway, if any such setup would need RT0 in a controlled enviroment, it
could be switched back on there. (After controlling RT0 *transmission*
past the environment borders.)

Regards,
	-is

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Fri, 27 Apr 2007 22:57:49 +0900 (JST)

even though Japanese, itojun2.0 is much like Theo so bare with me.
	i will use quite a language, so it's X-rated.

	and for those who didn't know, theo finally plan about enabling INET6
	on cvs.openbsd.org and studying jinmei/shima/qingli book.
	our 15 years of effort was not a waste!  then this doomsday news.
	how ironical.

> > > > That's a BSD bug, not a standard bug.

	no, both.
	RFC problem:
	- standard introduced mistake in RFC1883 -> RFC2460
	  (dropped loose/strict bit, at the same time maxhop/rthdr0 bumped to
	  128)
	  for this hinden or deering needs harakiri
	- no limit in # routing headers in packet
	  diagram just show typical header ordering not limitation so it's
	  a big pitfall.  in a very small font "you can put as many routing
	  headers in a packet"!!
	  for ths i guess deering harakiri

	  exercise: how many hops you can make if link MTU=1280?  or 9000?

	- even HOST must forward rthdr (we have checked w/ Steve 1000 times
	  so KAME does not need harakiri, Deering is)
	implementation support
	- we were too spec conformant :-)
	- didn't know hinden/deering are spec writer, no coder
	  they may have code when they were young, but in 1995 they had
	  grandchild or big kid
	- forcused too much onto IPv6, forgot about 1992 common sense
	  "routing header considered harmful" (another ironical coindidence,
	  INET92 kobe was where ipng effort was started).
	  because IPv4 option was dead from the beginning (WIDE"s mobility
	  protocol, VIP, used IPv4 option and it could not reach the States
	  due to banned IPv4 option
	  for this one, KAME needs to harakiri.

	with this doomsday situation and feel of guilt, how can i (or kame)
	take even a nap?  that's why you see i keep posting and posting.  
	deering is total slacker because he's in canada fishing Salmon!!
	i tried very hard to reach the author, and hinden came to us with
	total non-understanding and optimism when tomorrow is the doomsday.
	how do you think?  nokia people, someone is trying to impersonate
	lovely hinden.  if i'm wrong and it was real hinden he sent to SM club
	and spanked by thousands of dominas before harakiri.  but that's
	may actually what makes him happy.  but joy of SM and bondage world
	will finish by harakiri, we gladly allow him to enjoy SM and bondage.

	now, think about how IETF work as ex-IAB:
	in IPv4 days:
	- implement and test
	- then write a draft
	or,
	- BSD IPv4 code is there
	- everyone cheated and looked at it
	today:
	- write a draft with pipe dream
	- spam IESG
	- then implement
	- big issue happen
	- go back to 1

	now, in KAME we meant to make t-shirt

			"code then spec, not spec then code'

	clearly KAME made successful "spec then code", but it was because Jun
	Murai bawed million (if not billion) times to get people like jinmei
	(he's ICHIRO or GOILLA MATSUI of toshiba), kazu (in project management
	he is also ICHIRO) and me (king of v6, jinmei beats me in careful
	spec reading because i'm spine-coder and nanosleep guy)
	to make "IPv6 samurais", which is IPv6.
	and we seriously we devoted our very lives onto that i was dumped by
	two or three girlfriends.  that guilt adds up.  then spice domestic
	violence by father, knowledge of DNA and darwin theory (hate father,
	then hate myself because half of my blood is toilet water),
	you have a guy with mental illness.  yes, that's very reason you do
	not bump into me at IETF venue.  too much computing hurts you, i know,
	but to deploy IPv6 in "spec then code" way we need a Kamikaze attack
	by IPv6 samurais.

	let us assume 2^128 was not enough.  another set of harakiri and
	feel guilt.  i would go suicide.  not suicide attack, but the
	game hangman.

	to summarize, to stop this kind of doomsday spec issue we have to
	switch our mind from "spec then code" to "code then spec".  require
	2 interoperable independent implementation to submit draft.  effects
	are:
	- robust protocol
	- much fewer drafts
	- no spam-like loony tune drafts
	- iesg hapy
	- iesg queue flushes quickly

	so, everyone will happy.  if you object, you can call me any time,
	i won't be able to sleep until very last IPv6-capable machine gets
	upgraded.  hope it will finish before i become zombie.

	i leave "code then spec" discussion to current IESG/IAB.  at least
	IESG will be extremely happy about it.  do not hesitate to cc: me, if
	it is IAB/IESG and email amount moderate so that i can handle rthdr0.
	i'm an ex IAB, so keep me in the loop.

	thanks for reading this rant.

itojun

PS: "itojun2.0" is like "Web2.0".  i.e. i know how to control adrenaline rush,
i now forgot about my father completely.  i slack sometimes when my friend
calls me so do not worry.  noone but me can work and post 24x7 without
sleeping.
PPS: no need to send "please sleep" letters to me, i got plenty of them
already.  i need to read rthdr0 spams so i do not need more spams.  i do know
you all love me and i love you all,  it's just the feel of guilt which keeps
me awake.  and my next door neighbor is my doctor so i don't need to even
call ambulance.  and if tomorrow is doomsday, what do you care?  harakiri?
kamikaze? family?  no, i do not have family i'm alone so only people who cries
when i die would be theo and IPv6 samurais and of course, "Father of Japanese
net", Jun Murai, IAB 1992-94.
PPPS: i'm not crazy.  i'm quite sane.  i'm king of v6.  the mental illness
story is real.  if you think you can beat me you ay fuck my anal and suck
my dick, or perform scull fuck.  or you can check with jinmei, who is the
only guy beats me.

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Sat, 28 Apr 2007 00:59:41 +0900 (JST)

> 	to make "IPv6 samurais", which is IPv6.

	$s/IPv6\.$/KAME./

	it's miracle that i need to correct only one typo.
	my hands are shaking due to 24x7.  now i can finally take a nap.
	you can see if i'm awake/bbusy bby skype status of itojun.hagino
	(do not DDoS me please)

itojun2.0

---

From: Jari Arkko <[email-masked]>
Date: Fri, 27 Apr 2007 20:43:53 +0300

>  4) Limit it's usage to one RH0 per IPv6 packet and limit the number

My preference is 2 or alternatively 1. I am currently not
aware of any real use case for Type 0 header (but please
educate me if there is some). It has been known to be
dangerous for a long time and without a use case, it
seems waste of energy to work on 4 or other more
detailed limitations to make it safe. In particular
I would very much like to see us publishing the
RFC deprecating/turning this off soon. Developing the
rules for 4 is possible, but it will take time.

More fundamentally, I believe functions like this
need to be tailored to a specific need before they
can be made restricted enough to be safe and
useful at the same. This is what was done with
Type 2, for instance. If we will see a future need
for something like this, I suspect that it may need
a new Type number anyway.

Alternative 3 is an interesting one. It would actually
align IPv6 with current IPv4 specifications. RFC 1812
calls for a configuration option to turn off source routes,
but requires the default to be that the source routes
are processed. I'm not sure this is right, however...
perhaps we should update corresponding IPv4
specifications at the same time, too.

Jari

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 27 Apr 2007 14:43:21 -0400

> From: Tony Hain [mailto:[email-masked]] 
> Sent: Thursday, April 26, 2007 6:52 PM
> 

That makes good sense for the sending host. But the receiving host would
have no reason to forward anything beyond the destination address of the
packet, no matter what the extension header says. Except for the case of
multiple IP addresses in that host, which I had not considered.

If Steve Deering wanted all hosts, whether set to forward packets or
not, to process extension headers, my only conclusion is that he was
thinking of multiple IP addresses in that host.

Just trying to figure out what the corner cases are.

Bert

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 27 Apr 2007 12:24:20 -0700

> multiple IP addresses in that host, which I had not considered.

Well by definition a host does not forward, else it becomes a router.
In any case, I don't recall discussion about using it for alternate path
selection to the same destination, but assuming the source tried RH0 using
the address set from dns, it would be a lot simpler than the shim6 sillyness
with exactly the same security downsides. The thing that it doesn't do is
take the alternate addressing out of the source host and put it under
control of the network boundary policy. 

> thinking of multiple IP addresses in that host.

Except for hop-by-hop, the extension headers are explicitly about taking the
end-to-end options out of the base IPv6 header. Essentially every extension
header is there for processing by the receiving host. The fact that there
are artifacts of the routing extension that might be useful to the receiving
host was not a design goal. 

> Just trying to figure out what the corner cases are.

What you are witnessing is the eternal struggle for -control- between the
end system oriented implementers and the network operations oriented
implementers. There are use cases on both sides that can & will be abused.
People tend to disparage the use cases that don't fit their particular take
on the 'who is in control' issue, and rather than defining best practice
configurations they would rather take the easy out of abolishing things that
give the other side some degree of control. 

Tony

---

From: Dave Thaler <[email-masked]>
Date: Fri, 27 Apr 2007 14:32:18 -0700

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.

-Dave

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Friday, April 27, 2007 10:44 AM
To: [email-masked]
Cc: Brian Carpenter; IETF IPv6 Mailing List
Subject: Re: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing
Headerissues]

Jari

---

From: Tim Hartrick <[email-masked]>
Date: Fri, 27 Apr 2007 15:20:18 -0700

Bob,

> Please respond to the list with your preference and justifications.

I am a bit surprised that the security problems with the routing header
come as some sort of revelation at this stage.  The intent, as I recall,
in including this feature was to duplicate IPv4 source routing
(originally strict source routing was supported) with all the problems,
but get the specification of the processing cleaned up.  That was
accomplished in spades.  As I recall from my conversations with him,
Steve Deering never wanted this mess in the specification in the first
place.  I don't think it was part of SIPP but I don't have the spec
handy.  My recollection of a conversation with Steve on this topic back
in the previous century, at an IPv6 bake-off, was that it was "forced
upon us" by the politics of the IPng "process".  I think we can safely
put to bed the idea that the designers were dolts who didn't learn from
history.  That doesn't mean there weren't dolts involved in the
"process".:-)

That said I am in favor of 2.  It is the easiest to retrofit onto
existing implementations.  The question I have is what action should a
host and/or router take if it receives a datagram with a routing header
while support is disabled:

1) ICMPv6 destination unreachable/admininistratively prohibited.
2) Other ICMPv6 destination unreachable.
3) Silent discard.

I vote for 3 but I could be convinced about 1 or 2.  It appears that
IPv4 is supposed to do the equivalent of 1.

Tim Hartrick

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Sat, 28 Apr 2007 11:29:02 +0900 (JST)

> My preference is 2 or alternatively 1. I am currently not

	bzzzt, you got Z grade.  were you sleeping?

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Sat, 28 Apr 2007 11:31:25 +0900 (JST)

i don't understand, rthdr0 must be killed, grilled, diced into million
	pieces.  say farewell.  you did not do my exercise even:
	- how many hops you can make w/ a packet sized 1280?

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Sat, 28 Apr 2007 12:07:48 +0900 (JST)

> come as some sort of revelation at this stage.  The intent, as I recall,

	yup, it's such 1992 problem.  hinden and kame needs harakiri.

> history.  That doesn't mean there weren't dolts involved in the

	steve and bob are too optimistic/academic, or too focused into
	ipv6 so that they forget about ipv4.
	they need to come to japan and take "real world ipv6" tutorial then
	visit Calgary for "security" tutorial by theo.  it's just like
	boot camp (no, not apple's, but army).  openbsd group meeting, called
	c2k7 next month, and theo will gladly sneak you in so that they can
	put two of you into BBQ grill (but they may free to bomit).

> That said I am in favor of 2.  It is the easiest to retrofit onto

	2 is not the right answer.  bzzzt.  bad boy.  you ate 10 minutes of
	sleeping time of mine.

itojun
PS: for those of you contacted me to say "sleep man", stop.  my skype is
keep rebooting and my cellphone battery is dying... it's "sleep man" spam.

---

From: Theo de Raadt <[email-masked]>
Date: Fri, 27 Apr 2007 23:42:44 -0600

> I think we can safely

Bob, actually, why should we put anything to bed?  Are you statements
not some "put it to bed, shove it under the carpet" game?

Really -- why not just call them stupid dolts?  Why not hold them
accountable?  Is accountability suddenly un-American and un-IETF?

The only people who I see discounting accountability (on various
lists) are the ones who either don't understand the scope and impact
of the problem, or are to escape the impact of the disaster that IETF
has thrown at the IPV4 operators who now suddenly face this problem of
IPV6-over-tunnels on the networks they operate.  Talk to some
operators.  It's no longer DoS.  You take your DoS, you IPV6 it, and
voila -- it's DoS x 100, at least.  You wait and see.

So, why do we need to wipe the slate clean?  Why not should we not
identify the academics involved in IETF who are unaware of the
pushback against source routing that happened in 1992-1995?  If people
are unaware if how IPV4 source routing was pushed back against, should
they be at all involved in an any future IETF process that rubber
stamps their kind of bullshit in a "New generation" protocol?  If you
don't blame the people who pushed for this crap, who will you blame?
Noone?

Or is the wiping clean of the slate just another retarded IETF process
that will let this stupid mistake be made again, by an IETF that
thinks that the "academic inclusion, uber ales, minus actual code in
use" principle they believe in helps they build things better than
crap?

If I have come to one viewpoint in life it is this:

	IF NOONE LEARNS, NOONE LEARNS.

And here I see Bob Hindin (and perhaps some others) making apologies
for his buddies who he personally gave the scope to screw things up
this badly.  Bob, you were there.  You are one of the dolts.

If IETF has no accountability at present time, now is the time for
accountability.  You guys were given a *responsibility* to try to do
right, hell -- the industry and goverments gave you a MANDATE.
Instead you fucked the dog, and my lord, you fucked the dog to death,
and potentially the cat and the canary too.

Bob, I don't know who totally fucked this up; not exactly.  But either
the leaders of the process did, or... noone did.  And I think we need
to know who did fuck it up, so that they never let their stupid ideas
of process enter into the Internet game again, or the researchers they
listened to (who totally ignore an IETF directive of "security
concerns must be addressed".)

If you were unaware of the vendor and operator push-back against IPV4
source routing, and let this go through, then you are #1 retard of the
century.  If you did not, but simply managed researchers who sold you
a bum ride -- you need to say who they were or you are an even bigger
retard.

Yes, I am mean.  But Bob, I have dealt with you before and you should
have gotten out of technology a long time ago.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 28 Apr 2007 11:55:23 -0700

Theo,

> not some "put it to bed, shove it under the carpet" game?

Before you launch a personal attack on me on the list you at least  
attack the words I actually wrote on the topic.  I have not suggested  
putting anything to bed.  This is clearly a problem we should fix.

Bob

---

From: Pekka Savola <[email-masked]>
Date: Mon, 30 Apr 2007 10:43:24 +0300 (EEST)

Hi,

> case of the second scenario is for a round-trip

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Apr 2007 11:15:03 +0200

Theo,

Your language is unfitting for professional discussion,
in my opinion.

The issue having been raised, we should deal with it as
an engineering matter.

     Brian

---

From: Pars Mutaf <[email-masked]>
Date: Mon, 30 Apr 2007 14:28:29 +0200

>>  - how many hops you can make w/ a packet sized 1280?

Maybe I'm missing something, but the attacker wouldn't 
rather send millions of *very small* packets (to keep the 
routers busy) instead sending elephants??

My 0.02 cents

pars

---

From: Theo de Raadt <[email-masked]>
Date: Mon, 30 Apr 2007 09:26:17 -0600

> The issue having been raised, we should deal with it as

If it is an engineering matter, then perhaps the IETF should be left
out of it, especially those particular people who created this
problem.

10 years of source route-routing impacts in IPv4 resulted in
source-routing eventually being disabled by vendors -- and then IETF
grudgingly followed suit.  Engineering disciplines in all other fields
normally react to problems before consumers/vendors do.

After that, nearly 10 years of warnings about the impact of
source-routing in IPv6 having severe security impacts resulted in the
IETF process ENTIRELY IGNORING THE SECURITY IMPACTS.

You call that 'Engineering'?

Engineering groups plan for safety ahead of the consumers -- in this
case the network operators who will face these issues for years to
come.  IETF doesn't deserve the word Engineering, if this is the best
they can do.

If there is no mailing list for accountability, then perhaps one
should be setup.  Until then, I think it is very important for the
IETF IPv6 forum to realize that engineering had nothing to do with the
RH0 inclusion in IPv6.  A few academics wanted the extra complexity,
and they pushed it through.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 30 Apr 2007 10:30:57 -0700

Round-trip traceroute is useful inside intra-domain environments as 
you note, where ingress filtering isn't generally deployed.  Hence
it works in many places today and it can be very useful for debugging.

Also, as noted in the original PDF that started this thread, Windows
(and I think at least one other OS if I remember the PDF correctly)
supports RH for compliance, but already disables RH by default. 
Since that's already the deployed behavior of many hosts, I'd
support the disabled-by-default as the best choice.

-Dave

> From: Pekka Savola [mailto:[email-masked]]
> Sent: Monday, April 30, 2007 12:43 AM
> To: Dave Thaler
> Cc: Jari Arkko; IETF IPv6 Mailing List
> Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing
> Headerissues]
> 
> Hi,
>

---

From: [email-masked] (Jun-ichiro itojun Hagino 2.0)
Date: Tue, 1 May 2007 02:46:52 +0900 (JST)

again reading from backwards.

> support the disabled-by-default as the best choice.

	i know! that's why "routing header type 7" (a variant of routing
	header type 0 which has no bad sideeffect) was mentioned a couple of
	days ago!

itojun
PS: please let me sleep.  stop wasteful repetitive proposal before i turn into
zombie.  your cooperation is needed, but "go to bed" DDoS stops my work.  tnx.

---

From: "Eric Klein" <[email-masked]>
Date: Mon, 30 Apr 2007 21:24:06 +0300

I have just noticed that this topic seems to be going on simutaniously on
both the IPv6 and v6OPS mailing lists.

The two threads are not coordinated, but both seem very concerned with IPv6
Type 0 Routing Header issues.

This is seperate to the rash of Linux related warnings that have come out in
the new IPv6 news - weekly summary :
*Security:
*Linux Kernel IPv6 Protocol Type 0 Route Header Remote Denial of Service
Vulnerability
http://www.ipv6tf.org/news/counter.php?id=2837<http://mail.softhome.net/email?timestamp=1177957366&md5=pRuj%2BiFkKKYGt0gdD1Wxmg%3D%3D&redirect=http%3A%2F%2Fwww.ipv6tf.org%2Fnews%2Fcounter.php%3Fid%3D2837>

FreeBSD Security Advisory - IPv6 Routing Header 0 is dangerous
http://www.ipv6tf.org/news/counter.php?id=2834<http://mail.softhome.net/email?timestamp=1177957366&md5=pRuj%2BiFkKKYGt0gdD1Wxmg%3D%3D&redirect=http%3A%2F%2Fwww.ipv6tf.org%2Fnews%2Fcounter.php%3Fid%3D2834>

OpenBSD IPv6 Type 0 Route Headers Denial of Service
http://www.ipv6tf.org/news/counter.php?id=2819

It concerns me that the two teams are working seperatly to solve the same
issue.

Eric