Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6313

Export of Structured Data in IP Flow Information Export (IPFIX)

Pages: 71
Proposed Standard
Errata
Updates:  5102
Part 4 of 4 – Pages 51 to 71
First   Prev   None

Top   ToC   RFC6313 - Page 51   prevText

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]
Top   ToC   RFC6313 - Page 52
   +------------------------+-----------------+-------------+
   | 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.
Top   ToC   RFC6313 - Page 53
   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.
Top   ToC   RFC6313 - Page 54
      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.
Top   ToC   RFC6313 - Page 55

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
Top   ToC   RFC6313 - Page 56

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: current

11.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: current

11.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
Top   ToC   RFC6313 - Page 57

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 6313

11.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 6313

11.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 6313

11.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
Top   ToC   RFC6313 - Page 58

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 6313

12. 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.
Top   ToC   RFC6313 - Page 59
   [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.
Top   ToC   RFC6313 - Page 60

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>
Top   ToC   RFC6313 - Page 61
    <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>
Top   ToC   RFC6313 - Page 62
     <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.
Top   ToC   RFC6313 - Page 63
 <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>
Top   ToC   RFC6313 - Page 64
 <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>
Top   ToC   RFC6313 - Page 65

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.
Top   ToC   RFC6313 - Page 66
   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)
Top   ToC   RFC6313 - Page 67
    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
Top   ToC   RFC6313 - Page 68
    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.
Top   ToC   RFC6313 - Page 69
   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              |
Top   ToC   RFC6313 - Page 70
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          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
Top   ToC   RFC6313 - Page 71

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