1 IPFIX Protocol Specifications IPFIX IETF-59 March 3, 2004 Benoit Claise Mark Fullmer Reinaldo Penno Paul Calato Stewart Bryant Ganesh Sadasivan

222 Changes from version 01 to 02 Time Synchronization Proposal Section 10 "Export Packet UNIX Secs Computation and Flow Records Times" Section 10.1 "microsecond precision" Section 10.2 "millisecond precision“ Section 10.3 "nanosecond precision" Section 10.4 "multiple precisions"

333 Changes from version 01 to 02 Linkage with Information Model A new section Defining the encoding rules: "Boolean“, "Byte“, "UnsignedByte“, "Short"... -> Needs to be completed "Reduced Size Encoding of Integral Types"

444 Changes from version 01 to 02 Security New section 15.1 "IPsec Profile" New section "Selectors" New section "Mode" New section "Key Management" New section "Security Policy" New section "Authentication" New section "Availability" New section 15.2 "Network Architecture" New section 15.3 "When IPsec is not an Option" New section 15.4 "Transport Issues" New section 15.5 "Logging an IPFIX Attack" Note: TLS has been added in version 03

555 Changes from version 01 to 02 Vendor Specific Information Element Section "IETF Exclusive Template FlowSet Format" FlowSet ID = 0 Section "IETF Exclusive Options Template FlowSet Format“ FlowSet ID = 1 Section "Vendor Specified Template FlowSet Format“ FlowSet ID = 2 Section "Vendor Specified Options Template FlowSet Format" FlowSet ID = 3

666 Changes from version 01 to 02 Metering Process Statistics Option Template New section 9.1 "Metering Process Statistics Option Template“ This is a proposal At minimum: ipfixOption, observationDomain, lostFlows, time Still under discussion on the mailing list

777 Changes from version 01 to 02 Editorial Changes New IPFIX Overview Section Length replaced the Count in the header. Example at the end of the draft is updated. Updated the Variable Length Data Type As a consequence, the new term "Information Element" exists in the terminology section Normative versus informative references Minor editorial changes

888 Changes from version 02 to 03 Terminology Terminology sections synchronized between [IPFIX-PROTO] and [IPFIX-ARCH] Actually the next version of [IPFIX-ARCH]

999 Changes from version 02 to 03 Transport Protocol(s) SCTP MUST be implemented by all compliant implementations. UDP and TCP is a MAY also be implemented by compliant implementations. SCTP SHOULD be used in deployments where exporters and collectors are communicating over links which are susceptible to congestion. TCP MAY be used in deployments where exporters and collectors communicate over links which are susceptible to congestion, but SCTP is preferred, due to its ability to limit back pressure on exporters (especially when using PR-SCTP) and its message vs. stream orientation. Other non-congestion aware protocols (like UDP) MAY be used in deployments where exporters and collectors always communicate over dedicated links which are not susceptible to congestion. Note: need some text for UDP and TCP

10 Changes from version 02 to 03 Flow Expiration Flow Expiration section is now synchronized with [IPFIX-ARCH]: 4.0 Criteria for flow expiration and Export 4.1 Flow Expiration 4.2 Flow Export

11 Changes from version 02 to 03 Editorial Changes Abstract modified Structure changed 9. Specific Reporting Requirements 9.1 The Metering Process Statistics Option Template Change the IPFIX Header "Unix Secs" to "Export Time" The Option Data Record Format can have multiple scopes: figure updated Minor editorial changes

12 Changes from version 02 to 03 List of Open Issues and Actions 30 of them identified Please provide feedback and text on the mailing list Let’s discuss some of them

13 Open Issues Exporter Time Accuracy? [IPFIX-REQ] The timestamp resolution MUST be at least the one of the sysUpTime [RFC3418], which is one centisecond. Meeting Minutes for IETF 58: The consensus was that a UTC-based seconds and microseconds, similar to Unix struct timeval, should be adopted. The IPFIX implementation may need to report its time resolution, which presumably would require new text in the protocol draft. What if the exporter can’t report timestamps with a microsecond time accuracy? But only centisecond? Must we find a way to report the time accuracy (resolution)? Or we don’t care?

14 Open Issues IP Encapsulated Packet IP Traffic Flow or Flow definition: A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval. The initial question is: Should we add: “or encapsulated IP packets”? [IPFIX-REQ]: If the observation point is located at a device supporting Multiprotocol Label Switching (MPLS, see [RFC3031]) then the metering process MUST be able to separate flows by the MPLS label.

15 Open Issues IP Encapsulated Packet (part 2) What do we want to report? What do we want the flow key to be? Examples: -GRE -IP-in-IP -IPV6 tunnel (original packet IPV6/IPV4) -MPLS packets with IP(v4/v6) -MPLS packets with non-IP -We support MPLS or any other sub-IP as long as the original packet is IP? -One can define flow based on just MPLS labels? -Should we change the Flow definition? -Removed IP in the Flow definition? A flow is defined as a set of IP packets passing an observation point in the network during a certain time interval.

16 Open Issues Padding The Exporting Process SHOULD insert some padding bytes so that the subsequent FlowSet starts at a 4-byte aligned boundary. It is important to note that the Length field includes the padding bits. The Collector MUST accept padding in the Data FlowSet and Options Template FlowSet, which means for the Flow Data Records, the Options Data Records and the Template Records. Question: padding as a MAY, SHOULD or MUST? Proposal: padding a MAY

17 Feedback Any others to be discussed now? Thank you