tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6313

 
 
 

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

Part 4 of 4, p. 51 to 71
Prev RFC Part

 


prevText      Top      Up      ToC       Page 51 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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