[secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-05

Vincent Roca <vincent.roca@inrialpes.fr> Mon, 11 April 2011 13:50 UTC

Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 74D5D3A6B1D; Mon, 11 Apr 2011 06:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.091
X-Spam-Status: No, score=-10.091 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id lSqljogwkY6w; Mon, 11 Apr 2011 06:50:49 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr []) by core3.amsl.com (Postfix) with ESMTP id 1BBED3A6B1C; Mon, 11 Apr 2011 06:50:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.63,339,1299452400"; d="scan'208";a="80582123"
Received: from geve.inrialpes.fr ([]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 11 Apr 2011 15:50:47 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Mon, 11 Apr 2011 15:50:47 +0200
Message-Id: <A76FCDEF-42DA-421B-95F1-202A076682C4@inrialpes.fr>
To: IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-netlmm-pmipv6-mib.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [secdir] SecDir review of draft-ietf-netlmm-pmipv6-mib-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 11 Apr 2011 13:50:50 -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.

Globally, the "Security Considerations" section is well
written and provides details for the associated risks.
It clearly RECOMMENDs the use of SNMPv3, which should not come
as a surprise given the risks associated to previous versions.
This "Security Considerations" section is globally similar
to that of RFC4295 (MIPv6 MIB).

A few comments:

** What about the completeness of the two lists provided in
section 6?
For instance the MIB defines the pmip6Capabilities object with
attribute MAX-ACCESS read-only (see p. 13). However this object
is not listed in the security considerations sections. Is it
a mistake? If yes, then does anything miss (I didn't check)?

** Clarification needed:
It is said:
  "Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module."
I'm rather surprised that no ACL (or similar) functionality
be available. If IPsec is enabled, then hosts are authenticated
(using one of several techniques) and it's no longer a big deal
to check the authorizations associated to the peer. So that's

BTW, you can maybe remove the redundant "even then," in above

** Wrong reference:
It is said:
  "It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8) [...]"
Section  is not the section of interest as it only focuses
on the standardization status. More interesting sections in RFC3410
- section 6.3 "SNMPv3 security and administration", and in particular
- section 7, in particular section 7.8 "user based security model".

NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an
issue, now it is. The last sentence of RFC3410/section 7.8 mentions
on-going work on using AES in the user-based security model. If this
work gave birth to an RFC, that's probably a good document to refer

** Obscur:
The last sentence of this section:
  "It is then a customer/operator... them."
could easily be improved (split the sentence, please). As such it
remains rather obscure.

I hope this is useful.