1 / 9

IPFIX Applicability Statement - Update -

IPFIX Applicability Statement - Update -. Tanja Zseby zseby@fokus.fhg.de. Issue 1: Too Many Exotic Examples. Too many exotic examples that require extensions Should concentrate on IPFIX usage in typical scenarios More about applicability limits How addressed

misae
Télécharger la présentation

IPFIX Applicability Statement - Update -

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. IPFIX Applicability Statement- Update - Tanja Zseby zseby@fokus.fhg.de

  2. Issue 1: Too Many Exotic Examples • Too many exotic examples that require extensions • Should concentrate on IPFIX usage in typical scenarios • More about applicability limits • How addressed • Removed some exotic use cases, shortened some text • Concentrated on target applications from RFC3917 • Usage-based Accounting • Attack/Intrusion Detection • QoS Monitoring • Traffic Profiling • Traffic Engineering • Provided more detailed examples • Examples with IEs • Table about when to use IEs from IPFIX, PSAMP, extensions

  3. Issue 2: IPFIX Limitations for usage-based Billing • IPFIX not compliant to reliability requirements for usage-based billing as stated in [RFC2975] • Record loss: problem if UDP is used • Network or device failures: multiple collectors allowed but not explicitly demanded for fault tolerance • Detection and elimination of duplicate records • Application layer acknowledgements: not supported • Changes in IPFIX-AS: • Added a section (4.2.) on limitations for usage-based billing • Added several warnings • AAA examples not removed but warnings added • Reliability Extensions  draft-bclaise-ipfix-reliability-01.txt

  4. Issue 3: Reporting TCP Flags • IPFIX Applicability to attack detection • Tried to give some examples in IPFIX-AS • Occurrence of TCP flags important for attack detection • Detection of incomplete connections, claim&hold attacks, etc. • Useful metrics: • #SYN packets to a destination • #SYN/#FIN ratio • BUT: Currently no direct support in IPFIX • No IE for counting SYN packets per flow (e.g. to one destination) • TCP flags not defined as flow keys in IPFIX-INFO • IPFIX IE: tcpControlBits (per flow) defined as bitfield • bit=1 if any packet of flow contained the TCP flag • bit=0 if no packet of flow contained the TCP flag •  IPFIX provides no information on TCP flags per flow

  5. Issue 3: Reporting TCP Flags • Approach 1: Report every TCP connection as separate (bi-)flow • Flow keys: sourceIPv4Address,destinationIPv4Address, protocolIdentifier, tcpSourcePort, tcpDestinationPort • Evaluate tcpControlBits per TCP flow (e.g. count #flows for which only SYN and no FIN packet was observed)  only partial solution • Will work for attacks from multiple sources or with spoofed src addresses per packet • Will work for attacks from single sources with different source ports per packet • Will not work for attacks with modified source port field from single sources with same source port per packet  high classification effort, many flow records  high resource consumption • Approach 2: Observe flowEndReason • Flows that didn’t receive a FIN will have other end reasons (e.g. idle time,…)  only partial solution • Highly depends on idle timeout and max lifetime settings • Flow termination may have been triggered by lack of resources • Flow termination may have been forced by other events (shut-down etc.)

  6. Issue 3: Reporting TCP Flags • Approach 3: Use PSAMP IEs • Report PSAMP IE ipPayloadPacketSection for all packets • Extract flags from packets  full solution, but extremely high effort • information per packet is transferred • post processing of packet reports required • Approach 4: Introduce new IEs • Filling tcpControlBits field requires TCP flags evaluation anyway • 4.a: IE for TCP flags as flow key •  #”FIN flows”, #”SYN flows”  full solution, but many flows, high resource consumption • 4.b.: Introduce TCP flag counters as new IEs  preferred solution • full solution, less resource consumption • Other request/response pairs • Beyond scope of IPIFX • May be added as vendor specific IEs

  7. Further Issues • Example IP Addresses have to be from RFC3330 address range •  now example with subnetting • Some minor editing (wording, typos) • Further comments (will be addressed in next version) • Too IPv4 centric •  mention that examples also apply to IPv6 •  move „IPFIX and IPv6“ from section 4 (limitations) to section 3 (relations to other FWs and protocols) • Stronger statement on usage of IPPM metrics • Add recommendation to use IPPM metrics whenever applicable (for QoS monitoring)

  8. My (AS-)biased view… … on the Priority of Future IPFIX Work Items 1. New IEs for TCP flags, flag counters 2. Reporting Bi-Flows (draft-trammell-ipfix-biflow-02.txt) • Desperately needed by security people 3. Configuration of IPFIX exporters and collectors • IPFIX MIB: draft-dietz-ipfix-mib-00.txt • XML Data model: draft-muenz-ipfix-configuration-00.txt • Related: draft-dressler-nsis-metering-nslp-04.txt 4. Reliability Extension (draft-bclaise-ipfix-reliability-01.txt) • Needed to use IPFIX for billing purposes 5. File format (draft-trammell-ipfix-file-01.txt) • Post-incident analysis for network security • Sharing IPFIX data (providers, research community, etc.) • Provide training data for anomaly detection (traces with “normal” behavior)

  9. Thank You

More Related