[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 RFC 5472

 Internet Draft                                              Tanja Zseby
 Document: <draft-ietf-ipfix-as-07.txt>                 Fraunhofer FOKUS
 Expires: October 2006                                      Elisa Boschi
                                                          Nevil Brownlee
                                                           Benoit Claise
                                                           Cisco Systems
                                                                May 2006
                           IPFIX Applicability
    Status of this Memo
    By submitting this Internet-Draft, each author represents that
    any applicable patent or other IPR claims of which he or she is
    aware have been or will be disclosed, and any of which he or she
    becomes aware will be disclosed, in accordance with Section 6 of
    BCP 79.
    Internet-Drafts are working documents of the Internet
    Engineering Task Force (IETF), its areas, and its working
    groups.  Note that other groups may also distribute working
    documents as Internet-Drafts.
    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-
    Drafts as reference material or to cite them other than as "work
    in progress."
    The list of current Internet-Drafts can be accessed at
    The list of Internet-Draft Shadow Directories can be accessed at
    Copyright Notice
    Copyright (C) The Internet Society (2006).
 Zseby, Boschi, Brownlee, Claise                           [Page 1]

                      IPFIX Applicability              May 2006
    This document describes the applicability of the IP Flow
    Information Export (IPFIX) protocol for a variety of
    applications. It shows how applications can use IPFIX, describes
    the relevant information elements (IEs) and shows opportunities
    and limitations of the protocol. The document furthermore
    describes relations of the IPFIX framework to other
    architectures and frameworks.
 Zseby, Boschi, Brownlee, Claise                           [Page 2]

                      IPFIX Applicability              May 2006
 Table of Contents
    1.   Introduction.............................................4
    2.   Applications of IPFIX....................................4
    2.1  Accounting...............................................4
    2.1.1 Example.................................................5
    2.2  Traffic Profiling........................................7
    2.3  Traffic Engineering......................................7
    2.4  Network Security.........................................8
    2.5  QoS Monitoring..........................................10
    2.5.1 Correlating Events from Multiple Observation Points....11
    2.5.2 Examples...............................................11
    2.6  Inter-Domain Exchange of IPFIX data.....................13
    2.7  Export of Derived Metrics...............................13
    2.8  Summary.................................................14
    3.   Relation of IPFIX to Other Frameworks and Protocols.....14
    3.1  IPFIX and PSAMP.........................................14
    3.2  IPFIX and RMON..........................................15
    3.3  IPFIX and IPPM..........................................15
    3.4  IPFIX and AAA...........................................16
    3.4.1 Connecting via an AAA Client...........................17
    3.4.2 Connecting via an Application Specific Module (ASM)....17
    3.5  IPFIX and RTFM..........................................18
    3.5.1 Architecture...........................................18
    3.5.2 Flow Definition........................................19
    3.5.3 Configuration and Management...........................19
    3.5.4 Data Collection........................................19
    3.5.5 Data Model Details.....................................20
    3.5.6 Transport Protocol.....................................20
    3.5.7 Summary................................................20
    4.   Limitations.............................................21
    4.1  Using IPFIX for other Applications than in RFC3917......21
    4.2  Using a Different Transport Protocol than SCTP..........21
    4.3  Push vs. Pull Mode......................................21
    4.4  Template ID number......................................22
    4.5  Exporting Bidirectional Flow Information................22
    4.6  IPFIX and IPv6..........................................23
    5.   Security Considerations.................................23
    6.   Normative References....................................24
    7.   Informative References..................................24
    8.   Acknowledgements........................................26
    9.   Authors' Addresses......................................26
    10.  Full Copyright Statement................................27
    11.  Intellectual Property Statement.........................27
    12.  Copyright Statement.....................................28
    13.  Disclaimer..............................................28
 Zseby, Boschi, Brownlee, Claise                           [Page 3]

                      IPFIX Applicability              May 2006
 1. Introduction
    The IPFIX protocol defines how IP Flow information can be
    exported from routers, measurement probes or other devices. It
    is intended to provide this information as input to various
    applications. IPFIX is a general data transport protocol, easily
    extensible to suit the needs of different applications. This
    document describes how typical applications that can use the
    IPFIX protocol. It shows opportunities and limitations of the
    protocol. Furthermore, the relationship of IPFIX to other
    frameworks and architectures is described.
 2. Applications of IPFIX
    IPFIX data enables several critical applications. The IPFIX
    target applications and the requirements that originate from
    those applications are described in [RFC3917]. Those
    requirements were used as basis for the design of the IPFIX
    protocol. This section describes how these target applications
    can use the IPFIX protocol. Considerations for using IPFIX for
    other applications than described in [RFC3917] can be found in
    section 4.1.
  2.1 Accounting
    Usage based accounting is one of the major applications for
    which the IPFIX protocol has been developed. IPFIX records
    provide fine-grained measurement results for highly flexible and
    detailed resource usage accounting.
    In order to realize usage-based accounting with IPFIX the flow
    definition has to be chosen in accordance to the tariff model.
    Flows can be distinguished by various IEs (e.g. packet header
    fields) from [IPFIX-INFO]. Due to the flexible IPFIX flow
    definition, arbitrary flow-based accounting models can be
    realized without extensions to the IPFIX protocol.
    A tariff can, for instance, be based on individual end-to-end
    flows, in which case accounting can be realized with a flow
    definition determined by the quintuple consisting of source
    address (sourceIPv4Address), destination address
    (destinationIPv4Address), protocol (protocolIdentifier) and port
    numbers (e.g., udpSourcePort, udpDestinationPort). Another
    example is a class-dependent tariff (e.g. in a DiffServ
    network). In this case flows could be distinguished just by the
    DiffServ codepoint (DSCP) (ipDiffServCodePoint) and IP addresses
    (sourceIPv4Address, destinationIPv4Address). The essential
    elements needed for accounting are the number of transferred
 Zseby, Boschi, Brownlee, Claise                           [Page 4]

                      IPFIX Applicability              May 2006
    packets and bytes per flow, which can be represented by the per-
    flow counter IEs (e.g., packetTotalCount, octetTotalCount).
    For accounting purposes, it would be advantageous to have the
    ability to use IPFIX flow records as accounting input in an AAA
    infrastructure. AAA servers then could provide the mapping
    between user and flow information.
    Note that the reliability requirements defined in [RFC3917] are
    not sufficient to guarantee the level of reliability that is
    needed for many usage-based accounting systems. Particular
    reliability requirements for accounting systems are discussed in
 2.1.1 Example
    Please note: [RFC3330] demands the use of the address block for example addresses. In the example below we use
    two example networks. In order to be conformant to [RFC3330] we
    divide the given address block into two networks by subnetting
    with a 25 bit netmask ( as follows:
    Network A: ...
    Network B: ...
    Let's suppose someone has a Service Level Agreement (SLA) in a
    DiffServ network requiring accounting based on traffic volume.
    Flows are distinguished by source and destination address. The
    information to export in this case is:
        - IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO],
         with a length of 4 octets
        - IPv4 destination IP address: destinationIPv4Address in
         [IPFIX-INFO], with a length of 4 octets
        - DSCP: ipDiffServCodePoint in [IPFIX-INFO], with a length of
         1 octet
        - Number of octets of the Flow: OctetDeltaCount in [IPFIX-
         INFO], with a length of 4 octets
    The template set will look as follows:
          |         Set ID = 2            |      Length = 24 octets       |
          |       Template ID 256         |       Field Count = 4         |
          |0|    sourceIPv4Address = 8    |       Field Length = 4        |
          |0| destinationIPv4Address = 12 |       Field Length = 4        |
 Zseby, Boschi, Brownlee, Claise                           [Page 5]

                      IPFIX Applicability              May 2006
          |0|  ipDiffServCodePoint = 195  |       Field Length = 1        |
          |0|     OctetDeltaCount = 1     |       Field Length = 4        |
    The information to be exported might be as listed in the
    following example table:
    Src. IP addr. | Dst. IP addr. |  DSCP  | Octets Number
    --------------+---------------+--------+--------------    |  |   46   |   120868    |  |   46   |   310364    |  |   46   |   241239
    In the example we use Diffserv CodePoint 46, recommended for the
    Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC2598].
    The Flow Records will then look 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 = 256         |          Length = 43          |
       |                                           |
       |                                          |
       |      46       |               120868                          |
       |               |                           |
       |               |                          |
       |               |       46      |                 310364        |
       |                               |            |
       |                               |           |
       |                               |       46      |               |
       |                   241239                      |
  2.2 Traffic Profiling
 Zseby, Boschi, Brownlee, Claise                           [Page 6]

                      IPFIX Applicability              May 2006
    Measurement results reported in IPFIX records can be used for
    traffic profiling. IPFIX records captured over a long period of
    time can be used to track and anticipate network growth and
    usage. Such Information is valuable for trend analysis and
    network planning.
    The parameters of interest are determined by the profiling
    objectives. Example parameters for traffic profiling are flow
    duration, flow volume, burstiness, the distribution of used
    services and protocols, the amount of packets of a specific
    type, etc. [RFC3917].
    The distribution of services and protocols in use can be
    analyzed by configuring appropriate flows keys for flow
    discrimination. Protocols can be distinguished by the
    protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort)
    often provide information about services in use. Those flow keys
    are defined in [IPFIX-INFO]. If portnumbers are not sufficient
    for service discrimination, further parts of the packet may be
    needed. Header fields can be expressed by IEs from [IPFIX-INFO]
    Packet payload can be reported by using the IE
    ipPayloadPacketSection in [PSAMP-INFO].
    The flow duration can be calculated from the flow time stamp IEs
    defined in [IPFIX-INFO] (e.g., flowEndMicroseconds -
    flowStartMicroseconds). The number of packets and number of
    bytes of a flow are represented in the per-flow counter IEs
    (e.g., packetTotalCount, octetTotalCount). The burstiness of a
    flow can be calculated from the flow volume measured at
    different time intervals.
  2.3 Traffic Engineering
    Traffic engineering aims at the optimization of network resource
    utilization and traffic performance [RFC2702]. Typical
    parameters are link utilization, load between specific network,
    nodes, number, size and entry/exit points of active flows and
    routing information [RFC3917].
    Size of flows in packets and bytes can be reported by IEs
    packetTotalCount, octetTotalCount. Link utilization can be
    reported by using a coarse grained flow definition (e.g. based
    on identifier IEs such as egressInterface or ingressInterface)
    and per-flow counter IEs (e.g. packetTotalCount,
    octetTotalCount) defined in [IPFIX-INFO].
    The load between specific network nodes can be reported in the
    same way if one interface of a network node receives only
 Zseby, Boschi, Brownlee, Claise                           [Page 7]

                      IPFIX Applicability              May 2006
    traffic from exactly one neighbor node (as usually the case). If
    the ingress interface is not sufficient for an unambiguous
    identification of the neighbor node, sub-IP header fields IEs
    (like sourceMacAddress) can be added as flow keys.
    The IE observedFlowTotalCount provides the number of all flows
    exported for the observation domain since the last
    initialization of the metering process [IPFIX-INFO]. If this IE
    is exported at subsequent points in time, one can derive the
    number of active flows in a specific time interval from the
    difference of the reported counters. The configured flow
    termination criteria have to be taken into account to interpret
    that numbers correctly.
    Entry and exit points can be derived from flow records if
    metering processes are installed at all edges of the network and
    results are mapped in accordance to flow keys. For this and
    other analysis methods that require the mapping of records from
    different observation points, the same flow keys should be used
    at all observation points. The path that packets take through a
    network can be investigated by using hash-based sampling
    techniques as described in [DuGr00] and [PSAMP-TECH]. For this
    IEs from [PSAMP-INFO] are needed.
    Neither [IPFIX-INFO] nor [PSAMP-INFO] defines IEs suitable for
    exporting routing information.
  2.4 Network Security
    Attack and intrusion detection are among the IPFIX target
    applications described in [RFC3917]. Due to the enormous amount
    of different network attack types, only general requirements
    could be addressed in [RFC3917].
    IPFIX can export flow information for arbitrary flow definitions
    as defined in [IPFIX-PROTO]. Packet information can be exported
    with IPFIX by using the additional information elements
    described in [PSAMP-INFO]. With this theoretically all
    information about traffic in the network at IP layer and above
    is accessible. This data can be used either directly to detect
    anomalies or can provide the basis for further post processing
    to generate more complex attack detection metrics.
    Depending on the attack type different metrics are useful. A
    sudden increase of traffic load can be a hint that an attack has
    been launched. The overall traffic at an observation point can
    be monitored using per-flow counter IEs like packetTotalCount,
    octetTotalCount as described in 2.3. The number of active flows
 Zseby, Boschi, Brownlee, Claise                           [Page 8]

                      IPFIX Applicability              May 2006
    can be monitored by regular reporting of the
    A sudden increase of flows from different sources to one
    destination may be caused by an attack on a specific host or
    network node using spoofed addresses. Many flows to the same
    machine but on different ports or many flows to the same port
    and different machines may be an indicator for vertical or
    horizontal port scanning activities. An unusual ratio of TCP-SYN
    to TCP-FIN packets can refer to SYN-flooding. Worms may leave
    signatures in traffic patterns.
    The amount of metrics useful for attack detection is as diverse
    as attack patterns themselves. Attackers adapt rapidly to
    circumvent detection methods and try to hide attack patterns
    using slow or stealth attacks. Furthermore, unusual traffic
    patterns are not always caused by malicious activities. A sudden
    traffic increase may be caused by legitimate users who seek
    access to a recently published content. Strange traffic patterns
    may also be caused by mis-configuration.
    The difficult task is the separation of good from bad packets to
    prepare and launch counteraction. This may require a deeper look
    into packet content by using further header field IEs from
    [IPFIX-INFO] and/or packet payload from IE
    ipPayloadPacketSection in [PSAMP-INFO]. Multi-step analysis
    techniques may be useful, e.g., to launch an in-depth analysis
    (e.g. based on packet information) in case the flow information
    shows suspicious patterns. In order to supervise traffic to a
    specific host or network node one has to apply filtering methods
    as those described in [PSAMP-TECH].
    Mapping the two directions of a communication is often useful
    for checking correct protocol behavior (see section 4.5). A
    correlation of IPFIX data from multiple observation points (see
    section 2.5.1) allows assessing the propagation of an attack and
    can help to locate its source.
    The integration of previous measurement results helps to review
    traffic changes over time for detection of traffic anomalies and
    provides the basis for forensic analysis. A standardized storage
    format for IPIFX data would support the offline analysis of data
    from different operators.
    Nevertheless, capturing full packet traces at all observation
    points in the network is not viable due to resource limitations
    and privacy concerns. Therefore metrics should be chosen wisely
    to allow a solid detection with minimal resource consumption.
 Zseby, Boschi, Brownlee, Claise                           [Page 9]

                      IPFIX Applicability              May 2006
    Resources can be saved for instance by using coarser grained
    flow definitions, reporting pre-processed metrics (e.g. with
    additional information elements) or deployment of sampling
    Detecting security incidents in real-time often requires the
    pre-processing of data already at the measurement device.
    Immediate data export in case of a potential incident is
    desired. IPIFX supports such source-triggered exporting of
    information due to the push model approach. Nevertheless,
    further exporting criteria have to be implemented to export
    IPFIX records upon incident detection events and not only upon
    flow end or fixed time intervals.
    Security incidents can become a threat to IPFIX processes
    themselves (see also security considerations in [IPFIX-PROTO]).
    If an attack generates a large amount of flows (e.g. by sending
    packets with spoofed addresses or simulating flow termination)
    exporting and collecting process may get overloaded by the
    immense amount of records that are exported. A flexible
    deployment of packet or flow sampling methods can prevent the
    exhaustion of resources.
    Intrusion detection would profit from the combination of IPFIX
    functions with AAA functions (see section 3.4). Such an
    interoperation enables further means for attacker detection,
    advanced defense strategies and secure inter-domain cooperation.
  2.5 QoS Monitoring
    QoS monitoring is one target application of the IPFIX protocol
    [RFC3917]. QoS monitoring is the passive observation of the
    transmission quality for single flows or traffic aggregates in
    the network. One example of its use is the validation of QoS
    guarantees in service level agreements (SLAs). Typical QoS
    parameters are loss [RFC2680], one-way [RFC2679] and round-trip
    delay [RFC2681] and delay variation [RFC3393]. The calculation
    of those QoS metrics requires per-packet processing. Reporting
    packet information with IPFIX is possible by simply considering
    a single packet as flow. [IPFIX-PROTO] also allows the reporting
    of multiple identical information elements in one flow record.
    Using this feature for reporting information about multiple
    packets in one record would require additional agreement on
    semantics regarding the order of information elements (e.g.
    which timestamp belongs to which packet payload in a sequence of
    information elements). [PSAMP-INFO] defines useful additional
    information elements for exporting per packet information with
 Zseby, Boschi, Brownlee, Claise                           [Page 10]

                      IPFIX Applicability              May 2006
 2.5.1 Correlating Events from Multiple Observation Points
    Some QoS metrics require the correlation of data from multiple
    observation points. For this the clocks of the involved metering
    processes must be synchronized. Furthermore, it is necessary to
    recognize that the same packet was observed at different
    observation point.
    This can be done by capturing parts of the packet content
    (packet header and/or parts of the payload) that do not change
    on the way to the destination. Based on the packet content it
    can be recognized when the same packet arrived at another
    observation point. To reduce the amount of measurement data a
    unique packet ID can be calculated from the packet content e.g.
    by using a CRC or hash function instead of transferring and
    comparing the unprocessed content. Considerations on collision
    probability and efficiency of using such packet IDs are
    described in [GrDM98, DuGr00, ZsZC01].
    IPFIX allows the reporting of several IP and transport header
    fields (see section 5.3 and 5.4 in [IPFIX-INFO]). Using only
    those fields for packet recognition or ID generation can be
    sufficient in scenarios where those header fields vary a lot
    among subsequent packets, where a certain amount of packet ID
    collisions is tolerable or where packet IDs need to be unique
    only for a small time interval.
    For including packet payload information the information element
    ipPayloadPacketSection defined in [PSAMP-INFO] can be used. The
    information element ipHeaderPacketSection can also be used. But
    header fields that can change on the way from source to
    destination have to be excluded from the packet ID generation,
    because they may differ at different observation points.
    For reporting packet IDs generated by a CRC or hash function the
    information element digestHashValue defined in [PSAMP-INFO] can
    be used.
 2.5.2 Examples
    The following examples show which information elements need to
    be reported by IPFIX to generate specific QoS metrics. As an
    alternative the metrics can be generated directly at the
    exporter and IPIFX can be used to export the metrics (see
    section 2.7) RTT measurements with packet pair matching (single-point)
 Zseby, Boschi, Brownlee, Claise                           [Page 11]

                      IPFIX Applicability              May 2006
    The passive measurement of round-trip-times (RTT) can be
    performed by using packet pair matching techniques as described
    in [Brow00]. For the measurements, request/response packet pairs
    from protocols such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK,
    DATA/ACK) are utilized to passively observe the RTT [Brow00].
    This technique requires the correlation of data from both
    Required information elements per packet (DNS example):
    - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO]
    - DNS header: ipPayloadPacketSection [PSAMP-INFO]
    Required functions:
    - Recognition of request/response packet pairs
    - Requires information elements from [PSAMP-INFO]
    - observationTimeMicroseconds    can    be    substituted    by
       flowStartMicroseconds [IPFIX-INFO], because a single packet
       can be represented as a flow.
    - If  time  values  with  a  higher  granularity  are  needed
       observationTimeNanoseconds can be used. One-way Delay Measurements (multi-point)
    Passive one-way-delay measurements require the collection of
    data at two observation points. The recognition of packets at
    the second observation point can be based on parts of the packet
    content directly. A more efficient way is to use a packet ID
    (generated from packet content).
    Required information elements per packet (with packet ID):
    - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO]
    - Packet ID: digestHashValue [PSAMP-INFO]
    Required functions:
    - packet ID generation
    - delay calculation (from arrival times at the two observation
    - Requires information elements from [PSAMP-INFO]
    - observationTimeMicroseconds    can    be    substituted    by
       flowStartMicroseconds [IPFIX-INFO], because a single packet
       can be represented as a flow.
    - If  time  values  with  a  higher  granularity  are  needed
       observationTimeNanoseconds can be used.
 Zseby, Boschi, Brownlee, Claise                           [Page 12]

                      IPFIX Applicability              May 2006
    - The amount of content used for ID generation influences the
       number of collisions (different packets that map to the same
       ID)  that  can  occur.  Investigations  on  this  and  other
       considerations  on  packet  ID  generation  can  be  found  in
       [GrDM98], [DuGr00], and [ZsZC01].
  2.6 Inter-Domain Exchange of IPFIX data
    IPFIX data can be used to share information with neighbor
    providers. A few recommendations should to be considered if
    IPFIX records travel over the public Internet compared to its
    usage within a single domain. First of all, security threats are
    higher if data travels over the public Internet. Protection
    against disclosure or manipulation of data is even more
    important than for intra-domain usage. Therefore IPsec or
    Transport Layer Security (TLS) should be used as described in
    Furthermore data transfer should be congestion-aware in order to
    allow untroubled co-existence with other data flows. That means
    transport over SCTP or TCP is required.
    Some ISPs are still reluctant to share information due to
    concerns that competing ISPs might exploit network information
    from neighbor providers to strengthen their own position in the
    market. Nevertheless, technical needs have already triggered the
    exchange of data in the past (e.g. exchange of routing
    information by BGP). The need to provide inter-domain guarantees
    is one big incentive to increase inter-domain cooperation. The
    necessity to defend networks against current and future threats
    (denial of service attacks, worm distributions, etc.) will
    hopefully increase the willingness to exchange measurement data
    between providers.
  2.7  Export of Derived Metrics
    The IPFIX protocol is used to transport flow and packet
    information to provide the input for the calculation of a
    variety metrics (e.g. for QoS validation or attack detection).
    IPFIX can also be used to transfer these metrics directly, e.g.
    if the metric calculation is co-located with measurement and
    exporting process.
    It doesn't matter which measurement and post-processing
    functions are applied to generate a specific metric. IPFIX can
    be used to transport the results from passive and active
    measurements and from post-processing operations. For the
 Zseby, Boschi, Brownlee, Claise                           [Page 13]

                      IPFIX Applicability              May 2006
    reporting of derived metrics additional information elements
    need to be defined.
  2.8 Summary
    The following table shows an overview of the information
    elements required for the target applications described in
    [RFC3917] (M-mandatory, R-recommended, O-optional).
    | Application |[IPFIX-INFO]| [PSAMP-INFO] | additional IEs  |
    | Accounting  |     M      |      -       |       -         |
    | Traffic     |     M      |      O       |       -         |
    | Profiling   |            |              |                 |
    | Traffic     |     M      |      -       |       O         |
    | Engineering |            |              | (routing info)  |
    | Attack      |     M      |      R       |       R         |
    | Detection   |            |              |(derived metrics)|
    | QoS         |     M      |      M       |       O         |
    | Monitoring  |            |(most metrics)|(derived metrics)|
    For accounting the IEs in [IPFIX-INFO] are sufficient. For
    traffic profiling additionally IEs from [PSAMP-INFO] can be
    useful to gain more insight into the traffic. For traffic
    engineering flow information from [IPFIX-INFO] is sufficient but
    it would profit from routing information, which could be
    exported by IPFIX. Attack detection usually profits from further
    insight into the traffic. This can be achieved with IEs from
    [PSAMP-INFO]. Furthermore the reporting of derived metrics in
    additional IEs would be useful. Most QoS metrics require the use
    of IEs from [PSAMP-INFO]. IEs from [PSAMP-INFO]are also useful
    for the mapping of results from different observation points as
    described in section 2.5.1.
 3. Relation of IPFIX to Other Frameworks and Protocols
  3.1 IPFIX and PSAMP
    PSAMP defines packet selection methods, their configuration at
    routers and probes and the reporting of packet information.
    PSAMP uses IPIFX as basis for exporting packet information
    [PSAMP-PROTO]. [PSAMP-INFO] describes further information
 Zseby, Boschi, Brownlee, Claise                           [Page 14]

                      IPFIX Applicability              May 2006
    elements for exporting packet information and reporting
    configuration information.
    The main difference between IPFIX and PSAMP is that IPFIX
    addresses the export of flow records whereas PSAMP addresses the
    export of packet records. Furthermore, PSAMP explicitly
    addresses remote configuration. It defines a MIB for the
    configuration of packet selection processes. Remote
    configuration is not (yet) addressed in IPFIX, but one could
    consider extending the PSAMP MIB to also allow configuration of
    IPFIX processes.
  3.2 IPFIX and RMON
    RMON [RFC3577] is a widely used monitoring system that gathers
    traffic data from RMON Agents in network devices in a general
    way using SNMP. The RMON MIB is divided into sections, each
    section providing different monitoring functions.  For example,
    the 'Hosts' section gathers statistics for hosts which are
    active on the network being monitored.
    RMON has three MIBs that deal with flow information:
    - The Application Performance Measurement MIB (APM-MIB)
       [RFC3729] has a complex system for tracking user application
       performance, with flow reporting and SLA threshold
       notification-trigger configuration, and persistence across
       DHCP lease expirations. It requires full RMON2-MIB
       protocolDirTable implementation.
    - The Transport Performance Metrics MIB (TPM-MIB) [RFC4150]
       breaks out the APM-MIB user flow data into statistics based on
       the IPPM metrics. It requires APM-MIB and RMON2-MIB.
    - The Synthetic Sources for Performance Monitoring Algorithms
       MIB (SSPM-MIB) [RFC4149] is used to configure and run packet
       and flow generators for performance testing purposes.  It
       requires RMON2-MIB.
  3.3 IPFIX and IPPM
    The IPFIX protocol can be used to carry IPPM network performance
    metrics or information that can be used to calculate those
    metrics (see sections 2.5 and 2.7).
  3.4 IPFIX and AAA
 Zseby, Boschi, Brownlee, Claise                           [Page 15]

                      IPFIX Applicability              May 2006
    AAA defines a protocol and architecture for authentication,
    authorization and accounting for service usage [RFC2903]. The
    DIAMETER protocol [RFC3588] is used for AAA communication, which
    is needed for network access services (Mobile IP, NASREQ, and
    ROAMOPS). The AAA architecture [RFC2903] provides a framework
    for extending AAA support to other services. DIAMETER defines
    the exchange of messages between AAA entities, e.g. between AAA
    clients at access devices and AAA servers, and among AAA
    servers. DIAMETER is used for the transfer of accounting
    records. In order to form accounting records for usage-based
    accounting measurement data from the network is required. IPFIX
    defines a protocol to export such data from routers, measurement
    probes and other devices. Therefore it looks promising to
    connect those two architectures.
    As shown in section 2.1 accounting can be realized without an
    AAA infrastructure. Accounting applications can directly
    incorporate an IPFIX collecting process to receive IPFIX records
    with information about the transmitted volume. Nevertheless, if
    an AAA infrastructure is in place, the cooperation between IPFIX
    and AAA provides many valuable synergistic benefits. IPFIX
    records can provide the input for AAA accounting functions and
    provide the basis for the generation of DIAMETER accounting
    records. Further potential features include the mapping of a
    user ID to flow information (by using authentication
    information) or facilitating the secure authorized exchange of
    DIAMETER accounting records with neighbor domains. The last
    feature is especially useful in roaming scenarios where the user
    connects to a foreign network and the home provider generates
    the invoice.
    Coupling an IPFIX collecting process with AAA functions has also
    high potential for intrusion and attack detection. AAA controls
    network access and maintains data about users and nodes. AAA
    functions can help to identify the source of malicious traffic.
    They are able to deny access to suspicious users or nodes.
    Therefore coupling those functions with an IPFIX collecting
    process can provide an efficient defense against network
    attacks. Sharing IPFIX records (either directly or encapsulated
    in DIAMETER) with neighbor providers allows an efficient inter-
    domain attack detection. The AAA infrastructure can also be used
    to configure measurement functions in the network as proposed in
    Two possibilities exist to connect IPFIX and AAA:
    - Connecting via an AAA Client
    - Connecting via an Application Specific Module (ASM)
 Zseby, Boschi, Brownlee, Claise                           [Page 16]

                      IPFIX Applicability              May 2006
    Both are explained in the following sections. The approaches
    only require few additional functions. They do not require any
    changes to IPFIX or DIAMETER.
 3.4.1 Connecting via an AAA Client
    One possibility of connecting IPFIX and AAA is to run an AAA
    client on the IPFIX collector. This client can generate DIAMETER
    accounting messages and send them to an AAA server. The mapping
    of the flow information to a user ID can be done in the AAA
    server by using data from the authentication process. DIAMETER
    accounting messages can be sent to the accounting application or
    to other AAA servers (e.g. in roaming scenarios).
           +---------+  DIAMETER    +---------+
           |  AAA-S  |------------->|  AAA-S  |
           +---------+              +---------+
                | DIAMETER
         |  |  AAA-C |  |
         +  +--------+  |
         |              |
         |  Collector   |
                | IPFIX
          |  Exporter  |
    Figure 2: IPFIX collector connects to AAA server via AAA client
 3.4.2 Connecting via an Application Specific Module (ASM)
    Another possibility is to directly connect the IPFIX collector
    with the AAA server via an application specific module (ASM).
    Application specific modules have been proposed by the IRTF AAA
    architecture research group (AAARCH) in [RFC2903]. They act as
    an interface between AAA server and service equipment. In this
    case the IPFIX collector is part of the ASM. The ASM acts as an
    interface between the IPFIX protocol and the input interface of
    the AAA server. The ASM translates the received IPFIX data into
    an appropriate format for the AAA server. The AAA server then
 Zseby, Boschi, Brownlee, Claise                           [Page 17]

                      IPFIX Applicability              May 2006
    can add information about the user ID and generate a DIAMETER
    accounting record. This accounting record can be sent to an
    accounting application or to other AAA servers.
           +---------+  DIAMETER    +---------+
           |  AAA-S  |------------->|  AAA-S  |
           +---------+              +---------+
        |     ASM          |
        |  +------------+  |
        |  |  Collector |  |
                | IPFIX
          |  Exporter  |
    Figure 3: IPFIX connects to AAA server via ASM
  3.5 IPFIX and RTFM
    The Real-time Traffic Flow Measurement (RTFM) working group
    defined an architecture for flow measurement [RFC2722]. This
    section compares the Real-time Traffic Flow Measurement (RTFM)
    framework with the IPFIX framework.
 3.5.1   Architecture
    The RTFM architecture is very similar to the IPFIX architecture.
    It defines meter, meter reader and a manager as building blocks
    of the measurement architecture. The manager configures the
    meter and the meter reader collects data from the meter.
    In RTFM the building blocks communicate via SNMP.
    The IPFIX architecture [IPFIX-ARCH] defines metering, exporting
    and collecting processes. IPFIX speaks about processes instead
    of devices to clarify that multiple of those processes may be
    collocated on the same machine.
    Both definitions do not contradict each other. One could see the
    metering process as part of the meter and the collecting process
    as part of the meter reader.
    One difference is that IPFIX currently does not define a
    managing process, because remote configuration was at least
    initially out of scope for the working group.
 Zseby, Boschi, Brownlee, Claise                           [Page 18]

                      IPFIX Applicability              May 2006
 3.5.2    Flow Definition
    RTFM and IPFIX both consider flows as a group of packets which
    share a common set of properties. A flow is completely specified
    by that set of values, together with a termination criterion
    (like inactivity timeout).
    A difference is that RTFM defines flows as bidirectional. An
    RTFM meter matches packets from B to A and A to B as separate
    parts of a single flow, and maintains two sets of packet and
    byte counters, one for each direction.
    IPFIX does not explicitly state whether flows are uni- or
    bidirectional. Nevertheless information elements for describing
    flow properties were defined only for one direction in [IPFIX-
    INFO]. Nevertheless, there are several solutions for reporting
    bi-directional flow information (see section 4.5).
 3.5.3   Configuration and Management
    In RTFM, remote configuration is the only way to configure a
    meter. This is done by using SNMP and a specific Meter MIB [RFC
    2720]. The IPFIX group currently does not address IPFIX remote
    IPFIX metering processes export the layout of data within their
    templates, from time to time. IPFIX collecting processes use
    that template information to determine how they should interpret
    the IPFIX flow data they receive.
 3.5.4   Data Collection
    One major difference between IPFIX and RTFM is the data
    collection model. RTFM retrieves data in pull mode whereas IPFIX
    uses a push mode model to send data to collecting processes.
    An RTFM meter reader pulls data from a meter by using SNMP. SNMP
    security on the meter determines whether a reader is allowed to
    pull data from it. An IPFIX exporting process is configured to
    export records to a specified list of IPFIX collecting
    processes. The condition when to send IPFIX records (e.g. flow
    termination) has to be configured in the exporting or metering
 3.5.5   Data Model Details
 Zseby, Boschi, Brownlee, Claise                           [Page 19]

                      IPFIX Applicability              May 2006
    RTFM defines all its attributes in the RTFM Meter MIB [RFC
    2720]. IPFIX information elements are defined in [IPFIX-INFO].
    RTFM uses continuously-incrementing 64-bit counters for the
    storage of the number of packets of a flow. The counters are
    never reset and just wrap back to zero if the maximum value is
    exceeded. Flows can be read at any time. The difference between
    counter readings gives the counts for activity in the interval
    between readings.
    IPFIX allows absolute (totalCounter) and relative counters
    (deltaCounter) [IPFIX-INFO]. The totalCounter is never reset and
    just wraps to zero if values are too large, exactly as the
    counters used in RTFM. The deltaCounter is reset to zero when
    the associated flow record is exported.
 3.5.6   Transport Protocol
    RTFM has a standards-track Meter MIB [RFC 2720], which is used
    both to configure a meter and to store metering results.  The
    MIB provides a way to read lists of attributes with a single
    Object Identifier (called a 'package'), which reduces the SNMP
    overhead for flow data collection. SNMP, of course, normally
    uses UDP as its transport protocol. Since RTFM requires a
    reliable flow data transport system, an RTFM meter reader must
    time out and resend unanswered SNMP requests. Apart from being
    clumsy, this can limit the maximum data transfer rate from meter
    to meter reader.
    IPFIX is designed to work over a variety of different transport
    protocols.  SCTP [RFC2960] and SCTP-PR [RFC3758] are mandatory.
    UDP and TCP are optional.  In addition, the IPFIX protocol
    encodes data much more efficiently than SNMP does, hence IPFIX
    has lower data transport overheads than RTFM.
 3.5.7   Summary
    IPFIX exports flow information in push model by using SCTP, TCP
    or UDP. It currently does not address remote configuration. RTFM
    data collection is using the pull model and runs over SNMP. RTFM
    addresses remote configuration which also runs over SNMP. Both
    frameworks allow a very flexible flow definition, although RTFM
    is based on a bi-directional flow definition.
 4. Limitations
 Zseby, Boschi, Brownlee, Claise                           [Page 20]

                      IPFIX Applicability              May 2006
    The goal of this section is to show the limitations of IPFIX and
    to give advice where not to use IPFIX or in which cases
    additional considerations are required.
  4.1 Using IPFIX for other Applications than in RFC3917
    IPFIX provides a generic export mechanism. Due to its template
    based structure, it is a quite flexible protocol. Network
    operators and users may want to use it also for other
    applications than those described in [RFC 3917].
    Apart from sending raw flow information it can be used to send
    aggregated or post-processed data. For this new templates and
    information elements can be defined if needed. Due to its push
    mode operation IPFIX is also suited to send network initiated
    events like alarms and other notifications. It can be used for
    exchanging information among network nodes to autonomously
    improve network operation.
    Nevertheless, the IPFIX design is based on the requirements that
    originate only from the target applications stated in [RFC
    3917]. Using IPFIX for other purposes requires a careful
    checking of IPFIX capabilities against application requirements.
    Only with this, can one decide whether IPFIX is a suitable
    protocol to meet the needs of a specific application.
  4.2 Using a Different Transport Protocol than SCTP
    SCTP is the preferred protocol for IPFIX, i.e. a conforming
    implementation must work over SCTP. Although IPFIX can also work
    over TCP or UDP, both protocols have drawbacks [IPFIX-PROTO].
    Users should make sure they have good reasons befor using
    protocols other than SCTP in a specific environment.
  4.3 Push vs. Pull Mode
    IPFIX works in push mode. That means IPFIX records are
    automatically exported without waiting for a request.
    The responsibility for initiating a data export lies with the
    exporting process.
    Criteria for exporting data need to be configured at the
    exporting process. Therefore push mode has more benefits if the
    trigger for data export is related to events at the exporting
    process (e.g. flow termination, memory shortage due to large
    amount of flows, etc.). If the protocol used pull mode, the
    exporting process would need to wait for a request to send the
 Zseby, Boschi, Brownlee, Claise                           [Page 21]

                      IPFIX Applicability              May 2006
    data. With push mode it can send data immediately e.g. before
    memory shortage would require a discarding of data.
    With push mode one can prevent the overloading of resources at
    the exporting process by simply exporting the information as
    soon as certain thresholds are about to exceed. Therefore
    exporting criteria are often related to traffic characteristics
    (e.g. flow timeout) or resource limitations (e.g. size of flow
    cache). But traffic characteristics are usually quite dynamic
    and often impossible to predict. If those are used to trigger
    flow export, the exporting rate and the resource consumption for
    flow export becomes variable and unpredictable.
    Pull mode has advantages if the trigger for data export is
    related to events at the collecting process (e.g. a specific
    application requests immediate input).
    In a pull mode, a request could simply be forwarded to the
    exporting process. In a push mode, the exporting configuration
    must be changed to trigger the export of the requested data.
    Furthermore, with pull mode one can prevent the overloading of
    the collecting process by the arrival of more records than it
    can process.
    Whether this is a relevant drawback depends on the flexibility
    of the IPFIX configuration and how IPFIX configuration rules are
  4.4 Template ID number
    The IPFIX specification limits the different template ID numbers
    that can be assigned to the newly generated template records in
    an observation domain. In particular, template IDs up to 255 are
    reserved for Template or option sets (or other sets to be
    created) and template IDs from 256 to 65535 are assigned to data
    sets. In the case of many exports requiring many different
    templates, the set of Template IDs could be exhausted.
  4.5 Exporting Bidirectional Flow Information
    Although IPFIX does not explicitly state that flows are
    unidirectional, information elements that describe flow
    characteristics are defined only for one direction in [IPFIX-
    INFO]. [IPFIX-PROTO] allows the reporting of multiple identical
    information elements in one flow record. With this information
    elements for forward and reverse direction can be reported in
    one flow record.
 Zseby, Boschi, Brownlee, Claise                           [Page 22]

                      IPFIX Applicability              May 2006
    But this is not sufficient. Using this feature for reporting
    bidirectional flow information would require an agreement on the
    semantic of information elements (e.g. first counter is counter
    for the forward direction, second counter for reverse
    Another option is to use two adjacent flow records to report
    both directions of a bidirectional flow separately. This
    approach requires additional means for mapping those records and
    is quite inefficient due to the redundant reporting of flow
  4.6 IPFIX and IPv6
    There are two issues to consider:
    - Generation and reporting of IPFIX records about IPv6 traffic
    - Exporting IPFIX records over IPv6
    The generation and reporting of IPFIX records about IPv6 traffic
    is possible as appropriate information elements exist in [IPFIX-
    Exporting IPFIX records over IPv6 is not explicitly addressed in
    [IPFIX-PROTO]. Since IPFIX runs over SCTP, SCTP-PR, UDP or TCP,
    it is trivial to run IPFIX over IPv6 networks, provided that the
    transport protocol being used to carry IPFIX is running on the
    IPv6 network.
 5. Security Considerations
    This document describes the usage of IPFIX in various scenarios.
    Security requirements for IPFIX target applications and security
    considerations for IPFIX are addressed in [RFC3917] and [IPFIX-
    PROTO]. Those requirements have to be met for the usage of
    IPFIX. To our current knowledge, the usage scenarios proposed in
    section 2 do not induce further security hazards.
    Section 3 of this document describes how IPFIX can be used in
    combination with other frameworks. New security hazards can
    arise when two individually secure frameworks are combined. For
    the combination of AAA with IPFIX an application specific module
    (ASM) or an IPFIX collector can function as transit point for
    the messages. It has to be ensured that at this point the
    applied security mechanisms (e.g. encryption of messages) are
 Zseby, Boschi, Brownlee, Claise                           [Page 23]

                      IPFIX Applicability              May 2006
 6. Normative References
    [IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, "Information Model
                  for IP Flow Information Export", Internet Draft
                  <draft-ietf-ipfix-info-07>, work in progress, May
    [IPFIX-PROTO] B. Claise (Editor), "IPFIX Protocol Specification",
                  Internet Draft <draft-ietf-ipfix-protocol-21.txt>,
                  work in progress, April 2006
    [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise,
                  "Information Model for Packet Sampling Exports",
                  Internet Draft <draft-ietf-psamp-info-04.txt>, work
                  in progress, March 2006
    [RFC3917]    J. Quittek, T. Zseby, B. Claise, S. Zander,
                  "Requirements for IP Flow Information Export", RFC
                  3917, October 2004
 7. Informative References
    [Brow00]     Nevil Brownlee, "Packet Matching for NeTraMet
    [DuGr00]     Nick Duffield, Matthias Grossglauser, "Trajectory
                  Sampling for Direct Traffic Observation",
                  Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden,
                  August 28 - September 1, 2000
    [GrDM98]     Ian D. Graham, Stephen F. Donnelly, Stele Martin,
                  Jed Martens, John G. Cleary, "Nonintrusive and
                  Accurate Measurement of Unidirectional Delay and
                  Delay Variation on the Internet", INET'98, Geneva,
                  Switzerland, 21-24 July, 1998
    [IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek,
                  "Architecture for IP Flow Information Export",
                  Internet Draft <draft-ietf-ipfix-architecture-
                  08.txt>, work in progress, March 2005
    [PSAMP-PROTO] Benoit Claise (Ed.), Packet Sampling (PSAMP)
                  Protocol Specifications, Internet Draft <draft-
                  ietf-psamp-protocol-04.txt>, work in progress,
                  March 2006
 Zseby, Boschi, Brownlee, Claise                           [Page 24]

                      IPFIX Applicability              May 2006
    [PSAMP-TECH]  T. Zseby, M. Molina, N. Duffield, S. Niccolini, F.
                  Raspall, "Sampling and Filtering Techniques for IP
                  Packet Selection" Internet Draft <draft-ietf-psamp-
                  sample-tech-07.txt>, work in progress, July 2005
    [RFC2598]    V. Jacobson, K. Nichols, K. Poduri, "An Expedited
                  Forwarding PHB", RFC 2598, June 1999
    [RFC2679]    G. Almes, S. Kalidindi, M. Zekauskas, "A One-way
                  Delay Metric for IPPM", RFC 2679, September 1999
    [RFC2680]    G. Almes, S. Kalidindi, M. Zekauskas, "A One-way
                  Packet Loss Metric for IPPM",RFC 2680, September
    [RFC2681]    G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip
                  Delay Metric for IPPM", RFC 2681, September 1999
    [RFC2702]    D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J.
                  McManus, "Requirements for Traffic Engineering Over
                  MPLS", RFC 2702, September 1999
    [RFC2722]    Brownlee, N., Mills, C., G. Ruth, "Traffic Flow
                  Measurement: Architecture", RFC 2722, October 1999
    [RFC2903]    C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D.
                  Spence, "Generic AAA Architecture", RFC 2903,
                  August 2000
    [RFC2960]    R. Stewart (ed.) "Stream Control Transmission
                  Protocol", RFC 2960, October 2000
    [RFC2975]    B. Aboba, J. Arkko, D. Harrington, "Introduction to
                  Accounting Management", RFC 2975, October 2000
    [RFC3330]    IANA, "Special-Use IPv4 Addresses", RFC 3330
                  September 2002
    [RFC3334]    T. Zseby, S. Zander, G. Carle, "Policy-Based
                  Accounting", RFC 3334, October 2002
    [RFC3393]    C. Demichelis, P. Cimento, "IP Packet Delay
                  Variation Metric for IPPM", RFC 3393, November 2002
    [RFC3577]    S. Waldbusser, R. Cole, C. Kalbfleisch,
                  D.Romascanu, "Introduction to the Remote Monitoring
                  (RMON) Family of MIB Module", RFC 3577, August 2003
 Zseby, Boschi, Brownlee, Claise                           [Page 25]

                      IPFIX Applicability              May 2006
    [RFC3588]    P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J.
                  Arkko, "Diameter Base Protocol", RFC 3588,
                  September 2003
    [RFC3729]    S. Waldbusser, "Application Performance Measurement
                  MIB", RFC 3729, March 2004
    [RFC3758]    R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P.
                  Conrad, "Stream Control Transmission Protocol
                  (SCTP) Partial Reliability Extension", RFC 3758,
                  May 2004
    [RFC4149]    C. Kalbfleisch, R. Cole, D. Romascanu, "Definition
                  of Managed Objects for Synthetic Sources for
                  Performance Monitoring Algorithms", RFC 4149,
                  August 2005
    [RFC4150]    R. Dietz, R. Cole, "Transport Performance Metrics
                  MIB", RFC 4150, August 2005
    [ZsZC01]     T. Zseby, S. Zander, G. Carle, "Evaluation of
                  Building Blocks for Passive One-way-delay
                  Measurements", Proceedings of Passive and Active
                  Measurement Workshop (PAM 2001), Amsterdam, The
                  Netherlands, April 23-24, 2001
 8. Acknowledgements
    We would like to thank the following persons for their
    contribution, discussion on the mailing list and valuable
    Sebastian Zander
    Robert Loewe
    Reinaldo Penno
    Lutz Mark
    Andy Biermann
    Part of the work has been developed in the research project 6QM
    co-funded with support from the European Commission.
 9. Authors' Addresses
    Tanja Zseby
    Fraunhofer Institute for Open Communication Systems (FOKUS)
    Kaiserin-Augusta-Allee 31
    10589 Berlin, Germany
    Phone: +49 30 3463 7153
 Zseby, Boschi, Brownlee, Claise                           [Page 26]

                      IPFIX Applicability              May 2006
    Email: zseby@fokus.fhg.de
    Elisa Boschi
    Hitachi Europe SAS
    Immeuble Le Theleme
    1503 Route des Dolines
    06560 Valbonne, France
    Phone: +33 4 89874180
    Email: elisa.boschi@hitachi-eu.com
    Nevil Brownlee
    9500 Gilman Drive
    La Jolla, CA 92093-0505
    Phone : +1 858 534 8338
    Email : nevil@caida.org
    Benoit Claise
    Cisco Systems
    De Kleetlaan 6a b1
    1831 Diegem
    Phone: +32 2 704 5622
    Email: bclaise@cisco.com
 10.Full Copyright Statement
    "Copyright (C) The Internet Society (2006). All Rights Reserved.
    This document and translations of it may be copied and furnished
    to others, and derivative works that comment on or otherwise
    explain it or assist in its implementation may be prepared,
    copied, published and distributed, in whole or in part, without
    restriction of any kind, provided that the above copyright
    notice and this paragraph are included on all such copies and
    derivative works. However, this document itself may not be
    modified in any way, such as by removing the copyright notice or
    references to the Internet Society or other Internet
    organizations, except as needed for the purpose of developing
    Internet standards in which case the procedures for copyrights
    defined in the Internet Standards process must be followed, or
    as required to translate it into.
 11. Intellectual Property Statement
    The IETF has been notified by Cisco of intellectual property
    rights claimed in regard to some or all of the specification
    contained in this document. For more information, see
 Zseby, Boschi, Brownlee, Claise                           [Page 27]

                      IPFIX Applicability              May 2006
    The IETF takes no position regarding the validity or scope of
    any Intellectual Property Rights or other rights that might be
    claimed to pertain to the implementation or use of the
    technology described in this document or the extent to which any
    license under such rights might or might not be available; nor
    does it represent that it has made any independent effort to
    identify any such rights.  Information on the procedures with
    respect to rights in RFC documents can be found in BCP 78 and
    BCP 79.
    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the
    use of such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR
    repository at http://www.ietf.org/ipr.
    The IETF invites any interested party to bring to its attention
    any copyrights, patents or patent applications, or other
    proprietary rights that may cover technology that may be
    required to implement this standard.  Please address the
    information to the IETF at ietf-ipr@ietf.org.
 12. Copyright Statement
    Copyright (C) The Internet Society (2006).  This document is
    subject to the rights, licenses and restrictions contained in
    BCP 78, and except as set forth therein, the authors retain all
    their rights.
 13. Disclaimer
    This document and the information contained herein are provided
 Zseby, Boschi, Brownlee, Claise                           [Page 28]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/