Re: [secdir] Secdir review of draft-ietf-6man-multicast-addr-arch-update-05
<mohamed.boucadair@orange.com> Thu, 03 July 2014 12:03 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31F91B28ED; Thu, 3 Jul 2014 05:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zarorWxEgF9H; Thu, 3 Jul 2014 05:03:49 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A301A0A74; Thu, 3 Jul 2014 05:03:48 -0700 (PDT)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 0D13AC0BA3; Thu, 3 Jul 2014 14:03:47 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id E0B3FC807B; Thu, 3 Jul 2014 14:03:46 +0200 (CEST)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.67]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0181.006; Thu, 3 Jul 2014 14:03:47 +0200
From: mohamed.boucadair@orange.com
To: Charlie Kaufman <charliek@microsoft.com>, "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Secdir review of draft-ietf-6man-multicast-addr-arch-update-05
Thread-Index: Ac+SiKW4XRhXv3zlTOeprxoPra3d/wEKgMQw
Date: Thu, 03 Jul 2014 12:03:46 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933002BAA3@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <5e3dd927cd2c401bb107b3c3c7f617da@BL2PR03MB498.namprd03.prod.outlook.com>
In-Reply-To: <5e3dd927cd2c401bb107b3c3c7f617da@BL2PR03MB498.namprd03.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.3.74221
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/R8-mrWgNIFfXX_sO_NcbWA_WiDo
Cc: "draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org" <draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-6man-multicast-addr-arch-update-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jul 2014 12:03:51 -0000
Dear Charlie, Thank you for the review. Please see inline. Cheers, Med >-----Message d'origine----- >De : Charlie Kaufman [mailto:charliek@microsoft.com] >Envoyé : samedi 28 juin 2014 07:11 >À : secdir@ietf.org >Cc : draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org; >iesg@ietf.org >Objet : Secdir review of draft-ietf-6man-multicast-addr-arch-update-05 > >I have reviewed this document as part of the security directorate's ongoing >effort to review all IETF documents being processed by the IESG. These >comments were written primarily for the benefit of the security area >directors. Document editors and WG chairs should treat these comments just >like any other last call comments. > >This document tightens the wording around the usage of flag bits specified >in RFCs 3306 and 3956. I don't believe it would require changes to any >existing implementations, and it would be a real stretch to claim it has >any security implications at all. The document's security considerations >section references the security considerations sections of other documents. >This seems appropriate. [Med] Great, thanks. > >This document addresses an issue that I personally am very passionate >about, and I believe this document takes what is already a bad situation in >those earlier RFCs and makes it worse. (It is possible there is some >subtlety in the issues surrounding IP Multicast Addresses that makes my >arguments invalid, but please hear me out and think about it.) > >There are too many documents that have fields labelled "flags" or >"undefined" or "reserved for future use" and they expect implementers to do >the right thing with them. Documents should always specify what a sender >should send and what recipients should do with received values. A good >default policy for implementers to follow is to always send packets with >such fields set to zero and always ignore values seen in these fields. But >if that is the desired policy, the spec should say so, and there are times >when a different policy makes more sense. For example, it might also be >useful to have a reserved for future use field where a sender always sends >zero and a recipient treats any message containing a non-zero value as >invalid. That would allow a new implementation to send a message that >another new implementation would process correctly and an old >implementation would reject as invalid rather than processing incorrectly. > >The reason for specifying behavior carefully is that future revisions to >the protocol may want to encode information in these fields, but to do so >safely it must be possible to predict what existing implementations will do >when interacting with the new ones. That is only possible if we know what >existing systems are going to send and what existing systems will do when >they receive newly defined values. [Med] FWIW, this is in part one of motivations for this draft (see the examples provided in Section 3 of the draft). This document reiterates that flag bits are to be treated as separate bits. Remaining flag bits that are not associated yet with a meaning can be set to 0 or 1. After checking the text, I found this is clearly mentioned for X but not for r bits. I made a change for r bits (see below) > >RFCs 3306 and 3956 break these rules by saying things like "The behavior is >unspecified if P or T is not set to 1". Behavior should never be >unspecified. Either the values of P and T should be ignored, or the address >should be treated as invalid if P or T is not set to 1, or some other >behavior should be specified. The sender should have a specified behavior >of always setting them to 1. [Med] I agree with your point. I suggest to remove that sentence from the UPDARED text because valid P&T values when R is set are clearly indicated. > >This I-D, while trying to correct some ambiguities, actually makes it >worse. It says things like "X may be set to 0 or 1" (where X is a flag >bit). It would be fine to say X MUST be ignored on receipt. [Med] Ignoring an undefined flag or expecting an undefined flag to be set to 0 or 1 have the same consequences, no? Explicitly saying an undefined flag can be set to 0 or 1 is IMHO superior in case an implementation does not treat flags as separate bits acts on prefix ranges. But it should >specify that it MUST be sent as zero. [Med] This does not apply for this specification because this will lead to exclude a range of valid addresses for a given flag; see the example in Section 3. Otherwise, implementations of the >spec are free to set it to zero or one and no future modification to the >protocol can ascribe any meaning to the value set because when >interoperating with an old implementation the received value is >unpredictable and meaningless. > >It divides a 4 bit "reserved" field into four 1 bit "flag" fields, but >still does not specify what values those flags should be set to (presumably >zero) nor what an implementation should do if they are non-zero on receipt >(perhaps ignore them, or perhaps reject the address... I can't guess the >intent. [Med] Good point. I made this change: OLD: where "rrrr" are for future assignment as additional flag bits. NEW: where "rrrr" are for future assignment as additional flag bits. r bits may each be set to 0 or 1. > >It might be too late to do an optimal job of specifying the desired >behaviors with respect to these flags because that might "break" existing >implementations. But we certainly shouldn't make it worse by permitting >useless flexibility unless it was already promised in the earlier >documents. > > --Charlie Kaufman
- [secdir] Secdir review of draft-ietf-6man-multica… Charlie Kaufman
- Re: [secdir] Secdir review of draft-ietf-6man-mul… mohamed.boucadair