Subject: Re: IPv6 WG Last Call: <draft-ietf-ipv6-deprecate-rh0-01.txt>

From: Brian E Carpenter <[email-masked]>
Date: Sun, 01 Jul 2007 07:48:04 +0200

Ship it.

     Brian

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

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 2 Jul 2007 21:18:26 +0300

Le jeudi 28 juin 2007, ext Bob Hinden a écrit :
> This starts a two week IPv6 working group last call on advancing
>
> 	Title		: Deprecation of Type 0 Routing Headers in IPv6
> 	Author(s)	: J. Abley, et al.
> 	Filename	: draft-ietf-ipv6-deprecate-rh0-01.txt
> 	Pages		: 9
> 	Date		: 2007-6-28
>
> to Proposed Standard.  Please send substantive comments to the IPv6
> mailing list. Editorial comments can be sent to the authors.

Document is fine with me. But what are the consequences with regards to 
RFC3542? Should implementations stop parsing RH0 at that level as well?

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

---

From: "Christopher Morrow" <[email-masked]>
Date: Thu, 5 Jul 2007 20:54:44 -0400

> RFC3542? Should implementations stop parsing RH0 at that level as well?

I fear that deprecating a part of the spec is going to lead to some
confusion (as is shown above) and probably isn't the only option... I
had wanted to send some longer feedback to jabley/ipv6@ but missed out
it seems :(

In short, I think that deprecation removes some functionality that
people may want  to use (perhaps even for a good reason). There are
other issues with removing this from the spec, like making another set
of corner cases implementors will have to check for, ala cisco's
'protocols' bug of 2 years ago (just picking an example not picking on
a vendor). Giving the network the option to ignore RH0 headers would
have skipped us past this problem, and left the spec in good standing
for the cases that might want to use it for good.

-Chris

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 5 Jul 2007 20:58:08 -0700

Hi Chris,

I think the general view was that RH0, can be deprecated and a new
more secure Routing Header can be used to get the functionality for
required.

I have put a draft for the checks required, in any such header. I
intend to modify the draft to take care of introducing the new Routing
Header. It would be great to hear of use cases from the operators
where the functionality is required.

Thanks,
Vishwas

---

From: "Christopher Morrow" <[email-masked]>
Date: Fri, 6 Jul 2007 00:31:22 -0400

> more secure Routing Header can be used to get the functionality for

So, sure... my fear is that lots of baked code/hardware today is going
to do 'funny things' ... and isn't going to get replaced any time
soon. I admit that I'm not sure that routing gear could be easily
'modified' to  ignore RH0 either, so maybe my fear is moot.

> where the functionality is required.

unfortunately I can only come up with a sample cheesey example: (which
depends on the applications doing RH0 tagging)

an enterprise has a set of links between remote sites ( one expensive
and low-latency/low-jitter/low-loss, one the opposite ) Perhaps it
makes sense for them to push their voip across the 'better' link and
everything else on the 'bad' link. They could do this with policy
routing, or by being careful with addressing plans... or their
applications could simply RH0 the traffic and take care of it
themselves.

(yes, I realize there probably a half dozen ways/reasons to do this
but it's one example that I'm certain some wierd enterprise op will
attempt at some point)

There might be one other use which was an original use for ipv4 source-routing:

I want to test a path between ATT and L3 and on to a L3 customer, I'm
a UU customer, I want to bounce the traffic off the CHI ATT device and
through an NYC UU device, I'd need to force routing to UU in NYC, then
ATT in CHI then on to the destination. (yes, this is also contrived,
sorry)

The point being that atleast 2 hops might be necessary, perhaps
more... Breaking this thruogh deprecation seems sketchy at best. In
the abstract for the draft:

   "The functionality provided by IPv6's Type 0 Routing Header can be
   exploited in order to achieve traffic amplification over a remote
   path for the purposes of generating denial-of-service traffic.  This
   document updates the IPv6 specification to deprecate the use of IPv6
   Type 0 Routing Headers, in light of this security concern. "

My point about deprecating something we really can't quantify usage of
is that I can pull examples from my hindquarters all day long, but I
can't (nor can anyone I suspect) really say if this is being used in
practice. That's a bad thing, we could be advocating breaking
something that folks depend upon, in closed communities off of the
'internet' where most of the concern seems to live (for this draft
atleast).

I think there are probably many other reasons that RH0 could be
considered 'bad', why is this one (amplification) the focus? why not
also get rid of icmp or udp or tcp? these can also all be use for
amplification attacks, yes?

I hesitate to get rid or something because of this sole reason, I
think another answer would be to make paying attention to it just
optional for routing gear (or all things, honestly I really only care
about routing gear, and so does this draft).

I'd also take issue, for many of the same reasons stated earlier with:

"The severity of this threat is considered to be sufficient to warrant
   deprecation of RH0 entirely"

from the draft, I don't think that deprecation is warranted in this
case, if it is than anything that can cause amplification attacks is
likely also in need of deprecation.

Allow consenting adults to do potentially harmful things is 'ok'.
Intermediate networks may decide to honor or not the 'potentially
harmful things', but that's their individual decision and shouldn't be
baked into the spec if at all possible.

-Chris

---

From: Joe Abley <[email-masked]>
Date: Fri, 6 Jul 2007 09:54:43 -0400

> about routing gear, and so does this draft).

Actually, no -- hosts which conform to the current spec also process  
RH0. So even if all IPv6 routers had RH0 functionality removed, hosts  
could still act as bounce points for the purposes of congesting  
remote paths.

> likely also in need of deprecation.

So, to summarise: your proposal is that RH0 should not be deprecated,  
but that it should be made optional? I'm not convinced that I  
understand how that's going to prevent the "amplification over remote  
paths" problem.

Note too that several widely-deployed IPv6 stacks have already taken  
the approach of effectively deprecating RH0. So there's a practical  
consideration that if we decide to do something different, we are  
diverging from deployed practice.

Joe

---

From: "Christopher Morrow" <[email-masked]>
Date: Fri, 6 Jul 2007 10:46:17 -0400

> could still act as bounce points for the purposes of congesting

I recognize that a host could still be used as a bounce-point, if the
router ignores the header though ... no real amp effect arises, unless
you can bounce between hosts across a router link in a meaningful
manner. This still is fixable with a simple filter (just like smurf or
other sorts of amplification attacks).

I should probably also flesh out some of the 'ignore' option, if RH0
exists, pass along the packet unless it's destined to 'me' then decide
to honor/ignore the header.

> understand how that's going to prevent the "amplification over remote

I'm not convinced that the problem is dire enough to warrant
completely removing the capability that we don't even have any idea
about usage of :( I suppose I see deprecation as a very large hammer,
where letting folks decide to not honor the header on their
wide-area/internet network seems less damaging, or less drastic
atleast.

> diverging from deployed practice.

which? fbsd? obsd? they took the large hammer approach for some
specious set of reasons? What about XP/MacOSX/Vista/Solaris/HP-UX ?

I still go back to the 'do we want to use the really big hammer here?'
question. I don't see this as being any worse than other amplification
vectors and we haven't talked seriously about deprecating any of
those, so why this one?

-Chris

---

From: Joe Abley <[email-masked]>
Date: Fri, 6 Jul 2007 11:31:02 -0400

[Note that I am not replying out of a desire to engage in advocacy;  
you should read this more as editorial summaries of discussions that  
have already happened here when the questions you raised were asked  
before.]

On 6-Jul-2007, at 10:46, Christopher Morrow wrote:

> manner.

No, that's not the case. If you bounce traffic between two RH0- 
supporting hosts, then all the routers between them need to do is  
process the destination address in order for the remote congestion  
effect to be possible.

> This still is fixable with a simple filter (just like smurf or

Right, to stop the traffic routers would need to examine the whole  
chain of extension headers in each packet in order to see whether  
there's a type-0 routing header in there, and apply suitable policy  
in the event that one is found.

I think we heard from people that this is a lot of work to be done  
(e.g. in an ASIC), and is contrary to the high-level design goal of  
letting routers do their thing with minimal amounts of per-packet work.

> about usage of :(

I think the inference is that we are early enough in the IPv6  
deployment cycle that if someone really is relying on RH0 support in  
protocol stacks, there's sufficient time for a new (RH, something) to  
be defined and implemented to provide whatever functionality is  
required without posing a wider hazard.

I think the only use cases we have heard of here are (a) the  
experimentation documented by Biondi/Ebalard in their CanSecWest  
presentation, and (b) the ability to perform traceroutes from a  
remote source. We did not hear from anybody with the perspective that  
RH0 support was a critical aspect of IPv6 for them. I do not mean to  
imply that the lack of such an opinion means that there's nobody who  
holds that opinion, of course.

The pertinent questions are, I suppose, (a) whether there's a use- 
case which would be profoundly crippled by the deprecation of RH0 in  
the protocol specification, and (b) whether such a crippling would  
pose a greater danger to the Internet at large than the risks of RH0  
which have been documented.

The current best-known answers (wrt "remote traceroute") are (a) yes,  
but it's functionality that the IPv4 Internet happily does without,  
and hence (b) no.

> which? fbsd? obsd?

The WIDE-derived stacks have done this, which in practical terms  
means *BSD plus Apple. Itojun may be able to clarify if you want a  
more exact list of implementations and the changes they have decided  
to make.

> they took the large hammer approach for some

According to the CanSecWest slides, "Windows" (not sure which  
versions) "implements a conservative default behaviour (drops en- 
route packets)". I don't know what Solaris or HP/UX do. I see  
committed patches for Linux which deprecate RH0, but I'm not  
sufficiently in-tune with the Linux development process to know  
whether any of those have been formally adopted in a mainstream kernel.

Whether or not their reasons were specious seems entirely subjective.  
However, in the interests of avoiding that rat-hole, I think I will  
constrain myself to technical considerations :-)

> vectors and we haven't talked seriously about deprecating any of

Which other amplification vectors did you have in mind?

Joe

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 6 Jul 2007 14:30:01 -0700

Processing RH0 does not mean a host acts as a bounce point. If a node
decides to forward traffic it is a router.  A host can properly process an
RH0 packet and drop it if one of its other addresses is not the next hop. 

I object to the entire hysteria driven effort to deprecate RH0. 

Tony

> -----Original Message-----
> From: Joe Abley [mailto:[email-masked]]
> Sent: Friday, July 06, 2007 6:55 AM
> To: Christopher Morrow
> Cc: IPv6 WG
> Subject: Re: IPv6 WG Last Call: <draft-ietf-ipv6-deprecate-rh0-01.txt>
> 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 07 Jul 2007 00:39:35 +0200

I agree with Tony, this is pure hysteria, and this effort should be killed.

Regards,
Jordi

> De: Tony Hain <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Fri, 6 Jul 2007 14:30:01 -0700
> Para: 'Joe Abley' <[email-masked]>, 'Christopher Morrow'
> <[email-masked]>
> CC: 'IPv6 WG' <[email-masked]>
> Asunto: RE: IPv6 WG Last Call: <draft-ietf-ipv6-deprecate-rh0-01.txt>
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Christopher Morrow" <[email-masked]>
Date: Fri, 6 Jul 2007 18:48:04 -0400

> I agree with Tony, this is pure hysteria, and this effort should be killed.

yes.

thanks.
-Chris

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 7 Jul 2007 09:40:55 +0900 (JST)

> > I agree with Tony, this is pure hysteria, and this effort should be killed.

	in this case, it is good to be a bit of paranoid.  the level of
	"paranoid"ness differs by person/standpoint.

	minor nit (i sound like jinmei):
	in RFC1883/2460 terminology "forwarding" is defined as "re-transmit
	packet even when ip6_dst is not mine".  so when a host (non-router)
	handles rthdr0, it is not "forwarding".

itojun

---

From: Joe Abley <[email-masked]>
Date: Sat, 7 Jul 2007 10:44:36 -0400

>> I agree with Tony, this is pure hysteria, and this effort should  

OK, so just to be clear, you're commenting on an earlier  
determination of consensus by the wg chair that RH0 should be  
deprecated, and you're not commenting specifically on this draft. Right?

Joe