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