Subject: [ipfix] DRAFT IPFIX meeting minutes, 65th IETF, Dallas

From: Dave Plonka <[email-masked]>
Date: Thu, 23 Mar 2006 10:49:33 -0600

IPFIXers,

Please review the attached DRAFT minutes of the IPFIX meeting yesterday
afternoon.  You are welcome to send any follow-up comments/suggestions/
corrections to the list.

The minutes can also be found here:

   http://ipfix.doit.wisc.edu/IETF65/minutes.txt

Thanks to all those that participated, and to to Tanja and Ralf for
their notes.

Dave

-- 
[email-masked]  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Dave Plonka <[email-masked]>
Date: Thu, 23 Mar 2006 10:53:32 -0600

This one actually has the attachment that I forgot to attach. ;^)

---

From: Andrew Johnson <[email-masked]>
Date: Thu, 23 Mar 2006 19:29:42 +0000

> This one actually has the attachment that I forgot to attach. ;^)

Thanks Dave.  I have some comments inline to help kick off the next
round of discussions.  People should bear in mind that these are
just my opinions and a lively discussion is welcomed.

> IPFIX Drafts Status (Nevil Brownlee)
> 
> The chair reported that our Area Directors have reviewed all four
> drafts and had no serious concerns.  He proposed one more editing
> iteration to fix the primarily editorial changes.  Also, security
> considerations sections should be improved before last call.

I attended the Security Tutorial on Sunday.  It's primary focus was
on what should be written in the security considerations of an RFC.
A summary of what is being looked for is to produce a set of security
problems which should be addressed, and detail how they are addressed.

For example, in the IPFIX protocol, the problems include:
  Integrity
    Knowing the received records are from authorised exporters
     (i.e. not spoofed).

  Privacy
    Protecting the messages from eavesdropping.
    Knowing you are exporting to authorised receiver.

These problems may well be covered by the authentication and
encryption functionality of IPSEC, but it needs to be demonstrated
that these issues have been thought about and addressed.

> IPFIX Charter Discussion (Juergen Quittek)
> 
> Juergen proposed that IPFIX recharter with a set of short term goals.
> Nevil suggested that they should be completed in less than one year and
> that the selections should encourage use of IPFIX as currently
> defined.

I agree with Nevil's statement from yesterday, and to a large extent
Carter's feelings.  I feel the next goal of the working group should be
to encourage the use of the IPFIX protocol in commercial products for a
wide range of real-world applications.

We should focus on the drafts which aid implementation:
   draft-boschi-ipfix-implementation-guidelines-01 (Elisa Boschi)
   draft-schmoll-ipfix-testing-00 (Paul Aitken)

and those which extend the protocol in ways which will encourage
adoption:
   draft-boschi-ipfix-reducing-redundancy-01 (Elisa Boschi)
   draft-bclaise-ipfix-reliability-01 (Benoit Claise)
   draft-trammel-ipfix-biflow-00 (Brian Trammel)

As mentioned, the choice of WG items should also take into consideration
the maturity, WG support and WG agreement on approach.

I feel that drafts like the aggregation and concentrator are a
premature.  They're focus is the manipulation of IPFIX data and, at
the moment, there is a lack of devices which generate this data.

From the opening introduction of the aggregation draft:
  "Flow measurement in high-speed large-scale networks easily
   produces huge amount of data that can not be handled by a
   single IPFIX collector or analyzer."

The solution will hopefully be as simple as re-configuring your
IPFIX devices to use the flow keys your really want.  If the
implantations are found to have a fixed set of flow keys and you
can't configure a subset, then perhaps some form of aggregation
will become necessary, but we shouldn't be solving hypothetical
issues.

regards

Andrew

---

From: Robert Lowe <[email-masked]>
Date: Thu, 23 Mar 2006 14:00:24 -0600

From the meeting minutes...

> It was suggested that, in rechartering, we consider whether the group
> is defining probes' functionality or just a transport protocol.  Under
> the existing charter it may have been a combination of both.  In
> response, Dan mentioned that security and reliability concerns
> sometimes require that both be considered.

I'm not sure I understand what is being questioned or proposed.
Anyone care to elaborate?  They seem unrelated to me.

> A number of participants showed support for an IPFIX MIB.

For the purpose of exposing what part of IPFIX?  Configuration
items?

-Robert

---

From: Simon Leinen <[email-masked]>
Date: Fri, 24 Mar 2006 04:06:00 +0100

> For the purpose of exposing what part of IPFIX?  Configuration

The focus is more on monitoring I think.  Personally I use SNMP today
for monitoring the performance of my (Net)flow exporters and
collectors, using vendor-specific and home-grown MIBs, respectively.
Standard MIB modules for common functions of IPFIX devices would be
very useful.

About configuration, Benoit mentioned that he doesn't really believe
in the utility of SNMP "set"s for this, and I would agree.  It might
be more useful to specify IPFIX device configuration schemata for
NETCONF, with the caveat that we don't (yet) have a standard data
modeling language for NETCONF.  But that hasn't prevented people to
already work on such models even for IPFIX (well Netflow v9)
meter/exporters, e.g. http://www.liberouter.org/netflow/flowmon-rng.php
-- 
Simon.

---

From: Gerhard Muenz <[email-masked]>
Date: Fri, 24 Mar 2006 11:12:27 +0100

Simon, All,

Thanks for the interesting link.

We are also using NetConf for configuring our IPFIX/PSAMP
probes/concentrators.
Interested readers can find information in the deliverables of the
DIADEM Firewall Project:
http://www.diadem-firewall.org/
http://www.diadem-firewall.org/documents/Diadem%20Firewall%20-%20D6%20-%20Revised%20Interfaces%20Specification.pdf
http://www.diadem-firewall.org/documents/Diadem%20Firewall%20-%20D9%20-%20Initial%20Violation%20Detection%20Prototype.pdf
Moremore, a poster on this subject will be presented at NOMS 2006.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Auf der Morgenstelle 10C 9P16, D-72076 Tuebingen, Germany
Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220
EMail: [email-masked]
WWW:   http://net.informatik.uni-tuebingen.de/~muenz

---

From: Robert Lowe <[email-masked]>
Date: Fri, 24 Mar 2006 12:18:43 -0600

> Standard MIB modules for common functions of IPFIX devices would be

Are there any performance issues to worry about, especially a conflict
of interest between exporting/collecting data and recording performance
metrics?  It seems as though a MIB could be useful though.

> in the utility of SNMP "set"s for this, and I would agree. 

I would agree as well.  And, IIRC, we went down that path a while ago,
and I was hoping we weren't going to revisit it.

-Robert

> It might