Subject: Re: Fwd: I-D ACTION:draft-ietf-ipv6-deprecate-rh0-00.txt

From: Tim Enos <[email-masked]>
Date: Wed, 16 May 2007 17:09:34 -0500 (CDT)

Hi Bob/all,

Having read the new draft, I think it is a great first pass. The References used are IMO both thorough and relevant.
 
In section 4.1, IMO it would seem good to see an example each of what RH0 uses [a]would and [b]would not be mitigated via BCP 38/84 implementation.

In section 4.2, IMO it would seem good to see a brief justification of the statement: "filtering based on the presence of any
   Routing Headers on IPv6 routers, regardless of type, is strongly
   discouraged." (FWIW I absolutely concur).

Best Regards,

Tim Enos
Rom 8:28

>Not sure why this hasn't gotten to the list yet, but here it is again.
>
>Bob
>
>
>Begin forwarded message:
>
>> From: "ext [email-masked]" <i-d-announce- 
>> [email-masked]>
>> Date: May 16, 2007 12:50:02 PM PDT
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: I-D ACTION:draft-ietf-ipv6-deprecate-rh0-00.txt
>> Reply-To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the IP Version 6 Working Group Working  
>> Group of the IETF.
>>
>> 	Title		: Deprecation of Type 0 Routing Headers in IPv6
>> 	Author(s)	: J. Abley, et al.
>> 	Filename	: draft-ietf-ipv6-deprecate-rh0-00.txt
>> 	Pages		: 7
>> 	Date		: 2007-5-16
>> 	
>>
>>    The functionality provided by IPv6's Type 0 Routing Header can be
>>    exploited in order to perform remote network discovery, to bypass
>>    firewalls and to achieve packet amplification 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
>>
>>    the light of these security concerns.
>>
>>    This document updates RFC 2460.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ipv6-deprecate- 
>> rh0-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the body of
>> the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login with the
>> username "anonymous" and a password of your e-mail address. After
>> logging in, type "cd internet-drafts" and then
>> "get draft-ietf-ipv6-deprecate-rh0-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	[email-masked].
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-ipv6-deprecate-rh0-00.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <[email-masked]>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>
>--------------------------------------------------------------------
>IETF IPv6 working group mailing list
>[email-masked]
>Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
>--------------------------------------------------------------------

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

---

From: Dow Street <[email-masked]>
Date: Wed, 16 May 2007 15:54:48 -0700

I think the new draft is too extreme in its mitigation approach, and  
would favor the "disable by default" option instead.

Underlying this debate seems to be the question of whether *any* form  
of source routing is ok / worthwhile.  I'm curious how much of the  
RH0 FUD is actually related to the question of control.  While a  
significant move to source routing is likely to impact the (economic)  
status quo, I don't think that means all investigation of a new  
capability should be taken off the table.

It may not be the mechanism itself that is the inherent problem, but  
rather the operational use model.  In this case, disabling by default  
and filtering when RH0 is turned on allows for careful investigation  
and experimentation of different use models.  Killing the mechanism  
outright does not.

If we decide that certain behaviors have no beneficial use, we can  
modify behavior for the RH0 later (hard-code some limits for RH0  
use).  We could also add a new RH type, and deprecate RH0 then.   
However, if we jump to deprecate RH0 now, without any plan to re- 
introduce some general source routing capability in IPv6, I can see a  
significant uphill battle for adding source routing functionality  
later.  "remember how dangerous source routing is?!"

R,
Dow

On May 16, 2007, at 3:09 PM, Tim Enos wrote:

> Hi Bob/all,
>
> Having read the new draft, I think it is a great first pass. The  
> References used are IMO both thorough and relevant.
>
> In section 4.1, IMO it would seem good to see an example each of  
> what RH0 uses [a]would and [b]would not be mitigated via BCP 38/84  
> implementation.
>
> In section 4.2, IMO it would seem good to see a brief justification  
> of the statement: "filtering based on the presence of any

---

From: Joe Abley <[email-masked]>
Date: Wed, 16 May 2007 21:29:34 -0400

On 16-May-2007, at 18:54, Dow Street wrote:

> It may not be the mechanism itself that is the inherent problem,  
> but rather the operational use model.  In this case, disabling by  
> default and filtering when RH0 is turned on allows for careful  
> investigation and experimentation of different use models.  Killing  
> the mechanism outright does not.

There is an argument that the right approach to facilitate source  
routing experiments is to deprecate RH0, and define a new type of  
routing header which is, from the outset, disabled by default.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Thu, 17 May 2007 02:11:03 +0000

> There is an argument that the right approach to facilitate source  routing
> experiments is to deprecate RH0, and define a new type of  routing header
> which is, from the outset, disabled by default.

yes please.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 17 May 2007 04:11:47 +0200

> routing header which is, from the outset, disabled by default.

Please present this argument; it's not self-evident.

---

From: Ryan McBride <[email-masked]>
Date: Thu, 17 May 2007 03:01:27 +0000

> would favor the "disable by default" option instead.

I think the new draft is too soft in it's mitigation approach, and would
favour language that more strongly encourages filtering rthdr0 on the
forwarding path for all routers.

> In this case, disabling by default  and filtering when RH0 is turned
> on allows for careful investigation  and experimentation of different
> use models.

We've had decades to carefully investigate and expermient with different
use models for loose source routing, and the only compelling ones we've
discovered are malicious attacks.

-Ryan

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 May 2007 10:55:08 +0200

> routing header which is, from the outset, disabled by default.

Either that, or secured against spoofing by default. I wouldn't exclude
some sort of secured routing header being proposed for the ongoing
Routing and Addressing discussion over on the RAM list, but it surely
won't be anything as easy to abuse as RH0.

I support the draft.

     Brian

---

From: Joe Abley <[email-masked]>
Date: Thu, 17 May 2007 10:09:14 -0400

> Please present this argument; it's not self-evident.

I agree that was not especially clear.

Suppose there are reasons to think that deprecation rather than  
disable-by-default is the preferred approach.

A requirement to continue to provide source-routing functionality  
akin to RH0 could be satisfied by either abandoning the deprecation  
approach in favour of disable-by-default, or by defining new types of  
Routing Header which will facilitate the desired functionality in  
such a way that will not jeopardise the stability of the network as a  
whole.

If there is actually no requirement to provide source-routing  
functionality, then this is a non-issue.

The remaining assumption is that deprecation rather than disable-by- 
default is the right thing to do. That is presumably what you are  
questioning. My point was that a requirement to support RH0-like  
functionality is not fundamentally incompatible with the deprecation  
approach.

Joe

---

From: Dow Street <[email-masked]>
Date: Thu, 17 May 2007 10:29:35 -0700

On May 17, 2007, at 4:18 AM, Brian Haberman wrote:

> I don't think that is the case at all.  What this draft does is
> deprecates a *form* of source routing that is open to attack.  It does
> not ban all source routing (e.g. MIPv6 can still use Type 2 source
> routing) and it does not preclude someone from defining a new type  
> that
> addresses a need that they have.

Thanks, Brian / all.

I guess what I'm trying to understand is how to strike the right  
balance between preventing undesirable behavior and allowing  
flexibility for innovation.  One approach is to provide a general  
source-routing capability that can be used in a variety of ways - in  
other words, allow for experiment and innovation within the context  
of the operational network.  A different approach is to incrementally  
add specific functionality only to meet specific goals - essentially  
moving much of the process of innovation off the operational network.

As currently specified, the RH0 is pretty far in the direction of the  
former (i.e. provide flexibility).  If an adjustment to RH0 is needed  
to address the concern at hand, perhaps we should not make a single  
and complete move to the latter model.  (this is how I interpreted  
your above comment, but maybe I got that wrong).  One reason is the  
(potential) interplay between source routing and inter-domain routing  
policy may well require the innovation to occur within the  
operational environment.

I think it's true that the IPv6 spec and any related RH docs will  
provide the upper bound on flexibility, which can then be reduced  
through configuration, filtering, outside mechanisms, etc.  The  
inverse does not seem to be true - in other words, if the inherent  
flexibility of the current spec is reduced said flexibility could not  
be recovered through configuration, outside mechanisms, etc.  I could  
more easily support deprecation of RH0 if there were an accompanying  
action to add (return) a general source-routing mechanism to the IPv6  
spec.

I'm still thinking through this, but the fact that the RH0 is so  
widely implemented seems to be a desirable property for fostering  
innovation.  If we took RN0 out, and then added something similar  
back in, it would take some time to recover that property.  It may be  
easier to simply disable-by-default, improve the fidelity of  
filtering (RH0 vs RH2), etc.  Of course, if one is not interested in  
supporting a general and flexible mechanism, then taking RH0 out  
makes a lot more sense.

R,
Dow

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 May 2007 07:18:59 -0400

Dow,

Dow Street wrote:
> Underlying this debate seems to be the question of whether *any* form of
> source routing is ok / worthwhile.  I'm curious how much of the RH0 FUD
> is actually related to the question of control.  While a significant
> move to source routing is likely to impact the (economic) status quo, I
> don't think that means all investigation of a new capability should be
> taken off the table.

I don't think that is the case at all.  What this draft does is
deprecates a *form* of source routing that is open to attack.  It does
not ban all source routing (e.g. MIPv6 can still use Type 2 source
routing) and it does not preclude someone from defining a new type that
addresses a need that they have.  For example, if someone wants source
routing for a "remote traceroute" capability, they can submit an I-D
describing the new type.

> and filtering when RH0 is turned on allows for careful investigation and
> experimentation of different use models.  Killing the mechanism outright
> does not.
> 
> modify behavior for the RH0 later (hard-code some limits for RH0 use). 
> We could also add a new RH type, and deprecate RH0 then.  However, if we
> jump to deprecate RH0 now, without any plan to re-introduce some general
> source routing capability in IPv6, I can see a significant uphill battle
> for adding source routing functionality later.  "remember how dangerous
> source routing is?!"

Well, I don't see anyone on a witch hunt against MIPv6 source routing.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Thu, 17 May 2007 07:18:59 -0400

Dow,

Regards,
Brian