1 / 7

Implementing IPFIX

Implementing IPFIX. Luca Deri <luca.deri@netikos.com> NETikos S.p.A. Implementation Overview. This work evaluated the effort required to implement IPFIX starting from NetFlow v9 because: NetFlow is the leading protocol for flow-based measurements.

kirby-cotton
Télécharger la présentation

Implementing IPFIX

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing IPFIX Luca Deri <luca.deri@netikos.com> NETikos S.p.A.

  2. Implementation Overview • This work evaluated the effort required to implement IPFIX starting from NetFlow v9 because: • NetFlow is the leading protocol for flow-based measurements. • This is a reasonable scenario at least for the early days of IPFIX. • Implementing IPFIX basically means: • Provide support for vendor-specific (I.e. non IETF) field types. • Add SCTP support.

  3. Vendor-Specific Extensions • Vendor-specific fields are defined using a PEN (IANA enterprise number) and a numeric field. • As templates and flows are slightly different from IETF-defined fields this requires the implementation of additional logic inside the IPFIX applications. • Suggestion: IETF should unify the template format using an unique format for both IETF and vendor-specific fields.

  4. SCTP Support • It is a shift from connection-less to connection-oriented protocols. • Little coding is necessary for supporting the protocol ‘per-se’. • Reduce template traffic: they are sent at the beginning or in case of reconnection. • Major code changes the probe supports multiple collectors: it is necessary to resend the templates per-connection (i.e. only when it’s necessary).

  5. SCTP Issues • Flows are (often) acknowledged (almost) immediately increasing significantly the network traffic. This amplifies problems in some situations (e.g. in case of DoS attacks). • SCTP is supported only on a few platforms and there are no plans to support it in Windows or network equipment. This could limit the usage of IPFIX at least in its early days. • Unclear how reliable/robust is SCTP and how it behaves in production environments (network attacks?).

  6. IPFIX Evaluation IPFIX Evaluation: • It’s basically a “standard” NetFlow (that’s both good and bad). • Very little innovation after 10 years of flow-based measurement. Major IPFIX limitations are: • No dynamic templates: static templates push people to define a “super-template” that contains everything even if only a few fields are used. • Ability to define flows but not flow headers. • Still based on the concept of flow-packet even with SCTP. • One-way protocol (probe->collector): no support for configuration, monitoring, and error reporting (e.g. via SNMP like sFlow does). • Too tight to NetFlow: will IPFIX be able to grow and evolve without Cisco’s blessing?

  7. IPFIX Feedback • Written Internet Draft about IPFIX implementation experience. • Implemented IPFIX support in both probe and collector (ntop). • Availability: http://www.ntop.org/

More Related