[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [192.134.164.104]) 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 ([194.199.24.116]) 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
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. 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 surprising. BTW, you can maybe remove the redundant "even then," in above sentence. ** 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 are: - 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 too. ** 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. Cheers, Vincent
- [secdir] SecDir review of draft-ietf-netlmm-pmipv… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-netlmm-p… Juergen Schoenwaelder
- Re: [secdir] SecDir review of draft-ietf-netlmm-p… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-netlmm-p… Jari Arkko
- Re: [secdir] SecDir review of draft-ietf-netlmm-p… Sri Gundavelli
- Re: [secdir] SecDir review of draft-ietf-netlmm-p… Vincent Roca
- Re: [secdir] SecDir review of draft-ietf-netlmm-p… Glenn M. Keeni