[secdir] Secdir review of draft-ietf-mboned-64-multicast-address-format-01

Matt Lepinski <mlepinski@bbn.com> Tue, 05 June 2012 03:49 UTC

Return-Path: <mlepinski@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 282CD11E812A; Mon, 4 Jun 2012 20:49:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id t-4hHNlqIbnJ; Mon, 4 Jun 2012 20:49:25 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2638911E80B4; Mon, 4 Jun 2012 20:49:25 -0700 (PDT)
Received: from mail.bbn.com ([]:55999) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <mlepinski@bbn.com>) id 1SbklE-0000Di-IL; Mon, 04 Jun 2012 23:48:48 -0400
Received: from [] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from <mlepinski@bbn.com>) id 1Sbkll-0008Ab-VI; Mon, 04 Jun 2012 23:49:22 -0400
Message-ID: <4FCD81E7.7050001@bbn.com>
Date: Mon, 04 Jun 2012 23:49:59 -0400
From: Matt Lepinski <mlepinski@bbn.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-mboned-64-multicast-address-format.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [secdir] Secdir review of draft-ietf-mboned-64-multicast-address-format-01
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 05 Jun 2012 03:49:26 -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 specifies an embedding (for use by IPv4 to IPv6 translation devices) as an IPv4 multicast address within an IPv6 address. (This is a companion document to RFC 6052, which specifies an embedding for IPv4 unicast addresses.)

The Security Considerations section claims that the relevant security considerations are identical to those in RFC 6052. (That is, the security considerations for translating IPv4 multicast addresses are the same as those for translating unicast addresses.) I believe this is essentially true.

However, the first security consideration discussed in RFC 6052 is source address spoofing. Although quite relevant for unicast address translation, source address spoofing does not seem (to me) to be an issue for multicast addresses translation because multicast addresses are typically not used as source addresses for IP datagrams. In situations such as this where the authors wish to incorporate security considerations by reference, I think it is helpful to the reader to add a couple sentences explaining which considerations in the referenced document (i.e., RFC 6052) are relevant to the current draft.

Minor editorial note:
It would be helpful if you define the acronyms ASM and SSM in the terminology section. (As someone who doesn't frequently think about multicast, it wasn't immediately obvious to what these two acronyms referred.)