[secdir] review of draft-ietf-multimob-pmipv6-ropt-07

"Dan Harkins" <dharkins@lounge.org> Mon, 05 August 2013 18:27 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FB421F9A74; Mon, 5 Aug 2013 11:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kyQEJ96xq-Q; Mon, 5 Aug 2013 11:27:17 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DF74721F9A71; Mon, 5 Aug 2013 11:27:17 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 433DC10224008; Mon, 5 Aug 2013 11:27:16 -0700 (PDT)
Received: from 64.164.138.146 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 5 Aug 2013 11:27:16 -0700 (PDT)
Message-ID: <af32bbd31aede24d7237b6b5023afc14.squirrel@www.trepanning.net>
Date: Mon, 5 Aug 2013 11:27:16 -0700 (PDT)
From: "Dan Harkins" <dharkins@lounge.org>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-multimob-pmipv6-ropt.all@tools.ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: [secdir] review of draft-ietf-multimob-pmipv6-ropt-07
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: Mon, 05 Aug 2013 18:27:23 -0000

  Hello,

  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. My apologies
for the tardiness of this review.

  This draft describes an experimental way to use existing protocols
to address a tunnel convergence problem where multiple instance of
the same multicast traffic converges to the same Mobile Access
Gateway. It also defines a new option to support dynamic policy
subscriptions for use with the Proxy Binding Acknowledge message.
It is heavy on acronyms and could use some additional definitions
in section 2 for things like "MAG" and "LMA" (note: I am not a proxy
mobile IPv6 person).

  The draft is ready for publication but I do have a few comments:

  1. It would be easier to read if you move the definition of the new
      option before the description of the two operational modes that
      define the experimental solution, that presumably use the new
      option.

  2. the protocol field "maps the type codification used in the original
      MLD specification for the Report message" and gives two explicit
      values. Is there a registry for this mapping somewhere that might
      be better to point at?

  3. are bits really set to zero and set to one? I thought they were
      set (1) and cleared (0).

  4. the security considerations say that the draft just explains how to
      use existing protocols without modification and therefore does
      not introduce new security threats. That makes me think that the
      problem hasn't even been looked at. It is certainly possible to
      use existing protocols in a way that introduces security problems.
      Maybe expand on why there are none. Also, the draft introduces
      a new option for dynamic policy subscriptions. Are there no
      security issues associated with that addition? If so, it might be
      good to mention that.

  Again, sorry for the delay, I hope these comments are still useful.

  regards,

  Dan.