IPFIX Working Group B. Claise Internet-Draft G. Dhandapani Intended Status: Standard Track S. Yates Expires: September 3, 2009 P. Aitken Cisco Systems, Inc. March 3, 2009 Export of Structured Data in IPFIX draft-claise-structured-data-in-ipfix-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August, 2009. Expires September 3 2009 [Page 1] Internet-Draft March 2009 Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies an extension to IP Flow Information eXport (IPFIX) protocol specification in [RFC5101] and the IPFIX information model specified in [RFC5102] to support hierarchical structured data and lists (sequences) of Information Elements in data records. This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Expires September 3, 2009 [Page 2] Internet-Draft March 2009 Table of Contents 1. Overview...................................................6 1.1. IPFIX Documents Overview..............................6 1.2. Relationship between IPFIX and PSAMP..................7 2. Terminology................................................7 2.1. New Terminology.......................................7 3. Introduction...............................................8 3.1. IPFIX Limitations.....................................9 4. Linkage with the Information Model........................10 4.1. New Abstract Data Types..............................10 4.1.1. basicList.......................................10 4.1.2. subTemplateList.................................10 4.1.3. subTemplateMultiList ...........................11 4.2. New Data Type Semantic...............................11 4.2.1. list............................................11 4.3. New Information Elements.............................11 4.3.1. basicList.......................................11 4.3.2. subTemplateList.................................12 4.3.3. subTemplateMultiList ...........................12 4.4. Encoding of IPFIX Data Types.........................12 4.4.1. basicList.......................................12 4.4.2. subTemplateList.................................15 4.4.3. subTemplateMultiList ...........................16 5. Structured Data Format....................................18 5.1. Length Encoding Considerations.......................18 5.2. Structured Data Information Elements Applicability in Options Template Sets.....................................19 5.3. Padding..............................................19 6. Template Management.......................................19 7. The Collecting Process's Side.............................20 8. Structured Data Encoding Examples.........................20 8.1. Encoding BasicList ..................................21 8.2. Encoding subTemplateList.............................22 8.3. Encoding subTemplateMultiList........................26 9. Relationship with the Other IFPIX Documents...............29 9.1. Relationship with Bidirectional Flow Export [RFC5103]............................................29 9.2. Relationship with Reducing Redundancy [RFC5473]......29 9.2.1. Encoding Common Properties elements in Structured Data...................................................30 9.2.2. Encoding Structured Data using Common Properties30 9.3.Relationship with Guidelines for IPFIX Testing [RFC5471] .......................................................30 10. IANA Considerations......................................31 10.1. New Abstract Data Types.............................31 10.1.1. basicList......................................32 10.1.2. subTemplateList................................32 Expires September 3, 2009 [Page 3] Internet-Draft March 2009 10.1.3. subTemplateMultiList..........................32 10.2. New Data Type Semantics............................32 10.2.1. list..........................................32 10.3. New Information Elements ..........................33 10.3.1. basicList.....................................33 10.3.2. subTemplateList...............................33 10.3.3. subTemplateMultiList..........................33 11. Security Considerations.................................34 12. References..............................................34 12.1. Normative References...............................34 12.2. Informative References.............................34 13. Acknowledgement ........................................35 14. Authors' Addresses......................................35 Expires September 3, 2009 [Page 4] Internet-Draft March 2009 Table of Figures Figure A: basicList Information Element Encoding..............13 Figure B: basicList Encoding with Enterprise Number............14 Figure C: Variable-Length basicList Information Element Encoding (Length < 255 octets) ..................................14 Figure D: Variable-Length basicList Information Element Encoding (Length 0 to 65535 octets)..............................14 Figure E: subTemplateList Encoding..........................15 Figure F: Variable-Length subTemplateList Information Element Encoding (Length < 255 octets)...........................16 Figure G: Variable-Length subTemplateList Information Element Encoding (Length 0 to 65535 octets) ......................16 Figure H: subTemplateMultiList Encoding......................17 Figure I: Variable-Length subTemplateMultiList Information Element Encoding (Length.......................................18 Figure J: Variable-Length subTemplateMultiList Information Element Encoding (Length >= 255 octets)..........................18 Figure K: Encoding basicList, Template Record.................21 Figure L: Encoding basicList, Data Record....................22 Figure M: Encoding subTemplateList, Template for Target........23 Figure N: Encoding subTemplateList, Template for Attacker ......24 Figure O: Encoding subTemplateList, Template for Participant....24 Figure P: Encoding subTemplateList, Template for IPS Alert......24 Figure Q: Encoding subTemplateList, Data Set..................26 Figure R: Encoding subTemplateMultiList, Template for Target....27 Figure S: Encoding subTemplateMultiList, Template for Attacker..27 Figure T: Encoding subTemplateMultiList, Template for Participant27 Figure U: Encoding subTemplateMultiList, Template for IPS Alert.28 Figure V: Encoding subTemplateMultiList, Data Set.............29 Expires September 3, 2009 [Page 5] Internet-Draft March 2009 Below is the TODO list that will appear when the draft is posted - Should we specify how to use Structured Data Information Element as scope in an Options Template Record? - Produce the XML code for the information elements definition, like it is done in RFC5102. - Specify the case of circular references 1. Overview 1.1. IPFIX Documents Overview The IPFIX Protocol [RFC5101] provides network administrators with access to IP Flow information. The architecture for the export of measured IP Flow information out of an IPFIX Exporting Process to a Collecting Process is defined in the IPFIX Architecture [RFC5470], per the requirements defined in RFC 3917 [RFC3917]. The IPFIX Architecture [RFC5470] specifies how IPFIX Data Records and Templates are carried via a congestion-aware transport protocol from IPFIX Exporting Processes to IPFIX Collecting Processes. IPFIX has a formal description of IPFIX Information Elements, their name, type and additional semantic information, as specified in the IPFIX Information Model [RFC5102]. In order to gain a level of confidence in the IPFIX implementation, probe the conformity and robustness, and allow interoperability, the Guidelines for IPFIX Testing [RFC5471] presents a list of tests for implementers of compliant Exporting Processes and Collecting Processes. The Bidirectional Flow Export [RFC5103] specifies a method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. The "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] specifies a bandwidth saving method for exporting Flow or packet information, by separating information common to several Flow Records from Expires September 3, 2009 [Page 6] Internet-Draft March 2009 information specific to an individual Flow Record: common Flow information is exported only once. 1.2. Relationship between IPFIX and PSAMP The specification in this document applies to the IPFIX protocol specifications [RFC5101]. All specifications from [RFC5101] apply unless specified otherwise in this document. The Packet Sampling (PSAMP) protocol [RFC5476] specifies the export of packet information from a PSAMP Exporting Process to a PSAMP Collecting Process. Like IPFIX, PSAMP has a formal description of its information elements, their name, type and additional semantic information. The PSAMP information model is defined in [RFC5477]. As the PSAMP protocol specifications [RFC5476] are based on the IPFIX protocol specifications, the specifications in this document are also valid for the PSAMP protocol. Indeed, the major difference between IPFIX and PSAMP is that the IPFIX protocol exports Flow Records while the PSAMP protocol exports Packet Reports. From a pure export point of view, IPFIX will not distinguish a Flow Record composed of several packets aggregated together, from a Flow Record composed of a single packet. So the PSAMP export can be seen as a special IPFIX Flow Record containing information about a single packet. 2. Terminology IPFIX-specific terminology used in this document is defined in section 2 of the IPFIX protocol specification [RFC5101] and section 3 of PSAMP protocol specification [RFC5476]. As in [RFC5101], these IPFIX-specific terms have the first letter of a word capitalized when used in this document. 2.1. New Terminology Structured Data Information Element One of the Information Elements supporting structured data, i.e., the basicList, subTemplateList, or subTemplateMultiList Information Elements as defined in section 4.3. Expires September 3, 2009 [Page 7] Internet-Draft March 2009 3. Introduction The IPFIX working group has specified a protocol to export IP Flow information [RFC5101]. This protocol is designed to export information about IP traffic Flows and related measurement data, where a Flow is defined by a set of key attributes (e.g. source and destination IP address, source and destination port, etc.). The IPFIX protocol specification [RFC5101] specifies that IP traffic measurements for Flows are exported using a TLV (type, length, value) format. The information is exported using a Template Record that is sent once to export the {type, length} pairs that define the data format for the Information Elements in a Flow. The Data Records specify values for each Flow. Based on the Requirements for IP Flow Information Export (IPFIX) [RFC3917], the IPFIX protocol has been optimized to export Flow related information. However, thanks to its Template mechanism, the IPFIX protocol can export any type of information, as long as the relevant Information Element is specified in the IPFIX Information Model [RFC5102], registered with IANA, or specified as an enterprise-specific Information Element. For each Information Element, the IPFIX Information Model [RFC5102] defines a numeric identifier, an abstract data type, an encoding mechanism for the data type, and any semantic constraints. Only basic, single- valued data types, e.g., numbers, strings, and network addresses are currently supported. The IPFIX protocol specification [RFC5101] does not support the encoding of hierarchical structured data and arbitrary-length lists (sequences) of Information Elements as fields within a Template Record. As it is currently specified, a Data Record is a "flat" list of single-valued attributes. However, it is a common data modeling requirement to compose complex hierarchies of data types, with multiple occurrences, e.g., 0..* cardinality allowed for instances of each Information Element in the hierarchy. One example relates to security. An IPS (Intrusion Prevention System) alert data structure could contain multiple participants. Each participant can contain multiple attackers and multiple targets, with each target potentially composed of multiple applications. See the Structured Data Encoding Examples in section 8. for specific examples related to this case study. Therefore, this document specifies an IPFIX extension to support hierarchical structured data and variable-length lists by defining Expires September 3, 2009 [Page 8] Internet-Draft March 2009 three new Information Elements and three corresponding new abstract data types called basicList, subTemplateList, and subTemplateMultiList. These are defined in section 4.1. New Abstract Data Types. It is important to note that whereas the Information Elements and abstract data types defined in the IPFIX Information Model [RFC5102] represent single values, these new abstract data types are structural in nature and primarily contain references to other Information Elements and to Templates. By referencing other Information Elements and Templates from an Information Element's data content, it is possible to define complex data structures such as variable-length lists and to specify hierarchical containment relationships between Templates. Therefore, this document prefers the more generic "Data Record" term to the "Flow Record" term. 3.1. IPFIX Limitations Consider the example scenario of an IPS (Intrusion Pevention System) alert data structure containing multiple participants, where each participant contains multiple attackers and multiple targets, with each target potentially composed of multiple applications, as depicted below: alert signatureId protocolIdentifier riskRating participant 1 attacker 1 sourceIPv4Address applicationId ... attacker N sourceIPv4Address applicationId target 1 destinationIPv4Address applicationId 1 ... applicationId n ... Expires September 3, 2009 [Page 9] Internet-Draft March 2009 target N destinationIPv4Address applicationId 1 ... applicationId n participant 2 ... To export this information in IPFIX, the data would need to be flattened (thus losing the hierarchical relationships) and a new IPFIX Template created for each alert, according to the number of applicationID elements in each target, the number of targets and attackers in each participant and the number of participants in each alert. Clearly each Template will be unique to each alert, and a large amount of CPU, memory and export bandwith will be wasted creating, exporting, maintaining, and withdrawing the Templates. 4. Linkage with the Information Model As in the IPFIX Protocol specification [RFC5101], the new Information Elements specified in section 4.3. below MUST be sent in canonical format in network-byte order (also known as the big- endian byte ordering). 4.1. New Abstract Data Types This document specifies three new abstract data types, as described below. 4.1.1. basicList The type "basicList" represents a list of zero or more instances of any single Information Element, primarily used for single- valued data types. For example, a list of port numbers, list of interface indexes, etc. 4.1.2. subTemplateList The type "subTemplateList" represents a list of zero or more instances of structured data, where the data type of each list element is the same and corresponds with a single Template Record. For example, structured data composed of multiple pairs of IP Expires September 3, 2009 [Page 10] Internet-Draft March 2009 address. 4.1.3. subTemplateMultiList The type "subTemplateMultiList" represents a list of of zero or more instances of structured data, where the data type of each list element can be different and corresponds with different template definitions. For example, a structured data composed of multiple access-list entries, where entries can be composed of different criteria types. 4.2. New Data Type Semantic This document specifies a new data type semantic, as described below. 4.2.1. list A list represents an arbitrary-length sequence of structured data, either composed of regular Information Elements or composed of data conforming to a Template Record. 4.3. New Information Elements This document specifies three new Information Elements, as described below. 4.3.1. basicList A basicList specifies a generic Information Element with a basicList abstract data type as defined in section 4.1.1. and list semantics as defined in section 4.2.1. For example, a list of port numbers, list of interface indexes, etc. EDITOR'S NOTE: while waiting for IANA to assign this new Information Element identifier, the value XXX is used in all the examples. Expires September 3, 2009 [Page 11] Internet-Draft March 2009 4.3.2. subTemplateList A subTemplateList specifies a generic Information Element with a subTemplateList abstract data type as defined in section 4.1.2. and list semantics as defined in section 4.2.1. EDITOR'S NOTE: while waiting for IANA to assign this new Information Element identifier, the value YYY is used in all the examples. 4.3.3. subTemplateMultiList A subTemplateMultiList specifies a generic Information Element with a subTemplateMultiList abstract data type as defined in section 4.1.3. and list semantics as defined in section 4.2.1. EDITOR'S NOTE: while waiting for IANA to assign this new Information Element identifier, the value ZZZ is used in all the examples. 4.4. Encoding of IPFIX Data Types The following sections define the encoding of the data types defined in section 4.1. above. When the encoding of a Structured Data Information Element has a fixed length (because, for example, it contains the same number of fixed-length elements, or if the permutations of elements in the list always produces the same total length), the element length can be encoded in the corresponding Template Record. However, when representing variable-length data, hierarchical data, and repeated data with variable element counts, we RECOMMEND these are encoded as a Variable-Length Information Element as described in section 7 of [RFC5101], with the length carried in one or three octets before the Structured Data Information Element encoding. 4.4.1. basicList The basicList Information Element defined in section 4.3.1. represents a list of zero or more instances of an Information Element and is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Expires September 3, 2009 [Page 12] Internet-Draft March 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Field ID | Element Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BasicList Content ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure A: basicList Information Element Encoding Field ID The Field ID is the Information Element identifier of the Information Element(s) contained in the list. Element Length The Element Length indicates the length of each element or contains the value 0xFFFF if the length is encoded as a variable-length Information Element. BasicList Content A Collection Process decodes list elements from the BasicList Content until no further data remains. A record count is not included but can be derived when the Information Element is decoded. Note that in the diagram above, the Field ID is shown with the Enterprise bit (most significant bit) set to 0. If instead the Enterprise bit is set to 1, a four-byte Enterprise Number MUST be encoded immediately after the Element Length as shown below. See the "Field Specifier Format" section in the IPFIX Protocol [RFC5101] for additional information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Field ID | Element Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Enterprise Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BasicList Content ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires September 3, 2009 [Page 13] Internet-Draft March 2009 Figure B: basicList Encoding with Enterprise Number Also note that, if a basicList has zero elements, the encoded data contains the Field ID, the Element Length and the four-byte Enterprise Number (if present); the BasicList Content is empty. The Element Length field is effectively part of a header, so even in the case of a zero-element list with no Enterprise Number, it MUST NOT be omitted. If the basicList is encoded as a Variable-Length Information Element in less than 255 octets, it is encoded with the Length per section 7 of [RFC5101] as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (< 255)| basicList Information Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... continuing as needed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure C: Variable-Length basicList Information Element Encoding (Length < 255 octets) If the basicList is encoded as a Variable-Length Information Element in 255 or more octets, it is encoded with the Length per section 7 of [RFC5101] as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | Length (0 to 65535) | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | basicList Information Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure D: Variable-Length basicList Information Element Encoding (Length 0 to 65535 octets) Expires September 3, 2009 [Page 14] Internet-Draft March 2009 4.4.2. subTemplateList The subTemplateList Information Element represents a list of zero or more instances of Template data. Because the Template Record referenced by a subTemplateList Information Element can itself contain other subTemplateList Information Elements, and because these Template Record references are part of the Information Elements content in the Data Record, it is possible to represent complex hierarchical data structures. The following diagram shows how a subTemplateList Information Element is encoded within a Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID | SubTemplateList Content | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure E: subTemplateList Encoding Template ID The Template ID is the ID of the template used to encode and decode the SubTemplateList Content. SubTemplateList Content The SubTemplateList Content consists of zero or more instances of Data Records corresponding to the Template ID. A Collecting Process decodes the Data Records until no further data remains. A record count is not included but can be derived when the subTemplateList is decoded. Encoding and decoding are performed recursively if the specified Template itself contains Structured Data Information Elements as described here. Note that, if a subTemplateList has zero elements, the encoded data contains just the Template ID; the SubTemplateList Content is empty. If the subTemplateList is encoded as a Variable-Length Information Element in less than 255 octets, it is encoded with the Length per section 7 of [RFC5101] as follows: Expires September 3, 2009 [Page 15] Internet-Draft March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (< 255)| subTemplateList Information Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... continuing as needed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure F: Variable-Length subTemplateList Information Element Encoding (Length < 255 octets) If the subTemplateList is encoded as a Variable-Length Information Element in 255 or more octets, it is encoded with the Length per section 7 of [RFC5101] as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | Length (0 to 65535) | IE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... continuing as needed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure G: Variable-Length subTemplateList Information Element Encoding (Length 0 to 65535 octets) 4.4.3. subTemplateMultiList Whereas each top-level element in a subTemplateList Information Element corresponds with a single Template ID and therefore has the same data type, sometimes it is useful for a list to contain elements of more than one data type. To support this case, each top-level element in a subTemplateMultiList Information Element carries a Template ID and Length. The following diagram shows how a subTemplateMultiList Information Element is encoded within a Data Record: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element 1 Length | Element 1 Template ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element 1 Content ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Expires September 3, 2009 [Page 16] Internet-Draft March 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element 2 Length | Element 2 Template ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element 2 content ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element N Length | Element N Template ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element N content ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure H: subTemplateMultiList Encoding Element Length The total length of the Element encoding, not counting the Element Length field itself. Element Template ID Unlike the subTemplateList Information Element, each list element contains an Element Length and Element Template ID which specifies the encoding of the following Element Content. Element Content The Element Content consists of zero or more instances of Data Records corresponding to the Element Template ID. A Collecting Process decodes the Data Records until no further data remains. A record count is not included but can be derived when the Element Content is decoded. Encoding and decoding are performed recursively if the specified Template itself contains Structured Data Information Elements as described here. In the exceptional case of zero instances in the subTemplateMultiList, no data is encoded and the Length is set to zero. If the subTemplateMultiList is encoded as a Variable-Length Information Element in less than 255 octets, it is encoded with the Length per section 7 of [RFC5101] as follows: 0 1 2 3 Expires September 3, 2009 [Page 17] Internet-Draft March 2009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (< 255)| subTemplateMultiList Information Element | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... continuing as needed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure I: Variable-Length subTemplateMultiList Information Element Encoding (Length 0 to 65535 octets) If the subTemplateMultiList is encoded as a Variable-Length Information Element in 255 or more octets, it is encoded with the Length per section 7 of [RFC5101] as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | Length (0 to 65535) | IE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... continuing as needed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure J: Variable-Length subTemplateMultiList Information Element Encoding (Length >= 255 octets) 5. Structured Data Format 5.1. Length Encoding Considerations The new Structured Data Information Elements represent a list that potentially carries complex hierarchical and repeated data. In the normal case where the number and length of elements can vary from record to record, these Information Elements are encoded as variable-length Information Elements as described in section 7 of [RFC5101]. Because of the complex and repeated nature of the data, it is potentially difficult for the Exporting Process to efficiently know in advance the exact encoding size; as a result, data may be recursively encoded starting at a fixed offset, with the final length only known and filled in afterwards. Therefore, the three-byte length encoding is RECOMMENDED for variable-length information elements in all Template Records Expires September 3, 2009 [Page 18] Internet-Draft March 2009 containing a Structured Data Information Element, even if the encoded length can be less than 255 bytes, because the starting offset of the data is known in advance. An Exporting Process MUST take care when encoding such data to not exceed the maximum allowed length of an IPFIX Message, 65535 bytes, respecting the IPFIX specifications [RFC5101] that imposes: "The IPFIX Message Header 16-bit Length field limits the length of an IPFIX Message to 65535 octets, including the header". 5.2. Structured Data Information Elements Applicability in Options Template Sets All the examples in this document uses the Structured Data Information Elements, abstract data types, and data type semantic in Template Sets. However, they could also be used in and Options Template Sets. Regarding the scope in the Options Template Record, the IPFIX specification [RFC5101] mentions that "The IPFIX protocol doesn't prevent the use of any Information Elements for scope". Therefore, a Structured Data Information Element could be used as scope in an Options Template Set. However, in practice, the authors don't see an immediate business case for such a case. The specifications are not covered in this document. Note that an additional New Set ID for Options Template Sets would be required for Option Template Sets that carry Structured Data Information Elements. 5.3. Padding The Exporting Process MAY insert some padding octets in structured data field values in a Data Record by including the 'paddingOctets' Information Element as described in [RFC5101] section 3.3.1, "Set Format". The paddingOctets Information Element can be included in a Template Record referenced by structured data for this purpose. 6. Template Management This section introduces some more specific Template Management and Template Withdrawal Message-related specifications compared to the IPFIX protocol specification [RFC5101]. Expires September 3, 2009 [Page 19] Internet-Draft March 2009 First of all, the Template ID uniqueness is unchanged compared to [RFC5101]; the uniqueness is local to the Transport Session and Observation Domain that generated the Template ID. In other words, the Set ID used to export the Template Record does not influence the Template ID uniqueness. While [RFC5101] mentions that: "If an Information Element is required more than once in a Template, the different occurrences of this Information Element SHOULD follow the logical order of their treatments by the Metering Process.", this rule MAY not be followed for the Structured Data Information Elements. As specified in [RFC5101], Templates that are not used anymore SHOULD be deleted. Before reusing a Template ID, the Template MUST be deleted. In order to delete an allocated Template, the Template is withdrawn through the use of a Template Withdrawal Message. Multiple Template IDs MAY be withdrawn with a single Template Withdrawal Message, in that case, padding MAY be used. 7. The Collecting Process's Side This section introduces some more specific specifications to the Collection Process compared to section 9 in the IPFIX Protocol [RFC5101]. As described in [RFC5101], a Collecting Process MUST note the Information Element identifier of any Information Element that it does not understand and MAY discard that Information Element from the Flow Record. Therefore a Collection Process that does not support the extension specified in this document can ignore the Structured Data Information Elements in a Data Record, or it can ignore Data Records containing these new Structured Data Information Elements while continuing to process other Data Records. 8. Structured Data Encoding Examples The following examples are created solely for the purpose of illustrating how the extensions proposed in this document are encoded. Expires September 3, 2009 [Page 20] Internet-Draft March 2009 8.1. Encoding BasicList Consider encoding an user_record containing the following data: -------------------------------------------------------- userId | sourceIPv4Address | applicationId list -------------------------------------------------------- 1 192.0.2.201 1001, 1002, 1003 -------------------------------------------------------- userId is created for this example only and Field ID for this attribute is N/A. The userId is to uniquely identify the user; the user_record contains the data for a user from a particular IP address accessing a set of applications where the number of applications could be variable. Template Record for user_record, with the Template ID 258: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 20 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 258 | Field Count = 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| userId = N/A | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| basicList = XXX | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure K: Encoding basicList, Template Record The list of applications is represented as a basicList, the Length of the list is chosen to be encoded in three bytes even though it may be less than 255 octets. The Data Set is represented as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 258 | Length = 31 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires September 3, 2009 [Page 21] Internet-Draft March 2009 | userId = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sourceIPv4Address = 192.0.2.201 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 |applicationId List Length = 16 |appId Field ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... ID = 95 | appId Field Length = 4 | appId = 1001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2-4 octets of applicationId = 1001 | appId = 1002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2-4 octets of applicationId = 1002 | appId = 1003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2-4 octets of applicationId = 1003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure L: Encoding basicList, Data Record 8.2. Encoding subTemplateList An IPS alert consists of the following mandatory attributes: signatureId, protocolIdentifier and riskRating. It can also contain zero or more participants, each participant can contain zero or more attackers and zero or more targets. An attacker contains the attributes sourceIPv4Address and applicationId and a target contains the attribute destinationIPv4Address and zero or more occurrences of the attribute applicationId. Note that the signatureId and riskRating Information Element fields are created for these examples only; the Field IDs are shown as N/A. The signatureId helps to uniquely identify the IPS signature that triggered the alert. The riskRating identifies the potential risk, on a scale of 0-100 (100 being most serious), of the traffic that triggered the alert. To represent an alert, the following Templates are defined: Template for target (258) Template for attacker (259) Template for participant (260) Template for alert (261) alert (261) | (signatureId) | (protocolIdentifier) | (riskRating) | +------- participant (260) Expires September 3, 2009 [Page 22] Internet-Draft March 2009 | +------- attacker (259) | (sourceIPv4Address) | (applicationId) | +------- target (258) | (destinationIPv4Address) | (list of applicationId) Template Record for target, with the Template ID 258: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 258 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address = 12 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| basicList = XXX | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure M: Encoding subTemplateList, Template for Target The list of applicationId in the target is represented as a basicList. Template Record for attacker: 259 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 259 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| applicationId = 95 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires September 3, 2009 [Page 23] Internet-Draft March 2009 Figure N: Encoding subTemplateList, Template for Attacker Template Record for participant, with the Template ID 260: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 260 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| subTemplateList = YYY | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| subTemplateList = YYY | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure O: Encoding subTemplateList, Template for Participant The first subTemplateList in participant contains a list of attackers; the second contains a list of targets. Template Record for alert, with the Template ID 261: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 24 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 261 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| signatureId = N/A | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| protocolIdentifier = 4 | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| riskRating = N/A | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| subTemplateList = YYY | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure P: Encoding subTemplateList, Template for IPS Alert The subTemplateList in the alert Template Record contains a list of participants. Expires September 3, 2009 [Page 24] Internet-Draft March 2009 Consider an IPS alert with one participant, where the participant contains multiple attackers and one target with multiple applications. ----------------------------------------------------------------- | | | participant sigId |protocol| risk | attacker | target | Id | Rating | ip | appId | ip | appId(s) ----------------------------------------------------------------- 1003 17 10 192.0.2.3 103 192.0.2.4 104 192.0.2.104 4001, 4002 192.0.2.5 105 ----------------------------------------------------------------- The Data Record is represented as follows, the Length of basicList and subTemplateList are encoded in three bytes even though it may be less than 255 octets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 261 | Length = 66 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signatureId = 1003 | protocolId=17 | riskRating=10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | participant Length = 55 |participant... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Template ID=260| 255 | attacker Length = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | attacker Template ID = 259 | attacker1 sourceIPv4Address = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.3 | attacker1 applicationId = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 103 | attacker2 sourceIPv4Address = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.4 | attacker2 applicationId = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 104 | attacker3 sourceIPv4Address = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.5 | attacker3 applicationId = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 105 | 255 | target ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 21 | target Template ID = 259 | target ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | destinationIPv4Address = 192.0.2.104 | 255 | Expires September 3, 2009 [Page 25] Internet-Draft March 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |target appId List Length = 16 | target appId Field Id = 95 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |target appId Field Length = 4 | target appId = 4001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3-4 octets of appId 4001 | target appId = 4002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3-4 octets of appId 4002 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure Q: Encoding subTemplateList, Data Set 8.3. Encoding subTemplateMultiList Consider the following contrived example of an IPS alert. The participant can contain attackers and targets in any order and the sequence conveys some information to the Collector and needs to be preserved. In the example below, we have A1, T1 and A2 and this is encoded as a subTemplateMultiList. ------------------------------------------------------------------ | | | participant sigId |protocol| risk | attacker | target | Id | Rating | ip | appId | ip | appId(s) ------------------------------------------------------------------ 1003 17 10 192.0.2.3 103 192.0.2.103 3001, 3002 192.0.2.4 104 ------------------------------------------------------------------ Where attacker A1 is: 192.0.2.3 103 Where attacker A2 is: 192.0.2.4 104 Where target T1 is: 192.0.2.104 4001, 4002 To represent an alert, the following Templates are defined: Template for target (258) Template for attacker (259) Template for participant (260) Template for alert (261) Template Record for target, with the Template ID 258: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 octets | Expires September 3, 2009 [Page 26] Internet-Draft March 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 258 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| destinationIPv4Address = 12 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| basicList = XXX | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure R: Encoding subTemplateMultiList, Template for Target The list of applicationId in the target Template Record is represented as a basicList. Template Record for attacker, with the Template ID 259: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 16 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 259 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| applicationId = 95 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure S: Encoding subTemplateMultiList, Template for Attacker Template Record for participant, with the Template ID 260: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 12 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 260 | Field Count = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| subTemplateMultiList = ZZZ | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure T: Encoding subTemplateMultiList, Template for Participant Expires September 3, 2009 [Page 27] Internet-Draft March 2009 The Template Record for the participant has one subTemplateMultiList Information Element, which is a list that can include attackers and targets repeated in any order. Template Record for IPS alert, with the Template ID 261: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 2 | Length = 24 octets | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Template ID = 261 | Field Count = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| signatureId = N/A | Field Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| protocolIdentifier = 4 | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| riskRating = N/A | Field Length = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| subTemplateList = YYY | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure U: Encoding subTemplateMultiList, Template for IPS Alert The subTemplateList in the alert Template Record contains a list of participants. The Length of basicList, subTemplateList and subTemplateMultiList are encoded in three bytes even though it may be less than 255 octets. The Data Set is represented as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Set ID = 261 | Length = 66 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signatureId = 1003 |protocolId=17 | riskRating=10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | participant Length = 55 | participant | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Template ID=260| 255 |subTemplateMultiList Length=50 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | attacker1 Length = 10 | attacker1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires September 3, 2009 [Page 28] Internet-Draft March 2009 |Template ID=259| attacker1 sourceIPv4Address = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.3 | attacker1 applicationId = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 103 | 255 | target1 Length = 21 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | target1 Template ID = 258 |target1 destinationIPv4Address=| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.103 | 255 |target1 appId .| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |List Length=12 | target1 appId Field ID = 95 | target1 appId | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Field ID Len=4| target1 applicationId = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3001 | target1 applicationId = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3002 | attacker2 Length = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | attacker2 Template ID = 259 | attacker2 srcIPv4Address = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 192.0.2.4 | attacker2 applicationId = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 104 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure V: Encoding subTemplateMultiList, Data Set 9. Relationship with the Other IFPIX Documents 9.1. Relationship with Bidirectional Flow Export [RFC5103] [RFC5103] describes a method for exporting bidirectional flow information, and defines the biflowDirection Information Element for this purpose. [RFC5103] biflowDirection Information Elements may be encoded in a basicList, subTemplateList or subTemplateMultiList. 9.2. Relationship with Reducing Redundancy [RFC5473] [RFC5473] describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information eXport (IPFIX) protocol. Expires September 3, 2009 [Page 29] Internet-Draft March 2009 It defines the commonPropertiesID Information Element for exporting Common Properties. 9.2.1. Encoding Common Properties elements in Structured Data. The new structured data types listed in section 4.1. may be used to define a list of commonPropertiesID. 9.2.2. Encoding Structured Data using Common Properties. When structured data contains repeated elements, these elements may be replaced with a commonPropertiesID Information Element as described in [RFC5473]. The replaced elements may include the basicList, subTemplateList and subTemplateMultiList Information Elements. 9.3. Relationship with Guidelines for IPFIX Testing [RFC5471] [RFC5471] presents a list of tests for implementers of IP Flow Information eXport (IPFIX) compliant Exporting Processes and Collecting Processes. Although [RFC5471] doesn't define any Structured Data specific tests, the Structured Data Information Elements can be used in many of the [RFC5471] tests. The [RFC5471] series of test could be useful because the document specifies that every Information Element type should be tested. However, not all cases from this document are tested in [RFC5471]. The following sections are especially noteworthy: . 3.2.1. Transmission of Template with fixed size Information Elements - each data type should be used in at least one test. The new data types specified in section 4.1. should be included in this test. Expires September 3, 2009 [Page 30] Internet-Draft March 2009 . 3.2.2. Transmission of Template with variable length Information Elements - this test should be expanded to include Data Records containing variable length basicList, subTemplateList, and subTemplateMultiList Information Elements. . 3.3.1. Enterprise-specific Information Elements - this test should include the export of basicList, subTemplateList, and subTemplateMultiList Information Elements containing Enterprise-specific Information Elements. e.g., see the example in figure B. . 3.3.3. Multiple instances of the same Information Element in one Template - this test should verify that multiple instances of the basicList, subTemplateList and subTemplateMultiList Information Elements are accepted. . 3.5 Stress/Load tests - since the structured data types defined here allow modeling of complex data structures, they may be useful for stress testing both Exporting Processes and Collecting Processes. 10. IANA Considerations This document specifies several new IPFIX abstract data types, a new IPFIX Data Type Semantic, and several new Information Elements. These require the creation of two new IPFIX registries and updating the existing IPFIX Information Element registry as detailed below. 10.1. New Abstract Data Types Section 4.1. of this document specifies several new IPFIX abstract data types. Per section 6 of the IPFIX Information Model [RFC5102], new abstract data types can be added to the IPFIX Information Model. This requires creation of a new IPFIX Expires September 3, 2009 [Page 31] Internet-Draft March 2009 "abstract data types" registry at http://www.iana.org/assignments/ipfix. This registry should include all the abstract data types from section 3.1 of [RFC5102]. Abstract data types to be added to the IPFIX "abstract data types" registry are listed below. 10.1.1. basicList The type "basicList" represents a list of any Information Element used for single-valued data types. 10.1.2. subTemplateList The type "subTemplateList" represents a list of structured data, where the data type of each list element is the same and corresponds with a single Template Record. 10.1.3. subTemplateMultiList The type "subTemplateMultiList" represents a list of structured data, where the data type of list elements can be different and correspond with different template definitions. 10.2. New Data Type Semantics Section 4.2. of this document specifies a new IPFIX Data Type Semantic. Per section 3.2 of the IPFIX Information Model [RFC5102], new data type semantics can be added to the IPFIX Information Model. This requires creation of a new IPFIX "data types semantics" registry at http://www.iana.org/assignments/ipfix. This registry should include all the data type semantics from section 3.2 of [RFC5102]. Data type semantics to be added to the IPFIX "data types semantics" registry are listed below. 10.2.1. list A list is a structured data type, being composed of a sequence of elements e.g. Information Element, Template Record, etc. Expires September 3, 2009 [Page 32] Internet-Draft March 2009 10.3. New Information Elements Section 4.3. of this document specifies several new Information Elements which are to be created in the IPFIX Information Element registry located at http://www.iana.org/assignments/ipfix. New Information Elements to be added to the IPFIX Information Element registry are listed below. 10.3.1. basicList Name: basicList Description: Specifies a generic Information Element with a basicList abstract data type. For example, list of port numbers, list of interface indexes, etc. Abstract Data Type: basicList Data Type Semantics: list ElementId: XXX (to be specified) Status: current 10.3.2. subTemplateList Name: subTemplateList Description: Specifies a generic Information Element with a subTemplateList abstract data type. Abstract Data Type: subTemplateList Data Type Semantics: list ElementId: YYY (to be specified) Status: current 10.3.3. subTemplateMultiList Name: subTemplateMultiList Description: Specifies a generic Information Element with a subTemplateMultiList abstract data type. Abstract Data Type: subTemplateMultiList Data Type Semantics: list ElementId: ZZZ (to be specified) Status: current Expires September 3, 2009 [Page 33] Internet-Draft March 2009 11. Security Considerations The same security considerations as for the IPFIX Protocol [RFC5101] apply. 12. References 12.1. Normative References [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [RFC5101] Claise, B., Ed., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. 12.2. Informative References [RFC3917] Quittek, J., Zseby, T., Claise, B. Zander, S, Requirements for IP Flow Information Export, RFC 3917, October 2004. [RFC5103] Trammell, B., Boschi, E., "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008. [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, February 2009. [RFC5471] Schmoll, C., Aitken, P., Claise, B., " Guidelines for IP Flow Information Export (IPFIX) Testing", RFC 5471, February 2009. [RFC5473] Boschi, E., Mark, L., and Claise, B., "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, February 2009. Expires September 3, 2009 [Page 34] Internet-Draft March 2009 [RFC5476] Claise, B., Ed., "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, February 2009. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, February 2009. 13. Acknowledgement The authors would like to thank Zhipu Jin and Nagaraj Varadharajan for their feedback. 14. Authors' Addresses Benoit Claise Cisco Systems Inc. De Kleetlaan 6a b1 Diegem 1813 Belgium Phone: +32 2 704 5622 EMail: bclaise@cisco.com Gowri Dhandapani Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, Virigina 20171 United States Phone: +1 408 853 0480 EMail: gowri@cisco.com Stan Yates Cisco Systems Inc. 7100-8 Kit Creek Road PO Box 14987 Research Triangle Park North Carolina, 27709-4987 United States Phone: +1 919 392 8044 EMail: syates@cisco.com Expires September 3, 2009 [Page 35] Internet-Draft March 2009 Paul Aitken Cisco Systems (Scotland) Ltd. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX, United Kingdom Phone: +44 131 561 3616 EMail: paitken@cisco.com Expires September 3, 2009 [Page 36]