idnits 2.17.1 draft-ietf-ipfix-as-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 917. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 924. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 930. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 20 longer pages, the longest (page 16) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 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.) == 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2004) is 7126 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 323, but not defined == Missing Reference: 'RFC 2722' is mentioned on line 603, but not defined == Missing Reference: 'RFC 2724' is mentioned on line 514, but not defined == Missing Reference: 'RFC 2723' is mentioned on line 543, but not defined == Missing Reference: 'RFC 2720' is mentioned on line 618, but not defined == Missing Reference: 'PSAMP-PROTOCOL' is mentioned on line 671, but not defined == Unused Reference: 'QuZC03' is defined on line 778, but no explicit reference was found in the text == Unused Reference: 'Awdu02' is defined on line 784, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3917 (ref. 'QuZC03') -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) Summary: 7 errors (**), 0 flaws (~~), 14 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Tanja Zseby 2 Document: Elisa Boschi 3 Expires: April 2005 Fraunhofer FOKUS 4 Reinaldo Penno 5 Nortel Networks 6 Nevil Brownlee 7 CAIDA 8 Benoit Claise 9 Cisco Systems 11 October 2004 13 IPFIX Applicability 14 draft-ietf-ipfix-as-03.txt 16 Status of this Memo 18 This document is an Internet-Draft and is subject to all 19 provisions of section 3 of RFC 3667. By submitting this 20 Internet-Draft, each author represents that any applicable 21 patent or other IPR claims of which he or she is aware have been 22 or will be disclosed, and any of which he or she become aware 23 will be disclosed, in accordance with RFC 3668. 25 Internet-Drafts are working documents of the Internet 26 Engineering Task Force (IETF), its areas, and its working 27 groups. Note that other groups may also distribute working 28 documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other 31 documents at any time. It is inappropriate to use Internet- 32 Drafts as reference material or to cite them other than as "work 33 in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 IPFIX Applicability 47 Abstract 49 This document describes what type of applications can use the IP 50 Flow Information Export (IPFIX) protocol and how they can use 51 the information provided by IPFIX. It furthermore shows how the 52 IPFIX framework relates to other architectures and frameworks. 54 IPFIX Applicability 56 Table of Contents 57 1. Introduction.............................................3 58 2. Applications of IPFIX....................................4 59 2.1 Accounting...............................................4 60 2.2 Security Analysis and Intrusion Detection with IPFIX.....4 61 2.3 Network Planning.........................................5 62 2.4 Peering Agreements.......................................6 63 2.5 Traffic Engineering......................................6 64 2.6 Data Warehousing and Mining..............................6 65 2.7 SLA validation...........................................6 66 2.8 Traffic Monitoring.......................................7 67 2.8.1 Measurement of Round-trip-time (RTT)....................7 68 2.8.2 Measurement of One-way-delay (OWD)......................8 69 2.8.3 Measurement of One-way-loss (OWL).......................8 70 2.8.4 Measurement of IP delay variation (IPDV)................9 71 3. Relation of IPFIX to other frameworks and protocols......9 72 3.1 IPFIX and AAA............................................9 73 3.1.1 Connecting via an AAA Client...........................10 74 3.1.2 Connecting via an Application Specific Module (ASM)....11 75 3.2 IPFIX and RTFM..........................................12 76 3.2.1 Definition of 'flow'...................................12 77 3.2.2 Configuration and Management...........................13 78 3.2.3 Data Model Details.....................................14 79 3.2.4 Application/Transport Protocol.........................15 80 3.3 IPFIX and IPPM..........................................15 81 3.4 IPFIX and PSAMP.........................................16 82 3.4.1 Export using one-packet flow records...................16 83 3.4.2 Export using flow and packet properties templates......16 84 3.5 IPFIX and IDMEF.........................................17 85 4. IPFIX and Ipv6..........................................17 86 5. Where not to use IPFIX..................................17 87 6. Security Considerations.................................18 88 7. Normative References....................................18 89 8. Informative References..................................18 90 9. Acknowledgements........................................19 91 10. Author's Addresses......................................19 92 11. Copyright Statement.....................................20 93 12. Intellectual Property Statement.........................21 94 13. Disclaimer..............................................21 96 1. Introduction 98 The IPFIX protocol defines how IP Flow information can be 99 exported from routers, measurement probes or other devices. It 100 is intended to provide this information as input for various 101 applications. This document describes what applications can use 102 the IPFIX protocol and how they can use it. Furthermore, the 104 IPFIX Applicability 106 relationship of IPFIX to other frameworks and architectures is 107 described. 109 2. Applications of IPFIX 111 IPFIX data enables several critical customer applications. This 112 section describes how different applications can use IPFIX. 114 2.1 Accounting 116 Usage based accounting is one of the major applications for 117 which the IPFIX protocol has been developed. IPFIX data provide 118 fine-grained metering (for example, flow records include details 119 such as IP addresses, packet and byte counts, timestamps, Type 120 of Service (ToS), application ports, etc.) for highly flexible 121 and detailed resource usage accounting. ISPs can use this 122 information to migrate from single fee, flat-rate billing to 123 more flexible charging mechanisms based on time of day, 124 bandwidth usage, application usage, quality of service, etc. 125 Enterprise customers can use this information for departmental 126 chargeback or cost allocation for resource usage. 128 In order to realize usage-based accounting with IPFIX the flow 129 definition has to be chosen in accordance to the tariff model. A 130 tariff can, for instance, be based on individual end-to-end 131 streams. In that case accounting can be realized with a flow 132 definition determined by the quintuple that consists of source 133 address, destination address, protocol and port numbers. Another 134 example is a class-dependent tariff (e.g. in a DiffServ 135 network). For this flows could be distinguished just by DiffServ 136 codepoint (DSCP) and source address. 138 The essential elements needed for accounting are the number of 139 transferred packets and bytes per flow which are contained in 140 IPFIX flow records. Furthermore IPFIX provides a very flexible 141 definition of flows, so arbitrary flow-based accounting models 142 can be realized without any extensions to the IPFIX protocol. 143 Nevertheless the configuration of flow definitions is out of 144 scope of the IPFIX definition. 146 For accounting purposes, it would be advantageous to have the 147 ability to use IPFIX flow records as accounting input in an AAA 148 infrastructure. AAA servers then could provide the mapping 149 between user and flow information. 151 2.2 Security Analysis and Intrusion Detection with IPFIX 153 IPFIX Applicability 155 Intrusion detection systems (IDS) monitor and control security 156 incidents. A typical IDS system includes components like sensor, 157 event collector, and management stations. Sensors monitor 158 network and system traffic for attacks and other security- 159 related events. Sensors respond to and notify the administrator 160 about these events as they occur. Event collectors are a middle- 161 tier component responsible for transmitting events from sensors 162 to the console and database. The management component serves the 163 following purposes: 165 _ - visually monitors events (with a console) 166 _ - collects data from sensors (with one or more event 167 collectors) 168 _ - stores data from sensors (in a database) 170 IPFIX can report events of interest to the sensor either by the 171 collecting process or directly by the exporting process. Which 172 approach is best depends on the scenario and the events of 173 interest. Getting information directly from the exporting 174 process has the advantage that the sensor gets the information 175 faster. It does not need to wait for collector processing time 176 or until the collector has all relevant data. Getting the 177 information from a collector allows correlating data from 178 different exporting processes (e.g. from different routers) to 179 get a better picture of what is going on in the network. 181 IPFIX provides useful input data for basic intrusion detection 182 functions (e.g. detecting unusually high loads) such as details 183 on source and destination addresses, along with the start time 184 of flows, TCP flags, application ports and flow volume. This 185 data can be used to analyze network security incidents and 186 identify attacks. Nevertheless, for some scenarios intrusion 187 detection may require further insight into packet content. Since 188 IPFIX allows a flexible report definition, the metering process 189 and the IPFIX report format could be extended to support other 190 data needed for intrusion detection systems. 192 Detecting security incidents in real-time would require the pre- 193 processing of data already at the measurement device and 194 immediate data export in case a possible incident has been 195 identified. This means that IPFIX reports must be generated upon 196 incident detection events and not only upon flow end or fixed 197 time intervals. 199 2.3 Network Planning 201 IPFIX data captured over a long period of time can be used to 202 track and anticipate network growth and plan upgrades to 204 IPFIX Applicability 206 increase the number of routing devices, ports, or higher- 207 bandwidth interfaces. IPFIX data optimizes both strategic 208 network planning (peering, backbone upgrade planning, and 209 routing policy planning) as well as tactical network engineering 210 decisions (upgrading the router or link capacity). This helps to 211 minimize the total cost of network operations while maximizing 212 network performance, capacity, and reliability. 214 2.4 Peering Agreements 216 IPFIX data enables ISP peering partners to measure the volume 217 and characteristics of traffic exchanged with other ISP peers. 218 ISP peering partners, consortia, or business coalitions can use 219 IPFIX to exchange data between different domains. Having a means 220 to share measurement data allows for more accurate end-to-end 221 measurements. Through IPFIX data measured with different (often 222 domain specific) tools can be exchanged and compared with data 223 belonging to other domains. 224 This is especially useful for inter-domain SLA validation where, 225 in order to be able to provide accurate data, an ISP has to 226 obtain measurements from other ISPs crossed in the end-to-end 227 path. 229 2.5 Traffic Engineering 231 IPIFX data provides traffic engineering details for a set of 232 prefixes. This data can be used in network optimization for load 233 balancing traffic across alternate paths, or for forwarding 234 traffic of a certain set of prefixes on a preferred route. 236 2.6 Data Warehousing and Mining 238 IPFIX data (or derived information) can be stored for later 239 retrieval and analysis to support proactive marketing and 240 customer service programs. An example of this would be to 241 determine which applications and services are being used by 242 internal and external users and then target them for improved 243 services such as advertising. This is especially useful for ISPs 244 because IPFIX data enables them to create better service 245 packaging. 247 2.7 SLA validation 249 Performing QoS monitoring is one target application of the IPFIX 250 protocol. QoS monitoring is the passive observation of 251 transmission quality for single flows or traffic aggregates in 252 the network. One example of its usefulness is the validation of 254 IPFIX Applicability 256 QoS guarantees in service level agreements (SLAs). Some QoS 257 metrics require the correlation of data from multiple 258 measurement points. For this the clocks of the involved 259 exporting devices must be synchronized. Furthermore, such 260 measurements would benefit from post-processing functions (e.g. 261 packet ID generation and mapping) at the exporter and/or 262 collector. 264 2.8 Traffic Monitoring 266 IPFIX data can be used for extensive near real-time traffic 267 monitoring. Traffic patterns associated with routing devices and 268 switches on an individual or network wide basis can be displayed 269 enabling proactive problem detection, efficient troubleshooting, 270 and rapid problem resolution. 272 IPFIX data enables content and service providers to perform a 273 detailed, time-based, and application-based usage analysis of a 274 network. They also provide detailed information for 275 understanding customer or end-user usage of network and 276 application resources. This information can then be used to 277 efficiently plan and allocate access, backbone, and application 278 resources, as well as to detect and resolve potential security 279 and policy violations. 281 This section describes how the monitoring of different metrics 282 can be performed with IPFIX. All of the metrics require at least 283 an extension of the IPFIX information model because the 284 necessary information such as round-trip-time, packet Ids, etc., 285 is currently not part of the model. However given the 286 extensibility and flexibility of IPFIX the missing attributes 287 can be easily defined. 289 2.8.1 Measurement of Round-trip-time (RTT) 291 The passive measurement of round-trip-times (RTT) can be 292 performed by using packet pair matching techniques as described 293 in [Brow00]. For the measurements, request/response packet pairs 294 from protocols such as DNS, ICMP, SNMP or TCP (syn/syn-ack, 295 data/ack) are utilized to passively observe the RTT [Brow00]. As 296 always, this only works for passive measurements if the required 297 traffic of interest is actually present in the network. 298 Furthermore, if the observed protocol supports retransmissions 299 (e.g. TCP) the RTT is not the network RTT but rather the RTT of 300 the network and the protocol stack of the receiver. In case the 301 reply packet is lost or can not be observed the RTT can not be 302 calculated. 304 IPFIX Applicability 306 In order to use this measurement technique, the IPFIX metering 307 process needs to measure in both directions. A classification of 308 the protocols mentioned above has to be done. That means parts 309 of the transport header are used for the classification. Since a 310 differentiation of flows in accordance to the transport header 311 is one of the requirements for IPFIX, such classification can be 312 performed without extensions. Nevertheless, the meter needs to 313 recognize request and response packets for the given protocols 314 and therefore needs to look further into the packets. The 315 capability to do this analysis is not part of the IPFIX 316 requirements but can be achieved by optional extensions to the 317 classification process. The exporting device needs to assign a 318 timestamp for the arrival of the packets. The calculation of the 319 RTT can be done directly at the exporter or at the collector. In 320 the first case IPFIX would transfer the calculated RTT to the 321 collector. In the second case IPFIX needs to send the observed 322 packet types and the timestamps to the collector. The round- 323 trip-time-delay metric is defined in [RFC2681]. 325 2.8.2 Measurement of One-way-delay (OWD) 327 Passive one-way-delay measurements require the collection of 328 data at two measurement points. It is necessary to recognize 329 packets at the second measurement point to correlate packet 330 arrival events from both points. This can be done by capturing 331 packet header and parts of the packet that can be used to 332 recognize the same packet at the subsequent measurement point. 333 To reduce the amount of measurement data a unique packet ID can 334 be calculated from the header and part and/of the content e.g. 335 by using a CRC or hash function [GrDM98, DuGr00, ZsZC01]. The 336 capability of using content information is out of scope of IPFIX 337 but can be achieved by an optional extension. Nevertheless, in 338 some scenarios it might even be sufficient to calculate a packet 339 ID based on header fields (including datagram ID and maybe 340 sequence numbers from transport protocols) without looking at 341 parts of the packet content. If packet IDs need to be unique 342 only for a certain time interval or a certain amount of packet 343 ID collisions is tolerable this is a sufficient solution. The 344 second issue is the export of packet IDs. IPFIX exports per flow 345 information. However, it is possible to extend IPFIX with a 346 scheme to export per-packet information by providing special 347 templates for that purpose. The one way delay metric is defined 348 in [RFC2679]. 350 2.8.3 Measurement of One-way-loss (OWL) 352 Passive loss measurements for single flows can be performed at 353 one measurement point by using sequence numbers that are present 355 IPFIX Applicability 357 in protocols (e.g. IP identification, TCP sequence numbers) 358 similar to the approach described in section 2.8.1. This 359 requires the capturing of the sequence numbers of subsequent 360 packets of the observed flow by the IPFIX metering process. 362 An alternative to this is to perform a two-point measurement as 363 described in section 2.8.2 and consider packets as lost that do 364 not arrive at the second measurement point in a given time 365 frame. This approach assumes that a packet observed at the first 366 point should also be observed at the second point (known 367 routing). 369 The one-way loss metric is defined in [RFC2680]. 371 2.8.4 Measurement of IP delay variation (IPDV) 373 IP Delay variation is defined as the difference of one-way-delay 374 values for selected packets [RFC3393]. Therefore, this metric 375 can be calculated by performing passive measurement of one-way- 376 delay for subsequent packets (e.g. of a flow) and then 377 calculating the differences. 379 3. Relation of IPFIX to other frameworks and protocols 381 3.1 IPFIX and AAA 383 AAA defines a protocol and architecture for authentication, 384 authorization and accounting for service usage. The DIAMETER 385 protocol is used for AAA communication for network access 386 services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture 387 [RFC2903] provides a framework for extending the AAA support 388 also for other services. DIAMETER defines the exchange of 389 messages between AAA entities, e.g. between AAA clients at 390 access devices and AAA servers and among AAA servers. It is used 391 also for the transfer of accounting records. Usage-based 392 accounting requires measurement data from the network. IPFIX 393 defines a protocol to export such data from routers, measurement 394 probes and other devices. 396 The provisioning of accounting with IPFIX can be realized 397 without an AAA infrastructure. The collector can directly 398 forward the measurement information to an accounting 399 application. Nevertheless, if an AAA infrastructure is in place, 400 IPFIX can provide the input for the generation of accounting 401 records and several features of the AAA architecture can be 402 used. Features include the mapping of a user ID to the flow 403 information (by using authentication information), the 404 generation of DIAMETER accounting records and the secure 406 IPFIX Applicability 408 exchange of accounting records between domains with DIAMETER. 409 Two possibilities to connect IPFIX and AAA can be distinguished: 411 3.1.1 Connecting via an AAA Client 413 One possibility means of connecting IPFIX and AAA is to run an 414 AAA client on the IPFIX collector. This client can generate 415 DIAMETER accounting messages and send them to an AAA server. The 416 mapping of the flow information to a user ID can be done in the 417 AAA server by using data from the authentication process. 418 DIAMETER accounting messages can be sent to the accounting 419 application or to other AAA servers (e.g. in roaming scenarios). 421 IPFIX Applicability 423 +---------+ DIAMETER +---------+ 424 | AAA-S |------------->| AAA-S | 425 +---------+ +---------+ 426 ^ 427 | DIAMETER 428 | 429 | 430 +--+--------+--+ 431 | | AAA-C | | 432 + +--------+ | 433 | | 434 | Collector | 435 +--------------+ 436 ^ 437 | IPFIX 438 | 439 +------------+ 440 | Exporter | 441 +------------+ 443 Figure 2: IPFIX collector connects to AAA server via AAA client 445 3.1.2 Connecting via an Application Specific Module (ASM) 447 Another possibility is to directly connect the IPFIX collector 448 with the AAA server via an application specific module (ASM). 449 Application specific modules have been proposed by the IRTF AAA 450 architecture research group (AAARCH) in [RFC2903]. They act as 451 an interface between AAA server and service equipment. In this 452 case the IPFIX collector is part of the ASM. The ASM acts as an 453 interface between the IPFIX protocol and the input interface of 454 the AAA server. The ASM translates the received IPFIX data into 455 an appropriate format for the AAA server. The AAA server then 456 can add information about the user ID and generate a DIAMETER 457 accounting record. This accounting record can be sent to an 458 accounting application or to other AAA servers. 460 IPFIX Applicability 462 +---------+ DIAMETER +---------+ 463 | AAA-S |------------->| AAA-S | 464 +---------+ +---------+ 465 ^ 466 | 467 +------------------+ 468 | ASM | 469 | +------------+ | 470 | | Collector | | 471 +------------------+ 472 ^ 473 | IPFIX 474 | 475 +------------+ 476 | Exporter | 477 +------------+ 479 Figure 3: IPFIX connects to AAA server via ASM 481 3.2 IPFIX and RTFM 483 This section compares the Real-time Traffic Flow Measurement 484 (RTFM) framework with the IPFIX framework. 486 3.2.1 Definition of 'flow' 488 RTFM and IPFIX both use the same definition of flow; a flow is a 489 set of packets which share a common set of end-point address 490 attribute values. A flow is therefore completely specified by 491 that set of values, together with an inactivity timeout. A flow 492 is considered to have ended when no packets are seen for at 493 least the inactivity time. 495 RTFM flows are bidirectional, which has given rise to some 496 confusion. 497 At the simplest level, a flow information exporter may achieve 498 this by maintaining two unidirectional flows, one for each 499 direction. To export bidirectional flow information, e.g. to- 500 and from- packet counts, for a flow from A to B, the exporter 501 has only to search its flow table to find the matching flow from 502 B to A. 504 RTFM, however, takes bi-directionality a step further, by 505 including in the RTFM architecture [RFC 2722] a fully-detailed 506 algorithm for real-time matching of the two directions of a 507 flow. This was done for two reasons: to reduce the memory 508 required to store each flow (common address attributes for each 510 IPFIX Applicability 512 direction), and to allow for attributes which required fine 513 detail for the two directions, e.g. short-term bit rate 514 distributions [RFC 2724]. 515 ** So far there has been no suggestion that IPFIX should do 516 this. 518 3.2.2 Configuration and Management 520 The RTFM architecture specifies a complete system for gathering 521 flow information. It defines three entities, 522 - Meters are very similar to IPFIX exporters. 523 - Meter Readers are very similar to IPFIX collectors. 524 - Managers coordinate the activities of meters and meter 525 readers, and download configuration to them. 527 Note that the whole RTFM system is asynchronous; many readers 528 may collector flow data from a meter, and any reader may collect 529 flow data from many meters. 531 Rulesets allow the user to specify which flows are of interest, 532 which are the source and destination ends of each flow, and what 533 level of address granularity is required in the metered flows. 534 For example, one may select all packets from 192.168/16, but 535 build flow information for 192.168/24. RTFM selection is done 536 by testing under masks, and the masks do not have to use 537 consecutive ones from the left. Non-contiguous masks were 538 considered important for handling some OSI protocols, but the 539 need for that has diminished considerably. 541 The RTFM approach is based on RMON, in that if a user wants to 542 collect flow data for some particular set of flows, this can be 543 achieved by writing a ruleset, i.e. an SRL program [RFC 2723], 544 to specify what flows are of interest, requesting a manager to 545 download that ruleset to a meter, and requesting the manager to 546 have a meter reader collect the flow data at specified 547 intervals. 549 The details of how the manager communicates this information to 550 meters and meter readers are not specified in the architecture. 551 RTFM has a Meter MIB [RFC 2720], which is a standard which can 552 be used to configure a meter, but nothing is said about how to 553 configure a meter reader. 555 The extent to which IPFIX should specify how meters or exporters 556 should be configured is, at this stage, an open question. 557 Clearly a collector needs some way to be sure of what it's 558 collecting, e.g. by receiving 'templates' from the meter. 560 IPFIX Applicability 562 RTFM and IPFIX both leave parts of the system unspecified. For 563 RTFM flow data to be useful one must know the ruleset used to 564 configure the meter, but a user can specify the ruleset. For 565 IPFIX one knows what the data is from the templates, but we have 566 yet to determine whether in-band configuration will be 567 supported. 569 3.2.3 Data Model Details 571 3.2.3.1 Count in One Bucket 573 Within a ruleset, a packet may only be counted in one bucket, 574 i.e. it may only be included in one flow. This means that the 575 meter does not have to keep track of overlapping flows - if such 576 aggregation is required, it must be done after the raw flow data 577 has been read by a meter reader. 579 From time to time one may wish to collect flow data for 580 different levels of aggregation at the same time. RTFM allows a 581 meter to run several rulesets at the same time, and meter 582 readers must specify which rulesets they are collecting data 583 from. 585 The 'count in one bucket' rule, together with the ability to run 586 multiple rulesets, has proved very simple and effective in 587 practice. 589 3.2.3.2 Counter Wrapping 591 For its packet- and byte-count attributes RTFM uses 592 continuously-incrementing 64-bit counters, which are never 593 reset. This makes asynchronous meter reading easy, any reader 594 simply has to remember its previous reading and compute the 595 difference. The only caveat is that the meter should be read 596 often enough to avoid situations when the counter has cycled 597 more than once between readings. 599 3.2.3.3 Sampling Issues 601 RTFM provides 1 out of N sampling as a configuration option, so 602 that some metering interfaces may only process every Nth packet. 603 The RTFM Architecture [RFC 2722] does not discuss the 604 statistical implications of this, merely saying that users will 605 need to satisfy themselves that sampling makes sense in their 606 environment. 608 RTFM makes no provision for flow sampling. Recently there has 609 been a lot of interest in flow sampling schemes which favour the 611 IPFIX Applicability 613 'most important' flows. Perhaps we need to consider this for 614 IPFIX. 616 3.2.4 Application/Transport Protocol 618 RTFM has a standards-track Meter MIB [RFC 2720], which can be 619 used both to configure a meter and to read flow data from it. 620 The MIB provides a way to read lists of attributes with a single 621 Object Identifier (called a 'package'), which dramatically 622 reduces the SNMP overhead for flow data collection. NeTraMet, a 623 widely-used open-source RTFM implementation, uses SNMPv2C for 624 configuration and data collection. 626 SNMP, of course, normally uses UDP as its transport protocol. 627 Since RTFM requires a reliable flow data transport system, an 628 RTFM meter reader must time out and resend unanswered SNMP 629 requests. Apart from being clumsy, this can limit the maximum 630 data transfer rate from meter to meter reader. SNMP over TCP 631 would be a better approach, but that is currently an IRTF 632 project. 634 On the other hand, RTFM does not specify an application protocol 635 in its architecture, leaving this as an implementation issue. 636 For example, a team at IBM Research implemented a RTFM meter and 637 meter reader in a single host, with the reader storing the flow 638 data directly into a large database system [reference]. 639 Similarly, many NeTraMet users run the meter and meter reader on 640 the same host system. 642 A need for high flow data rates highlights the need for careful 643 systems design when building a flow data collection system. 644 When data rates are high, and it is not possible to use a high 645 level of aggregation, then it makes sense to have the collectors 646 very close to their exporters. Once the data is safely on a 647 dedicated host machine, large volumes of it can be moved using 648 'background' techniques such as FTP. 650 The RTFM architecture only specifies a pull model for getting 651 data out of a meter. To implement push mode data transfer would 652 require specification of triggers to indicate when data should 653 be sent for each flow. 655 3.3 IPFIX and IPPM 657 The IPFIX protocol can be used to carry IPPM network performance 658 metrics or information that can be used to calculate those 659 metrics (see section2.8). 661 IPFIX Applicability 663 3.4 IPFIX and PSAMP 665 There is currently a very dynamic relation between IPFIX and 666 PSAMP. PSAMP defines, between others, the information to be 667 reported on sampled packets, describes the protocol by which 668 this information is reported and the protocol by which the 669 packet reporting is configured. The Working Group describes in 670 [PSAMP-FRAMEWORK] a set of requirements that affect directly the 671 export protocol. In [PSAMP-PROTOCOL] the requirements have been 672 analyzed with respect to IPFIX and the conclusion is that IPFIX 673 is an exporting protocol general enough to be suitable for 674 PSAMP. 675 The major difference between IPFIX and PSAMP protocols is that 676 while the former exports flow records, the latter exports packet 677 records. The following sections describe two different ways to 678 export sampled packets using IPFIX. 680 3.4.1 Export using one-packet flow records 682 A single packet can be considered a special case of a flow. So, 683 a PSAMP export would be a special IPFIX flow record containing 684 information about a flow composed of a single packet. Using this 685 method, no modifications would be required for IPFIX at the 686 actual stage, but flow information would be repeated for every 687 packet introducing a high degree of redundancy. 689 +------+------+------------+---------+ 690 | srcA | dstA | packet info| ... | 691 +------+------+------------+---------+ 692 | srcA | dstA | packet info| ... | 693 +------+------+------------+---------+ 694 | srcB | dstB | packet info| ... | 695 +------+------+------------+---------+ 696 | srcA | dstA | packet info| ... | 697 +------+------+------------+---------+ 699 Figure 3: Exporting One-packet flows 701 3.4.2 Export using flow and packet properties templates 703 Packet information can be exported using two templates: a Packet 704 Properties Template containing the information related to the 705 sampled packet and a Flow Property Template summarizing flow 706 information. The relation between the two templates is kept by 707 using indices that link a packet to the flow it belongs to. This 708 method is shown in the following figure. 710 IPFIX Applicability 712 Packet Properties 713 +-----+------------+---------+ 714 Flow Properties |idxA | packet info| ... | 715 +------+------+-----+ +-----+------------+---------+ 716 | srcA | dstA |idxA | |idxA | packet info| ... | 717 +------+------+-----+ +-----+------------+---------+ 718 | srcB | dstB |idxB <-------->idxB | packet info| ... | 719 +------+------+-----+ +-----+------------+---------+ 720 |idxB | packet info| ... | 721 +-----+------------+---------+ 723 Figure 4: Packet Properties and Flow Properties templates for 724 PSAMP export 726 3.5 IPFIX and IDMEF 728 The Intrusion Detection Message Exchange Format (IDMEF) [CuDF04] 729 is a standard data format developed within the IDWG Working 730 Group to exchange data alerts between automated Intrusion 731 Detection Systems (IDS). IDMEF provides a standard 732 representation of the alert information that an Intrusion 733 Detection analyzer reports when a suspicious event is detected. 734 These alerts may be simple or complex depending on analyzers 735 capabilities, commercial vendor objectives, and intrusion 736 detection environments. IDMEF messages are implemented in XML 737 and composed by a basic schema and extension modules to define 738 alerts that are more complex. Once the kind of alert that should 739 be sent has been determined by the analyzer, it must be 740 formatted following the IDMEF rules. 741 Generally, alerts are sent when analyzers detect an event that 742 they have been configured to look for. 743 The IPFIX protocol can be used complementarily to IDMEF for 744 providing detailed information of intrusions traffic, suspect 745 events or anomalous traffic that differs from normal network 746 behavior. 748 4. IPFIX and Ipv6 750 5. Where not to use IPFIX 752 The goal of this section is to give recommendations where not to 753 use IPFIX. While the protocol is general enough to be adequate 754 for exporting flow data in many applications, it still has 755 limitations. 757 IPFIX Applicability 759 6. Security Considerations 761 This document describes the usage of IPFIX in various scenarios. 762 The security requirements for the IPFIX target applications are 763 addressed in the IPFIX requirements draft. These requirements 764 must be considered for the specification of the IPFIX protocol. 765 The IPFIX extensions proposed in this document do not induce 766 further security hazards. 768 Section 3 of this document describes how IPFIX can be used in 769 combination with other frameworks. New security hazards can 770 arise when two individually secure frameworks are combined. For 771 the combination of AAA with IPFIX an ASM or an IPFIX collector 772 can function as transit point for the messages. It has to be 773 ensured that at this point the applied security mechanisms (e.g. 774 encryption of messages) are maintained. 776 7. Normative References 778 [QuZC03] J. Quittek ,et. al "Requirements for IP Flow 779 Information Export ", Request for Comments: RFC 3917, 780 October 2004 782 8. Informative References 784 [Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of 785 Internet Traffic Engineering", (work in progress), 786 Internet Draft, Internet Engineering Task Force, draft- 787 ietf-tewg-principles-02.txt, May 2002 789 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet 790 Distributions,http://www2.auckland.ac.nz/net//Internet/r 791 tfm/meetings/47-adelaide/pp-dist/ 793 [CuDF04] D.Curry, H. Debar, H. Feinstein: ��The Intrusion 794 Detection Message Exchange Format��,(work in progress), 795 Internet Draft, Internet Engineering Task Force, , January 2004 798 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory 799 Sampling for Direct Traffic Observation", Proceedings of 800 ACM SIGCOMM 2000, Stockholm, Sweden, August 28 - 801 September 1, 2000. 803 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed 804 MARTENS, John G. CLEARY: Nonintrusive and Accurate 805 Measurement of Unidirectional Delay and Delay Variation 807 IPFIX Applicability 809 on the Internet, INET'98, Geneva, Switzerland, 21-24 810 July, 1998 812 [PSAMP-FRAMEWORK] N. Duffield, D. Chiou, B. Claise, A. Greenber, 813 M. Grossglauser "A Framework for Passive Packet 814 Measurement" (work in progress), Internet draft , 817 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay 818 Metric for IPPM, Request for Comments: 2679, September 819 1999 821 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet 822 Loss Metric for IPPM, September 1999 824 [RFC2681]G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip 825 Delay Metric for IPPM.", RFC 2681, September 1999 827 [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. 828 Spence, "Generic AAA Architecture", RFC 2903, August 829 2000 831 [RFC3393] C. Demichelis, P. Cimento: IP Packet Delay Variation 832 Metric for IPPM, RFC 3393, November 200 834 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation 835 of Building Blocks for Passive One-way-delay 836 Measurements, Proceedings of Passive and Active 837 Measurement Workshop (PAM 2001), Amsterdam, The 838 Netherlands, April 23-24, 2001 840 9. Acknowledgements 842 We would like to thank the following persons for their 843 contribution, discussion on the mailing list and valuable 844 comments: 846 - Sebastian Zander 847 - Robert Loewe 849 Part of the work has been developed in the research project 6QM 850 co-funded with support from the European Commission. 852 10.Author's Addresses 854 Tanja Zseby 856 IPFIX Applicability 858 Fraunhofer Institute for Open Communication Systems (FOKUS) 859 Kaiserin-Augusta-Allee 31 860 10589 Berlin, Germany 861 Phone: +49 30 3463 7153 862 Email: zseby@fokus.fhg.de 864 Elisa Boschi 865 Fraunhofer Institute for Open Communication Systems (FOKUS) 866 Kaiserin-Augusta-Allee 31 867 10589 Berlin, Germany 868 Phone: +49 30 3463 7366 869 Email: boschi@fokus.fhg.de 871 Reinaldo Penno 872 Nortel Networks, Inc. 873 2305 Mission College Boulevard 874 Building SC9-B1240, Santa Clara, CA 95134 875 Email: rpenno@nortelnetworks.com 877 Nevil Brownlee 878 CAIDA (UCSD/SDSC) 879 9500 Gilman Drive 880 La Jolla, CA 92093-0505 881 Phone : +1 858 534 8338 882 Email : nevil@caida.org 884 Benoit Claise 885 Cisco Systems 886 De Kleetlaan 6a b1 887 1831 Diegem 888 Belgium 889 Phone: +32 2 704 5622 890 Email: bclaise@cisco.com 892 11. Copyright Statement 894 Copyright (C) The Internet Society (2004). This document is 895 subject to the rights, licenses and restrictions contained in 896 BCP 78, and except as set forth therein, the authors retain all 897 their rights. 899 IPFIX Applicability 901 12. Intellectual Property Statement 903 The IETF has been notified by Cisco of intellectual property 904 rights claimed in regard to some or all of the specification 905 contained in this document. For more information, see 906 http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-ipfix- 907 protocol.txt 909 The IETF takes no position regarding the validity or scope of 910 any Intellectual Property Rights or other rights that might be 911 claimed to pertain to the implementation or use of the 912 technology described in this document or the extent to which any 913 license under such rights might or might not be available; nor 914 does it represent that it has made any independent effort to 915 identify any such rights. Information on the procedures with 916 respect to rights in RFC documents can be found in BCP 78 and 917 BCP 79. 919 Copies of IPR disclosures made to the IETF Secretariat and any 920 assurances of licenses to be made available, or the result of an 921 attempt made to obtain a general license or permission for the 922 use of such proprietary rights by implementers or users of this 923 specification can be obtained from the IETF on-line IPR 924 repository at http://www.ietf.org/ipr. 926 The IETF invites any interested party to bring to its attention 927 any copyrights, patents or patent applications, or other 928 proprietary rights that may cover technology that may be 929 required to implement this standard. Please address the 930 information to the IETF at ietf-ipr@ietf.org. 932 13. Disclaimer 934 This document and the information contained herein are provided 935 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 936 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 937 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 938 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 939 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 940 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 941 FOR A PARTICULAR PURPOSE.