Subject: [IPFIX] Should the IPFIX MIB be writeable?

From: "Thomas Dietz" <[email-masked]>
Date: Thu, 19 Oct 2006 04:19:05 +0200

Dear Benoit, Kobayashi and others,

I want to summarize 2 points that arose in the current discussion of the
IPFIX MIB and poll the list for comments how we should proceed with it.

It is a fundamental decision if we should allow the IPFIX devices to be
configured via SNMP. For the collector there is not much to configure but
for the exporter there are many things that could be set-up, changed and
deleted.

Making the MIB writeable would have the consequence that we need to
carefully review the status for each variable and table. We must define the
row status and how it must be set and what each setting means. Furthermore
we need to carefully elaborate the conformance section and need to discuss
every writeable object in the security considerations. So it is a really big
effort to make the MIB writeable so that it is secure to use it.

Nevertheless, if the majority on the list has the opinion that it is really
useful to have the MIB (especially the EXPORTER MIB) writeable than we would
take that effort.

Please keep in mind that the decision we take here would also affect the
PSAMP MIB accordingly.

Awaiting your comments,

Thomas

-- 
Thomas Dietz                       E-mail: [email-masked]
Network Laboratories               Phone:  +49 6221 4342-128
NEC Europe Ltd.                    Fax:    +49 6221 4342-155
Kurfuersten-Anlage 36
69115 Heidelberg, Germany          http://www.netlab.nec.de
_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: "David Harrington" <[email-masked]>
Date: Thu, 19 Oct 2006 02:07:56 -0400

Hi,

I generally think that technical decisions should not be based on how
much editing might be required for the security considerations. 

I also think your argument shows a problem with the current IESG
review of management security requirements. The security
considerations really should be written for the configuration
parameters whether they are configured using SNMP or some other
interface. You should NOT be allowed to not discuss the sensitivity of
a parameter just because you don't use SNMP to perform the
configuration. The current MIB security boilerplate reflects an aging
IETF-ism that SNMP is the ONLY protocol to be used to manage Internet
technologies. The boilerplate really should be updated (and I'll work
with DanR to get it updated).

If ipfixFooParameter is sensitive if it is written using an SNMP SET,
because setting it to certain values could leave ipfix vulnerable to
man-in-the-middle attacks or could destabilize the network, then it is
also sensitive if it is configured to that value by an <edit-config>
using Netconf, or a "set ipfix FooParameter=27" CLI command. The
difference is that we have a clear idea of how to secure it using
SNMPv3, and we provide boilerplate to help document it in a consistent
manner, and we do not have a clear idea of how to secure it using
other interfaces and do not have corresponding boilerplate for other
interfaces.

I think the MIB module should permit remote configuration using SNMP
so ipfix-related SNMP management applications can modify the
configuration to best meet their needs.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: Thomas Dietz [mailto:[email-masked]] 
> Sent: Wednesday, October 18, 2006 10:19 PM
> To: [email-masked]
> Subject: [IPFIX] Should the IPFIX MIB be writeable?
>

---

From: "David Harrington" <[email-masked]>
Date: Thu, 19 Oct 2006 02:07:56 -0400

Hi,

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: "Thomas Dietz" <[email-masked]>
Date: Thu, 19 Oct 2006 12:17:51 +0200

Dear David,

I don't want to base the decision whether that MIB should be writeable or
not on the amount of work. I just wanted to point out that we have to
carefully review every object to decide which status it has to get and that
we have to consider also the security aspects on the decision to make an
object writeable.

I also want that you take into account that the IPFIX MIB will get rather
complex (even if we try to keep it as simple as possible). You need to
carefully set up several tables in the right order and link them with the
right indexes. I just wanted that you make up your mind and really think
about it carefully.

Best Regards,

Thomas

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, October 19, 2006 8:08 AM
> To: Thomas Dietz; [email-masked]
> Cc: 'Romascanu, Dan (Dan)'
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Hi,
> 
> manner, and we do not have a clear idea of how tID: <[email-masked]>
From: "Thomas Dietz" <[email-masked]>
To: "David Harrington" <[email-masked]>, <[email-masked]>
Cc: 

This is a multi-part message in MIME format.
Dear David,

I don't want to base the decision whether that MIB should be writeable or
not on the amount of work. I just wanted to point out that we have to
carefully review every object to decide which status it has to get and that
we have to consider also the security aspects on the decision to make an
object writeable.

I also want that you take into account that the IPFIX MIB will get rather
complex (even if we try to keep it as simple as possible). You need to
carefully set up several tables in the right order and link them with the
right indexes. I just wanted that you make up your mind and really think
about it carefully.

Best Regards,

Thomas

> From: David Harrington [mailto:[email-masked]] 
> Sent: Thursday, October 19, 2006 8:08 AM
> To: Thomas Dietz; [email-masked]
> Cc: 'Romascanu, Dan (Dan)'
> Subject: RE: [IPFIX] Should the IPFIX MIB be writeable?
> 
> Hi,
>

---

From: "Thomas Dietz" <[email-masked]>
Date: Thu, 19 Oct 2006 12:17:51 +0200

Dear David,

Best Regards,

Thomas

---

From: Benoit Claise <[email-masked]>
Date: Fri, 20 Oct 2006 14:32:43 +0200

Dear all,

If the question is: "would you like to have a writable MIB",  the answer 
will probably be: "sure, it's useful/nice-to-have!"
It's a logical answer when you offer the choice of a solution with more 
features compared to a solution with less features.

While I don't want to restart a discussion on SNMPset ("SNMPSet: can it 
be saved? 
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduction),  
let me ask the question differently: will this read-write MIB be 
practical and useful?

Let me concentrate on the Exporter MIB, as the Collector MIB should be 
read-only (what can we configure on the collector side?)
Even if the information related to the IPFIX exporting process (such as 
where to export, which transport protocol, which port, backup or not, 
template retransmission timeout, etc...) is somehow pretty static in 
networks, this type of configuration via SNMP might be useful.
However, I'm not sure about the configuration of everything that relates 
to metering process as it's getting pretty complex.
For example, is it practical to specify via SNMP all the possible the 
template definition from Flexible NetFlow?
     Flexible NetFlow = 
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd804be091.shtml
This would require the ipfixTemplateTable to have the following indexes:
    the transport session source IP address
    the transport session destination IP address
    the transport session source port
    the transport session destination port
    the observation domain Id
    the template Id
    the information element position
A table with 7 indexes. Sure, it's possible but this starts to be quite 
a complex MIB
Some more remarks that will add to the complexity:
- In ipfixTemplateTable, we still need to find a way via SNMP to express 
whether a specific I.E. is a flow key or not
- We have the choice of template versus options template. So an extra 
table for options template is required. In this table, as we can have 
multiple scope information elements, we need a way to express whether an 
I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
- This implies that Template Ids are assigned by the collector if the 
collector creates new templates.
- The collector configures the template Ids.
  Note: remember that the template Id are unique per observation domain 
and per transport session.
  So now, if the SCTP association goes down, what should the collector do?
    1. erase all the templates on the exporter, and reconfigure them? 
This implies that if only the connection is down, not the metering 
process, then this action basically stopped the metering process
    2. wait for the template retransmission? What if the metering 
process went down and the template id allocation changed. Shall the 
collector update his MIB?
    3. something else?
- As Thomas mentioned: "We must define the row status and how it must be 
set and what each setting means."

To summarize, my views are:
Even if this might be an interesting little challenge to write this MIB, 
I'm questioning this practicality/complexity... and as a consequence its 
chances to be implemented if everything is read-write
However, I agree with the configuration of the exporting process information
Finally I agree that a way to configure the templates is needed, I'm 
wondering whether SNMP is the right way to do. Maybe NETCONF?

Potential solution:
Could we have specify the full exporter MIB as writable, but limit the 
metering part to read-only in the "Units of Conformance"?
That way, the end customers will decide by pushing or not the vendor: 
SNMP versus NETCONF versus CLI

Regards, Benoit.
> ------------------------------------------------------------------------
>

---

From: Benoit Claise <[email-masked]>
Date: Fri, 20 Oct 2006 14:32:43 +0200

Dear all,

Potential solution:

Regards, Benoit.

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 20 Oct 2006 15:05:16 +0200

Dear all,

I assume that talking about Netconf implies talking about XML-based
configuration. Apart from offering the possiblity to reflect complex
configurations in an intuitive and comprehensible way, I see the
following advantage: XML makes it easy to extend the configuration with
new standardized or device/vendor-specific parameters. This means, the
data model can evolve with the evolution of IPFIX/PSAMP. With a MIB, we
probably have to cope with more dependencies which make it more
complicated to change its definition.

Regards,
Gerhard

Benoit Claise wrote:
>> [email-masked] <mailto:[email-masked]>

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 20 Oct 2006 15:05:16 +0200

Dear all,

Regards,
Gerhard

---

From: Benoit Claise <[email-masked]>
Date: Fri, 20 Oct 2006 15:32:28 +0200

Gerhard,
> new standardized or device/vendor-specific parameters. 
Good point. I forgot about the vendor-specific parameters.

Regards, Benoit.
> This means, the

---

From: Benoit Claise <[email-masked]>
Date: Fri, 20 Oct 2006 15:32:28 +0200

Gerhard,

Regards, Benoit.

---

From: "David Harrington" <[email-masked]>
Date: Fri, 20 Oct 2006 16:10:33 +0200

Hi,
 
The question that was originally proposed was "should the IPFIX MIB be
writable?"
I believe there would be benefit to making IPFIX manageable.
Since you have defined a MIB module to perform management, it seems a
simple extension to make some of the objects writable, rather than
requring a whole extra protocol be supported to configure ipfix
parameters. 
 
Has anybody argued that every aspect of IPFIX should be configurable
using the MIB module? I haven't seen anybody make such an argument,
and I am not making such an argument. Deciding that none of the
objects CAN be used by an application to modify the configuration of
IPFIX may make it difficiult to configure ipfix functionality. 
 
Some of the questions below deal with anomalies, such as SCTP going
down. The question is not about SNMP, it is about interoperable IPFIX
behavior and should be addressed regardless of the management protocol
being used to do configuration.
If a collector uses Netconf to configure the templates, and SCTP goes
down, what should the collector do? delete the templates and
reconfigure them from scratch? wait for the template retransmission?
something else? What if CLI is used? The fact that some of the config
is done using SNMP should not be the telling factor; the appropriate
behavior should be specified regardless of config protocol.
 
Even if template management were to be addressed, there are ways to
reduce the complexity of configuration.
 
The question that should be asked is "which aspects of ipfix should be
made manageable, and how?". Such a discussion should consider issues
of persistence, fate-sharing, static vs. dynamic aspects of ipfix, and
so on. And thsi discussion should happen whether the MIB module is
made writable or not.
 
David Harrington
[email-masked]
[email-masked]
[email-masked]

  _____  

From: Benoit Claise [mailto:[email-masked]] 
Sent: Friday, October 20, 2006 2:33 PM
To: Thomas Dietz
Cc: [email-masked]
Subject: Re: [IPFIX] Should the IPFIX MIB be writeable?

Dear all,

If the question is: "would you like to have a writable MIB",  the
answer will probably be: "sure, it's useful/nice-to-have!"
It's a logical answer when you offer the choice of a solution with
more features compared to a solution with less features.

While I don't want to restart a discussion on SNMPset ("SNMPSet: can
it be saved?
http://www.simple-times.org/pub/simple-times/issues/9-1.html#introduct
ion),  let me ask the question differently: will this read-write MIB
be practical and useful? 

Let me concentrate on the Exporter MIB, as the Collector MIB should be
read-only (what can we configure on the collector side?)
Even if the information related to the IPFIX exporting process (such
as where to export, which transport protocol, which port, backup or
not, template retransmission timeout, etc...) is somehow pretty static
in networks, this type of configuration via SNMP might be useful.
However, I'm not sure about the configuration of everything that
relates to metering process as it's getting pretty complex.
For example, is it practical to specify via SNMP all the possible the
template definition from Flexible NetFlow?
     Flexible NetFlow =
http://www.cisco.com/en/US/products/ps6601/products_qanda_item0900aecd
804be091.shtml
This would require the ipfixTemplateTable to have the following
indexes: 
    the transport session source IP address
    the transport session destination IP address
    the transport session source port
    the transport session destination port
    the observation domain Id
    the template Id
    the information element position
A table with 7 indexes. Sure, it's possible but this starts to be
quite a complex MIB
Some more remarks that will add to the complexity:
- In ipfixTemplateTable, we still need to find a way via SNMP to
express whether a specific I.E. is a flow key or not
- We have the choice of template versus options template. So an extra
table for options template is required. In this table, as we can have
multiple scope information elements, we need a way to express whether
an I.E. is a scope or not (similar to flow key in ipfixTemplateTable)
- This implies that Template Ids are assigned by the collector if the
collector creates new templates.
- The collector configures the template Ids. 
  Note: remember that the template Id are unique per observation
domain and per transport session. 
  So now, if the SCTP association goes down, what should the collector
do?
    1. erase all the templates on the exporter, and reconfigure them?
This implies that if only the connection is down, not the metering
process, then this action basically stopped the metering process
    2. wait for the template retransmission? What if the metering
process went down and the template id allocation changed. Shall the
collector update his MIB?
    3. something else?
- As Thomas mentioned: "We must define the row status and how it must
be set and what each setting means."

To summarize, my views are:
Even if this might be an interesting little challenge to write this
MIB, I'm questioning this practicality/complexity... and as a
consequence its chances to be implemented if everything is read-write 
However, I agree with the configuration of the exporting process
information
Finally I agree that a way to configure the templates is needed, I'm
wondering whether SNMP is the right way to do. Maybe NETCONF?

Potential solution:

Regards, Benoit.

I want to summarize 2 points that arose in the current discussion of
the

IPFIX MIB and poll the list for comments how we should proceed with
it.

It is a fundamental decision if we should allow the IPFIX devices to
be

configured via SNMP. For the collector there is not much to configure
but

for the exporter there are many things that could be set-up, changed
and

deleted.

carefully review the status for each variable and table. We must
define the

row status and how it must be set and what each setting means.
Furthermore

we need to carefully elaborate the conformance section and need to
discuss

every writeable object in the security considerations. So it is a
really big

Nevertheless, if the majority on the list has the opinion that it is
really

useful to have the MIB (especially the EXPORTER MIB) writeable than we
would

take that effort.

Please keep in mind that the decision we take here would also affect
the

PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  _____  

IPFIX mailing list

[email-masked]

---

From: "David Harrington" <[email-masked]>
Date: Fri, 20 Oct 2006 16:10:33 +0200

Hi,

 

 
David Harrington
[email-masked]
[email-masked]
[email-masked]

  _____  

Dear all,

Potential solution:

Regards, Benoit.

deleted.

take that effort.

PSAMP MIB accordingly.

Awaiting your comments,

Thomas

  _____  

IPFIX mailing list

[email-masked]

---

From: Carter Bullard <[email-masked]>
Date: Fri, 20 Oct 2006 10:58:10 -0400

Gentle people,
    I brought up this question much earlier.  If the IPFIX WG is  
genuinely specifying a
transport protocol, then the nature of the MIB should resemble those  
of other transport
protocols.   SCTP (RFC 3873) and TCP (RFC 4022) are good examples,  
there is only
one object in either MIB that is "read-write", and that allows a  
management station to
'delete' or 'close' an SCTP or TCP connection.   All other MIB  
objects are read-only.

Which is what you would expect for a transport protocol MIB.

Carter

On Oct 20, 2006, at 10:10 AM, David Harrington wrote:

> Hi,
>
> The question that was originally proposed was "should the IPFIX MIB  
> be writable?"
> Since you have defined a MIB module to perform management, it seems  
> a simple extension to make some of the objects writable, rather  
> than requring a whole extra protocol be supported to configure  
> ipfix parameters.
>
> Has anybody argued that every aspect of IPFIX should be  
> configurable using the MIB module? I haven't seen anybody make such  
> an argument, and I am not making such an argument. Deciding that  
> none of the objects CAN be used by an application to modify the  
> configuration of IPFIX may make it difficiult to configure ipfix  
> functionality.
>
> down. The question is not about SNMP, it is about interoperable  
> IPFIX behavior and should be addressed regardless of the management  
> protocol being used to do configuration.
> If a collector uses Netconf to configure the templates, and SCTP  
> goes down, what should the collector do? delete the templates and  
> reconfigure them from scratch? wait for the template  
> retransmission? something else? What if CLI is used? The fact that  
> some of the config is done using SNMP should not be the telling  
> factor; the appropriate behavior should be specified regardless of  
> config protocol.
>
> The question that should be asked is "which aspects of ipfix should  
> be made manageable, and how?". Such a discussion should consider  
> issues of persistence, fate-sharing, static vs. dynamic aspects of  
> ipfix, and so on. And thsi discussion should happen whether the MIB  
> module is made writable or not.
>
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
>
>
> While I don't want to restart a discussion on SNMPset ("SNMPSet:  
> can it be saved? http://www.simple-times.org/pub/simple-times/ 
> issues/9-1.html#introduction),  let me ask the question  
> differently: will this read-write MIB be practical and useful?
>
> Let me concentrate on the Exporter MIB, as the Collector MIB should  
> be read-only (what can we configure on the collector side?)
> Even if the information related to the IPFIX exporting process  
> (such as where to export, which transport protocol, which port,  
> backup or not, template retransmission timeout, etc...) is somehow  
> pretty static in networks, this type of configuration via SNMP  
> might be useful.
> For example, is it practical to specify via SNMP all the possible  
> the template definition from Flexible NetFlow?
>      Flexible NetFlow = http://www.cisco.com/en/US/products/ps6601/ 
> products_qanda_item0900aecd804be091.shtml
> - We have the choice of template versus options template. So an  
> extra table for options template is required. In this table, as we  
> can have multiple scope information elements, we need a way to  
> express whether an I.E. is a scope or not (similar to flow key in  
> ipfixTemplateTable)
> - This implies that Template Ids are assigned by the collector if  
> the collector creates new templates.
>     1. erase all the templates on the exporter, and reconfigure  
> them? This implies that if only the connection is down, not the  
> metering process, then this action basically stopped the metering  
> process
> - As Thomas mentioned: "We must define the row status and how it  
> must be set and what each setting means."
>
> Finally I agree that a way to configure the templates is needed,  
> I'm wondering whether SNMP is the right way to do. Maybe NETCONF?
>
> Potential solution:
> Could we have specify the full exporter MIB as writable, but limit  
> the metering part to read-only in the "Units of Conformance"?
> That way, the end customers will decide by pushing or not the  
> vendor: SNMP versus NETCONF versus CLI
>
> Regards, Benoit.

---

From: Carter Bullard <[email-masked]>
Date: Fri, 20 Oct 2006 10:58:10 -0400

Gentle people,

Carter

---

From: Benoit Claise <[email-masked]>
Date: Mon, 23 Oct 2006 20:29:12 +0200

Dave,
> being used to do configuration.
On that specific issue, you've got a point. My example of SCTP going 
down was a bad one as this is independent of the management protocol.

regards, Benoit.
>     *From:* Benoit Claise [mailto:[email-masked]]
>     *Sent:* Friday, October 20, 2006 2:33 PM
>     *To:* Thomas Dietz
>     *Cc:* [email-masked]
>     *Subject:* Re: [IPFIX] Should the IPFIX MIB be writeable?
>
>     Dear all,
>
>     can it be saved?
>     Let me concentrate on the Exporter MIB, as the Collector MIB
>     should be read-only (what can we configure on the collector side?)
>     process went down and the template id allocation changed. Shall
>     the collector update his MIB?
>         3. something else?
>     Even if this might be an interesting little challenge to write
>     this MIB, I'm questioning this practicality/complexity... and as a

---

From: Benoit Claise <[email-masked]>
Date: Mon, 23 Oct 2006 20:29:12 +0200

Dave,

regards, Benoit.