[secdir] review of ipfix-5815bis

Stephen Kent <kent@bbn.com> Tue, 06 March 2012 18:17 UTC

Return-Path: <kent@bbn.com>
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 D9D8721F88ED for <secdir@ietfa.amsl.com>; Tue, 6 Mar 2012 10:17:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.08
X-Spam-Level:
X-Spam-Status: No, score=-106.08 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 7g+cZaLSZUmD for <secdir@ietfa.amsl.com>; Tue, 6 Mar 2012 10:17:02 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id B842321F88E8 for <secdir@ietf.org>; Tue, 6 Mar 2012 10:17:01 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15]:42233 helo=[192.168.1.4]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1S4ywP-00083P-Kq for secdir@ietf.org; Tue, 06 Mar 2012 13:16:54 -0500
Mime-Version: 1.0
Message-Id: <p0624080acb7c04351665@[192.168.1.4]>
Date: Tue, 06 Mar 2012 13:16:27 -0500
To: secdir@ietf.org
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/mixed; boundary="============_-881064676==_============"
Subject: [secdir] review of ipfix-5815bis
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, 06 Mar 2012 18:17:03 -0000

I 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, "Definitions of Managed Objects for IP Flow 
Information Export"is a "bis" of RFC 5815, which was published about 
2 years ago (April 2010).

This is a longish document (68 pages), and it's a MIB. Since I am not 
a MIB expert I focused on the Security Considerations section of the 
document, which is about a page and a quarter in length. The text in 
this section is identical to the corresponding section from the 
version of RFC 5815 that this document is updating.

The security considerations text is clear. It enumerates 
tables/objects in the MIB that have a MAX-ACCESS other than "non 
accessible" and that contain data that might be considered sensitive. 
It notes why these tables/objects might require (read) access 
security controls. Other text in this section focuses on security 
issues applicable to MIBs in general. It admonishes users to employ 
SNMPv3 and to enable crypto security.

I suggest the following minor, editorial revisions to the end of this 
section (see the attached PDF for the full MS Word change tracking 
graphics).


    SNMP versions prior to SNMPv3 did not include adequate security.
    Even if the network itself is secure (for example by using IPsec),
    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 these MIB modules.

    It is RECOMMENDED that implementers consider the security features
    provided by the SNMPv3 framework (see [RFC3410] Section 8), including
    full support for the SNMPv3 cryptographic mechanisms (for
    authentication and confidentiality).

    Further, deployment of SNMP versions prior to SNMPv3 is NOT
    RECOMMENDED.  Instead, it is RECOMMENDED that SNMPv3 be deployed and that
    cryptographic security be enabled.  It is then a customer/operator
    responsibility to ensure that the SNMP entity granting access to an
    instance of these MIB modules is properly configured to grant access
    to objects only to those principals (users) that have legitimate
    rights to indeed GET or SET (change/create/delete) them.