Re: IPv6 Type 0 Routing Header issues

Ed Jankiewicz <edward.jankiewicz@sri.com> Thu, 26 April 2007 12:50 UTC

Return-path: <ipv6-bounces@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@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@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@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@mail.sri.com> for ipv6@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@sri.com>
In-reply-to: <20070425141336.E95D522875@thrintun.hactrn.net>
To: v6ops@ops.ietf.org
Message-id: <462F7005.50700@sri.com>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net> <m2mz0xp6je.wl%gnn@neville-neil.com> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@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@isc.org>, "nav6tf@ipv6forum.com" <nav6tf@ipv6forum.com>, ipv6@ietf.org, ipv6-ops@lists.cluenet.de
Subject: Re: IPv6 Type 0 Routing Header issues
X-BeenThere: ipv6@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@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@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@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@sri.com 



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------