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

Paul Aitken <paitken@brocade.com> Thu, 19 November 2015 14:46 UTC

Return-Path: <paitken@Brocade.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 22FE91B2AB7 for <secdir@ietfa.amsl.com>; Thu, 19 Nov 2015 06:46:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.896
X-Spam-Level:
X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.004, SPF_PASS=-0.001] autolearn=no
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 yFLJo2KjBhzL for <secdir@ietfa.amsl.com>; Thu, 19 Nov 2015 06:46:31 -0800 (PST)
Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890FB1B2AB6 for <secdir@ietf.org>; Thu, 19 Nov 2015 06:46:31 -0800 (PST)
Received: from pps.filterd (m0000700.ppops.net [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tAJEUxOU014098; Thu, 19 Nov 2015 06:46:30 -0800
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1y90gvtkxx-3 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 19 Nov 2015 06:46:29 -0800
Received: from EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 19 Nov 2015 07:46:24 -0700
Received: from [172.27.212.109] (172.27.212.109) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 19 Nov 2015 15:46:22 +0100
Message-ID: <564DE0BE.5080200@brocade.com>
Date: Thu, 19 Nov 2015 14:46:22 +0000
From: Paul Aitken <paitken@brocade.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
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>
In-Reply-To: <564CA202.8030605@cisco.com>
Content-Type: multipart/alternative; boundary="------------080607060607090202040905"
X-Originating-IP: [172.27.212.109]
X-ClientProxiedBy: EMEAWP-EXCAS11.corp.brocade.com (172.29.18.102) To EMEAWP-EXMB11.corp.brocade.com (172.29.11.85)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.21, 1.0.33, 0.0.0000 definitions=2015-11-19_09:2015-11-19,2015-11-19,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1511190249
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/RcZHRZdikY5bX1r1M4G4-NWxeec>
X-Mailman-Approved-At: Thu, 19 Nov 2015 06:54:19 -0800
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 14:46:33 -0000

I've updated section 10 to capture both of these comments.

Note that I haven't yet addressed Sephen Farrell's comment on privacy, 
which will also be in this section.


   10.  Security Considerations

      For this extension to the IPFIX protocol, the same security
      considerations as for the IPFIX protocol apply [RFC7011].

      If the exporter is generating or capturing the field values itself,
      e.g. using the MIB objects only as an encoding or type mechanism,
      there are no extra security considerations beyond standard IPFIX.

      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.  An Exporter MUST NOT bypass SNMP access control
      rules to export a MIB object for which it is not granted access.

      The access to particular MIB objects is controlled by the
      configuration of the IPFIX exporter.  This is consistent with the way
      IPFIX controls access to other Information Elements in general.

      The configuration of an IPFIX Exporter determines which MIB objects
      are included in IPFIX Data Records sent to certain collectors.
      Network operators should take care that the only MIB objects which
      are included in IPFIX Data Records are ones which the receiving flow
      collector is allowed to receive.

P.

On 18/11/15 16:06, 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
>
> Regards, Benoit (as a document author)
>>
>> /js
>>
>