1 / 15

Per-Packet Record Export Proposal

Per-Packet Record Export Proposal. draft-kim-ipfix-ppr-00.txt Chang H. Kim, Taesang Choi { kimch, choits } @etri.re.kr. Motivation. Contents-awareness is getting more important Applicability Application Recognition/Identification

tamas
Download Presentation

Per-Packet Record Export Proposal

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. Per-Packet Record Export Proposal draft-kim-ipfix-ppr-00.txt Chang H. Kim, Taesang Choi {kimch, choits}@etri.re.kr

  2. Motivation • Contents-awareness is getting more important • Applicability • Application Recognition/Identification • User-configurable or dynamic ports, overloaded ports, etc. are big concerns • Contents-based Service Differentiation and Accounting • Attack/Intrusion Detection • Some worms or viruses do not incur flow/packet number increases, esp. at the early stage of dissemination.

  3. Real-world Situation PosTech Traffic Breakdown • PosTech Campus Network • (24h sum in May, 304GB total volume)

  4. Exporting Payload Required • Contents-awareness requires exporting packet payload • Entire/partial payloads can be exported • on a per-packet basis • our approach in the draft • on the existing flow basis • might be another decent option

  5. Why per-packet basis? • Payload investigation is expensive • requires fragmentation, drop, and out-of-order handling • O(t*p) or O(t+p) time complexity • t = text length, p = pattern length • Timely transmission is important • can’t wait until a flow terminates

  6. Other Applications of PPR Export • QoS Monitoring and Traffic Profiling • Understanding per-packet traits required

  7. The Objective of the Draft • Incorporating per-packet information export into the existing ipfix proposals • providing a generalized version of a ppr export mechanism so that all the required fields of a packet (including payload) can be exported • leveraging the existing ipfix protocol, information model, and architecture

  8. Correspondence with the WG Charters • ipfix or psamp? • When it’s literally grounded on the charters, the draft better matches with psamp than ipfix. • Nevertheless, we first brought this up to ipfix because psamp seems to be focusing on sampling and filtering mechanisms and the mibs for configuration • Corresponding to the “ipfix-psamp relationship” proposal

  9. Suggested Extensions • Information Model Extension • The draft includes information elements based on IPv4/TCP/UDP headers and packet payloads • Exporting first n bytes of a packet supported • Configuration Extension • A selection criteria for enabling/disabling per-packet record generation • Adding Per-Packet Info Export flag to the existing selection criteria suffices • Pattern Specification for packet payload investigation and export (optional)

  10. Extended Architecture Packet Capturing Timestamping Sampling PPIE flag == on Classifying Payload Investigation (Null when No pattern or Wildcard pattern) Generating Flow Records Generating Packet Records (A payload is appended only when a specified pattern is found on the payload)

  11. Data Export • Utilizing the existing Data Export mechanism • Requires at the most two different record templates • Flow Properties record and Packet Properties record • In psamp, Flow Properties record merely means shared information element; just for stringent network resource consumption • Associating packet records with the corresponding flow record • is accomplished on the basis of the order of the two records; a Flow Properties record must be disposed right ahead of the corresponding Packet Properties records • Packet record export intervals • synchronized with the flow export • unsynchronized with the flow export • periodic/instant export

  12. A Sample Layout of an Export Packet Containing PPR Packet Header Data FlowSet (Ordinary Flow Records) Flow Properties FlowSet (Flow Record of flow “X”) Packet Properties FlowSet (Packet Records within “X”) ... ... FlowSet ID = p FlowSet ID = q or p FlowSet ID = r

  13. Issues Discussed • Assigning a unique pkt id • globally unique? • flow-locally unique? • what about calculating the unique id at the collecting process? • Schemes for associating packet records to the corresponding flow record • Incorporating information elements for IPv6 packets

  14. Proposed Next Steps • Regarding contents-awareness • To supplement the applicability draft with some texts • Exporting packet payloads using the existing flow export mechanisms may also be separately documented • Regarding per-packet information export • Verifying the correctness of utilizing ipfix protocol and information model under ipfix/psamp? • Then, building up as a wg document in psamp? • Cooperation with another interested group expected

  15. Thank You!

More Related