Re: [ipfix] update of IPFIX-AS

[Benoit Claise <[e-mail]>]

Tanja,

Minor edit: OctetDeltaCount -> octetDeltaCount

Regards, Benoit.
> Hi all,
>
> I submitted an update of the IPFIX-AS draft (attached).
>
> Main changes are:
> - added more details (e.g. required IEs) to target application examples
> (applications from RFC3917) 
> - shortend/removed some sections (especially the exotic examples) and
> tried to put less promotional text ;-)
> - RFC3330 conformant example addresses (with /25 subnetting)
> - sections re-aranged in accordance to importance (e.g. IPFIX/PSAMP
> relations before IPFIX/AAA relations)
> - summary added with overview table 
>
> Benoit, I guess the example address in the protocol draft also need to
> be changed for conformance with RFC3330. 
>
> Regards,
> Tanja
>   
> ------------------------------------------------------------------------
>
>
>
>
>
>                                                                          
>  Internet Draft                                              Tanja Zseby 
>  Document: <draft-ietf-ipfix-as-07.txt>                 Fraunhofer FOKUS 
>  Expires: October 2006                                      Elisa Boschi 
>                                                                  Hitachi 
>                                                           Nevil Brownlee 
>                                                                    CAIDA 
>                                                            Benoit Claise 
>                                                            Cisco Systems 
>                                                                          
>                                                                 May 2006 
>   
>      
>                            IPFIX Applicability 
>                         draft-ietf-ipfix-as-07.txt 
>   
>     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 
>     http://www.ietf.org/ietf/1id-abstracts.txt. 
>      
>     The list of Internet-Draft Shadow Directories can be accessed at  
>     http://www.ietf.org/shadow.html.  
>      
>     Copyright Notice  
>      
>     Copyright (C) The Internet Society (2006). 
>   
>      
>      
>      
>      
>
>
>
>
>  Zseby, Boschi, Brownlee, Claise                           [Page 1] 
>                       IPFIX Applicability              May 2006 
>
>
>
>   
>     Abstract 
>      
>     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 
>     [RFC2975].  
>   
>  2.1.1 Example 
>   
>     Please note: [RFC3330] demands the use of the address block 
>     192.0.2.0/24 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 (192.0.2.0/25) as follows: 
>      
>     Network A: 192.0.2.0 ... 192.0.2.127 
>     Network B: 192.0.2.128 ... 192.0.2.255 
>   
>     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   
>     --------------+---------------+--------+-------------- 
>     192.0.2.12    |  192.0.2.144  |   46   |   120868        
>     192.0.2.24    |  192.0.2.156  |   46   |   310364 
>     192.0.2.36    |  192.0.2.168  |   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          |  
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>        |                          192.0.2.12                           | 
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>        |                          192.0.2.144                          |  
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>        |      46       |               120868                          |  
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>        |               |               192.0.2.24                      |  
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>        |               |               192.0.2.156                     |  
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
>        |               |       46      |                 310364        |  
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>        |                               |         192.0.2.36            |   
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
>        |                               |         192.0.2.168           |   
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>        |                               |       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 
>     observedFlowTotalCount. 
>      
>     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 
>     methods. 
>   
>     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 
>     IPFIX.  
>
>
>
>
>  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) 
>   
>  2.5.2.1 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 
>     directions. 
>      
>     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 
>      
>     Remarks: 
>     - 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. 
>   
>  2.5.2.2 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 
>        points) 
>   
>     Remarks: 
>     - 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 
>     [IPFIX-PROTO]. 
>      
>     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 
>     [RFC3334]. 
>      
>     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 
>     configuration. 
>      
>     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 
>     process. 
>   
>  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 
>     implemented.   
>      
>   
>   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 
>     direction).  
>      
>     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 
>     keys. 
>      
>   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-
>     INFO].  
>     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 
>     maintained. 
>      
>
>
>
>
>
>  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 
>                   2005 
>      
>     [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 
>                   Distributions", 
>                   http://www2.auckland.ac.nz/net//Internet/rtfm/meeti
>                   ngs/47-adelaide/pp-dist/ 
>      
>     [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 
>                   1999 
>      
>     [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 
>     comments: 
>      
>     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: [phone]   
>
>
>
>
>  Zseby, Boschi, Brownlee, Claise                           [Page 26] 
>                       IPFIX Applicability              May 2006 
>
>
>
>     Email: [e-mail] 
>      
>     Elisa Boschi 
>     Hitachi Europe SAS  
>     Immeuble Le Theleme  
>     1503 Route des Dolines  
>     06560 Valbonne, France  
>     Phone: [phone]     
>     Email: [e-mail]  
>      
>     Nevil Brownlee 
>     CAIDA (UCSD/SDSC) 
>     9500 Gilman Drive 
>     La Jolla, CA 92093-0505 
>     Phone : [phone] 
>     Email : [e-mail] 
>      
>     Benoit Claise 
>     Cisco Systems 
>     De Kleetlaan 6a b1 
>     1831 Diegem 
>     Belgium 
>     Phone: [phone] 
>     Email: [e-mail] 
>      
>  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 
>
>
>
>     http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-ipfix-as-
>     02.txt 
>      
>     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 [e-mail]. 
>      
>  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 
>     on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
>     REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 
>     THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 
>     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 
>     THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 
>     RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 
>     FOR A PARTICULAR PURPOSE. 
>   
>
>
>
>
>
>
>
>
>  Zseby, Boschi, Brownlee, Claise                           [Page 28] 
>