[ipfix-info] Re: draft-boschi-ipfix-biflow and software implementation

[Brian Trammell <[e-mail]>]

Alexandre,

On Feb 7, 2006, at 10:11 AM, Alexandre Dulaunoy wrote:

> I'll  try  to  "over"  summarize  back  what  I  understand  with  the
> information       you      gave       me      and       the      draft
> (draft-boschi-export-perpktinfo-01.txt) :
>
> The FlowID  is a 32bit id  unique across one observation  point and is
> (always?) generated by the exporter.
>
> We   (at  SES   ASTRA  and   CSRRT-LU)  are   trying  to   generate  a
> "unique/calculable" FlowID  among a specify dataset of  records. Why ?
> We  have  a  bunch  of  "exporters" (routers,  devices)  with  various
> versions  of Netflow  and  we have  to  live with  that  for the  time
> being. What we are doing currently  ? we use a simple hash function to
> generate a  "unique" FlowID per  data set based  on source/destination
> IP,  source/destination  PORT  and  (protocol).   We  use  the  lowest
> source/destination (IP/PORT) to generate a unified hash id per biflow.
>
> So it  seems that I was mixing  our and your definition  of FlowID but
> what do  you think ?  Can  we call that  a FlowID or something  else ?
> Have you think of a 'possible'  function to generate a FlowID based on
> records ? Like  that, we can rebuild biflow(s)  from uniflow(s) ? Does
> it make sense ?

flowId, as defined in -info-11, does not presently appear flexible  
enough to cover this use case; its "unique within Observation Domain"  
constraint appears to make multiple Flow Records sharing the same  
flowId impossible. Thinking about it for a moment, I think this is a  
fault in the information model. To increase the flexibility of this  
IE, I'd propose changing its definition to the following:

5.1.7.  flowId

    Description:
       An identifier of a Flow that is unique within an Observation
       Domain.  This Information Element can be used to distinguish
       between different Flows if Flow Keys such as IP addresses and  
port
       numbers are not reported or reported in separate records.  
Multiple
       Flow Records observed within the same Observation Domain may  
share
       the same flowId if they describe the same Flow as determined  
by the
       Metering Processes within that Domain.
    Abstract Data Type: unsigned32
    Data Type Semantics: identifier
    ElementId: 148
    Status: current

(Elisa - this also expands flowId as required for -biflow-02 section  
3.2)

> Brian : A site note, looking into naf source code (the pcap exporter),
> I can't  find the part of generating  the FlowID. Can you  point me to
> the correct part ?

We don't actually use the flowId anywhere (hence the cheating) - we  
do single-record biflow export per draft-boschi-ipfix-biflow section  
3.4 (section 4 in the forthcoming -02 draft), with CERT-private IEs  
standing in for IANA-assigned IEs pending completion of that draft.  
The relevant code is in nafcore.c. NAF unifies uniflows (from pcap or  
SiLK) into biflows the hard way; SiLK asymmetric unidirectional data  
is collected using the SiLK tools' proprietary protocol into a single  
database, relevant records are selected out of that database and  
sorted by time, mingling incoming and outgoing records and re- 
matching them before aggregation.

YAF also cheats; it's designed solely for deployment at symmetric  
routing points, or for use on packet capture data that can be  
prearranged to appear to have come from a symmetric routing point.

Regards,

Brian