Subject: [ipfix-req] Re: [Fwd: Re: version 3 of IPFIX requirements]

From: Juergen Quittek <[email-masked]>
Date: Tue, 25 Jun 2002 18:10:18 +0200

Hi Tanja and all,

I am sorry, that all these suggested changes got "lost"
in the Internet. I want to submit another version of the
requirements draft including Tanja's "lost" changes before
the cut-off date.

If anyone else has suggestions for modifications, please
post them by Thursday, June 27.

Cheers,

    Juergen
-- 
Juergen Quittek     [email-masked]     Tel: +49 6221 90511-15
NEC Europe Ltd.,    Network Laboratories     Fax: +49 6221 90511-55
Adenauerplatz 6, 69115 Heidelberg, Germany   http://www.ccrle.nec.de

--On 12 June 2002 17:30 +0200 Tanja Zseby <[email-masked]> wrote:

> Hi Jürgen,
>
>  it seems that something went wrong when I did send my comments to the requirements draft :-(
> (maybe because I did sent it from at home... I did not get an error from my mailtool, but it might have been caused by an unlucky combination of my virus scanner and zone alarm... )
>
> I had a lot of comments to the version. So I attached it again to this mail.
>  Maybe we can make further version and also include the comments that were send on the list during the last days ?
> Also if there are further comments from others they would have a last chance to contribute and send comments.
>
> Regards
>  Tanja
>
>
>
>  -------- Original Message --------
> Message-ID: <[email-masked]>
> Date: Thu, 06 Jun 2002 23:04:14 +0200
> From: Tanja Zseby <[email-masked]>
> Organization: FhI FOKUS
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
> X-Accept-Language: en-us
> MIME-Version: 1.0
> To: Juergen Quittek <[email-masked]>
> CC: Benoit Claise <[email-masked]> ,Tanja Zseby <[email-masked]> ,Sebastian Zander <[email-masked]> ,Georg Carle <[email-masked]> , "K.C. Norseth" <[email-masked]> , [email-masked] , [email-masked]
> Subject: Re: version 3 of IPFIX requirements
> References: <2900931.1019814195@[192.168.102.164]> <4782386.1023358227@[192.168.102.164]>
> Content-Type: multipart/mixed; boundary="------------090503030107020006050100"
>
>
> Dear Jürgen,
>
>  I read through the requirements draft and inserted my commnents in the document (marked with //TZS: ).
> It is mainly minor rephrasing and some typos. I attached the edited document.
>  One major point is that I still  have problems with the beginning  of section 6.3. (data transfer). I know we already discussed this several times... Please have a look at the extendended comment and proposed changes for this section in the document.
>  Furthermore it would be good if somebody reads the security considerations. Until now I only got some minor comments from Carter and Sebastian ...
>
>  Regards
>  Tanja
>  P.S.: I really like the new section. with the pictures..
>
>  Juergen Quittek wrote:
>
>  Dear all,
>
> Attached please find a new version of the IPFIX requirements
> draft based on our discussion on May 17. Please have a look
> at it and send comments until Saturday.
>
> I plan to submit the new version to the IETF on Monday, if we
> can agree on the draft until then.
>
> I have not yet read carefully the new security considerations.
> Also, the appendix with the application requirements table
> is still missing. I will include it over the weekend.
>
> Tanja or Sebastian, can one of you send me the source file
> of draft version 2?
>
> Cheers,
>
>    Juergen
>
>
>
> __________________________________________________
>
>
> Internet Draft                                                J. Quittek
> Document: draft-ietf-ipfix-reqs-03.txt                   NEC Europe Ltd.
> Expires: November 2002                                          T. Zseby
>                                                                FhI FOKUS
>                                                                B. Claise
>                                                            Cisco Systems
>                                                                S. Zander
>                                                                 G. Carle
>                                                                FhI FOKUS
>                                                             K.C. Norseth
>                                                               Consultant
>
>                                                                 May 2002
>
>               Req
>
>
> uirements for IP Flow Information Export
>
>                      <draft-ietf-ipfix-reqs-03.txt>
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of [RFC 2026]. Internet-Drafts are
>    working documents of the Internet Engineering Task Force (IETF), its
>    areas, and its working groups. Note that other groups may also
>    distribute working documents as Internet-Drafts.
>
>    Internet-Drafts are draft documents valid for a maximum of six months
>    and may be updated, replaced, or obsoleted by other documents at any
>    time. It is inappropriate to use Internet-Drafts as reference
>    material or to cite them other than as "work in progress."
>
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
>
>    The list o
> f
>
> Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html
>
>    Distribution of this document is unlimited.
>
> Copyright Notice
>
>    Copyright (C) The Internet Society (2001). All Rights Reserved.
>
>
> Abstract
>
>    This memo defines requirements for the export of measured IP flow
>    information out of routers, traffic measurement probes and
>    middleboxes.
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 1]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> Table of Contents
>
>    1 Introduction .................................................    2
>    2 Terminology ..................................................    2
>    2.1 IP Traffic Flow ............................................    2
>    2.2 Observation Point .............................
> ..
> ..
> .........    3
>    2.3 Metering Process ...........................................    3
>    2.4 Flow Record ................................................    4
>    2.5 Export Process .............................................    4
>    2.6 Collecting Process .........................................    4
>    3 Applications Requiring IP Flow Information Export ............    4
>    3.1 Usage-based Accounting .....................................    5
>    3.2 Traffic Profiling ..........................................    5
>    3.3 Attack/Intrusion Detection .................................    6
>    3.4 QoS Monitoring .............................................    6
>    4 Distinguishing Flows .........................................    7
>    4.1 Interfaces .................................................    7
>    4.2 IP Header Fields ...........................................    7
>    4.3 Transport Header Fields .......................
> ...
> ...
> .......    8
>    4.4 MPLS Label .................................................    8
>    4.5 DiffServ Code Point ........................................    8
>    4.6 Header Compression and Encryption ..........................    8
>    5 Metering Process .............................................    8
>    5.1 Reliability ................................................    8
>    5.2 Sampling ...................................................    9
>    5.3 Overload Behavior ..........................................    9
>    5.4 Timestamps .................................................   10
>    5.5 Time Synchronization .......................................   10
>    5.6 Timeout ....................................................   10
>    5.7 Ignore Port Copy ...........................................   10
>    6 Data Export ..................................................   11
>    6.1 Information Model .............................
> ....
> ....
> .....   11
>    6.2 Data Model .................................................   12
>    6.3 Data Transfer ..............................................   13
>    6.3.1 Congestion Awareness .....................................   13
>    6.3.2 Reliability ..............................................   13
>    6.3.3 Security .................................................   13
>    6.4 Push and Pull Mode Reporting ...............................   14
>    6.5 Regular Reporting Interval .................................   14
>    6.6 Notification on Specific Events ............................   14
>    6.7 Anonymization ..............................................   14
>    7 Configuration ................................................   14
>    8 General Requirements .........................................   15
>    8.1 Openness ...................................................   15
>    8.2 Scalability Concerning the Number of Export Pro
> cesse
> s ...
> ...   15
>    8.3 Several Collectors .........................................   15
>    9 Special Device Considerations ................................   15
>    10 Security Considerations .....................................   17
>    10.1 Disclosure of Flow Information Data .......................   18
>    10.2 Forgery of Flow Records ...................................   18
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 2]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    10.3 Denial of Service (DoS) Attacks ...........................   18
>    11 Acknowledgments .............................................   19
>    12 References ..................................................   19
>    13 Authors' Addresses ..........................................   20
>    14 Full Copyright Statement ....................................   21
>
>
> 1.  Introduction
>
>
>   Ther
> e are
> several applications that require flow-based IP traffic
>    measurements. Such measurements could be performed by a router while
>    forwarding the traffic, by a middlebox [RFC3234], or by a traffic
>    measurement probe attached to a line or a monitored port. This memo
>    defines requirements for exporting traffic flow information out of
>    these boxes for further processing by applications located on other
>    devices. In section 2 a selection of such applications is presented.
>    The following sections list requirements derived from these
>    applications.
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119].
>
>
> 2.  Terminology
>
>    The following terminology is used within this document:
>
> 2.1.  IP Traffic Flow
>
>    There are several definitions of the term
> 'flow'
> being u
> sed by the
>    Internet community. Within this document we use the following one:
>
>    A flow is defined as a set of IP packets passing an observation point
>    in the network during a certain time interval. All packets belonging
>    to a particular flow have a set of common properties. Each property
>    is defined as the result of applying a function to the values of:
>
>       1. one or more of packet header fields (e.g. destination IP
>          address)
>
>       2. one or more properties of the packet itself (e.g. packet
>          length)
>
>       3. one or more of fields derived from packet treatment (e.g. AS
>          number)
>
>    A packet is defined to belong to a flow if it completely satisfies
>    all the defined properties of the flow.
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 3]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>
>  This de
> finition
>  covers the range from a flow containing all packets
>    observed at a network interface to a flow consisting of just a single
>    packet between two applications with a specific sequence number.
>    Please note that the flow definition does not match a general
>    application-level end-to-end stream. However, an application may
>    derive properties of application-level streams by processing measured
>    flow data.
>
> 2.2.  Observation Point
>
>    The observation point is a location in the network where IP packets
>    can be observed. Examples are a line to which a probe is attached, a
>    shared medium, such as an Ethernet-based LAN, a single port of a
>    router, or a set of interfaces (physical or logical) of a router.
>
>    Please note that a coarse-grined observation point of one flow, for
>    example a line card with several ports, may be the superset of
>    several more fine-grained observation points of some other f
> lows, for
>
>    ex
> ample the individual ports of the line card.
>
> 2.3.  Metering Process
>
>    The metering process generates flow records. Input to the process are
>    IP packet headers observed at an observation point. The metering
>    process consists of a set of functions that includes packet header
>    capturing, timestamping, sampling, classifying, and maintaining flow
>    records.
>
>    The maintenance of flow records may include creating new records,
>    updating existing ones, computing flow statistics, deriving further
>    flow properties, detecting flow expiration, passing flows record to
>    the export process, and deleting flow records.
>
>    The sampling function and the classifying function may be applied
>    more than once with different parameters. Figure 1 shows the sequence
>    in which the functions are applied. Sampling is not illustrated in
>    the figure, it may be applied before any other function.
>
>
>
>
>
>
>
> <
> br>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 4]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>                            packet header capturing
>                                      |
>                                 timestamping
>                                      |
>                                      v
>                               +----->+
>                               |      |
>                               | classifying
>                               |      |
>                               +------+
>                                      |
>                           maintaining flow records
>                                      |
>                                      v
>
>
>                  Figure 1: Functions of the metering process
>
>
> 2.4.  Flow Record
>
>    A flow record contains information ab
> out a spec
> ific flow that wa
> s
>    metered at an observation point. A flow record contains measured
>    properties of the flow (e.g. the total number of bytes of all packets
>    of the flow) and usually also characteristic properties of the flow
>    (e.g. source IP address).
>
> 2.5.  Export Process
>
>    The export process sends flow records to one or more collectors.  The
>    flow records are generated by one or more metering processes.
>
> 2.6.  Collecting Process
>
>    The collecting process receives flow records from one or more export
>    processes. The collecting process might store received flow record or
>    further process them, but these actions are out of the scope of this
>    document.
>
>
> 3.  Applications Requiring IP Flow Information Export
>
>    The following list contains a selection of applications requiring IP
>    flow information export. Because requirements for flow export listed
>    in further sections below a
> re derived
> from these applica
> tions, their
>    selection is crucial. The goal of this requirements document is not
>    to cover all possible applications with all their flow export
>    requirements, but to cover applications which are considered to be of
>    significant importance in today's or future IP networks, and for
>    which requirements can be met with reasonable technical effort.
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 5]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    Please note, that the described applications can have a large number
>    of differing implementations. Requirement details or the weighting of
>    requirements could differ for specific implementations. Therefore we
>    derive the requirements from the general functionality of the
>    selected applications. Furthermore, the list of applications should
>    lead to a better understanding of the re
> quirements w
> hich is
>    parti
> cularly important when designing or implementing a traffic flow
>    measuring device.
>
> 3.1.  Usage-based Accounting
>
>    Several new business models for selling IP service and IP-based
>    services are currently under investigation. Beyond flat rate services
>    which do not need accounting, accounting for these models can be
>    based on time or volume. Accounting data can serve as input for
>    billing systems. Accounting can be performed per user or per user
>    group, it can be performed just for basic IP service or individually
>    per high-level service and/or per content type delivered. For
>    advanced/future services, accounting may also be performed per class
>    of service, per application, per time of day, per used (label
>    switched) path, etc.
>
> 3.2.  Traffic Profiling
>
>    Traffic profiling is a process of characterizing IP flows and flow
>    aggregates by using a model that represents
>  key paramete
> rs of the
>    flow
>  such as flow duration, volume, time and burstiness. It is a
>    prerequisite for network planning, network dimensioning, trend
>    analysis, developing business models, and other activities. It
>    heavily depends on the particular traffic profiling objective(s) what
>    statistics and accuracy are required from the measurements. Typical
>    information needed for traffic profiling are the distribution of used
>    services and protocols in the network, the amount of packets of a
>    specific type (e.g. percentage of IPv6 packets) and specific flow
>    profiles.
>
>    Since objectives for traffic profiling can vary, this application
>    requires a high flexibility of the measurement infrastructure,
>    especially regarding the options for measurement configuration and
>    packet classification.
>
>    Traffic Engineering (TE) comprises methods for measurement, modeling,
>    characterization and control of a net
> work. The goal
>  of TE is the
>    o
> ptimization of network resource utilization and traffic performance
>    [RFC2702]. Since control and administrative reaction to measurement
>    results requires access to the involved network nodes, TE mechanisms
>    and the required measurement function usually are performed within
>    one administrative domain. Typical parameters required for TE are
>    link utilization, load between specific network nodes, number, size
>    and entry/exit points of the active flows and routing information.
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 6]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> 3.3.  Attack/Intrusion Detection
>
>    Capturing of flow information plays an important role for network
>    security, both for detection of security violation, and for
>    subsequent defense. In case of a Denial of Service (DOS) attack, flow
>    monitoring
> can allow detec
> tion of unusual load s
> ituations or
>    suspicious flows. In a second step, flow analysis can be performed in
>    order to gather information about the attacking flows, and for
>    deriving a defense strategy.
>
>    Intrusion detection is a potentially more demanding application which
>    would not only look at specific characteristics of flows, but that
>    may also use a stateful packet flow analysis for detecting specific,
>    suspicious activities, or unusually frequent activities. Such
>    activities may be characterized by specific communication patterns,
>    detectable by characteristic sequences of certain packet types.
>
> 3.4.  QoS Monitoring
>
>    QoS monitoring is the non-intrusive (passive) measurement of quality
>    parameters for single flows or traffic aggregates. In contrast to
>    intrusive (active) measurements, non-intrusive measurements utilize
>    the existing traffic in the network for QoS analysis. Since
>  no test
>    t
> raffic is sent, non-int
> rusive measurements can only be applied in
>    situations where the traffic of interest is already present in the
>    network. One example application is the validation of QoS parameters
>    negotiated in a service level specification (SLS).
>
>    Non-intrusive measurements cannot provide the kind of controllable
>    experiments that can be achieved with active measurements. On the
>    other hand non-intrusive measurements do not suffer from undesired
>    side effects caused by sending test traffic (e.g. additional load,
>    potential differences in treatment of test traffic and real customer
>    traffic)
>
>    QoS monitoring often requires the correlation of data from multiple
>    measurement instances  (e.g. for measuring one-way metrics). This
>    requires proper clock synchronization of the involved measurement
>    instances. For some measurements packet events at the different
>    measurement points
>  must be correlat
> ed. For this, the provis
> ioning of
>    post-processing functions (e.g. the generation of packet IDs) at the
>    measurement instances would be useful. Furthermore, QoS monitoring
>    can lead to a huge amount of measurement result data. Therefore it
>    would highly benefit from mechanisms to reduce the measurement data,
>    like aggregation of results and flow sampling.
>
>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 7]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> 4.  Distinguishing Flows
>
>    Packets are mapped to flows by evaluating their properties. Packets
>    with common properties are considered to belong to the same flow. A
>    packet showing at least one difference in the set of properties is
>    considered to belong to a different flow.
>
>    The following subsections list a set of properties which a metering
>    process MU
> ST, SHOULD, or MAY
>  be able to evaluate for
> mapping packets
>    to flows. Please note that requiring the ability to evaluate a
>    certain property does not imply that this property must be evaluated
>    for each packet.
>
>    In other words, meeting the IPFIX requirements means that the
>    metering process in general must be able, via its configuration, to
>    somehow support to distinguish flows via all the MUST fields, even if
>    in certain circumstance/for certain applications, only a subset of
>    the MUST fields is needed and only a subset of the MUST fields is
>    effectively used to distinguish flows.
>
>    Which combination of properties is used for distinguishing a flow in
>    a particular measurement and how these properties are evaluated
>    depends on the configuration of the metering process. The configured
>    choice of evaluated properties strongly depends on the environment
>    and purpose of the measurement and on the infor
> mation required by
> the
>    collector.
>    For specific deployments, only a subset of the REQUIRED properties
>    listed below can be used to distinguish flows, for example in order
>    to aggregate the flow records and reduce the number of flow records
>    exported. On the other hand, some other deployments will require
>    distinguishing flows by some extra parameters, like for example the
>    TTL field of the IP header or the BGP Autonomous Systems.
>
> 4.1.  Interfaces
>
>    The metering process MUST be able to separate flows by the incoming
>    interface or by the outgoing interface or by both of them.
>
> 4.2.  IP Header Fields
>
>    The metering process MUST, SHOULD, or MAY be able to separate flows
>    by the following fields of the IP header as indicated.
>
>       1. source IP address (MUST)
>
>       2. destination IP address (MUST)
>
>       3. protocol type (TCP,UDP,ICMP,...) (MUST)
>
>
>
> Quittek et al.
>      draft-ietf-ipfi
> x-reqs-03.txt              [Pa
> ge 8]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>       4. IP version number (SHOULD)
>          This requirement only applies if the the observation point is
>          located at a device is supporting more than one version of IP.
>
>    For source address and destination address, separating by full match
>    MUST be supported as well as separation by a partial match (for
>    example subnet masking).
>
> 4.3.  Transport Header Fields
>
>    The metering process MUST be able to separate flows by the port
>    numbers of the transport header in case of TCP or UDP being used as
>    transport protocol. Both, source and destination port number MUST be
>    supported for distinguishing flows, individually as well as in
>    combination.
>
> 4.4.  MPLS Label
>
>    If the observation point is located at a device supporting
>    Multiprotocol Label Switchin
> g (MPLS, see [RFC3031
> ]) then the metering
>    proc
> ess MUST be able to separate flows by the MPLS label.
>
> 4.5.  DiffServ Code Point
>
>    If the observation point is located at a device supporting
>    Differentiated Services (DiffServ) then the metering process MUST be
>    able to separate flows by the DiffServ Code Point (DSCP, see
>    [RFC2474]).
>
> 4.6.  Header Compression and Encryption
>
>    If header compression or encryption is used, the metering process
>    might not be able to access all header fields. For packets with
>    compressed or encrypted headers, the requirements stated in this
>    section 4 MUST be met for observation points at end points of header
>    compression or of packet encryption, but they do not need to be met
>    for observation points between the end points.
>
>
> 5.  Metering Process
>
>    The following are requirements for the metering process. All
>    measurements MUST be conducted from the point
>  of view of the
>
> observation point.
>
> 5.1.
> Reliability
>
>    The metering process MUST either be reliable or missing reliability
>    MUST be known and indicated. The metering process is reliable, if
>    each packet passing the observation point is measured according to
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt              [Page 9]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    the configuration of the metering process. If, e.g. due to some
>    overload, not all passing packets can be included into the metering
>    process, then the metering process MUST be able to detect this
>    failure and to report about it.
>
> 5.2.  Sampling
>
>    Sampling describes the systematic or random selection of a subset of
>    elements (the sample) out of a set of elements (the parent
>    population). Usually the purpose of applying sampling techniques is
>    to estimate a parameter of th
> e parent population by
> using only the
>    elements of
> the subset. Sampling techniques can be applied for
>    instance to select a subset of packets out of all packets of a flow
>    or to select a subset of flows out of all flows on a link.  Sampling
>    methods differ in their sampling strategy (e.g. systematic or random)
>    and in the event that triggers the selection of an element. The
>    selection of one packet can for instance be triggered by its arrival
>    time (time-based sampling), by its position in the flow (count-based
>    sampling) or by the packet content (content-based sampling).
>
>    The metering process MAY support measuring traffic by packet
>    sampling. If sampling is supported the sampling configuration MUST be
>    well defined. The sampling configuration includes the samplng method
>    and all its parameters.
>
>    If the sampling configuration is changed during operation, the new
>    sampling configuration with its pa
> rameters MUST be indicat
> ed to all
>    collectors receivi
> ng the affected flow records.
>
>    In case of any change in the sampling configuration, all flow records
>    metered by the previous sampling configuration MUST be terminated and
>    exported according to the export configuration. The metering process
>    MUST not merge the flow records generated with the new sampling
>    configuration with the flow records generated with the previous
>    sampling configuration.
>
> 5.3.  Overload Behavior
>
>    In case of an overload, for example lack of memory or processing
>    power, the metering process MAY change in order to cope with the lack
>    of resources. Possible reactions include:
>
>       -  Reduce the number of flow accounts. This can be achieved by
>          more coarse grained flow measurement or by a restriction of the
>          flow accounts to a subset of the set of original ones.
>
>       -  Switch to sampling packets before
> they are processed by the
>
>          metering process or -
> if sampling is already performed - reduce
>          the sampling rate.
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 10]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>       -  Stop metering.
>
>       -  Reducing the resource usage of competing processes on the same
>          device.  Example: reducing the packet forwarding throughput
>
>    Overload behavior is not restricted to the four options listed above.
>    But in case the overload behavior has an impact on the metering
>    process or the export process, the overload behavior MUST be clearly
>    defined and the collector MUST be able to distinguish the flow
>    records exported before and after the metering process behavior
>    change: In case of any change of the meter's behavior, all flow
>    records metered by the previous behavior MUST be terminated
> and
>    exported accordi
> ng to the export configuration. The
> metering process
>    MUST not merge the flow records generated with the new behavior with
>    the flow records generated with the previous behavior.
>
> 5.4.  Timestamps
>
>    The metering process MUST be able to generate timestamps for the
>    first and the last observed packet of a flow. The timestamp
>    accuricaty MUST be at least the one of the sysUpTime [RFC1213], which
>    is one centisecond.
>
> 5.5.  Time Synchronization
>
>    Metering processes and collectors SHOULD be time-synchronized with
>    each other. Using NTP or GPS are possible ways of achieving this.
>    However selecting a method for time synchronization is not in the
>    scope of this document.
>
> 5.6.  Timeout
>
>    The metering process MUST be able to detect flow timeout. A flow is
>    considered to be timed out if no packet of this flow has been
>    observed for a given timeout interval. The meter
> ing process MAY
>    suppo
> rt means for detecting the end of a f
> low before a time out
>    occurs, for example by detecting the FIN or RST bits in a TCP
>    connection. The procedure for detecting a flow timeout MUST be
>    clearly defined.
>
> 5.7.  Ignore Port Copy
>
>    The metering process MAY be able to ignore packets which are
>    generated by a port copy function acting at the device where the
>    observation point of a flow is located.
>
>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 11]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> 6.  Data Export
>
>    The following are requirements for exporting measured flow data out
>    of the exporter. Beside requirements on the data transfer, we
>    separate requirements concerning the information model from
>    requirements concerning the data model. Furthermore, we list
>    requirements on reporting t
> imes and events and on anony
> mization of
>    records.
>
> 6.1.
>   Information Model
>
>    The information model for the flow information export is the list of
>    attributes of a flow to be contained in the report (including the
>    semantics of the attributes).
>
>    This section lists attributes an export process MUST or MAY be able
>    to report. This does not imply that each exported flow records MUST
>    contain all REQUIRED attributes, but that it MUST be possible to
>    configure the device in a way that all of the REQUIRED attributes are
>    transmitted from the export process to the colleting process for each
>    measured flow.
>
>    In other words, meeting the IPFIX requirements means that the export
>    process in general must be able, via its configuration, to somehow
>    support to report all the MUST fields, even if in certain
>    circumstance or for certain applications, only a subset of the MUST
>    fields is needed and on
> ly a subset of the MUST field
> s is effectively
>    reported.
>
>    Beyond that, the device might offer to report also further attributes
>    not mentioned here. A particular flow record may contain some of the
>    "REQUIRED" attributes as well as some additional ones, for example
>    covering future technologies.
>
>    This document does not impose that the following attributes would
>    reported for every single flow records, especially for repetitif
>    attributes. For example, if the observation point is the incoming
>    packet stream at IP interface with the ifIndex value 3, then this
>    observstion point does not have to be exported as part of every
>    single flow record. Exporting it just once might give sufficient
>    information to the collecting process.
>
>    The measuring device MUST be able to report the following attributes
>    for each measured flow:
>
>       1. IP version number
>          This requirement only applies i
> f the observation point is
>
>          located at a device supporting
>  more than one version of IP.
>       2. source IP address
>       3. destination IP address
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 12]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>       4. IP protocol type (TCP,UDP,ICMP,...)
>       5. source TCP/UDP port number
>       6. destination TCP/UDP port number
>       7. input interface (ifIndex)
>          This requirement does not apply if the observation point is
>          located at a probe device.
>       8. output interface (ifIndex)
>          This requirement does not apply if the observation point is
>          located at a probe device. This requirement does not apply in
>          case of multicast flow records.
>       9. packet counter
>          If a packet is fragmented, each fragment is counted as an
>          individual packet.
>      10. by
> te counter
>          Which by
> tes of a packet are counted MUST be defi
> ned exactly.
>      11. in case of IPv4: Type of Service
>      10. in case of IPv6: Flow Label
>      11. if BGP is supported at the observation point: BGP AS#
>      12. if MPLS is supported at the observation point: MPLS label
>      13. if DiffServ is supported at the observation point: DSCP
>      14. timestamp of the first packet of the flow
>      15. timestamp of the last packet of the flow
>      16. if sampling is used: sampling configuration
>      17. unique identifier of the observation point
>      18. unique identifier of the export process
>
>    The metering process MAY be able to report the following attributes
>    for each measured flow:
>
>      20. Time To Live
>      21. IP header flags
>      22. TCP header flags
>      23. dropped packet counter at the observation point
>          If a packet is fragmented, each fragment MUST be counted as an
>          indi
> vidual packet.
>      24. fragm
> ented packet counter
>          counter
> of all packets for which the fragmented bit is set in
>          the IP header
>      25. multicast replication factor
>          the number of outgoing packets originating from a single
>          incoming multicast packet
>
> 6.2.  Data Model
>
>    The data model describes how information is represented in flow
>    records.
>
>    The data model MUST be extensible for future attributes to be added.
>    Even if a set of attributes is fixed in the flow record, the data
>    model MUST provide a way of extending the record by configuration or
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 13]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    for certain implementations.
>
>    The data model used for exporting flow information MAY be flexible
>    concerning the flow attributes contained in flow records.
>  A flexible
>    record format w
> ould offer the possibility of defining rec
> ords in a
>    flexible (customizable) way regarding the number and type of
>    contained attributes.
>
>    The Data Model SHOULD be independent of the underlying transport
>    protocol, i.e. the data transfer.
>
> 6.3.  Data Transfer
>
>    Requirements for the data transfer include reliability and security
>    requirements. These requirements do not apply to the measuring device
>    alone, but also to the transport network. Consequently, the export
>    process does not necessarily have to guarantee that all requirements
>    are met. Particularly if the security requirements are already
>    guaranteed by the network used for data transfer, then these
>    requirements do not have to be considered anymore by the export
>    process. Therefore, these requirements are OPTIONAL for the export
>    process, although they may be REQUIRED for the data transfer as
>    specified
>  in the appendix.
>
> 6.3.1.  C
> ongestion Awareness
>
>    For the data
> transfer, a congestion aware protocol MUST be supported.
>
> 6.3.2.  Reliability
>
>    Absence of reliability, for example caused by export packet loss or
>    export packet reordering, of the data transfer MUST be indicated.
>
>    Please note that if an unreliable transport protocol is used,
>    reliability can be provided by higher layers. In such a case only
>    lack of overall reliability MUST be indicated. For example reordering
>    could be dealt with by adding a sequence number to each packet.
>
> 6.3.3.  Security
>
>    Confidentiality of flow specific data transferred from an export
>    process to a collecting process SHOULD be ensured.
>
>    Integrity of flow specific data transferred from an export process to
>    a collecting process MUST be ensured.
>
>    Authenticity of flow specific data transferred from an export process
>    to a collecting proce
> ss MUST be ensured.
>
>    See m
> ore about Security in the "Security Consider
> ations" section 10,
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 14]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    from which the 3 requirements above are deducted.
>
> 6.4.  Push and Pull Mode Reporting
>
>    In general, there are two ways of deciding on reporting times: push
>    mode and pull mode. In push mode, the export process decides without
>    an external trigger on when to send a report on measured flows. In
>    pull mode, sending a report is triggered by an explicit request from
>    a collector. The measuring device MUST support push mode reporting,
>    it MAY support pull mode reporting.
>
> 6.5.  Regular Reporting Interval
>
>    The export process SHOULD be capable of reporting measured traffic
>    data regularly according to a given interval length.
>
> 6.6.  Notification
>  on Specific Events
>
>    The ex
> port process MAY be capable of sending notifi
> cations to a
>    collecting process, if a specific event occurs. Such an event can be
>    the arrival of the first packet of a new flow, or the termination of
>    a flow after flow timeout.
>
> 6.7.  Anonymization
>
>    The export process MAY be capable of anonymizing source and
>    destination IP addresses in flow data before exporting them. It MAY
>    support anonymization of port numbers and other fields. Please note
>    that anonymization is not originally an application requirement, but
>    derived from general requirements for treatment of traffic within a
>    network.
>
>
> 7.  Configuration
>
>    The metering process MUST provide a way of configuring traffic
>    measurement. The following parameters of the metering process SHOULD
>    be configurable:
>
>       1. specification of the observation point, e.g. an interface or
>          a list of int
> erfaces to be monitored.
>       2.
> specifications of flows to be metered
>
>  3. flow timeouts
>
>    The following parameters MAY be configurable:
>
>       4. sampling method and parameters, if feature is supported
>       5. overload behavior
>
>    The export process MUST provide a way of configuring the data export.
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 15]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    The following parameters of the export process SHOULD be
>    configurable:
>
>       1. reporting data format
>          Specifying the reporting data format SHOULD include a selection
>          of attributes to be reported for each flow.
>       2. the collecting process (or list of collecting processes) to
>          which flows are reported 2. notifications to be sent to the
>          collecting process(es) 3. flow anonymization, if the export
>
>      process supports it
>
>    If
> configuration is done remotely, security of the
>  configuration
>    SHOULD be supported including confidentiality, integrity and
>    authenticity. The means used for remote configuration are out of the
>    scope of this document.
>
>
> 8.  General Requirements
>
> 8.1.  Openness
>
>    IPFIX specifications SHOULD be open to future technologies. This
>    includes extensibility of configuration of measurement and reporting.
>
>    Openness is also required concerning the extensibility of the data
>    model, as stated in section 6.2.
>
> 8.2.  Scalability Concerning the Number of Export Processes
>
>    Data collection from hundreds of different export processes MUST be
>    supported. The collecting process MUST be able to distinguish several
>    hundred export processes by their identifiers.
>
> 8.3.  Several Collectors
>
>    The export process MAY be able to export flow information to more
>    tha
> n one collecting process.
>
>
> 9.
>   Special Device Considerations
>
>    This d
> ocument is intended to avoid constraining the architecture of
>    probes, routers, and other devices hosting observation points,
>    metering processes, export processes, or collecting processes.  It
>    can be expected that typically observation point, metering process,
>    and export process are co-located at a single device.  However, the
>    requirements defined in this document do not exclude devices that
>    derive from this configureation. Figure 2 shows some examples.
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 16]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>             +---+     +-----+     +---------+       +---------+
>             | E-+->   |  E--+->   |    E----+->   <-+--E   E--+->
>             | | |     |  |  |     |   /    |       |  |   |  |
>
>      | M |     |  M  |     |  M   M  |
>      |  M   M  |
>             | | |     | /| |
>     | /| /| |       | /| /| |
>             | O |     | OOO |     | OOO OOO |       | OOO OOO |
>             +---+     +-----+     +---------+       +---------+
>             Probe      Basic        Complex          Multiple
>                        Router       Router           Exporters
>
>
>           +---+     +---+     +---+
>           | E-+->   | E-+->   | E-+------------->---+
>           | | |     | | |     | | | +---+         +-+-----+
>           +-+-+     | M |     | M | | E-+------->-+-C-M-E-+->
>             |       | | |     | | | | | | +---+   +-+-----+
>           +-+-+     +-+-+     | O | | M | | E-+->---+
>           | | |       |       +---+ | | | | | |
>           | M |     +-+-+           | O | | M |
>           | | |     | | |           +---+ | | |           +-----+
>           | O |     | O |                 | O |        ->
> -+-C-E-+->
>           +---+     +---
> +                 +---+           +-----+
>
>
>         Protocol   Remote             Concentrator        Proxy
>          Converter  Observation
>
>                       Figure X: IPFIX-related Devices
>
>    All examples are composed of one or more of the following elements:
>    observation point (O), full or partial metering process (M), export
>    process (E), collecting process (C).
>
>    A very simple device is a probe. It contains on a single observation
>    point, a single metering process, and a single export process.  For
>    this device the observation domain contains a single observation
>    point only.
>
>    A basic router extends this structure by multiple observation point.
>    Here an exported flow record may still have an observation domain
>    containing a single observation point. But also Observation domains
>    containing all observation points of the routers are possible.
>
>    A more complex router may host more th
> an one metering process, for
>    example one per
> line card. Please note that an observation domain is
>    restricted to the observation points connected to a single metering
>    process. An observation domain containing all observation points of
>    this router is not possible with this structure.
>
>    Alternatively, a complex router may use different export processes
>    for flow records generated by different metering processes.
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 17]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    A protocol converter makes use of a metering process that can be
>    accessed only by another protocol than the one defined for IPFIX, for
>    example the SNMP and the Meter MIB module [RFC2720]. Then the
>    exporter receives flow record from a remote metering process and
>    exports these records using the
>  IPFIX protocol.
>
>    Another choice i
> s remote packet observation. Packet header captured<
> br>   at an observation point may be exported as raw data to a device
>    hosting metering process and exproting process.
>
>    An intermediate structure between protocol converter and remote
>    observation (not shown in the Figure) would be a split metering
>    process, for example performing timestaping and sampling at the
>    device hosting the observation point and performing packet
>    classification at another device hosting the export process.
>
>    A concentrator receives flow records via the IPFIX protocol, merges
>    them into higher aggregated flows and exports the resulting flows
>    again using the IPFIX protocol. Please note that for the final flow
>    records the observation domain potentially contains observation
>    points at all first level devices. The metering process of the final
>    flow records is composed by the (partial)
> metering processes at the
>    first level
> devices and the partial metering process at the
>    conce
> ntrator.
>
>    Finally, a very simple IPFIX-related device is a proxy. It just
>    receives flow records using the IPFIX protocol and sends them further
>    using the same protocol. A proxy might be useful for traversing
>    firewalls or other gateways.
>
>
> 10.  Security Considerations
>
>    The future IPFIX protocol must be capable to transport data over the
>    public Internet. Therefore it cannot be excluded that an attacker
>    captures or modifies exchanged packets or inserts additional packets.
>
>    This section describes security requirements for IPFIX.  It therefore
>    also states the required security features for a future IPFIX
>    protocol. Like other requirements, the security requirements differ
>    for the considered applications. The incentive to modify collected
>    data for accounting or intrusion detection for instan
> ce is usually
>    higher than the incentive
>  to change data collected for traffic
>    profiling. There
> fore the required security features in this document
>    are listed per application in the appendix.  The suggestion of
>    concrete solutions for achieving the required security properties
>    will be part of the IPFIX architecture and protocol description and
>    is out of scope of this document. Furthermore, methods for remote
>    configuration of the IPFIX processes are out of scope for IPFIX.
>    Therefore, threads that are caused by data exchange for remote
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 18]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    configuration are not considered here.
>
>    The following potential security hazards for an IPFIX protocol can be
>    identified: disclosure of IP flow information, forgery of flow
>    records, and Denial of Service
>  (DoS) attacks.
>
> 10.1.  Disclosure of Fl
> ow Information Data
>
>    The content of data exchanged b
> y the IPFIX protocol (e.g. IPFIX flow
>    records) should be kept confidential between the involved parties
>    (export process and colleting process). Observation of IPFIX flow
>    records gives an attacker information about the active flows in the
>    network, communication endpoints and traffic patterns. This
>    information cannot only be used to spy out user behavior but also to
>    plan and conceal future attacks. Therefore the requirements document
>    recommends to ensure the confidentiality of the transferred data.
>    This can be achieved for instance by encryption.
>
> 10.2.  Forgery of Flow Records
>
>    Because of the potential uses of IPFIX flow records in accounting and
>    security applications, there are strong incentives to forge exported
>    IPFIX  flow records (e.g. to save money or prevent the detection of
>    an attack
> ). This can be done either by altering flow rec
> ords on the
>    path or by injecting forged flow records tha
> t pretend to be
>    originated by the original export process. In order to make the IPFIX
>    protocol resistant against such attacks this document requires to
>    ensure authenticity and integrity for the IPFIX data transfer.
>
>    Special caution is required if security applications rely on IPFIX
>    data. With forged flow records it is possible to trick on security
>    applications. It is for instance possible to pretend that a DoS
>    attack happens without even launching a real attack.
>
>    IPFIX flow records are used in accounting and security applications.
>    This leads to strong incentives for attackers to forge exported IPFIX
>    flow records (for example to save money or to prevent the detection
>    of an attack). In order to make the IPFIX protocol resistant against
>    such attacks, source authentication and integrity assuran
> ce must be
>    provided for IPFIX data. These
> requirements are covered in the
>    security requirements sec
> tion of this document.
>
> 10.3.  Denial of Service (DoS) Attacks
>
>    DoS attacks on routers or other middleboxes that have the IPFIX
>    protocol implemented would also affect the IPFIX protocol and impair
>    the sending of IPFIX records. Nevertheless, since such hazards are
>    not induced specifically by the IPFIX protocol the prevention of such
>    attacks is out of scope of this document.
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 19]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>    Nevertheless IPFIX itself also causes potential hazards for DoS
>    attacks.  All processes that expect the reception of traffic can be
>    target of a DoS attack. With the IPFIX export process this is only
>    the case if it supports the pull mode (which can be an optiona
> l
>    feature of the future IPFIX protocol acco
> rding to this document). The
>    collecting process always exp
> ects data and therefore can be flooded
>    by forged flow records.
>
>
> 11.  Acknowledgments
>
>    We like to thank all the people contributing to the requirements
>    discussion on the mailing list for a lot of valuable comments.
>
>
> 12.  References
>
> [RFC2026]   S. Bradner, "The Internet Standards Process -- Revision 3",
>             RFC 2026, October 1996.
>
> [RFC3234]   B. Carpenter, "Middleboxes: taxonomy and issues", RFC 3234,
>             February 2002.
>
> [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
>             Requirement Levels", RFC 2119, March 1997.
>
> [RFC2702]   D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus,
>             "Requirements for Traffic Engineering Over MPLS", RFC 2702,
>             September 1999.
>
> [RFC3031]   E. Rosen, A. Viswanathan, R. Callon, "Multip
> rotocol Label
>             Switching Architectur
> e", RFC 3031, January 2001.
>
> [RFC2474]   K. Nichols, S. Bla
> ke, F. Baker, D. Black, "Definition of the
>             Differentiated Services Field (DS Field) in the IPv4 and
>             IPv6 Headers", RFC 2474, December 1998.
>
> [RFC1213]   K. McCloghrie, M. Rose. "Management Information Base for
>             Network Management of TCP/IP-based internets: MIB-II", RFC
>             1213, March 1991.
>
>
>
>
>
>
>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 20]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
> 13.  Authors' Addresses
>
>      Juergen Quittek
>      NEC Europe Ltd., Network Laboratories
>      Adenauerplatz 6
>      69115 Heidelberg
>      Germany
>
>      Phone: +49 6221 90511-15
>      EMail: [email-masked].
> de
>
>
>      Tanja Zseby
>      Fraunhof
> er Institute for Open Communication Systems (FOKUS)
>      Kaiser
> in-Augusta-Allee 31
>      10589 Berlin
>      Germany
>
>      Phone: +49 30 3463 7153
>      Email: [email-masked]
>
>
>      Benoit Claise
>      Cisco Systems
>      De Kleetlaan 6a b1
>      1831 Diegem
>      Belgium
>
>      Phone: +32 2 704 5622
>      Email: [email-masked]
>
>
>      Sebastian Zander
>      Fraunhofer Institute for Open Communication Systems (FOKUS)
>      Kaiserin-Augusta-Allee 31
>      10589 Berlin
>      Germany
>
>      Phone: +49 30 3463 7287
>      Email: [email-masked]
>
>
>      Georg Carle
>      Fraunhofer Institute for Open Communication Systems (FOKUS)
>
>     Kaiserin-Augusta-Allee 31
>      10589 Berlin     Germany
>
>      Phone: +49 30 3463 7149
>      Email: <
> a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 21]
> 
> Internet-Draft             IPFIX Requirements                   May 2002
>
>
>      K.C. Norseth
>      Consultant
>      934 S. Palos Verdes Dr.
>      Kaysville, Utah 84037 USA
>
>      Phone: 801.546.3316
>      Email: [email-masked]
>
>
> 14.  Full Copyright Statement
>
>    Copyright (C) The Internet Society (2001). All Rights Reserved.
>
>    This document and translations of it may be copied and furnished to
>    others, and derivat
> ive 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 languages other than
>    English.
>
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assigns.
>
>    This document and the information contained herein i
> s provided on an
>    "AS IS" basis and THE INTERNET SOC
> IETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>    HEREIN WILL NOT INFRINGE ANY RI
> GHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Quittek et al.        draft-ietf-ipfix-reqs-03.txt             [Page 22]
>
>
>
>
>
>
>
> --
> Dipl.-Ing. Tanja Zseby			    	      	
> FhI FOKUS/Global Networking			Email: [email-masked]	
> Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
> D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
> --------------------------------------------------------------------------------------
> "Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
> --------------------------------------------------------------------------------------
>
>
>
>
> --
> Dipl.-Ing. Tanja Zseby			    	      	
> FhI FOKUS/Global Networking			Email: [email-masked]	
> Kaiserin-Augusta-Allee 31				Phone: +49-30-3463-7153
> D-10589 Berlin, Germany				Fax:   +49-30-3463-8153
> --------------------------------------------------------------------------------------
> "Living on earth is expensive but it includes a free trip around the sun." (Anonymous)
> --------------------------------------------------------------------------------------
>
>
>

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/