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

Benoit Claise <bclaise@cisco.com> Thu, 19 November 2015 08:40 UTC

Return-Path: <bclaise@cisco.com>
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 D1D6E1ACD47 for <secdir@ietfa.amsl.com>; Thu, 19 Nov 2015 00:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.086
X-Spam-Level:
X-Spam-Status: No, score=-15.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 aQ6w6kaeSsrL for <secdir@ietfa.amsl.com>; Thu, 19 Nov 2015 00:40:58 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636041ACD48 for <secdir@ietf.org>; Thu, 19 Nov 2015 00:40:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2476; q=dns/txt; s=iport; t=1447922457; x=1449132057; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=/0ATWlHfpL3iB/JK3EyGx+9nQXcaqYpjXJn7PTum7SY=; b=gtjz/YNVZhiUEG6IinYIMMHb47gGwRJDt4qd5s9pmYHwVn98GO5WUgo/ iC7K6G3hb0pfM81ATDe++2YkywCs92ZWUO3uB0C0gkSUETR6D+lUyXAba sfJ2anvPmrD2Nj+d9A81d8BiuzecQph5ML7u42RT36CbjZ4+tpMDnmk3R c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/BAD3iU1W/xbLJq1VCcVcgz2CUgKCD?= =?us-ascii?q?AEBAQEBAYELhDQBAQEDAThABgsLGAkWDwkDAgECAUUGAQwIAQGIIgi/NQEBAQE?= =?us-ascii?q?BAQEBAgEBAQEBAR2GVIR+hCARhQgBBIVNkH2Kc4I4iR2TKGOEBT2EE4FBAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,317,1444694400"; d="scan'208";a="606399684"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Nov 2015 08:40:55 +0000
Received: from [10.60.67.93] (ams-bclaise-89112.cisco.com [10.60.67.93]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tAJ8et1o029351; Thu, 19 Nov 2015 08:40:55 GMT
To: 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> <20151118162443.GA394@elstar.local>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <564D8B17.1000404@cisco.com>
Date: Thu, 19 Nov 2015 09:40:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151118162443.GA394@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/iQAGBd77ZeVIj_dP90clAB9QmGY>
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
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: Thu, 19 Nov 2015 08:41:00 -0000

Hi Juergen,

> 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.
My remark was in the context of a)

Regards, Benoit


>
> /js
>