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

Benoit Claise <> Wed, 18 November 2015 16:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0875F1B3872 for <>; Wed, 18 Nov 2015 08:06:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.086
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6xqtzFYZWA2A for <>; Wed, 18 Nov 2015 08:06:30 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 856F41B3856 for <>; Wed, 18 Nov 2015 08:06:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1826; q=dns/txt; s=iport; t=1447862789; x=1449072389; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=NiEWYSl+RV/vtSyQ1IwcMKYt+eqnKBzo63ElwLKTdhY=; b=D7++r2XDkvCLxsJxzi7rEeMHHqXWLXvI4hNCJ8CEkOwEtd8DmonBzzbU uKB5gbXBTf7T+s1hBWUZb/LcLTKmrxi13+n0IhupHpmeP6Wf/duXpxF66 1u0s18VlVe+IdH5zi+2Sxx3fHZ0ROdMLe3L/3eHtnXbjogjNEMUs+D7o1 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.20,313,1444694400"; d="scan'208";a="612864381"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2015 16:06:26 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id tAIG6QVm020130; Wed, 18 Nov 2015 16:06:26 GMT
To: Warren Kumari <>, IETF Security Directorate <>,
References: <> <20151118101339.GA17028@elstar.local>
From: Benoit Claise <>
Message-ID: <>
Date: Wed, 18 Nov 2015 17:06:26 +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: <20151118101339.GA17028@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [secdir] SecDir review of draft-ietf-ipfix-mib-variable-export.
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Nov 2015 16:06:31 -0000

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

Regards, Benoit (as a document author)
> /js