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
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 PROTECTED]" <i-d-announce-
[EMAIL PROTECTED]>
Date: May 16, 2007 12:50:02 PM PDT
To: [EMAIL PROTECTED]
Cc: ipv6@ietf.org
Subject: I-D ACTION:draft-ietf-ipv6-deprecate-rh0-00.txt
Reply-To: [EMAIL PROTECTED]
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 PROTECTED] 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 PROTECTED]
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 PROTECTED]>
_______________________________________________
I-D-Announce mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/i-d-announce
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
