Subject: [ipfix] YAF 0.1.0 Release

From: Brian Trammell <[email-masked]>
Date: Tue, 4 Apr 2006 17:29:37 -0400

All,

As mentioned in passing at the working group meeting in Dallas, CERT/ 
NetSA has released an experimental, open-source, libpcap-based flow  
sensor capable of exporting flow data via IPFIX. YAF 0.1.0 is now  
available from:

http://aircert.sourceforge.net/yaf

YAF is made available under the GNU General Public License; its IPFIX  
message format transcoder implementation, libfixbuf, is made  
available under the GNU Lesser General Public License. It is  
announced here for the information and convenience of other IPFIX  
implementors.

 From the README:

YAF is Yet Another Flow sensor. It processes packet data from pcap(3)  
dumpfiles as generated by tcpdump(1) or via live capture from an  
interface using pcap(3) into bidirectional flows, then exports those  
flows to IPFIX Collecting Processes or in an IPFIX-based file format.  
Prerequisites required for building YAF are listed at the website.

Why does the world need another network flow event generator? YAF is  
primarily intended as an experimental implementation tracking  
developments in the IETF IPFIX working group, specifically  
bidirectional flow representation and archival storage formats. It is  
designed to perform acceptably as a flow sensor on any network on  
which white-box flow collection with commodity hardware is  
appropriate, but tradeoffs between raw performance and clarity of  
design have generally been made in favor of the latter.

The YAF toolchain presently consists of two tools, yaf itself, and  
yafscii, which converts yaf output into ASCII format. A third  
(undocumented) tool, yafcollect, is an IPFIX Collecting Process  
intended for testing purposes. Further capabilities will be added to  
the suite as it evolves.

In general, YAF is alpha quality software. Not every reasonable use  
case has been thoroughly tested. Be aware of this before using YAF;  
it should not be deployed in production environments at this time.

Of special note to IPFIX implementors considering the use of YAF for  
testing: YAF and libfixbuf differ from draft-ietf-ipfix-protocol-19,  
draft-boschi-ipfix-implementation-guidelines-01, and draft-trammell- 
ipfix-biflow-01 in the following important ways:

1. Template management is not implemented as recommended. The  
protocol suggests that templates by uniquely identified by (Template  
ID, Source ID, Exporter Address) tuples; libfixbuf scopes templates  
solely by Template ID, with a split between "reader" and "writer"  
templates to avoid template collision in "IPFIX filter" applications.  
This is inadequate, and will require an incompatible change to the  
API in the next libfixbuf release.

2. While libfixbuf will read records containing multiple information  
elements of the same type, only the last information element of any  
given type will be available to the transcoder and copied to the  
application. The same caveat applies to writers; all but the last  
information element of any given type will be zeroed on transcode.  
This will be fixed in the next libfixbuf release.

3. SCTP is not supported. Future releases of libfixbuf will support  
SCTP via the sockets API as in Stevens et. al. _UNIX Network  
Programming, Volume One, Third Edition_; in reality this translates  
to SCTP being supported only on certain Linuxes. No plans exist to  
support any of the various SCTP userland implementations.

4. Single record biflow export as in section 5 of draft-trammell- 
ipfix-biflow-01 is supported, but as no choice has yet been made  
concerning the allocation of reverse Information Elements, it uses  
private Information Elements (specifically, reverseOctetTotalCount is  
6871/12, reversePacketTotalCount is 6871/13) for the reverse  
counters. A full listing of Information Elements, including private  
IEs, is listed in the YAF manpage. The --uniflow switch to yaf can be  
used to enable record adjacency biflow export as in section 4.1 of  
the biflow draft; this is provided solely for compatibility with  
Collecting Processes without biflow support.

I am YAF's principal author and maintainer, so questions, comments,  
concerns, and flames can be directed to me.

Regards,

Brian