Subject: Re: [IPFIX] ipfix mib export and context information

From: Benoit Claise <[email-masked]>
Date: Thu, 07 Jul 2011 12:29:15 +0200

Dear all,

Let me ask the question differently.
Do you see a use case for the export, within a single flow record, of 
MIB variables from different SNMP contexts?

Regards, Benoit.
> Hi,
>
> as explained in section 3.3 of RFC 3411, MIB objects (identified by an
> OID) always exist in a context. A context is identified by a
> contextEngineID and a contextName. In colloquial terms, the
> contextEngineID identifies an SNMP agent and a contextName identifies
> an OID tree accessible on that agent. In short, within a management
> domain, a unique name of a MIB object is the following 4-tuple:
>
>    (contextEngineID, contextName, object-type OID, instance-identifier)
>      |                        |    |                                |
>      +-----------+------------+    +--------------+-----------------+
>                  |                                |
>               context                            OID
>
> Many agents only have one context (the so called default context) and
> hence this is mostly invisible for many people. However, in certain
> situations, contexts are used. The classic example are bridges that
> have an instance of the BRIDGE-MIB for each VLAN (in this case the
> contextName used to distinguish BRIDGE-MIB instances is usually the
> VLAN name).
>
> For exporting MIB objects in IPFIX, we need to deal with the
> representation of contexts:
>
> a) If a MIB object exists in the default context (zero length
>     contextName), then the contextName is not carried in IPFIX.
>
> b) If a MIB object exists in a non-default context, then the
>     contextName needs to be carried in IPFIX. There are again two
>     options:
>
> b.1) The contextName is associated to the template. This means all MIB
>       objects in an IPFIX flow record must belong to the same SNMP
>       context. Continuing the example mentioned above, you would not be
>       able to have flow record that carries a MIB object for multiple
>       VLANs. (Note that a similar restriction exists in SNMP since a
>       PDU is always scoped to one context.) The trade-off here is that
>       flow records are smaller at the expense of having to deal with
>       more template options in cases where many contexts are used.
>
> b.2) The contextName is associated to a MIB object in a flow record.
>       This allows to have objects existing in different SNMP contexts
>       on the same "agent" to be carried in a single flow record.
>       However, there is a price for this flexibility since context
>       information is now repeated in every flow record.
>
> Independent of the options a), b.1), and b.2) above, there is a
> question whether the contextEngineID should be carried somewhere? This
> would disambiguate things if a device has multiple SNMP agents running
> concurrently. If the contextEngineID is carried, then this should
> likely be part of the template information, not the flow records.
>
> So the main question at this point (sorry for the lengthy
> explanation): Should we go for b.1) or b.2) or even allow both b.1)
> and b.2)?
>
> /js
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Jul 2011 13:01:02 +0200

On Thu, Jul 07, 2011 at 12:29:15PM +0200, Benoit Claise wrote:
> Do you see a use case for the export, within a single flow record,
> of MIB variables from different SNMP contexts?

Depends on the definition of "flow". As long as we keep the definition
found in RFC 3917 section 2.1, the likelihood of exporting MIB
variables from different SNMP context for a single flow record is
likely diminishing small.

That said, I think the main use case for MIB variable export via IPFIX
seems to be related to a much more liberal definition of a "flow",
that is, one uses IPFIX to simply stream MIB variables towards a
collector instead of polling them, likely independent of any traffic
flows. In such a scenario, the likelihood to want different SNMP
contexts in a single flow record might increase, but it might still be
acceptable to have a limitation that a single flow record can only
carry data from a single context (since SNMP has kind of the same
restriction - a PDU is always bound to a specific context).

So I guess my answer is "no", I do not see a strong use case for
having data from different contexts in a single flow record (but
different flow records should be able to carry data from different
SNMP contexts).

/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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 7 Jul 2011 13:42:54 +0200

Hi, 

I believe that this approach is also more consistent from a security
point of vew and can remove possible concerns of disclosing information
from different contexts if carried in the same flow record. 

Regards,

Dan 
(speaking as contributor)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Juergen Schoenwaelder
> Sent: Thursday, July 07, 2011 2:01 PM
> To: Benoit Claise
> Cc: [email-masked]
> Subject: Re: [IPFIX] ipfix mib export and context information
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Benoit Claise <[email-masked]>
Date: Thu, 07 Jul 2011 13:42:56 +0200

Juergen,

Good summary.
Basically, I would agree that there is no strong use cases right now
So I would like to the draft to the solution a) and b.1) from your 
initial email.

Regards, Benoit.