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