idnits 2.17.1 draft-ietf-ipfix-as-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 7) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2004) is 7225 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2681' is mentioned on line 284, but not defined == Missing Reference: 'RFC 2722' is mentioned on line 549, but not defined == Missing Reference: 'RFC 2724' is mentioned on line 462, but not defined == Missing Reference: 'RFC 2723' is mentioned on line 491, but not defined == Missing Reference: 'RFC 2720' is mentioned on line 561, but not defined == Unused Reference: 'Awdu02' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'DuGr00' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'GrDM98' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'QuZC03' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'ZsZC01' is defined on line 696, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-principles (ref. 'Awdu02') -- Possible downref: Non-RFC (?) normative reference: ref. 'Brow00' -- Possible downref: Non-RFC (?) normative reference: ref. 'CuDF04' -- Possible downref: Non-RFC (?) normative reference: ref. 'DuGr00' -- Possible downref: Non-RFC (?) normative reference: ref. 'GrDM98' -- Possible downref: Non-RFC (?) normative reference: ref. 'MaPZ03' -- Possible downref: Non-RFC (?) normative reference: ref. 'QuZC03' ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Downref: Normative reference to an Experimental RFC: RFC 2903 -- Possible downref: Non-RFC (?) normative reference: ref. 'ZsZC01' Summary: 11 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Tanja Zseby 3 Document: Elisa Boschi 4 Expires: January 2005 Fraunhofer FOKUS 5 Reinaldo Penno 6 Nortel Networks 7 Nevil Brownlee 8 CAIDA 9 Benoit Claise 10 Cisco Systems 12 July 2004 14 IPFIX Applicability 15 draft-ietf-ipfix-as-02.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance 20 with all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working 23 groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. Internet-Drafts are draft 25 documents valid for a maximum of six months and may be updated, 26 replaced, or obsoleted by other documents at any time. It is 27 inappropriate to use Internet- Drafts as reference material or 28 to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. The list of 31 Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes what type of applications can use the IP 37 Flow Information Export (IPFIX) protocol and how they can use 38 the information provided by IPFIX. It furthermore shows how the 39 IPFIX framework relates to other architectures and frameworks. 41 Table of Contents 42 1. Introduction.............................................2 43 2. Applications of IPFIX....................................2 44 2.1 Accounting...............................................3 45 2.2 Security Analysis and Intrusion detection with IPFIX.....3 46 2.3 Network Planning.........................................4 47 2.4 Peering Agreements.......................................5 48 2.5 Traffic Engineering......................................5 49 2.6 Data Warehousing and Mining..............................5 50 2.7 SLA validation...........................................5 51 2.8 Traffic Monitoring.......................................5 52 2.8.1 Measurement of Round-trip-time (RTT)....................6 53 2.8.2 Measurement of One-way-delay (OWD)......................7 54 2.8.3 Measurement of One-way-loss (OWL).......................7 55 2.8.4 Measurement of IP delay variation (IPDV)................8 56 3. Relation of IPFIX to other frameworks and protocols......8 57 3.1 IPFIX and AAA............................................8 58 3.1.1 Connecting via an AAA Client............................8 59 3.1.2 Connecting via an Application Specific Module (ASM).....9 60 3.2 IPFIX and RTFM..........................................10 61 3.2.1 Definition of 'flow'...................................10 62 3.2.2 Configuration and Management...........................11 63 3.2.3 Data Model details.....................................12 64 3.2.4 Application/transport protocol.........................13 65 3.3 IPFIX and IPPM..........................................13 66 3.4 IPFIX and IDMEF.........................................14 67 4. Security Consideration..................................14 68 5. References..............................................14 69 6. Acknowledgements........................................16 70 7. Author's Addresses......................................16 71 8. Full Copyright Statement................................17 73 1. Introduction 75 The IPFIX protocol defines how IP Flow information can be 76 exported from routers, measurement probes or other devices. It 77 is intended to provide this information as input for various 78 applications. This document describes what applications can use 79 the IPFIX protocol and how they can use it. Furthermore, the 80 relationship of IPFIX to other frameworks and architectures is 81 described. 83 2. Applications of IPFIX 85 IPFIX data enables several critical customer applications. This 86 section describes how different applications can use IPFIX. 88 2.1 Accounting 90 Usage based accounting is one of the major applications for 91 which the IPFIX protocol has been developed. IPFIX data provide 92 fine-grained metering (for example, flow records include details 93 such as IP addresses, packet and byte counts, timestamps, Type 94 of Service (ToS), application ports, etc.) for highly flexible 95 and detailed resource usage accounting. ISPs can use this 96 information to migrate from single fee, flat-rate billing to 97 more flexible charging mechanisms based on time of day, 98 bandwidth usage, application usage, quality of service, etc. 99 Enterprise customers can use this information for departmental 100 chargeback or cost allocation for resource usage. 102 In order to realize usage-based accounting with IPFIX the flow 103 definition has to be chosen in accordance to the tariff model. A 104 tariff can for instance be based on individual end-to-end 105 streams. In that case accounting can be realized with a flow 106 definition determined by the quintuple that consists of source 107 address, destination address, protocol and portnumbers. Another 108 example is a class-dependent tariff (e.g. in a DiffServ 109 network). For this flows could be distinguished just by DiffServ 110 codepoint (DSCP) and source address. 112 The essential elements needed for accounting are the number of 113 transferred packets and bytes per flow which are contained in 114 IPFIX flow records. Furthermore IPFIX provides a very flexible 115 definition of flows, so arbitrary flow-based accounting models 116 can be realized without any extensions to the IPFIX protocol. 117 Nevertheless the configuration of flow definitions is out of 118 scope of the IPFIX definition. 120 For accounting purposes, it would be advantageous to have the 121 ability to use IPFIX flow records as accounting input in a AAA 122 infrastructure. AAA servers then could provide the mapping 123 between user and flow information. 125 2.2 Security Analysis and Intrusion detection with IPFIX 127 Intrusion detection systems (IDS) monitor and control security 128 incidents. A typical IDS system includes components like sensor, 129 event collector, and management stations. Sensors monitor 130 network and system traffic for attacks and other security- 131 related events. Sensors respond to and notify the administrator 132 about these events as they occur. Event collectors are a middle- 133 tier component responsible for transmitting events from sensors 134 to the console and database. The management component serves the 135 following purposes: 137 _ - visually monitors events (with a console) 138 _ - collects data from sensors (with one or more event 139 collectors) 140 _ - stores data from sensors (in a database) 142 IPFIX can report events of interest to the sensor either by the 143 collecting process or directly by the exporting process. It 144 depends on the scenario and the events of interest which 145 solution is better. Getting information directly from the 146 exporting process has the advantage that the sensor gets the 147 information faster. It does not need to wait for collector 148 processing time or until the collector has all relevant data. 149 Getting the information from a collector allows correlating data 150 from different exporting processes (e.g. from different routers) 151 to get a better picture about what is going on in the network. 153 IPFIX provides useful input data for basic intrusion detection 154 functions (e.g. detecting unusual high loads) such as details on 155 source and destination addresses, along with the start time of 156 flows, TCP flags, application ports and flow volume. This data 157 can be used to analyze network security and identify 158 attacks. Nevertheless, for some scenarios intrusion detection 159 may require further insight into packet content. Since IPFIX 160 allows a flexible report definition the metering process and the 161 IPFIX report format could be extended to support other data 162 needed for intrusion detection systems. 164 Detecting security incidents in real-time would require a 165 preprocessing of data already at the measurement device and 166 immediate data export in case a possible incident has been 167 identified. This means that IPFIX reports must be generated upon 168 incident detection events and not only upon flow end or fixed 169 time intervals. 171 2.3 Network Planning 173 IPFIX data captured over a long period of time can be used to 174 track and anticipate network growth and plan upgrades to 175 increase the number of routing devices, ports, or higher- 176 bandwidth interfaces. IPFIX data optimizes both strategic 177 network planning (peering, backbone upgrade planning, and 178 routing policy planning) as well as tactical network engineering 179 decisions (upgrading the router or link capacity). This helps to 180 minimize the total cost of network operations while maximizing 181 network performance, capacity, and reliability. 183 2.4 Peering Agreements 185 IPFIX data enables ISP peering partners to measure the volume 186 and characteristics of traffic exchanged with other ISP peers. 187 Different domains often have different tools. In order to 188 achieve interoperability in such heterogeneous environment, it 189 becomes necessary to have a common format to share measurement 190 data. IPFIX provides the format through which data can be 191 exchanged and consequently compared, between different ISPs. 192 This makes also possible to provide End-to-End (E2E) 193 measurements spanning multiple domains. 195 2.5 Traffic Engineering 197 IPIFX data provides traffic engineering details for a set of 198 prefixes. This data can be used in network optimization for load 199 balancing traffic across alternate paths, or for forwarding 200 traffic of a certain set of prefixes on a preferred route. 202 2.6 Data Warehousing and Mining 204 IPFIX data (or derived information) can be stored for later 205 retrieval and analysis to support proactive marketing and 206 customer service programs. An example of this would be to 207 determine which applications and services are being used by 208 internal and external users and then target them for improved 209 services such as advertising. This is especially useful for ISPs 210 because IPFIX data enables them to create better service 211 packaging. 213 2.7 SLA validation 215 The performance of QoS monitoring is one target application for 216 using the IPFIX protocol. QoS monitoring is the passive 217 observation of transmission quality for single flows or traffic 218 aggregates in the network. One example of its usefulness is the 219 validation of QoS guarantees in service level agreements (SLAs). 220 Some QoS metrics require the correlation of data from multiple 221 measurement points. For this the clocks of the involved 222 exporting devices must be synchronized. Furthermore, such 223 measurements would benefit from post-processing functions (e.g. 224 packet ID generation and mapping) at the exporter and/or 225 collector. 227 2.8 Traffic Monitoring 229 IPFIX data can be used for extensive near real-time traffic 230 monitoring. Traffic patterns associated with routing devices and 231 switches on an individual or network wide basis can be displayed 232 enabling proactive problem detection, efficient troubleshooting, 233 and rapid problem resolution. 235 IPFIX data enables content and service providers to perform a 236 detailed, time-based, and application-based usage analysis of a 237 network. They also provide detailed information for 238 understanding customer or end-user usage of network and 239 application resources. This information can then be used to 240 efficiently plan and allocate access, backbone, and application 241 resources, as well as to detect and resolve potential security 242 and policy violations. 244 This section describes how the monitoring of different metrics 245 can be performed with IPFIX. All of the metrics require at least 246 an extension of the IPFIX information model because currently 247 the necessary information such as e.g. round-trip-time, packet 248 IDs etc. is not part of the model. However given the 249 extensibility and flexibility of IPFIX the missing attributes 250 can be easily defined. 252 2.8.1 Measurement of Round-trip-time (RTT) 254 The passive measurement of round-trip-times (RTT) can be 255 performed by using packet pair matching techniques as described 256 in [Brow00]. For the measurements, request/response packet pairs 257 from protocols like DNS, ICMP, SNMP or TCP (syn/syn-ack, 258 data/ack) are utilized to passively observe the RTT [Brow00]. As 259 always for passive measurements this only works if the required 260 traffic of interest is actually present in the network. 261 Furthermore, if the observed protocol supports retransmissions 262 (e.g. TCP) the RTT is not the network RTT but rather the RTT of 263 the network and the network stack of the receiver. In case the 264 reply packet is lost or can not be observed the RTT can not be 265 calculated. 267 In order to use this measurement technique, the IPFIX metering 268 process needs to measure both directions. A classification of 269 the protocols mentioned above has to be done. That means parts 270 of the transport header are used for the classification. Since a 271 differentiation of flows in accordance to the transport header 272 is one of the requirements for IPFIX, such classification can be 273 performed without extensions. Nevertheless, the meter needs to 274 recognize request and response packets for the given protocols 275 and therefore needs to look further into the packets. The 276 capability to do this analysis is not part of the IPFIX 277 requirements but can be achieved by optional extensions to the 278 classification process. The exporting device needs to assign a 279 timestamp for the arrival of the packets. The calculation of the 280 RTT can be done directly at the exporter or at the collector. In 281 the first case IPFIX would transfer the calculated RTT to the 282 collector. In the second case IPFIX needs to send the observed 283 packet types and the timestamps to the collector. The round- 284 trip-time-delay metric is defined in [RFC2681]. 286 2.8.2 Measurement of One-way-delay (OWD) 288 Passive one-way-delay measurements require the collection of 289 data at two measurement points. It is necessary to recognize 290 packets at the second measurement point to correlate packet 291 arrival events from both points. This can be done by capturing 292 packet header and parts of the packet that can be used to 293 recognize the same packet at the subsequent measurement point 294 [MaPZ03]. To reduce the amount of measurement data a unique 295 packet ID can be calculated from the header and part and/of the 296 content e.g. by using a CRC or hash function [GrDM98, DuGr00, 297 ZsZC01]. The capability of using content information is out of 298 scope of IPFIX but can be achieved by an optional extension. 299 Nevertheless, in some scenarios it might even be sufficient to 300 calculate a packet ID based on header fields (including datagram 301 ID and maybe sequence numbers from transport protocols) only 302 without looking at parts of the packet content. If packet IDs 303 need to be unique only for a certain time interval or a certain 304 amount of packet ID collisions is tolerable this is a sufficient 305 solution. The second issue is the export of packet IDs. IPFIX 306 exports per flow information. However, it is possible to extend 307 IPFIX with a scheme to export per-packet information by 308 providing special templates for that purpose. The one way delay 309 metric is defined in [RFC2679]. 311 2.8.3 Measurement of One-way-loss (OWL) 313 Passive loss measurements for single flows can be performed at 314 one measurement point by using sequence numbers that are present 315 in protocols (e.g. IP identification, TCP sequence numbers) 316 similar to the approach described in section 2.8.1. This 317 requires the capturing of the sequence numbers of subsequent 318 packets of the observed flow by the IPFIX metering process. 320 An alternative to this is to perform a two-point measurement as 321 described in section 2.8.2 and consider packets as lost that do 322 not arrive at the second measurement point in a given time 323 frame. This approach assumes that a packet observed at the first 324 point should also be observed at the second point (known 325 routing). 327 The one-way loss metric is defined in [RFC2680]. 329 2.8.4Measurement of IP delay variation (IPDV) 331 IP Delay variation is defined as the difference of one-way-delay 332 values for selected packets [RFC3393]. Therefore, this metric 333 can be calculated by performing passive measurement of one-way- 334 delay for subsequent packets (e.g. of a flow) and then 335 calculating the differences. 337 3. Relation of IPFIX to other frameworks and protocols 339 3.1 IPFIX and AAA 341 AAA defines a protocol and architecture for authentication, 342 authorization and accounting for service usage. The DIAMETER 343 protocol is used for AAA communication for network access 344 services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture 345 [RFC2903] provides a framework for extending the AAA support 346 also for other services. DIAMETER defines the exchange of 347 messages between AAA entities, e.g. between AAA clients at 348 access devices and AAA servers and among AAA servers. It is used 349 also for the transfer of accounting records. Usage-based 350 accounting requires measurement data from the network. IPFIX 351 defines a protocol to export such data from routers, measurement 352 probes and other devices. 354 The provisioning of accounting with IPFIX can be realized 355 without an AAA infrastructure. The collector can directly 356 forward the measurement information to an accounting 357 application. Nevertheless, if an AAA infrastructure is in place, 358 IPFIX can provide the input for the generation of accounting 359 records and several features of the AAA architecture can be 360 used. Features include the mapping of a user ID to the flow 361 information (by using authentication information), the 362 generation of DIAMETER accounting records and the secure 363 exchange of accounting records between domains with DIAMETER. 364 Two possibilities to connect IPFIX and AAA can be distinguished: 366 3.1.1Connecting via an AAA Client 368 One possibility to connect IPFIX and AAA is to run an AAA client 369 on the IPFIX collector. This client can generate DIAMETER 370 accounting messages and send them to an AAA server. The mapping 371 of the flow information to a user ID can be done in the AAA 372 server by using data from the authentication process. DIAMETER 373 accounting messages can be sent to the accounting application or 374 to other AAA servers (e.g. in roaming scenarios). 376 +---------+ DIAMETER +---------+ 377 | AAA-S |------------->| AAA-S | 378 +---------+ +---------+ 379 ^ 380 | DIAMETER 381 | 382 | 383 +--+--------+--+ 384 | | AAA-C | | 385 + +--------+ | 386 | | 387 | Collector | 388 +--------------+ 389 ^ 390 | IPFIX 391 | 392 +------------+ 393 | Exporter | 394 +------------+ 396 Figure 2: IPFIX collector connects to AAA server via AAA client 398 3.1.2Connecting via an Application Specific Module (ASM) 400 Another possibility is to directly connect the IPFIX collector 401 with the AAA server via an application specific module (ASM). 402 Application specific modules have been proposed by the IRTF AAA 403 architecture research group (AAARCH) in [RFC2903]. They act as 404 an interface between AAA server and service equipment. In this 405 case the IPFIX collector is part of the ASM. The ASM acts as an 406 interface between the IPFIX protocol and the input interface of 407 the AAA server. The ASM translates the received IPFIX data into 408 an appropriate format for the AAA server. The AAA server then 409 can add information about the user ID and generate a DIAMETER 410 accounting record. This accounting record can be sent to an 411 accounting application or to other AAA servers. 413 +---------+ DIAMETER +---------+ 414 | AAA-S |------------->| AAA-S | 415 +---------+ +---------+ 416 ^ 417 | 418 +------------------+ 419 | ASM | 420 | +------------+ | 421 | | Collector | | 422 +------------------+ 423 ^ 424 | IPFIX 425 | 426 +------------+ 427 | Exporter | 428 +------------+ 430 Figure 3: IPFIX connects to AAA server via ASM 432 3.2 IPFIX and RTFM 434 This section compares the Real-time Traffic Flow Measurement 435 (RTFM) framework with the IPFIX framework. 437 3.2.1Definition of 'flow' 439 RTFM and IPFIX both use the same definition of flow; a flow is a 440 set of packets which share a common set of end-point address 441 attribute values. A flow is therefore completely specified by 442 that set of values, together with an inactivity timeout. A flow 443 is considered to have ended when no packets are seen for at 444 least the inactivity time. 446 RTFM flows are bidirectional, which has given rise to some 447 confusion. 448 At the simplest level, a flow information exporter may achieve 449 this by maintaining two unidirectional flows, one for each 450 direction. To export bidirectional flow information, e.g. to- 451 and from- packet counts, for a flow from A to B, the exporter 452 has only to search its flow table to find the matching flow from 453 B to A. 455 RTFM, however, takes bi-directionality a stage further, by 456 including in the RTFM architecture [RFC 2722] a fully-detailed 457 algorithm for real-time matching of the two directions of a 458 flow. This was done for two reasons, to reduce the memory 459 required to store each flow (common address attributes for each 460 direction), and to allow for attributes which required fine 461 detail for the two directions, e.g. short-term bit rate 462 distributions [RFC 2724]. 463 ** So far there has been no suggestion that IPFIX should do 464 this. 466 3.2.2Configuration and Management 468 The RTFM architecture specifies a complete system for gathering 469 flow information. It defines three entities, 470 - Meters are very similar to IPFIX exporters. 471 - Meter Readers are very similar to IPFIX collectors. 472 - Managers co-ordinate the activities of meters and meter 473 readers, and download configuration to them. 475 Note that the whole RTFM system is asynchronous, many readers 476 may collector flow data from a meter, and any reader may collect 477 flow data from many meters. 479 Rulesets allow the user to specify which flows are of interest, 480 which are the source and destination ends of each flow, and what 481 level of address granularity is required in the metered flows. 482 For example, one may select all packets from 192.168/16, but 483 build flow information for 192.168/24. RTFM selection is done 484 by testing under masks, and the masks do not have to use 485 consecutive ones from the left. Non-contiguous masks were 486 considered important for handling some OSI protocols, but the 487 need for that has diminished considerably. 489 The RTFM approach is based on RMON, in that if a user wants to 490 collect flow data for some particular set of flows, this can be 491 achieved by writing a ruleset, i.e. an SRL program [RFC 2723], 492 to specify what flows are of interest, requesting a manager to 493 download that ruleset to a meter, and requesting the manager to 494 have a meter reader collect the flow data at specified 495 intervals. 497 The details of how the manager communicates this information to 498 meters and meter readers are not specified in the architecture. 499 RTFM has a Meter MIB [RFC 2720], which is a standard which can 500 be used to configure a meter, but nothing is said about how to 501 configure a meter reader. 503 The extent to which IPFIX should specify how meters or exporters 504 should be configured is, at this stage, an open question. 505 Clearly a collector needs some way to be sure of what it's 506 collecting, e.g. by receiving 'templates' from the meter. 508 RTFM and IPFIX both leave parts of the system unspecified. For 509 RTFM flow data to be useful one must know the ruleset used to 510 configure the meter, but a user can specify the ruleset. For 511 IPFIX one knows what the data is from the templates, but we have 512 yet to determine whether in-band configuration will be 513 supported. 515 3.2.3Data Model details 517 3.2.3.1 Count in one bucket 519 Within a ruleset, a packet may only be counted on one bucket, 520 i.e. it may only be included in one flow. This means that the 521 meter does not have to keep track of overlapping flows - if such 522 aggregation is required, it must be done after the raw flow data 523 has been read by a meter reader. 525 From time to time one may wish to collect flow data for 526 different levels of aggregation at the same time. RTFM allows a 527 meter to run several rulesets at the same time, and meter 528 readers must specify which rulesets they are collecting data 529 from. 531 The 'count in one bucket' rule, together with the ability to run 532 multiple rulesets, has proved very simple and effective in 533 practice. 535 3.2.3.2 Counter wrapping 537 For its packet- and byte-count attributes RTFM uses 538 continuously-incrementing 64-bit counters, which are never 539 reset. This makes asynchronous meter reading easy, any reader 540 simply has to remember its previous reading and compute the 541 difference. The only caveat is that the meter should be read 542 often enough to avoid situations when the counter has cycled 543 more than once between readings. 545 3.2.3.3 Sampling issues 547 RTFM provides 1 out of N sampling as a configuration option, so 548 that some metering interfaces may only process every Nth packet. 549 The RTFM Architecture [RFC 2722] does not discuss the 550 statistical implications of this, merely saying that users will 551 need to satisfy themselves that sampling makes sense in their 552 environment. 554 RTFM makes no provision for flow sampling. Recently there has 555 been a lot of interest in flow sampling schemes which favour the 556 'most important' flows, perhaps we need to consider this for 557 IPFIX. 559 3.2.4Application/transport protocol 561 RTFM has a standards-track Meter MIB [RFC 2720], which can be 562 used both to configure a meter and to read flow data from it. 563 The MIB provides a way to read lists of attributes with a single 564 Object Identifier (called a 'package'), which dramatically 565 reduces the SNMP overhead for flow data collection. NeTraMet, a 566 widely-used open-source RTFM implementation, uses SNMPv2C for 567 configuration and data collection. 569 SNMP, of course, normally uses UDP as its transport protocol. 570 Since RTFM requires a reliable flow data transport system, an 571 RTFM meter reader must time out and resend unanswered SNMP 572 requests. Apart from being clumsy, this can limit the maximum 573 data transfer rate from meter to meter reader. SNMP over TCP 574 would be a better approach, but that is currently an IRTF 575 project. 577 On the other hand, RTFM does not specify an application protocol 578 in its architecture, leaving this as an implementation issue. 579 For example, a team at IBM Research implemented a RTFM meter and 580 meter reader in a single host, with the reader storing the flow 581 data directly into a large database system. Similarly, many 582 NeTraMet users run the meter and meter reader on the same host 583 system. 585 A need for high flow data rates highlights the need for careful 586 systems design when building a flow data collection system. 587 When data rates are high, and it is not possible to use a high 588 level of aggregation, then it makes sense to have the collectors 589 very close to their exporters. Once the data is safely on a 590 dedicated host machine, large volumes of it can be moved using 591 'background' techniques such as FTP. 593 The RTFM architecture only specifies a pull model for getting 594 data out of a meter. To implement push mode data transfer would 595 require specification of triggers to indicate when data should 596 be sent for each flow. 598 3.3 IPFIX and IPPM 600 The IPFIX protocol can be used to carry IPPM network performance 601 metrics or information that can be used to calculate those 602 metrics (see section 2.7). 604 3.4 IPFIX and IDMEF 606 The Intrusion Detection Message Exchange Format (IDMEF) [CuDF04] 607 is a standard data format developed within the IDWG Working 608 Group to exchange data alerts between automated Intrusion 609 Detection Systems (IDS). IDMEF provides a standard 610 representation of the alert information that an Intrusion 611 Detection analyzer reports when a suspicious event is detected. 612 These alerts may be simple or complex depending on analyzers 613 capabilities, commercial vendor objectives, and intrusion 614 detection environments. IDMEF messages are implemented in XML 615 and composed by a basic schema and extension modules to define 616 alerts that are more complex. Once the kind of alert that should 617 be sent has been determined by the analyzer, it must be 618 formatted following the IDMEF rules. 619 Generally, alerts are sent when analyzers detect an event that 620 they have been configured to look for. 621 The IPFIX protocol can be used complementarily to IDMEF for 622 providing detailed information of intrusions traffic, suspect 623 events or anomalous traffic that differs from the normal network 624 behavior. 626 4. Security Consideration 628 This document describes the usage of IPFIX in various scenarios. 629 The security requirements for the IPFIX target applications are 630 addressed in the IPFIX requirements draft. These requirements 631 must be considered for the specification of the IPFIX protocol. 632 The IPFIX extensions proposed in this document do not induce 633 further security hazards. 635 Section 3 of this document describes how IPFIX can be used in 636 combination with other frameworks. New security hazards can 637 arise when two individually secure frameworks are combined. For 638 the combination of AAA with IPFIX an ASM or an IPFIX collector 639 can function as transit point for the messages. It has to be 640 ensured that at this point the applied security mechanisms (e.g. 641 encryption of messages) are maintained. 643 5. References 645 [Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of 646 Internet Traffic Engineering", (work in progress), 647 Internet Draft, Internet Engineering Task Force, draft- 648 ietf-tewg-principles-02.txt, May 2002 650 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet 651 Distributions,http://www2.auckland.ac.nz/net//Internet/r 652 tfm/meetings/47-adelaide/pp-dist/ 654 [CuDF04] D.Curry, H. Debar, H. Feinstein: ��The Intrusion 655 Detection Message Exchange Format��,(work in progress), 656 Internet Draft, Internet Engineering Task Force, , January 2004 659 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory 660 Sampling for Direct Traffic Observation", Proceedings of 661 ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - 662 September 1, 2000. 664 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed 665 MARTENS, John G. CLEARY: Nonintrusive and Accurate 666 Measurement of Unidirectional Delay and Delay Variation 667 on the Internet, INET'98, Geneva, Switzerland, 21-24 668 July, 1998 670 [MaPZ03] L. Mark, G. Pohl, T. Zseby, K. Sugauchi: Passive One- 671 way Delay Measurements, (work in progress), Internet 672 Draft , June 2003 674 [QuZC03] J. Quittek ,et. Al "Requirements for IP Flow 675 Information Export ", (work in progress) ,Internet 676 Draft, Internet Engineering Task Force, , June 2003 679 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay 680 Metric for IPPM, Request for Comments: 2679, September 681 1999 683 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet 684 Loss Metric for IPPM, September 1999 686 [RFC2681]G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip 687 Delay Metric for IPPM.", RFC 2681, September 1999 689 [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. 690 Spence, "Generic AAA Architecture", RFC 2903, August 691 2000 693 [RFC3393] C. Demichelis, P. Cimento: IP Packet Delay Variation 694 Metric for IPPM, RFC 3393, November 200 696 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation 697 of Building Blocks for Passive One-way-delay 698 Measurements, Proceedings of Passive and Active 699 Measurement Workshop (PAM 2001), Amsterdam, The 700 Netherlands, April 23-24, 2001 702 6. Acknowledgements 704 We would like to thank the following persons for their 705 contribution, discussion on the mailing list and valuable 706 comments: 708 - Sebastian Zander 709 - Robert Loewe 711 Part of the work has been developed in the research project 6QM 712 co-funded with support from the European Commission. 714 7. Author's Addresses 716 Tanja Zseby 717 Fraunhofer Institute for Open Communication Systems (FOKUS) 718 Kaiserin-Augusta-Allee 31 719 10589 Berlin, Germany 720 Phone: +49 30 3463 7153 721 Email: zseby@fokus.fhg.de 723 Elisa Boschi 724 Fraunhofer Institute for Open Communication Systems (FOKUS) 725 Kaiserin-Augusta-Allee 31 726 10589 Berlin, Germany 727 Phone: +49 30 3463 7366 728 Email: boschi@fokus.fhg.de 730 Reinaldo Penno 731 Nortel Networks, Inc. 732 2305 Mission College Boulevard 733 Building SC9-B1240, Santa Clara, CA 95134 734 Email: rpenno@nortelnetworks.com 736 Nevil Brownlee 737 CAIDA (UCSD/SDSC) 738 9500 Gilman Drive 739 La Jolla, CA 92093-0505 740 Phone : +1 858 534 8338 741 Email : nevil@caida.org 743 Benoit Claise 744 Cisco Systems 745 De Kleetlaan 6a b1 746 1831 Diegem 747 Belgium 748 Phone: +32 2 704 5622 749 Email: bclaise@cisco.com 751 8. Full Copyright Statement 753 "Copyright (C) The Internet Society (date). All Rights Reserved. 754 This document and translations of it may be copied and furnished 755 to others, and derivative works that comment on or otherwise 756 explain it or assist in its implementation may be prepared, 757 copied, published and distributed, in whole or in part, without 758 restriction of any kind, provided that the above copyright 759 notice and this paragraph are included on all such copies and 760 derivative works. However, this document itself may not be 761 modified in any way, such as by removing the copyright notice or 762 references to the Internet Society or other Internet 763 organizations, except as needed for the purpose of developing 764 Internet standards in which case the procedures for copyrights 765 defined in the Internet Standards process must be followed, or 766 as required to translate it into.