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

From: Warren Kumari <[email-masked]>
Date: Sat, 14 Nov 2015 02:17:20 +0900

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?

Also:
"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."
It may be worth mentioning that multiple users may have access to the
data from the flow collector.
I don't think that this is a major issue, as the sorts of data that
are likely to be exported are not (in my wild-ass guess) likely to be
sensitive.

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

W

-- 
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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Nov 2015 11:13:41 +0100

> 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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 18 Nov 2015 17:06:26 +0100

>       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)

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 18 Nov 2015 17:24:45 +0100

> 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.

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 19 Nov 2015 09:40:55 +0100

Hi Juergen,

>     defines what is exported to whom.
My remark was in the context of a)

Regards, Benoit

---

From: Paul Aitken <[email-masked]>
Date: Thu, 19 Nov 2015 14:46:22 +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:
> 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
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Nov 2015 16:34:17 +0100

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].

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). 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.

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 19 Nov 2015 18:05:52 +0100

On 11/19/2015 4:34 PM, Juergen Schoenwaelder wrote:
> is the entity that has knowledge about the access control rules).
Agreed.
> In
Note that this not part of Stephen's DISCUSS.

Regards, Benoit

---

From: Paul Aitken <[email-masked]>
Date: Fri, 20 Nov 2015 20:07:14 +0000

Benoit, Juergen, Warren,

>>      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).

>> is the entity that has knowledge about the access control rules).

+1. I've removed this line.

>> In the former case, more information would be needed since in order to

Good.

So section 10 now reads:

      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 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.

> 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.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 21 Nov 2015 05:44:58 +0200

On Fri, Nov 20, 2015 at 10:07 PM, Paul Aitken <[email-masked]> wrote:
> I've updated the text with this paragraph and added the xrefs as Informative
> (except for 3411, which was already Normative).
>
>
> I'll append another paragraph to this to address Stephen Farrell's comment
> on privacy, which I'll discuss in the relevant email thread.
>
>

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