Re: [secdir] SecDir review of draft-ietf-ipfix-mib-variable-export.

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Wed, 18 November 2015 16:24 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE911A0078 for <secdir@ietfa.amsl.com>; Wed, 18 Nov 2015 08:24:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.435
X-Spam-Level:
X-Spam-Status: No, score=-4.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRqCt7LPnVti for <secdir@ietfa.amsl.com>; Wed, 18 Nov 2015 08:24:54 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B301A005A for <secdir@ietf.org>; Wed, 18 Nov 2015 08:24:54 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B26C3100A; Wed, 18 Nov 2015 17:24:52 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gdK9qNUl2nuo; Wed, 18 Nov 2015 17:24:51 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 18 Nov 2015 17:24:51 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AA2A2004E; Wed, 18 Nov 2015 17:24:51 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id c6_c3lv010S1; Wed, 18 Nov 2015 17:24:50 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B61052003B; Wed, 18 Nov 2015 17:24:49 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 3256338E29EC; Wed, 18 Nov 2015 17:24:46 +0100 (CET)
Date: Wed, 18 Nov 2015 17:24:45 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Benoit Claise <bclaise@cisco.com>
Message-ID: <20151118162443.GA394@elstar.local>
Mail-Followup-To: Benoit Claise <bclaise@cisco.com>, Warren Kumari <warren@kumari.net>, IETF Security Directorate <secdir@ietf.org>, draft-ietf-ipfix-mib-variable-export.all@tools.ietf.org
References: <CAHw9_i+qp7Y1Eu8YiJj6AOUG22NMz=1PCK3k=BkHoxPgxR-8rw@mail.gmail.com> <20151118101339.GA17028@elstar.local> <564CA202.8030605@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <564CA202.8030605@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/Yeux55VEHEWOxCX5mV-qWfn7eBE>
Cc: draft-ietf-ipfix-mib-variable-export.all@tools.ietf.org, IETF Security Directorate <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-mib-variable-export.
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 18 Nov 2015 16:24:56 -0000

On Wed, Nov 18, 2015 at 05:06:26PM +0100, Benoit Claise wrote:
> On 11/18/2015 11:13 AM, Juergen Schoenwaelder wrote:
> >On Sat, Nov 14, 2015 at 02:17:20AM +0900, Warren Kumari wrote:
> >>Be ye not afraid...
> >>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.
> >>
> >>Version reviewed: draft-ietf-ipfix-mib-variable-export-09 - Exporting
> >>MIB Variables using the IPFIX Protocol
> >>
> >>Summary:
> >>LGTM, Security AD attention not required, modulo questions below.
> >>
> >>I'm not quite sure what:
> >>"However if the exporter is a client of an SNMP engine on the same
> >>  device it MUST abide by existing SNMP security rules." is supposed to
> >>mean. What exactly are "existing SNMP security rules"? Those defined
> >>in RFCs? Configured on the device?
> >I agree that this statement is a bit confusing. In the SNMP world, a
> >client must authenticate against the agent and then the agent uses the
> >clients authenticated identity to apply access control rules. This text
> >talks about a client of an "SNMP engine", which is a bit confusing.
> >
> >Perhaps the sentence was meant to say this:
> >
> >      However, if the exporter is implemented as an SNMP manager
> >      accessing an SNMP agent, it MUST authenticate itself to the SNMP
> >      agent and the SNMP agent MUST enforce SNMP access control rules
> >      as it would for any other SNMP manager.
> Yes, that was the meaning.
> For example, we can't export via IPFIX a MIB object for which we're not 
> granted access, completely bypassing the SNMP access control rules

Well, this is not exactly what the I-D says in section 10. The I-D
forsees two implementation options:

a) The exporter acts as an SNMP manager retrieving data from an SNMP
   agent. In this case, the usual SNMP procedures concerning
   authentication and authorization apply

b) The exporter is generating or capturing the field values itself.
   In this case the IPFIX approach applies that the IPFIX exporter
   defines what is exported to whom.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>