idnits 2.17.1 draft-ietf-ipfix-as-00.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 17 longer pages, the longest (page 2) being 70 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 687: '...rio the exporter SHOULD export private...' RFC 2119 keyword, line 713: '...NAT the exporter MUST export private a...' RFC 2119 keyword, line 864: '... address realms, it MUST include the VPN-ID [VPN-ID] in the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 803 has weird spacing: '...network infra...' -- 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 (June 2003) is 7615 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: 'RFC 2722' is mentioned on line 548, but not defined == Missing Reference: 'RFC 2723' is mentioned on line 491, but not defined == Missing Reference: 'RFC 2720' is mentioned on line 560, but not defined == Missing Reference: 'DIFF-ARCH' is mentioned on line 736, but not defined == Missing Reference: 'RFC2764' is mentioned on line 809, but not defined == Missing Reference: 'VPN-2547BIS' is mentioned on line 853, but not defined == Missing Reference: 'VPN-ID' is mentioned on line 864, but not defined == Missing Reference: 'TBD' is mentioned on line 867, but not defined == Unused Reference: 'QuZC03' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'Wood02' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'Awdu02' is defined on line 915, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 928, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'NAT-TRAD' is defined on line 958, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 968, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'QuZC03' == Outdated reference: A later version (-10) exists of draft-ietf-idwg-requirements-06 ** Downref: Normative reference to an Informational draft: draft-ietf-idwg-requirements (ref. 'Wood02') -- Possible downref: Non-RFC (?) normative reference: ref. 'MaPZ03' ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-principles (ref. 'Awdu02') -- Possible downref: Non-RFC (?) normative reference: ref. 'Brow00' ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) -- Possible downref: Non-RFC (?) normative reference: ref. 'ClPB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'GrDM98' -- Possible downref: Non-RFC (?) normative reference: ref. 'DuGr00' ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) -- Possible downref: Non-RFC (?) normative reference: ref. 'ZsZC01' -- Possible downref: Non-RFC (?) normative reference: ref. 'MCFW' ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT-TRAD') -- Possible downref: Non-RFC (?) normative reference: ref. 'PPVPN-FR' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-L2' ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Experimental RFC: RFC 2903 Summary: 17 errors (**), 0 flaws (~~), 20 warnings (==), 12 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: December 2003 Reinaldo Penno 5 Nortel Networks 6 Nevil Brownlee 7 CAIDA 8 Benoit Claise 9 Cisco Systems 11 June 2003 13 IPFIX Applicability 14 draft-ietf-ipfix-as-00.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 how various applications can use the IP 36 Flow Information Export (IPFIX) protocol. It furthermore shows 37 how the IPFIX framework relates to other architectures and 38 frameworks. 40 Table of Contents 42 1. Introduction................................................3 43 2. Applications of IPFIX.......................................3 44 2.1 Accounting..................................................3 45 2.2 Peering Agreements..........................................4 46 2.3 Traffic Engineering.........................................4 47 2.4 Data Warehousing and Mining.................................4 48 2.5 Network Monitoring..........................................4 49 2.5.1 Application Monitoring and Profiling.......................5 50 2.5.2 User Monitoring and Profiling..............................5 51 2.5.3 QoS Monitoring.............................................5 52 2.5.4 Measurement of delay variation with IPFIX..................6 53 2.5.5 Sampling for QoS Monitoring................................6 54 3. Relation of IPFIX to other frameworks and protocols.........7 55 3.1 IPFIX and AAA...............................................7 56 3.1.1 Connecting via an AAA Client...............................7 57 3.1.2 Connecting via an Application Specific Module (ASM)........7 58 3.2 IPFIX and RTFM..............................................8 59 3.2.1 Definition of 'flow'.......................................8 60 3.2.2 Configuration and Management...............................8 61 3.2.3 Data Model details.........................................9 62 3.2.4 Application/transport protocol.............................10 63 3.3 IPFIX Considerations for Middleboxes........................10 64 3.3.1 Firewall...................................................11 65 3.3.2 Network Address Translation................................11 66 3.3.3 Traffic Conditioners.......................................12 67 3.3.4 Tunneling..................................................13 68 3.3.5 VPNs.......................................................13 69 4. Security Consideration......................................15 70 5. References..................................................15 72 1. Introduction 74 The IPFIX protocol defines how IP Flow information can be 75 exported from routers, measurement probes or other devices. It 76 is intended to provide input for various applications. This 77 document describes how applications can use the IPFIX protocol. 78 Furthermore, the relationship of IPFIX to other frameworks and 79 architectures are 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 88 Usage based accounting is one of the major applications for 89 which the IPFIX protocol has been developed. IPFIX data provides 90 fine-grained metering (for example, flow records include details 91 such as IP addresses, packet and byte counts, timestamps, Type 92 of Service (ToS), application ports, etc.) for highly flexible 93 and detailed resource usage accounting. ISPs can use this 94 information to migrate from single fee, flat-rate billing to 95 more flexible charging mechanisms based on time of day, 96 bandwidth usage, application usage, quality of service, etc. 97 Enterprise customers can use this information for departmental 98 chargeback or cost allocation for resource usage. 100 The essential elements needed for this are the number of 101 transferred packets and bytes per flow. IPFIX flow records 102 contain this information together with the flow identification. 103 With this the essential input for usage-based accounting is 104 provided by IPFIX. 106 In order to realize usage-based accounting with IPFIX the flow 107 definition has to be chosen in accordance to the tariff model. A 108 tariff can for instance be based on individual end-to-end 109 streams. Accounting in such a scenario can be realized for 110 instance with a flow definition determined by the quintuple that 111 consists of source address, destination address, protocol and 112 portnumbers. Another example is a class-dependent tariff (e.g. 113 in a DiffServ networks). For this flows could be distinguished 114 just by DiffServ codepoint (DSCP) and source address. 116 IPFIX provides a very flexible definition of flows, so arbitrary 117 flow-based accounting models can be realized without any 118 extensions to the IPFIX protocol. Nevertheless the configuration 119 of flow definitions is out of scope of the IPFIX definition. 121 For accounting purposes, it would be advantageous to have the 122 ability to use IPFIX flow records as accounting input in a AAA 123 infrastructure. AAA servers then could provide the mapping 124 between user and flow information. 126 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 With IPFIX, events of interest can be reported to the sensor 143 either by the collecting process or directly by the exporting 144 process. It depends on the scenario and the events of interest 145 which 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 can provide useful input data for basic intrusion 154 detection functions (e.g. detecting unusual high loads). IPFIX 155 data provides details on source and destination addresses, along 156 with the start time of flows and application ports. 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. In other 160 scenarios, a preprocessing of data already at the measurement 161 device is desirable. IPFIX allows a flexible report definition. 162 Therefore, extensions to the metering process and the IPFIX 163 report format could improve the IPFIX support for intrusion 164 detection systems. 166 Network Planning 167 IPFIX data captured over a long period of time can be used to 168 track and anticipate network growth and plan upgrades to 169 increase the number of routing devices, ports, or higher- 170 bandwidth interfaces. IPFIX data optimizes both strategic 171 network planning (peering, backbone upgrade planning, and 172 routing policy planning) as well as tactical network engineering 173 decisions (upgrading the router or link capacity). This helps to 174 minimize the total cost of network operations while maximizing 175 network performance, capacity, and reliability. 177 2.2 Peering Agreements 179 IPFIX data enables ISP peering partners to measure the volume 180 and characteristics of traffic exchanged with other ISP peers. 182 2.3 Traffic Engineering 184 IPIFX data provides traffic engineering details for a set of 185 prefixes. This data can be used in network optimization for load 186 balancing traffic across alternate paths, or for forwarding 187 traffic of a certain set of prefixes on a preferred route. 189 2.4 Data Warehousing and Mining 191 IPFIX data (or derived information) can be stored for later 192 retrieval and analysis to support proactive marketing and 193 customer service programs. An example of this would be to 194 determine which applications and services are being used by 195 internal and external users and then target them for improved 196 services such as advertising. This is especially useful for ISPs 197 because IPFIX data enables them to create better service 198 packaging. 200 2.5 Network Monitoring 202 IPFIX data enables extensive near real-time network monitoring 203 capabilities. IPFIX data analysis can be used to display traffic 204 patterns associated with routing devices and switches on an 205 individual or network wide basis. This can display traffic or 206 application-based views and therefore provide proactive problem 207 detection, efficient troubleshooting, and rapid problem 208 resolution. 210 2.5.1 Application Monitoring and Profiling 212 IPFIX data enables content and service providers to view 213 detailed, time-based, and application-based usage of a network. 214 This information allows planning and allocation of network and 215 application resources (such as Web server, gaming or 216 multimedia). 218 2.5.2 User Monitoring and Profiling 220 IPFIX data provides a detailed understanding of customer or end- 221 user usage of network and application resources. This 222 information can then be used to efficiently plan and allocate 223 access, backbone, and application resources, as well as to 224 detect and resolve potential security and policy violations. 226 2.5.3 QoS Monitoring 228 The performance of QoS monitoring is one target application for 229 using the IPFIX protocol. QoS monitoring is the passive 230 observation of transmission quality for single flows or traffic 231 aggregates in the network. One example of its usefulness is the 232 validation of QoS guarantees in service level agreements (SLAs). 233 Some QoS metrics require the correlation of data from multiple 234 measurement points. For this the clocks of the involved 235 exporting devices need to be synchronized. Furthermore, such 236 measurements would benefit from post-processing functions (e.g. 237 packet ID generation) at the exporter and/or collector. This 238 section describes how the monitoring of different metrics can be 239 performed with IPFIX. The following metrics are considered: 240 round trip time, one-way-delay, loss and delay variation. 242 2.5.3.1 Measurement of Round-trip-time (RTT) 244 The passive measurement of round-trip-times (RTT) can be 245 performed by using packet pair matching techniques as described 246 in [Brow00]. For the measurements, request/response packet pairs 247 from protocols like DNS, ICMP, SNMP or TCP (syn/syn-ack, 248 data/ack) are utilized to passively observe the RTT [Brow00]. As 249 always for passive measurements this only works if the required 250 traffic of interest is actually present in the network. In order 251 to use this measurement technique, the IPFIX metering process 252 needs to measure both directions. A classification of the 253 protocols mentioned above has to be done. That means parts of 254 the transport header are used for the classification. Since a 255 differentiation of flows in accordance to the transport header 256 is one of the requirements for IPFIX, such classification can be 257 performed without extensions. Nevertheless, the meter needs to 258 recognize request and response packets for the given protocols 259 and therefore needs to look further into the packets. The 260 capability to do this analysis is not part of the IPFIX 261 requirements but can be achieved by optional extensions to the 262 classification process. The exporting device needs to assign a 263 timestamp for the arrival of the packets. The calculation of the 264 RTT can be done directly at the exporter or at the collector. In 265 the first case IPFIX would transfer the calculated RTT to the 266 collector. In the second case IPFIX needs to send the observed 267 packet types and the timestamps to the collector. 269 2.5.3.2 Measurement of One-way-delay (OWD) 270 Passive one-way-delay measurements require the collection of 271 data at two measurement points. It is necessary to recognize 272 packets at the second measurement point to correlate packet 273 arrival events from both points. This can be done by capturing 274 packet header and parts of the packet that can be used to 275 recognize the same packet at the subsequent measurement point 276 [MaPZ03]. 277 To reduce the amount of measurement data a unique packet ID can 278 be calculated from the header and part of the content e.g. by 279 using a CRC or hash function [GrDM98, DuGr00, ZsZC01]. Since 280 IPFIX is not targeted at packet capturing these functionalities, 281 do not need to be supported by a standard IPFIX meter. 282 Nevertheless, in some scenarios it might be sufficient to 283 calculate a packet ID under consideration of header fields 284 including datagram ID and maybe sequence numbers (from transport 285 protocols) without looking at parts of the packet content. If 286 packet IDs need to be unique only for a certain time interval or 287 a certain amount of packet ID collisions is tolerable this can 288 be a sufficient solution. 289 The second issue here is the transfer of packet IDs. IPFIX 290 transfers per flow information. Since the flow definition is 291 very flexible, one could define flows that consist only of one 292 packet and with this allow the transfer of per packet 293 information. Nevertheless, this approach would be very 294 inefficient, since flow records also contain further 295 information. A more efficient scheme could be defined by 296 modifying the flow record format and provide templates 297 especially for that purpose. 299 Measurement of Loss 300 Passive loss measurements for single flows can be performed at 301 one measurement point by using sequence numbers that are present 302 in higher layer protocols. This requires the capturing of the 303 sequence numbers of subsequent packets of the observed flow by 304 the IPFIX metering process. An alternative to this is to perform 305 a two-point measurement as described above and just consider 306 packets as lost that do not arrive at the second measurement 307 point in a given maximum time frame. 309 2.5.4 Measurement of delay variation with IPFIX 311 Delay variation is defined as the difference of one-way-delay 312 values for selected packets [RFC3393]. Therefore, this metric 313 can be calculated by performing passive measurement of one-way- 314 delay for subsequent packets (e.g. of a flow) and then 315 calculating the differences. 317 2.5.5 Sampling for QoS Monitoring 319 Since QoS monitoring can produce an overwhelming amount of 320 measurement data, methods such as aggregation of results, and 321 sampling would greatly increase the efficiency of the collection 322 and analysis process. Sampling methods can be grouped according 323 to the sampling strategy (systematic, random or stratified) and 324 the trigger that starts a sampling interval (count-based, time- 325 based or packet-content-based) [ClPB93]. Sampling can also be 326 used as a method to dynamically reduce resource consumption if 327 the meter is overloaded. Then the IPFIX meter can switch to a 328 sampling method if too many packets have to be observed. Since 329 the expected estimation error heavily depends on the deployed 330 sampling strategy, the application that receives the data needs 331 to be aware of the sampling scheme and the parameters in use. 332 Therefore, it is important that the IPFIX exporter informs the 333 collector precisely about the used sampling strategy. This is 334 especially important if the metering process dynamically invokes 335 sampling. The configuration and reporting of sampling methods is 336 addressed in the PSAMP group. 338 3. Relation of IPFIX to other frameworks and protocols 340 3.1 IPFIX and AAA 342 AAA defines a protocol and architecture for authentication, 343 authorization and accounting for service usage. The DIAMETER 344 protocol is used for AAA communication for network access 345 services (Mobile IP, NASREQ, and ROAMOPS). The AAA architecture 346 [RFC2903] provides a framework for extending the AAA support 347 also for other services. DIAMETER defines the exchange of 348 messages between AAA entities, e.g. between AAA clients at 349 access devices and AAA servers and among AAA servers. It is used 350 also for the transfer of accounting records. Usage-based 351 accounting requires measurement data from the network. IPFIX 352 defines a protocol to export such data from routers, measurement 353 probes and other devices. 355 The provisioning of accounting with IPFIX can be realized 356 without an AAA infrastructure. The collector can directly 357 forward the measurement information to an accounting 358 application. Nevertheless, if an AAA infrastructure is in place, 359 IPFIX can provide the input for the generation of accounting 360 records and several features of the AAA architecture can be 361 used. Features include the mapping of a user ID to the flow 362 information (by using authentication information), the 363 generation of DIAMETER accounting records and the secure 364 exchange of accounting records between domains with DIAMETER. 365 Two possibilities to connect IPFIX and AAA can be distinguished: 367 3.1.1 Connecting via an AAA Client 369 One possibility to connect IPFIX and AAA is to run an AAA client 370 on the IPFIX collector. This client can generate DIAMETER 371 accounting messages and send them to an AAA server. The mapping 372 of the flow information to a user ID can be done in the AAA 373 server by using data from the authentication process. DIAMETER 374 accounting messages can be sent to the accounting application or 375 to other AAA servers (e.g. in roaming scenarios). 377 +---------+ DIAMETER +---------+ 378 | AAA-S |------------->| AAA-S | 379 +---------+ +---------+ 380 ^ 381 | DIAMETER 382 | 383 | 384 +--+--------+--+ 385 | | AAA-C | | 386 + +--------+ | 387 | | 388 | Collector | 389 +--------------+ ^ 390 | IPFIX 391 | 392 +------------+ 393 | Exporter | 394 +------------+ 395 Figure 2: IPFIX collector connects to AAA server via AAA client 397 3.1.2 Connecting via an Application Specific Module (ASM) 399 Another possibility is to directly connect the IPFIX collector with 400 the AAA server via an application specific module (ASM). 401 Application specific modules have been proposed by the IRTF AAA 402 architecture research group (AAARCH) in [RFC2903]. They act as an 403 interface between AAA server and service equipment. In this case 404 the IPFIX collector is part of the ASM. The ASM acts as an 405 interface between the IPFIX protocol and the input interface of the 406 AAA server. The ASM translates the received IPFIX data into an 407 appropriate format for the AAA server. The AAA server then can add 408 information about the user ID and generate a DIAMETER accounting 409 record. This accounting record can be sent to an accounting 410 application or to other AAA servers. 412 +---------+ DIAMETER +---------+ 413 | AAA-S |------------->| AAA-S | 414 +---------+ +---------+ 415 ^ 416 | 417 +------------------+ 418 | ASM | 419 | +------------+ | 420 | | Collector | | 421 +------------------+ 422 ^ 423 | IPFIX 424 | 425 +------------+ 426 | Exporter | 427 +------------+ 429 Figure 3: IPFIX connects to AAA server via ASM 431 3.2 IPFIX and RTFM 433 This section compares the Real-time Traffic Flow Measurement 434 (RTFM) framework with the IPFIX framework. 436 3.2.1 Definition of 'flow' 438 RTFM and IPFIX both use the same definition of flow; a flow is a 439 set of packets which share a common set of end-point address 440 attribute values.A flow is therefore completely specified by 441 that set of values, together with an inactivity timeout. A flow 442 is considered to have ended when no packets are seen for at 443 least the inactivity time. 445 RTFM flows are bidirectional, which has given rise to some 446 confusion. 447 At the simplest level, a flow information exporter may achieve 448 this by maintaining two unidirectional flows, one for each 449 direcion. To export bidirectional flow information, e.g. to- 450 and from- packet counts, for a flow from A to B, the exporter 451 has only to search its flow table to find the matching flow from 452 B to A. 454 RTFM, however, takes bi-directionality a stage further, by 455 including in the RTFM architecture [RFC 2722] a fully-detailed 456 algorithm for realtime matching of the two directions of a flow. 457 This was done for two reasons, to reduce the memory required to 458 store each flow (common address attributes for each direction), 459 and to allow for attributes which required fine detail for the 460 two directions, e.g. short-term bit rate distributions [RFC 461 2724]. 462 ** So far there has been no suggestion that IPFIX should do 463 this. 465 3.2.2 Configuration and Management 467 The RTFM architecture specifies a complete system for gathering 468 flow information. It defines three entities, 469 - 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 consective 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 is 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.3 Data 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 aggreation 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 536 For its packet- and byte-count attributes RTFM uses 537 continuously-incrementing 64-bit counters, which are never 538 reset. This makes asynchronous meter reading easy, any reader 539 simply has to remember its previous reading and compute the 540 difference. The only caveat is that the meter should be read 541 often enough to avoid situations when the counter has cycled 542 more than once between readings. 544 3.2.3.3 Sampling issues 546 RTFM provides 1 out of N sampling as a configuration option, so 547 that some metering interfaces may only process every Nth packet. 548 The RTFM Arcitecture [RFC 2722] does not discuss the statistical 549 implications of this, merely saying that users will need to 550 satisfy themselves that sampling makes sense in their 551 environment. 553 RTFM makes no provision for flow sampling. Recently there has 554 been a lot of interest in flow sampling schemes which favour the 555 'most important' flows, perhaps we need to consider this for 556 IPFIX. 558 3.2.4 Application/transport protocol 560 RTFM has a standards-track Meter MIB [RFC 2720], which can be 561 used both to configure a meter and to read flow data from it. 562 The MIB provides a way to read lists of attributes with a single 563 Object 564 Identifier (called a 'package'), which dramatically reduces the 565 SNMP overhead for flow data collection. NeTraMet, a widely-used 566 open-source RTFM implementation, uses SNMPv2C for configuration 567 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. 573 Apart from being clumsy, this can limit the maximum data 574 transfer rate from meter to meter reader. SNMP over TCP would 575 be a better approach, but that is currently an IRTF 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. Simlarly, many 582 NeTraMet user run the meter and meter reader on the same host 583 system. 584 A need for high flow data rates highlights the need for careful 585 systems design when building a flow data collection system. 586 When data rates are high, and it is not possible to use a high 587 level of aggregation, then it makes sense to have the collectors 588 very close to their exporters. Once the data is safely on a 589 dedicated host machine, large volumes of it can be moved using 590 'background' techniques such as FTP. 592 The RTFM architecture only specifies a pull model for getting 593 data out of a meter. To implement push mode data transfer would 594 require specification of triggers to indicate when data should 595 be sent for each flow. 597 3.3 IPFIX Considerations for Middleboxes 599 A Middlebox is a network intermediate device that implements one 600 or more of the middlebox services. Policy based packet filtering 601 (a.k.a. firewall), Network address translation (NAT), Intrusion 602 detection, Load balancing, Policy based tunneling and IPsec 603 security are all examples of a middlebox function (or service). 604 [MCFW]. For instance, a NAT middlebox is a middlebox 605 implementing NAT service and a firewall middlebox is a middlebox 606 implementing firewall service. It is expected that the exporter 607 in the IPFIX architecture will probably implement some form of 608 middlebox service given its ubiquity today. Since some of these 609 middlebox services might affect flow exportation and how the 610 collector interprets them, there is a need to provide an 611 analysis of these implications in relation to the IPFIX 612 architecture and a set of recommendations. The following 613 sections provide a non-exhaustive analysis of middlebox 614 services, its implications on the IPFIX architecture and a 615 corresponding set of recommendations. 617 3.3.1 Firewall 619 Firewall is a policy based packet filtering middlebox function, 620 typically used for restricting access to/from specific devices 621 and applications. The policies are often termed Access Control 622 Lists (ACLs)[MCFW]. The firewall middlebox service allows the 623 exporter to explicitly drop packets based on some administrative 624 policy. In this case, the exporter can take one of the following 625 actions that will have a direct impact on the information 626 provided by the collector to the user. 628 * Silently Discard 630 In this case the packet is discarded and no flow information 631 record is sent to the collector. 633 * Discard and export flow 635 In this case the packet is discarded, and the flow information 636 record is sent to the collector. 638 * Discard and export flow with discard notification 640 In this case the packet is discarded, and the flow information 641 record is sent to the collector with an indication that the 642 packet was discarded. 644 3.3.2 Network Address Translation 646 Network Address Translation is a method by which IP addresses 647 are mapped from one address realm to another, providing 648 transparent routing to end hosts. Transparent routing here 649 refers to modifying end-node addresses en-route and maintaining 650 state for these updates so that when a datagram leaves one realm 651 and enters another, datagrams pertaining to a session are 652 forwarded to the right end-host in either realm [NAT-TERM]. 653 >From an exporter (middlebox) perspective, a NAT is composed of 654 two flows, one from the client to the NAT middlebox and another 655 from the NAT middlebox to the destination. Based on this fact, 656 the exporter has several modes of operation, i.e., it can export 657 the private realm flow, the public realm, or both. This is 658 further constrained by the flavor of NAT implemented, meaning 659 that in order for the exported information to be useful for the 660 collector, sometimes the associated flows on the two realms need 661 to be exported in the same flow record. Although there are many 662 flavors of address translation that lend themselves to different 663 applications, this section will only address the IPFIX 664 architecture implications of traditional NAT, bi- 665 directional NAT and twice NAT. 667 3.3.2.1 Traditional NAT 668 Traditional NAT would allow hosts within a private network to 669 transparently access hosts in the external network, in most 670 cases. In a traditional NAT, sessions are unidirectional, 671 outbound from the private network. This is in contrast with bi- 672 directional NAT, which permits sessions in both inbound and 673 outbound directions. A detailed description of traditional NAT 674 may be found in section [NAT-TERM]. 676 If the exporter is providing traditional NAT service and only 677 the private realm flow is exported, only destination based 678 information can be inferred from the collector. The reason for 679 this is twofold. First, the collector will not be able to find 680 the reverse flow (when applicable) associated with a private 681 realm flow record, and second is that in the more general 682 scenario the collector can be connected to several exporters 683 providing NAT service and there might be overlapping private 684 realm addresses between the networks connected to these 685 exporters. 687 In a traditional NAT scenario the exporter SHOULD export private 688 and public realm information in the same flow record or provide 689 the collector with a unique key to associate the two if exported 690 on different flow records. 692 3.3.2.2 Bi-Directional NAT 694 With a bi-directional NAT, sessions can be initiated from hosts 695 in the public network as well as the private network. Private 696 network addresses are bound to globally unique addresses, 697 statically or dynamically as connections are established in 698 either direction. Detailed description of Bi-Directional may be 699 found in section [NAT- 700 TERM]. 702 3.3.2.3 Twice NAT 704 Twice NAT is a variation of NAT in that both the source and 705 destination addresses are modified by NAT as a datagram crosses 706 address realms. This is in contrast to Traditional-NAT and Bi- 707 Directional NAT, where only one of the addresses (either source 708 or destination) is translated. Note, there is no such term as 709 'Once- 710 NAT'. Detailed description of Bi-Directional may be found in 711 section [NAT-TERM]. 713 In the case of twice NAT the exporter MUST export private and 714 public realm information in the same flow record or provide the 715 collector with a unique key to associate the two if exported on 716 different flow records. 718 3.3.3 Traffic Conditioners 720 A traffic conditioner may contain the following elements: meter, 721 marker, shaper, and dropper. A traffic stream is selected by a 722 classifier, which steers the packets to a logical instance of a 723 traffic conditioner[DIFF-ARCH]. 725 From an IPFIX architecture perspective we are going to address 726 marking, shaping and dropping services. 728 Marking 729 Diffserv packet markers set the DS field of a packet to a 730 particular codepoint, adding the marked packet to a particular 731 DS behavior aggregate. The marker may be configured to mark all 732 packets which are steered to it to a single codepoint, or may be 733 configured to mark a packet to one of a set of codepoints used 734 to select a PHB in a PHB group, according to the state of a 735 meter. When the marker changes the codepoint in a packet it is 736 said to have "re-marked" the packet [DIFF-ARCH]. 738 From and IPFIX architecture perspective, the exporter can take 739 one of the following actions when it needs to remark a packet. 741 * Unmarked flow 743 The exporter can export the flow before it was remarked. This 744 mode of operation is strongly discouraged. 746 * Remarked flow 748 The exporter can export the flow after it was remarked. 749 * Unmarked and remarked flow. 751 The exporter can export the flow before and after it was 752 remarked or export the flow before it was remarked and an 753 indication of what was the DSCP after it was remarked. 755 3.3.3.1 Shapers 757 Shapers delay some or all of the packets in a traffic stream in 758 Order to bring the stream into compliance with a traffic 759 profile. A shaper usually has a finite-size buffer, and packets 760 may be discarded if there is not sufficient buffer space to hold 761 the delayed packets. 763 For an IPFIX perspective, since the discard of a packet by a 764 shaper is not voluntary, no indication should be sent to the 765 collector. 767 3.3.3.2 Droppers 769 Droppers discard some or all of the packets in a traffic stream 770 in order to bring the stream into compliance with a traffic 771 profile. This process is known as "policing" the stream. Note 772 that a dropper can be implemented as a special case of a shaper 773 by setting the shaper buffer size to zero (or a few) packets. 775 In a manner analogous to the middlebox firewall service, 776 middlebox policing services also allow the exporter to 777 explicitly drop packets based on some administrative policy. 778 The three possible export behaviors described for the firewall 779 service when a packet needs to be dropped are also applicable to 780 here, i.e., silent discard, discard and export flow, discard and 781 export flow with discard notification. 783 3.3.4 Tunneling 785 The exporter can export the flows before and/or after they get 786 tunneled. In the later case the encapsulated flow information 787 might not be available due to confidentiality precautions such 788 as those used by IPsec, or due to the fact the exporter lacks 789 the necessary intelligence to inspect the encapsulated packet. 790 Moreover, depending on where in the network the exporter is 791 located, it might only be able to export flows associated with 792 the tunnel, without visibility into the encapsulated packet. 794 Apart from what was said above, it should also be factored in 795 the fact that flows exported before they get tunneled, will 796 provide information about the private network sites, but not 797 necessarily about the backbone, since the route taken by the 798 packet it's now know at that point in time (and vice-versa). 800 3.3.5 VPNs 801 The term "Virtual Private Network" (VPN) refers to the 802 communication between a set of sites, making use of a shared 803 network infrastructure. Multiple sites of a private network 804 may therefore communicate via the public infrastructure, in 805 order to facilitate the operation of the private network. The 806 logical structure of the VPN, such as addressing, topology, 807 connectivity, reachability, and access control, is equivalent to 808 part of or all of a conventional private network using private 809 facilities [RFC2764] [VPN-2547BIS]. 811 There are multiple flavors of VPNs, the one with more relevance 812 to the IPFIX architecture is the PE-based-VPN. A PE-based VPN 813 (or Provider Edge-based Virtual Private Network) is one in which 814 PE devices in the SP network provide the VPN. This allows the 815 existence of the VPN to be hidden from the CE devices, which can 816 operate as if part of a normal customer network. A detailed 817 discussion of VPNs can be found in [PPVPN-FR]. 819 3.3.5.1 Layer 3 PE-based VPN 821 A layer 3 PE-based VPN is one in which the SP takes part in IP 822 level forwarding based on the customer network's IP address 823 space. In general, the customer network is likely to make use 824 of private and/or non-unique IP addresses. This implies that at 825 least some devices in the provider network needs to understand 826 the IP address space as used in the customer network. Typically 827 this knowledge is limited to the PE device [PPVPN-FR] which is 828 directly attached to the customer. 830 In a layer 3 PE-based VPN the provider will need to participate 831 in some aspects of management and provisioning of the VPNs, such 832 as ensuring that the PE devices are configured to support the 833 correct VPNs. This implies that layer 3 PE-based VPNs are by 834 definition provider provisioned VPNs [PPVPN-FR]. 836 In order to connect the different VPN sites belonging to the 837 same VPN the SP uses a tunneling technique such as MPLS, L2TP or 838 IPsec. These tunnels originate and terminate on PE devices. 839 One of the characteristics of a layer 3 PE-based VPNs is that 840 they offload some aspects of VPN management from the customer 841 network. From an IPFIX architecture perspective, this means that 842 the SP is the one that potentially will be providing the IPFIX 843 service for the VPNs that it provides connectivity. 845 The exporter in Layer 3 PE-based VPN can be located on the 846 customer's network, on the SP's backbone (P Router) or on the 847 edge (PE router). The premise of this discussion is that the 848 exporter is the one providing middlebox services, so in the case 849 of VPNs we assume that the exporter is located in a PE device. 851 Overlapping Address Realms 853 In the case the exporter plays the role of a PE router [VPN- 854 2547BIS] in a provider provisioned VPN scenario and has VPNs 855 with overlapping private address realms, it can only provide 856 useful non-conflicting information to the provider for intra-VPN 857 traffic if it uses a technique that allows the collector to 858 uniquely identify to which VPN the flow belongs. 860 Several techniques could be used to accomplish this goal. One of 861 these techniques is to include the VPN Global unique identifier 862 [VPN-ID] as one of the keys in the flow record. 863 In the case the exporter supports VPNs with overlapping private 864 address realms, it MUST include the VPN-ID [VPN-ID] in the 865 exported flow record. 867 3.3.5.2 Layer 2 PE-based VPN [TBD] 869 A layer 2 PE-based VPN is one in which the network is aware of 870 the VPN, but does only layer 2 forwarding and signaling. This 871 implies that the SP provisions and maintains layer 2 872 connectivity between CE devices [VPN-L2]. 874 Forwarding options include MAC addresses (such as LAN 875 emulation), use of point-to-point link layer connections (FR or 876 ATM), multipoint-to-point (using MPLS multipoint to point LSPs), 877 and point-to-multipoint (e.g., ATM VCCs). 879 For a layer 2 PE-based VPN, the PE device may be a router, LSR, 880 or IP switch. From the CE's perspective, the PE will be 881 operating as a switch. 883 4. Security Consideration 885 This document describes the usage of IPFIX in various scenarios. 886 The security requirements for the IPFIX target applications are 887 addressed in the IPFIX requirements draft. These requirements 888 must be considered for the specification of the IPFIX protocol. 889 The IPFIX extensions proposed in this document do not induce 890 further security hazards. 892 The second section of this document describes how IPFIX can be 893 used in combination with other frameworks. New security hazards 894 can arise when two individually secure frameworks are combined. 895 For the combination of AAA with IPFIX an ASM or an IPFIX 896 collector can function as transit point for the messages. It has 897 to be ensured that at this point the applied security mechanisms 898 (e.g. encryption of messages) are maintained. 900 5. References 902 [QuZC03] J. Quittek ,et. Al "Requirements for IP Flow 903 Information Export ", (work in progress) ,Internet Draft, 904 Internet Engineering Task Force, , 905 June 2003 907 [Wood02] M. Wood ,et al.," Intrusion Detection Message Exchange 908 Requirements",(work in progress), Internet Draft, Internet 909 Engineering Task Force, draft-ietf-idwg-requirements-06, 910 February 2002. 911 [MaPZ03] L. Mark, G. Pohl, T. Zseby, K. Sugauchi: Passive One- 912 way Delay Measurements, (work in progress), Internet Draft 913 , June 2003 915 [Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of 916 Internet Traffic Engineering", (work in progress), Internet 917 Draft, Internet Engineering Task Force, draft-ietf-tewg- 918 principles-02.txt, May 2002 920 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet 921 Distributions, 922 http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47- 923 adelaide/pp-dist/ 925 [RFC3393] C. Demichelis, P. Cimento: IP Packet Delay Variation 926 Metric for IPPM, RFC 3393, November 2002 928 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet 929 Loss Metric for IPPM, September 1999 931 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: 932 Application of Sampling Methodologies to Network Traffic 933 Characterization, Proceedings of ACM SIGCOMM'93, San Francisco, 934 CA, USA, September 13 - 17, 1993 936 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed 937 MARTENS, John G. CLEARY: Nonintrusive and Accurate Measurement 938 of Unidirectional Delay and Delay Variation on the Internet, 939 INET'98, Geneva, Switzerland, 21-24 July, 1998 941 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory 942 Sampling for Direct Traffic Observation", Proceedings of ACM 943 SIGCOMM 2000, Stockholm, Sweden, August 28 - September 1, 2000. 945 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay 946 Metric for IPPM, Request for Comments: 2679, September 1999 947 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation 948 of Building Blocks for Passive One-way-delay Measurements, 949 Proceedings of Passive and Active Measurement Workshop (PAM 950 2001), Amsterdam, The Netherlands, April 23-24, 2001 951 [MCFW] Srisuresh, S. et al. "Middlebox Communication 952 Architecture and framework," work in progress. October 2001. 954 [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address 955 Translator (NAT) Terminology and Considerations", RFC 2663, 956 August 1999. 958 [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network 959 Address Translator (Traditional NAT)", RFC 3022, January 2001. 961 [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for 962 Provider Provisioned Virtual Private Networks ", work in 963 progress, , January 2002. 965 [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft 966 , July 2001. 968 [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, 969 Z. and W. Weiss, "An Architecture for Differentiated Services", 970 RFC 2475, December 1998. 972 [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. 973 Spence, "Generic AAA Architecture", RFC 2903, August 2000 975 7. Acknowledgements 977 We would like to thank the following persons for their 978 contribution, discussion on the mailing list and valuable 979 comments: 981 Robert Loewe 983 8. Author's Addresses 985 Tanja Zseby 986 Fraunhofer Institute for Open Communication Systems(FOKUS) 987 Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49 30 988 3463 7153 Email: zseby@fokus.fhg.de 990 Reinaldo Penno 991 Nortel Networks, Inc. 2305 Mission College Boulevard 992 Building SC9-B1240 Santa Clara, CA 95134 993 Email: rpenno@nortelnetworks.com 994 Nevil Brownlee 995 CAIDA (UCSD/SDSC) 996 9500 Gilman Drive 997 La Jolla, CA 92093-0505 998 Phone : +1 858 534 8338 999 Email : nevil@caida.org 1001 Benoit Claise 1002 Cisco Systems 1003 De Kleetlaan 6a b1 1004 1831 Diegem 1005 Belgium 1006 Phone: +32 2 704 5622 1007 Email: bclaise@cisco.com 1009 9. Full Copyright Statement 1011 "Copyright (C) The Internet Society (date). All Rights Reserved. 1012 This document and translations of it may be copied and furnished 1013 to others, and derivative works that comment on or otherwise 1014 explain it or assist in its implementation may be prepared, 1015 copied, published and distributed, in whole or in part, without 1016 restriction of any kind, provided that the above copyright 1017 notice and this paragraph are included on all such copies and 1018 derivative works. However, this document itself may not be 1019 modified in any way, such as by removing the copyright notice or 1020 references to the Internet Society or other Internet 1021 organizations, except as needed for the purpose of developing 1022 Internet standards in which case the procedures for copyrights 1023 defined in the Internet Standards process must be followed, or 1024 as required to translate it into.