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, 3 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
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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
Precedence: list

Dear Charlie,

Thank you for the review.=20

Please see inline.=20

Cheers,
Med

>-----Message d'origine-----
>De=A0: Charlie Kaufman [mailto:charliek@microsoft.com]
>Envoy=E9=A0: samedi 28 juin 2014 07:11
>=C0=A0: secdir@ietf.org
>Cc=A0: draft-ietf-6man-multicast-addr-arch-update.all@tools.ietf.org;
>iesg@ietf.org
>Objet=A0: Secdir review of draft-ietf-6man-multicast-addr-arch-update-05
>
>I have reviewed this document as part of the security directorate's ongoin=
g
>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 jus=
t
>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 i=
n
>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 d=
o
>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 d=
o
>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 exam=
ples provided in Section 3 of the draft). This document reiterates that fla=
g 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 tex=
t, I found this is clearly mentioned for X but not for r bits. I made a cha=
nge for r bits (see below)  =20

>
>RFCs 3306 and 3956 break these rules by saying things like "The behavior i=
s
>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 addres=
s
>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 U=
PDARED text because valid P&T values when R is set are clearly indicated.=20

>
>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 t=
o 0 or 1 have the same consequences, no? Explicitly saying an undefined fla=
g 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.=20

 But it should
>specify that it MUST be sent as zero.=20

[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 Sec=
tion 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 (presumabl=
y
>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