Subject: [IPFIX] some comments on IANA IPFIX XML

From: Chris Inacio <[email-masked]>
Date: Thu, 31 Mar 2011 10:44:34 -0400

The way IANA specifies the IPFIX registry for IE's is a little twisted.

First, I can't validate the XML.  I can get the ipfix.xml and the ipfix.xsd, but it is wrapped in "registry" elements, which are not described in ipfix.xsd (presumably they are defined somewhere in IANA for use across their registries.)

Another little nit about registries:  There are 2 registries in the ipfix.xml.  The first one describes the broad rules about IE's  (0 is reserved, 1-127 is reserved for NetFlow v9 compatibility (with expert review), and 128-32767 are for new (with expert review)).  The second one is a list of the IE's.  Registry elements _can_ contain created on and modified on dates.  Unfortunately, in the ipfix.xml file, the first registry entry does contain the created and modified on dates, while the second one (with the actual elements) doesn't contain any created on/updated on time stamps.  So they are time stamping the wrong record in the official registry.

It would be really great to wrap the record entries (defined in ipfix.xsd, each record represents an IE,) within another record which records a PEN - so that people can publish their PEN's in a standard way.

The current record definition allows marking up an IE with a "status" field.  The possible entries for status are: current, deprecated, obsolete.  It would be really cool to also have "transitioned", and then a pointer to another registry.  Along with that, I would want to time stamp the IE's separately, and to put in a pointer to the transitioned to location.  This would allow me to put something wrapped in my PEN in a standard way, propose it to IANA, get it moved, and then reuse that IE number in my space in the future.  I would need to leave the record in my IE XML forever, assuming collector operators might not delete the corresponding records "for a really long time."  Collectors would then be required to use the time stamps in the flow records to resolve IE's correctly.  Is that more complicated?  Absolutely.  But it does make IE's a lot more portable between everyone, and people can then reuse IE's.

Thoughts, comments?

Chris

---

From: Andrew Feren <[email-masked]>
Date: Thu, 31 Mar 2011 11:04:39 -0400

> It would be really great to wrap the record entries (defined in ipfix.xsd, each record represents an IE,) within another record which records a PEN - so that people can publish their PEN's in a sta…
This would be great.  A registry of all the info elements above 37,768 
that have been taken by vendors trying to extend v9 would be nice too.

On a related note... Is anyone implementing rfc5610?

-Andrew

---

From: Brian Trammell <[email-masked]>
Date: Thu, 31 Mar 2011 19:15:34 +0200

hi, Andrew, all,

On Mar 31, 2011, at 5:04 PM, Andrew Feren wrote:

> This would be great.  A registry of all the info elements above 37,768 that have been taken by vendors trying to extend v9 would be nice too.

It's up to each enterprise, of course, to determine which, whether, and how to make information about their enterprise-specific IEs (esIEs) available. I know that YAF's IEs (including esIEs) exported in PEN 6871 are documented on a manpage (http://tools.netsa.cert.org/yaf/yaf.html#OUTPUT), for example.

FWIW, IANA's schema does have an <enterpriseId> element for describing esIEs. Though the xsl that makes their webpage doesn't appear to use it.

> On a related note... Is anyone implementing rfc5610?

There will be scantily-documented initial support for this in the working revision of ripfix, which requires some API interaction to make it work. I'll release this as soon as I track down the last bugs in UDP export.

> -Andrew
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Chris Inacio <[email-masked]>
Date: Thu, 31 Mar 2011 13:36:51 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Brian Trammell [[email-masked]]
Sent: Thursday, March 31, 2011 1:15 PM
To: Andrew Feren
Cc: [email-masked]
Subject: Re: [IPFIX] some comments on IANA IPFIX XML

hi, Andrew, all,

I'm not sure I'm willing to commit to adding 5610 support, because I'm not sure if it solves problems.  (I know it doesn't solve any problems for me, but that's not shocking, I build my own EP & CP - but at least I give them away :) )

That said though, it's not clear to me how to use the 5610 data to be able to restructure my backend storage on the fly.  I mean it's nice to have, but if I've been operating my CP for 6 months, and then I get these 5610 messages, I don't see a model currently where I can reconfigure my storage engine (whatever that may be) to adapt.  If you have a slower collection rate, and want to display the data, or normalize to some other defined format (to a SIEM or something) then I can see the use.  So maybe I should implement it to support mediators?