[secdir] Secdir review of draft-ietf-multimob-pmipv6-source

Radia Perlman <radiaperlman@gmail.com> Tue, 18 March 2014 04:18 UTC

Return-Path: <radiaperlman@gmail.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 7EA1B1A03FC; Mon, 17 Mar 2014 21:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 I-RjoElpeoly; Mon, 17 Mar 2014 21:18:00 -0700 (PDT)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4F51A0364; Mon, 17 Mar 2014 21:18:00 -0700 (PDT)
Received: by mail-la0-f54.google.com with SMTP id mc6so4366674lab.13 for <multiple recipients>; Mon, 17 Mar 2014 21:17:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iTnPGD51TnsxEVIKIBA7WdYzVtnbDSdtCZkXiKH0MF4=; b=CtwVJ+JM6Sb/hzpwTMddKEbNXWWFv4kcgraXa1b6jcoyTsXBuXxGd3fqeC0MviucND XmNwYSeJfw67zwsmVCDy3up9XPnzDGxQfs8SNFbTaUGi3V8e8pexgu8lEUsOR8ClQBcl OWmeDkAxgX7GaBOVYnm8NZq28lvpziU/DmCpnKyR3Y7GzRL0BSFcy+pyoikfMdQ9s75b hV16PaODKYusFjuS5ZtkORHY1+U0tpGqiAnN2OaAQlgugE9pjuZ2MSl5BRo/jVPgVKSm BAgwHovA9IPfsfuo4Jn5HcNKdO7Og+2VIY35tGPKYPs/NVcdy6gPd7u1PtQl6X754hnc y0ig==
MIME-Version: 1.0
X-Received: by with SMTP id ym5mr80204lbb.48.1395116271389; Mon, 17 Mar 2014 21:17:51 -0700 (PDT)
Received: by with HTTP; Mon, 17 Mar 2014 21:17:51 -0700 (PDT)
Date: Mon, 17 Mar 2014 21:17:51 -0700
Message-ID: <CAFOuuo4wkvJduL2-6NOyzB_Bv5QrETMwONgC2aVdcFwzRQ-Njg@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-multimob-pmipv6-source.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a11c26818c6d1a304f4d9d112"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Flb-Zgha9y54Oj4AtK2dBxwd0vA
Subject: [secdir] Secdir review of draft-ietf-multimob-pmipv6-source
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: Tue, 18 Mar 2014 04:18:02 -0000

On Tue, Dec 17, 2013 at 7:11 PM, Radia Perlman <radiaperlman@gmail.com>wrote:

> 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 combines mobile IPv6 with multicast.  It's unnecessarily
difficult to read.  There should be a section upfront expanding all the
acronyms, at the very least.  For instance, MLD, PMIPv6, PIM, MAG, HNP.
 Some of these (like MAG) are expanded in the text the first time they are
used, but most are not, and people aren't necessarily going to remember it
because of seeing it once, and there's no downside to having a section in
the introduction called "acronyms".

It also wouldn't hurt to explain "proxy mobile IPv6 domains"  (not just
expand the acronym PMIPv6).

I admit I don't completely understand this document, because I didn't want
to have to read all the other documents that this thing assumes you
understand, but I think I get the general idea.

I think the security considerations section covers most of the downsides,
but it doesn't talk about how multicast in general can amplify DOS packets.
 And with mobility, there are two problems with having a proxy sending the
multicast (unless it's tunneled, which would be OK).  If packets with an IP
source address can come from a different location, then loops won't be
detected (the security considerations section mentions that), but also,
it's harder for the infrastructure to filter out packets from forged IP