RFC 6313
Export of Structured Data in IP Flow Information Export (IPFIX)
10. Relationship with the Other IPFIX Documents
10.1. Relationship with Reducing Redundancy
"Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] describes a bandwidth saving method for exporting Flow or packet information using the IP Flow Information Export (IPFIX) protocol. It defines the commonPropertiesID Information Element for exporting Common Properties.10.1.1. Encoding Structured Data Element Using Common Properties
When Structured Data Information Elements contain repeated elements, these elements may be replaced with a commonPropertiesID Information Element as specified in [RFC5473]. The replaced elements may include the basicList, subTemplateList, and subTemplateMultiList Information Elements. This technique might help reducing the bandwidth requirements for the export. However, a detailed analysis of the gain has not been done; refer to Section 8.3 of [RFC5473] for further considerations.10.1.2. Encoding Common Properties Elements with Structured Data Information Element
Structured Data Information Element MAY be used to define a list of commonPropertiesID, as a replacement for the specifications in [RFC5473]. Indeed, the example in Figures 1 and 2 of [RFC5473] can be encoded with the specifications in this document. +----------------+-------------+---------------------------+ | sourceAddressA | sourcePortA | <Flow1 information> | +----------------+-------------+---------------------------+ | sourceAddressA | sourcePortA | <Flow2 information> | +----------------+-------------+---------------------------+ | sourceAddressA | sourcePortA | <Flow3 information> | +----------------+-------------+---------------------------+ | sourceAddressA | sourcePortA | <Flow4 information> | +----------------+-------------+---------------------------+ | ... | ... | ... | +----------------+-------------+---------------------------+ Figure 28: Common and Specific Properties Exported Together [RFC5473]
+------------------------+-----------------+-------------+ | index for properties A | sourceAddressA | sourcePortA | +------------------------+-----------------+-------------+ | ... | ... | ... | +------------------------+-----------------+-------------+ +------------------------+---------------------------+ | index for properties A | <Flow1 information> | +------------------------+---------------------------+ | index for properties A | <Flow2 information> | +------------------------+---------------------------+ | index for properties A | <Flow3 information> | +------------------------+---------------------------+ | index for properties A | <Flow4 information> | +------------------------+---------------------------+ Figure 29: Common and Specific Properties Exported Separately According to [RFC5473] +----------------+-------------+---------------------------+ | sourceAddressA | sourcePortA | <Flow1 information> | +----------------+-------------+---------------------------+ | <Flow2 information> | +---------------------------+ | <Flow3 information> | +---------------------------+ | <Flow4 information> | +---------------------------+ | ... | +---------------------------+ Figure 30: Common and Specific Properties Exported with Structured Data Information Element The example in Figure 28 could be encoded with a basicList if the <Flow information> represents a single Information Element, with a subTemplateList if the <Flow information> represents a Template Record, or with a subTemplateMultiList if the <Flow information> is composed of different Template Records. Using Structured Data Information Elements as a replacement for the techniques specified in "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" [RFC5473] offers the advantage that a single Template Record is defined. Hence, the Collector's job is simplified in terms of Template management and combining Template/Options Template Records.
However, it must be noted that using Structured Data Information Elements as a replacement for the techniques specified in "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports" only applies to simplified cases. For example, the "Multiple Data Reduction" (Section 7.1 [RFC5473]) might be too complex to encode with Structured Data Information Elements.10.2. Relationship with Guidelines for IPFIX Testing
[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 element 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. 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 2.
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.3. Relationship with IPFIX Mediation Function
The Structured Data Information Elements would be beneficial for the
export of aggregated Data Records in mediation function, as was
demonstrated with the example of the aggregated Observation Point in
Section 5.3.
11. IANA Considerations
This document specifies several new IPFIX abstract data types, a new
IPFIX Data Type Semantic, and several new Information Elements.
Two new IPFIX registries have been created, and the existing IPFIX
Information Element registry has been updated as detailed below.
11.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
in the IPFIX Information Element Data Types registry.
Abstract data types that have been added to the IPFIX Information
Element Data Types registry are listed below.
11.1.1. basicList
The type "basicList" represents a list of any Information Element
used for single-valued data types.
11.1.2. subTemplateList
The type "subTemplateList" represents a list of a structured data
type, where the data type of each list element is the same and
corresponds with a single Template Record.
11.1.3. subTemplateMultiList
The type "subTemplateMultiList" represents a list of structured data types, where the data types of the list elements can be different and correspond with different Template definitions.11.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. Therefore, the IANA IPFIX informationElementSemantics registry [IANA-IPFIX], which contains all the data type semantics from Section 3.2 of [RFC5102], has been augmented with the "list" value below.11.2.1. list
A list is a structured data type, being composed of a sequence of elements, e.g., Information Element, Template Record.11.3. New Information Elements
Section 4.3 of this document specifies several new Information Elements that have been created in the IPFIX Information Element registry [IANA-IPFIX]. New Information Elements that have been added to the IPFIX Information Element registry are listed below.11.3.1. basicList
Name: basicList Description: Specifies a generic Information Element with a basicList abstract data type. Examples include a list of port numbers, and a list of interface indexes. Abstract Data Type: basicList Data Type Semantics: list ElementId: 291 Status: current
11.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: 292 Status: current11.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: 293 Status: current11.4. New Structured Data Semantics
Section 4.4 of this document specifies a series of new IPFIX structured data type semantics, which is expressed as an 8-bit value. This requires the creation of a new "IPFIX Structured Data Types Semantics" IPFIX subregistry [IANA-IPFIX]. Entries may be added to this subregistry subject to a Standards Action [RFC5226]. Initially, this registry includes all the structured data type semantics listed below.11.4.1. undefined
Name: undefined Description: The "undefined" structured data type semantic specifies that the semantic of list elements is not specified and that, if a semantic exists, then it is up to the Collecting Process to draw its own conclusions. The "undefined" structured data type semantic is the default structured data type semantic. Value: 0xFF Reference: RFC 6313
11.4.2. noneOf
Name: noneOf Description: The "noneOf" structured data type semantic specifies that none of the elements are actual properties of the Data Record. Value: 0x00 Reference: RFC 631311.4.3. exactlyOneOf
Name: exactlyOneOf Description: The "exactlyOneOf" structured data type semantic specifies that only a single element from the structured data is an actual property of the Data Record. This is equivalent to a logical XOR operation. Value: 0x01 Reference: RFC 631311.4.4. oneOrMoreOf
Name: oneOrMoreOf Description: The "oneOrMoreOf" structured data type semantic specifies that one or more elements from the list in the structured data are actual properties of the Data Record. This is equivalent to a logical OR operation. Value: 0x02 Reference: RFC 631311.4.5. allOf
Name: allOf Description: The "allOf" structured data type semantic specifies that all of the list elements from the structured data are actual properties of the Data Record. Value: 0x03 Reference: RFC 6313
11.4.6. ordered
Name: ordered Description: The "ordered" structured data type semantic specifies that elements from the list in the structured data are ordered. Value: 0x04 Reference: RFC 631312. Security Considerations
The addition of complex data types necessarily complicates the implementation of the Collector. This could easily result in new security vulnerabilities (e.g., buffer overflows); this creates additional risk in cases where either Datagram Transport Layer Security (DTLS) is not used or if the Observation Point and Collector belong to different trust domains. Otherwise, the same security considerations as for the IPFIX protocol [RFC5101] and the IPFIX information model [RFC5102] apply.13. References
13.1. Normative References
[RFC2119] Bradner, S., "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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.13.2. Informative References
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC5103] Trammell, B. and E. Boschi, "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, March 2009. [RFC5471] Schmoll, C., Aitken, P., and B. Claise, "Guidelines for IP Flow Information Export (IPFIX) Testing", RFC 5471, March 2009. [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009. [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing Redundancy in IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. Raspall, "Sampling and Filtering Techniques for IP Packet Selection", RFC 5475, March 2009. [RFC5476] Claise, B., Ed., Johnson, A., and J. Quittek, "Packet Sampling (PSAMP) Protocol Specifications", RFC 5476, March 2009. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009. [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", <http://www.iana.org/>.14. Acknowledgements
The authors would like to thank Zhipu Jin, Nagaraj Varadharajan, Brian Trammel, Atsushi Kobayashi, and Rahul Patel for their feedback, and Gerhard Muenz, for proofreading the document.
Appendix A. Additions to XML Specification of IPFIX Information Elements and Abstract Data Types
This appendix contains additions to the machine-readable description of the IPFIX information model coded in XML in Appendices A and B in [RFC5102]. Note that this appendix is of informational nature, while the text in Section 4 (generated from this appendix) is normative. The following field definitions are appended to the IPFIX information model in Appendix A of [RFC5102]. <field name="basicList" dataType="basicList" group="structured-data" dataTypeSemantics="List" elementId="291" applicability="all" status="current"> <description> <paragraph> Represents a list of zero or more instances of any Information Element, primarily used for single-valued data types. Examples include a list of port numbers, list of interface indexes, and a list of AS in a BGP AS-PATH. </paragraph> </description> </field> <field name="subTemplateList" dataType="subTemplateList" group="structured-data" dataTypeSemantics="List" elementId="292" applicability="all" status="current"> <description> <paragraph> Represents a list of zero or more instances of a structured data type, where the data type of each list element is the same and corresponds with a single Template Record. Examples include a structured data type composed of multiple pairs of ("MPLS label stack entry position", "MPLS label stack value"), a structured data type composed of performance metrics, and a structured data type composed of multiple pairs of IP address. </paragraph> </description> </field>
<field name="subTemplateMultiList"
dataType="subTemplateMultiList"
group="structured-data"
dataTypeSemantics="List"
elementId="293" applicability="all" status="current">
<description>
<paragraph>
Represents a list of zero or more instances of
structured data types, where the data type of each list
element can be different and corresponds with
different Template definitions. Examples include, a
structured data type composed of multiple access-list
entries, where entries can be composed of different
criteria types.
</paragraph>
</description>
</field>
The following structured data type semantic definitions are appended
to the IPFIX information model in Appendix A of [RFC5102].
<structuredDataTypeSemantics>
<structuredDataTypeSemantic name="undefined" value="255">
<description>
<paragraph>
The "undefined" structured data type semantic specifies
that the semantic of list elements is not specified and
that, if a semantic exists, then it is up to the
Collecting Process to draw its own conclusions. The
"undefined" structured data type semantic is the default
structured data type semantic.
</paragraph>
</description>
</structuredDataTypeSemantic>
<structuredDataTypeSemantic name="noneOf" value="0">
<description>
<paragraph>
The "noneOf" structured data type semantic specifies
that none of the elements are actual properties of the
Data Record.
</paragraph>
</description>
</structuredDataTypeSemantic>
<structuredDataTypeSemantic name="exactlyOneOf" value="1">
<description>
<paragraph>
The "exactlyOneOf" structured data type semantic
specifies that only a single element from the structured
data is an actual property of the Data Record. This is
equivalent to a logical XOR operation.
</paragraph>
</description>
</structuredDataTypeSemantic>
<structuredDataTypeSemantic name="oneOrMoreOf" value="2">
<description>
<paragraph>
The "oneOrMoreOf" structured data type semantic
specifies that one or more elements from the list in the
structured data are actual properties of the Data
Record. This is equivalent to a logical OR operation.
</paragraph>
</description>
</structuredDataTypeSemantic>
<structuredDataTypeSemantic name="allOf" value="3">
<description>
<paragraph>
The "allOf" structured data type semantic specifies that
all of the list elements from the structured data are
actual properties of the Data Record.
</paragraph>
</description>
</structuredDataTypeSemantic>
<structuredDataTypeSemantic name="ordered" value="4">
<description>
<paragraph>
The "ordered" structured data type semantic specifies
that elements from the list in the structured data are
ordered.
</paragraph>
</description>
</structuredDataTypeSemantic>
</structuredDataTypeSemantics>
The following schema definitions are appended to the abstract data
types defined in Appendix B of [RFC5102]. This schema and its
namespace are registered by IANA at
http://www.iana.org/assignments/xml-registry/schema/ipfix.xsd.
<simpleType name="dataType">
<restriction base="string">
<enumeration value="basicList">
<annotation>
<documentation>
Represents a list of zero or more instances of
any Information Element, primarily used for
single-valued data types. Examples include a list of port
numbers, a list of interface indexes, and a list of AS in a
BGP AS-PATH.
</documentation>
</annotation>
</enumeration>
<enumeration value="subTemplateList">
<annotation>
<documentation>
Represents a list of zero or more instances of a
structured data type, where the data type of each list
element is the same and corresponds with a single
Template Record. Examples include a structured data type
composed of multiple pairs of ("MPLS label stack entry
position", "MPLS label stack value"), a structured
data type composed of performance metrics, and a
structured data type composed of multiple pairs of IP
address.
</documentation>
</annotation>
</enumeration>
<enumeration value="subTemplateMultiList">
<annotation>
<documentation>
Represents a list of zero or more instances of
structured data types, where the data type of each
list element can be different and corresponds with
different Template definitions. An example is a
structured data type composed of multiple
access-list entries, where entries can be
composed of different criteria types.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<simpleType name="dataTypeSemantics">
<restriction base="string">
<enumeration value="List">
<annotation>
<documentation>
Represents an arbitrary-length sequence of structured
data elements, either composed of regular Information
Elements or composed of data conforming to a Template
Record.
</documentation>
</annotation>
</enumeration>
</restriction>
</simpleType>
<complexType name="structuredDataTypeSemantics">
<sequence>
<element name="structuredDataTypeSemantic"
minOccurs="1" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="description" type="text"/>
</sequence>
<attribute name="name" type="string" use="required"/>
<attribute name="value" type="unsignedByte" use="required"/>
</complexType>
</element>
</sequence>
</complexType>
<element name="structuredDataTypeSemantics"
type="structuredDataTypeSemantics">
<annotation>
<documentation>
Structured data type semantics express the relationship
among multiple list elements in a structured data
Information Element.
</documentation>
</annotation>
</element>
Appendix B. Encoding IPS Alert Using Structured Data Information Elements
In this section, an IPS alert example is used to demonstrate how complex data and multiple levels of hierarchy can be encoded using Structured Data Information Elements. Also, this example demonstrates how a basicList of subTemplateLists can be used to represent semantics at multiple levels in the hierarchy. An IPS alert consists of the following mandatory attributes: signatureId, protocolIdentifier, and riskRating. It can also contain zero or more participants, and 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 attributes destinationIPv4Address and 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. Consider the example described in case study 2 of Section 5.6. The IPS alert contains participants encoded as a subTemplateList with semantic allOf. Each participant uses a basicList of subTemplateLists to represent attackers and targets. For the sake of simplicity, the alert has two participants P1 and P2. In participant P1, attacker A1 or A2 attacks target T1. In participant P2, attacker A3 attacks targets T2 and T3.
Participant P1:
(basicList, allOf,
(subTemplateList, exactlyOneOf, attacker A1, A2)
(subTemplateList, undefined, target T1)
)
Participant P2:
(basicList, allOf,
(subTemplateList, undefined, attacker A3,
(subTemplateList, allOf, targets T2, T3)
)
Alert :
(subTemplateList, allOf, Participant P1, Participant P2)
------------------------------------------------------------------
| | | participant
sigId |protocol| risk | attacker | target
| Id | Rating | IP | appId | IP | appId
------------------------------------------------------------------
1003 17 10 192.0.2.3 103 192.0.2.103 3001
192.0.2.4 104
192.0.2.5 105 192.0.2.104 4001
192.0.2.105 5001
------------------------------------------------------------------
Participant P1 contains:
Attacker A1: (IP, appId)=(192.0.2.3, 103)
Attacker A2: (IP, appId)=(192.0.2.4, 104)
Target T1: (IP, appId)= (192.0.2.103, 3001)
Participant P2 contains:
Attacker A3: (IP, appId) = (192.0.2.5, 105)
Target T2: (IP, appId)= (192.0.2.104, 4001)
Target T3: (IP, appId)= (192.0.2.105, 5001)
To represent an alert, the following Templates are defined:
Template for target (268)
Template for attacker (269)
Template for participant (270)
Template for alert (271)
alert (271)
| (signatureId)
| (protocolIdentifier)
| (riskRating)
|
+------- participant (270)
|
+------- attacker (269)
| (sourceIPv4Address)
| (applicationId)
|
+------- target (268)
| (destinationIPv4Address)
| (applicationId)
Note that the attackers are always composed of a single
applicationId, while the targets typically have multiple
applicationIds; for the sake of simplicity, this example shows only
one applicationId in the target.
Template Record for target, with the Template ID 268:
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 = 268 | Field Count = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address = 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| applicationId = 95 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: Encoding IPS Alert, Template for Target
Template Record for attacker, with the Template ID 269: 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 = 269 | Field Count = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| sourceIPv4Address = 8 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| applicationId = 95 | Field Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 32: Encoding IPS Alert, Template for Attacker Template Record for participant, with the Template ID 270: 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 = 270 | Field Count = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| basicList = 291 | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 33: Encoding IPS Alert, Template for Participant The Template Record for the participant has one basicList Information Element, which is a list of subTemplateLists of attackers and targets.
Template Record for IPS alert, with the Template ID 271: 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 = 271 | 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 = 292 | Field Length = 0xFFFF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 34: Encoding IPS Alert, Template for IPS Alert The subTemplateList in the alert Template Record contains a list of participants. The Length of basicList and subTemplateList are encoded in three bytes even though they 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 = 271 | Length = 102 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | signatureId = 1003 | protocolId=17 | riskRating=10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 |participant List Length = 91 |semantic=allOf | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | participant Template ID = 270 | 255 | P1 List Len = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 41 | semantic=allOf| P1 List Field ID = 292 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P1 List Field ID Len = 0xFFFF | 255 |P1 attacker ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List Len = 19 |sem=exactlyOne | P1 attacker Template ID = 269 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P1 attacker A1 sourceIPv4Address = 192.0.2.3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P1 attacker A1 applicationId = 103 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P1 attacker A2 sourceIPv4Address = 192.0.2.4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P1 attacker A2 applicationId = 104 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | P1 target List Len = 11 | sem=undefined | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P1 target Template ID = 268 | P1 target T1 destinationIPv4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Address = 192.0.2.103 |P1 target T1 applicationId =...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 3001 | 255 | P2 List Len = | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 41 | semantic=allOf| P2 List Field ID = 292 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2 List Field ID Len = 0xFFFF | 255 |P2 attacker ...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List Len = 11 | sem=undefined | P2 attacker Template ID = 269 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2 attacker A3 sourceIPv4Address = 192.0.2.5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2 attacker A3 applicationId = 105 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | P2 target List Len = 19 |semantic=allOf | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2 target Template ID = 268 | P2 target T2 destinationIPv4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Address = 192.0.2.104 |P2 target T2 applicationId =...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 4001 | P2 target T3 destinationIPv4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Address = 192.0.2.105 |P2 target T3 applicationId =...| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... 5001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: sem=exactlyOne represents semantic=exactlyOneOf Figure 35: Encoding IPS Alert, Data Set
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, Virginia 20171 United States Phone: +1 408 853 0480 EMail: gowri@cisco.com Paul Aitken Cisco Systems, Inc. 96 Commercial Quay Commercial Street Edinburgh, EH6 6LX United Kingdom Phone: +44 131 561 3616 EMail: paitken@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