Re: secid review of draft-ietf-ipv6-deprecate-rh0-01

Jari Arkko <jari.arkko@piuha.net> Mon, 01 October 2007 09:28 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHa4-0000Hs-AQ; Mon, 01 Oct 2007 05:28:48 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcHJT-0004GD-6V for ietf@ietf.org; Mon, 01 Oct 2007 05:11:39 -0400
Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcHJS-0004z5-Ln for ietf@ietf.org; Mon, 01 Oct 2007 05:11:39 -0400
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0674D19865D; Mon, 1 Oct 2007 12:11:38 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6D5DE198646; Mon, 1 Oct 2007 12:11:37 +0300 (EEST)
Message-ID: <4700B9C6.6040202@piuha.net>
Date: Mon, 01 Oct 2007 12:11:34 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.13 (X11/20070824)
MIME-Version: 1.0
To: David Harrington <ietfdbh@comcast.net>
References: <02c601c7feef$b6460730$6702a8c0@china.huawei.com>
In-Reply-To: <02c601c7feef$b6460730$6702a8c0@china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: 6man-chairs@tools.ietf.org, 'IETF discussion list' <ietf@ietf.org>, tim.polk@nist.gov, secdir@mit.edu, psavola@funet.fi, 'Sam Hartman' <hartmans-ietf@mit.edu>, gnn@neville-neil.com
Subject: Re: secid review of draft-ietf-ipv6-deprecate-rh0-01
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

Hi David, and thanks for your review. Inline:


> As such, the whole document is a security consideration. The
> vulnerability appears well-documented, and the guidelines for handling
> the deprecated RH0 are clear.
>   

Good.

> I have a few comments
> 1) RH0 really is something we do not want to see used, right? Should
> this RH be obsoleted rather than deprecated? 
>   

The new RFC cannot obsolete the RFC where RH0 was defined,
because the latter contains also parts that we do not intend
to remove :-) i.e., base IPv6 spec.

> 2) Per BCP61, MUST is for implementers, and SHOULD is for
> users/deployers. There is a MUST NOT in section 4.2 that is a
> deployment decision, so this should be a SHOULD NOT. At the same time,
> there is a "must" in section 4.2 that is an implementation
> requirement, so this should be a MUST.
>   

Hmm. There was fair amount of discussion about this in the WG.
The problem is that wholesale filtering of protocol 43 breaks other things,
including Mobile IPv6. This is why the document explicitly says that
type specific filtering is required. There was a desire to make this
very clear.

But then again, who is the IETF to say what filtering MUST
be performed? If someone wants to block all of TCP, they should
be able to do it...

We'll talk about this point in the next IESG telechat.

> 3) Section three uses "must" where MUST would seem appropriate
>   

This is a quote from another RFC, and as such we should not
change it.

Jari


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf