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

Paul Aitken <paitken@brocade.com> Fri, 20 November 2015 20:07 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 BCAC51B343B for <secdir@ietfa.amsl.com>; Fri, 20 Nov 2015 12:07:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.897
X-Spam-Level:
X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jDn8GxrRz4Wc for <secdir@ietfa.amsl.com>; Fri, 20 Nov 2015 12:07:22 -0800 (PST)
Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB401B3438 for <secdir@ietf.org>; Fri, 20 Nov 2015 12:07:22 -0800 (PST)
Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tAKK0XKB009076; Fri, 20 Nov 2015 12:07:21 -0800
Received: from brmwp-exmb11.corp.brocade.com ([208.47.132.227]) by mx0a-000f0801.pphosted.com with ESMTP id 1ya75x0ep1-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 20 Nov 2015 12:07:20 -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; Fri, 20 Nov 2015 13:07:18 -0700
Received: from [10.252.53.4] (10.252.53.4) by EMEAWP-EXMB11.corp.brocade.com (172.29.11.85) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 20 Nov 2015 21:07:16 +0100
Message-ID: <564F7D72.9090400@brocade.com>
Date: Fri, 20 Nov 2015 20:07:14 +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, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
References: <CAHw9_i+qp7Y1Eu8YiJj6AOUG22NMz=1PCK3k=BkHoxPgxR-8rw@mail.gmail.com> <20151118101339.GA17028@elstar.local> <564CA202.8030605@cisco.com> <564DE0BE.5080200@brocade.com> <20151119153417.GB3518@elstar.local> <564E0170.7010908@cisco.com>
In-Reply-To: <564E0170.7010908@cisco.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.252.53.4]
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-20_12:2015-11-20,2015-11-20,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-1511200339
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/piIg32LNhrhjwwbkK5TlcPtVaG0>
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: Fri, 20 Nov 2015 20:07:23 -0000

Benoit, Juergen, Warren,


On 19/11/15 17:05, Benoit Claise wrote:
> On 11/19/2015 4:34 PM, Juergen Schoenwaelder wrote:
>> See my latest suggestion which adds a bunch of references to the third
>> paragraph - which was the original request of the security directorate
>> reviewer.
>>
>>      However, if the exporter is implemented as an SNMP manager
>>      accessing an SNMP agent, it MUST authenticate itself to the SNMP
>>      agent [RFC3414], [RFC5591], [RFC5592], RFC6353] and the SNMP agent
>>      MUST enforce SNMP access control rules [RFC3415] as required by
>>      the SNMP architecture [RFC 3411].

I've updated the text with this paragraph and added the xrefs as 
Informative (except for 3411, which was already Normative).


>> The additional sentence is somewhat unclear:
>>
>>      [...] An Exporter MUST NOT bypass SNMP access control rules to
>>      export a MIB object for which it is not granted access.
>>
>> Does this apply to any exporter or only to an exporter implemented as
>> an SNMP manager accessing an SNMP agent? In the later case, I would
>> say this sentence is not needed since the sentence before already says
>> that the SNMP agent MUST enforce SNMP access control rules (and this
>> is the entity that has knowledge about the access control rules).
> Agreed.

+1. I've removed this line.


>> In the former case, more information would be needed since in order to
>> apply SNMP access control rules, you need to have an authenticated
>> identity to work with.
> Note that this not part of Stephen's DISCUSS.

Good.


So section 10 now reads:

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
      [RFC3414], [RFC5591], [RFC5592], [RFC6353], and the SNMP agent MUST
      enforce SNMP access control rules [RFC3415] as required by the SNMP
      architecture [RFC3411].

      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.  Note that multiple users may have
      access to the data from the flow collector.



I'll append another paragraph to this to address Stephen Farrell's 
comment on privacy, which I'll discuss in the relevant email thread.


To address Warren's other point:

> I suspect that the MIB Doctors should review this (if they haven't
> already) - while not a MIB, they will probably have useful input.

We've asked Joel (as the sponsoring AD).


Are we all happy that the SecDir points have been addressed?


Thanks,
P.