Re: [secdir] Secdir review of draft-ietf-6man-multicast-addr-arch-update-05

<> Thu, 03 July 2014 12:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C31F91B28ED; Thu, 3 Jul 2014 05:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zarorWxEgF9H; Thu, 3 Jul 2014 05:03:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 95A301A0A74; Thu, 3 Jul 2014 05:03:48 -0700 (PDT)
Received: from (unknown [xx.xx.xx.199]) by (ESMTP service) with ESMTP id 0D13AC0BA3; Thu, 3 Jul 2014 14:03:47 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id E0B3FC807B; Thu, 3 Jul 2014 14:03:46 +0200 (CEST)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0181.006; Thu, 3 Jul 2014 14:03:47 +0200
To: Charlie Kaufman <>, "" <>
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: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2014.7.3.74221
Cc: "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-6man-multicast-addr-arch-update-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Jul 2014 12:03:51 -0000

Dear Charlie,

Thank you for the review. 

Please see inline. 


>-----Message d'origine-----
>De : Charlie Kaufman []
>Envoyé : samedi 28 juin 2014 07:11
>À :
>Cc :;
>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

[Med] Good point. I made this change:

      where "rrrr" are for future assignment as additional flag bits.

      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
>	--Charlie Kaufman