Re: IPv6 Type 0 Routing Header issues
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPv6 Type 0 Routing Header issues
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 ed.jankiewicz at sri.com and avoid cluttering
up the lists with specific objections and suggestions. I will summarize
back to the lists.
Thanks
Ed J.
Rob Austein wrote:
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-path: <ipv6-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1Hh3Qj-000808-8h; Thu, 26 Apr 2007 08:50:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjB8-0006rC-Ly
for ipv6 at ietf.org; Wed, 25 Apr 2007 11:13:10 -0400
Received: from mailgate-internal1.sri.com ([128.18.84.103])
by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HgjB7-0000BT-8O
for ipv6 at ietf.org; Wed, 25 Apr 2007 11:13:10 -0400
Received: from localhost (HELO mailgate-internal1.SRI.COM) (127.0.0.1)
by mailgate-internal1.sri.com with SMTP; 25 Apr 2007 15:13:07 -0000
Received: from srimail1.sri.com ([128.18.30.11])
by mailgate-internal1.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id
M2007042508130729011
for <ipv6 at ietf.org>; Wed, 25 Apr 2007 08:13:07 -0700
Received: from [127.0.0.1]
(static-68-236-201-128.nwrk.east.verizon.net [68.236.201.128])
by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3
2006)) with ESMTPA id <0JH200M9Q7LT8PMK at mail.sri.com> for ipv6 at ietf.org;
Wed, 25 Apr 2007 08:13:07 -0700 (PDT)
Date: Wed, 25 Apr 2007 11:13:09 -0400
From: Ed Jankiewicz <edward.jankiewicz at sri.com>
In-reply-to: <20070425141336.E95D522875 at thrintun.hactrn.net>
To: v6ops at ops.ietf.org
Message-id: <462F7005.50700 at sri.com>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
References: <462D4706.4000504 at spaghetti.zurich.ibm.com>
<462E7AB4.3050807 at piuha.net> <m2mz0xp6je.wl%gnn at neville-neil.com>
<20070425093402.A30586 at mignon.ki.iif.hu>
<20070425141336.E95D522875 at thrintun.hactrn.net>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
X-Mailman-Approved-At: Thu, 26 Apr 2007 08:50:32 -0400
Cc: Rob Austein <sra at isc.org>, "nav6tf at ipv6forum.com" <nav6tf at ipv6forum.com>,
ipv6 at ietf.org, ipv6-ops at lists.cluenet.de
Subject: Re: IPv6 Type 0 Routing Header issues
X-BeenThere: ipv6 at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
<mailto:ipv6-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6 at ietf.org>
List-Help: <mailto:ipv6-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>,
<mailto:ipv6-request at ietf.org?subject=subscribe>
Errors-To: ipv6-bounces at ietf.org
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 ed.jankiewicz at sri.com and avoid cluttering
up the lists with specific objections and suggestions. I will summarize
back to the lists.
Thanks
Ed J.
Rob Austein wrote:
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.
--
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or ed.jankiewicz at sri.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
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.
--
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research
Supporting DISA Standards Engineering Branch
732-389-1003 or ed.jankiewicz at sri.com
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
