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

Charlie Kaufman <charliek@microsoft.com> Sat, 28 June 2014 05:10 UTC

Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id F07801A02A4; Fri, 27 Jun 2014 22:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PdouxSbmdoRW; Fri, 27 Jun 2014 22:10:54 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F7DB1A029A; Fri, 27 Jun 2014 22:10:54 -0700 (PDT)
Received: from BL2PR03MB498.namprd03.prod.outlook.com ( by BL2PR03MB497.namprd03.prod.outlook.com ( with Microsoft SMTP Server (TLS) id 15.0.969.15; Sat, 28 Jun 2014 05:10:51 +0000
Received: from BL2PR03MB498.namprd03.prod.outlook.com ([]) by BL2PR03MB498.namprd03.prod.outlook.com ([]) with mapi id 15.00.0969.007; Sat, 28 Jun 2014 05:10:51 +0000
From: Charlie Kaufman <charliek@microsoft.com>
To: "secdir@ietf.org" <secdir@ietf.org>
Thread-Topic: Secdir review of draft-ietf-6man-multicast-addr-arch-update-05
Thread-Index: Ac+SiKW4XRhXv3zlTOeprxoPra3d/w==
Date: Sat, 28 Jun 2014 05:10:50 +0000
Message-ID: <5e3dd927cd2c401bb107b3c3c7f617da@BL2PR03MB498.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(50986999)(33646001)(20776003)(101416001)(99286002)(95666004)(106356001)(76482001)(105586002)(66066001)(54356999)(80022001)(31966008)(76576001)(85852003)(83072002)(99396002)(74502001)(64706001)(74316001)(86362001)(92566001)(4396001)(21056001)(77982001)(81542001)(85306003)(86612001)(2656002)(74662001)(87936001)(83322001)(107046002)(2351001)(81342001)(229853001)(46102001)(79102001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB497; H:BL2PR03MB498.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/k-dyQmL31RYI0kleGSJ98tJKxjM
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: [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: Sat, 28 Jun 2014 05:10:57 -0000

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.

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.

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.

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. But it should specify that it MUST be sent as zero. 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.

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