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

Warren Kumari <warren@kumari.net> Sat, 21 November 2015 03:45 UTC

Return-Path: <warren@kumari.net>
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 5CFB91A1B8F for <secdir@ietfa.amsl.com>; Fri, 20 Nov 2015 19:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] 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 D2C9Ru9alnsW for <secdir@ietfa.amsl.com>; Fri, 20 Nov 2015 19:45:00 -0800 (PST)
Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4581A1B8A for <secdir@ietf.org>; Fri, 20 Nov 2015 19:44:59 -0800 (PST)
Received: by ykdr82 with SMTP id r82so186145046ykd.3 for <secdir@ietf.org>; Fri, 20 Nov 2015 19:44:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BNK7d2mb8R8Q0XZOFwXegNaLE+Wycmd6DC6wjrXkDYM=; b=gruNjzqN3kS5/t78H475BqLV2FF6Vnq9IPhyDiI+/1X6fWPECYGcIUEzDSpOF0vFur TdtjF8C6Qe2cZ4Ek7Dp6T7nFOowlud+xfgrEba8TWz9T+q5hYOCOF2WwpDf/4Xl8O3AA BmFrQ6+rt+/28ceggmZmQ++7PQB0uVMkTBFDU2XYk4vrhstD1tf/LWsHDhbt6cKmDBUa SgWAWNd16/1Gi+C/WvHtP3P0aTURRzqxoaCQcPReX5CxY2gwzO1dYeaZwi+oM9/Z9N/5 NbwfJfOKCm038/Jnmyuq/spQhuZLkkc5qUMLlu00wLqXVH862IJzIpPCnjpmKVFT7kBg KMdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BNK7d2mb8R8Q0XZOFwXegNaLE+Wycmd6DC6wjrXkDYM=; b=leNSDaccN6OptdMIHQzX9iEI80n4MhN5uhZ0iKMmk19iab45wcvfoQCmKvruVdw0NE 4niLiEibR4p5fscszSNdqj0MmepXwganYxAbuSpgGcc4grhnw23Q/4UWTsD7nLeyvByy WgsS0jXbNWrQzX7iLuVLWfSqAjc7mj2cpU3R9S5J+kqs8sufxjUm1ND6lfvdvGW9WhOj TvPF4xhSpgH3l1L2QpKy5R9zERZFysoL8czAVxI0sB3TVPWC4npC2PiEaE6uOy0QxcS3 Dm/9KmmDZBvfVSMlL4iL/mwlgmIUxcQZP+vtuRdraWeIspd7Lg3gwTDOzj2ObTscdc2Y ijDw==
X-Gm-Message-State: ALoCoQlSVSWr+4kqHL1My1bwApE98pZUXAVHepp7tFb+2tE/ytmdwp9B65tkLijUuJlKRKdQImNy
MIME-Version: 1.0
X-Received: by 10.13.204.19 with SMTP id o19mr9979558ywd.333.1448077499083; Fri, 20 Nov 2015 19:44:59 -0800 (PST)
Received: by 10.37.202.11 with HTTP; Fri, 20 Nov 2015 19:44:58 -0800 (PST)
In-Reply-To: <564F7D72.9090400@brocade.com>
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> <564F7D72.9090400@brocade.com>
Date: Sat, 21 Nov 2015 05:44:58 +0200
Message-ID: <CAHw9_iLd7efhL8horArzucdWvS-K3R1YTOyFbS8qnW80Rjvsuw@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
To: Paul Aitken <paitken@brocade.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/druOl9crjd592VxwNMQSeDZUv0s>
Cc: Benoit Claise <bclaise@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, 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
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: Sat, 21 Nov 2015 03:45:01 -0000

On Fri, Nov 20, 2015 at 10:07 PM, Paul Aitken <paitken@brocade.com> wrote:
> 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?
>

I'm happy. Thanks for taking this so seriously,
W

>
> Thanks,
> P.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf