idnits 2.17.1 draft-ietf-ipfix-as-10.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 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1380. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1387), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 1356. ** 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. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (August 2006) is 6461 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX-INFO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX-PROTO' -- Possible downref: Non-RFC (?) normative reference: ref. 'PSAMP-INFO' ** Downref: Normative reference to an Informational RFC: RFC 3917 -- Obsolete informational reference (is this intentional?): RFC 2598 (Obsoleted by RFC 3246) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 17 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: January 2007 Elisa Boschi 5 Hitachi 6 Nevil Brownlee 7 CAIDA 8 Benoit Claise 9 Cisco Systems 11 August 2006 13 IPFIX Applicability 14 draft-ietf-ipfix-as-10.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that 19 any applicable patent or other IPR claims of which he or she is 20 aware have been or will be disclosed, and any of which he or she 21 becomes aware will be disclosed, in accordance with Section 6 of 22 BCP 79. 24 Internet-Drafts are working documents of the Internet 25 Engineering Task Force (IETF), its areas, and its working 26 groups. Note that other groups may also distribute working 27 documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as "work 32 in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document describes the applicability of the IP Flow 47 Information Export (IPFIX) protocol for a variety of 48 applications. It shows how applications can use IPFIX, describes 49 the relevant information elements (IEs) and shows opportunities 50 and limitations of the protocol. The document furthermore 51 describes relations of the IPFIX framework to other 52 architectures and frameworks. 54 Table of Contents 55 1. Introduction.............................................4 56 2. Applications of IPFIX....................................4 57 2.1 Accounting...............................................4 58 2.1.1 Example.................................................5 59 2.2 Traffic Profiling........................................7 60 2.3 Traffic Engineering......................................8 61 2.4 Network Security.........................................9 62 2.5 QoS Monitoring..........................................11 63 2.5.1 Correlating Events from Multiple Observation Points....11 64 2.5.2 Examples...............................................12 65 2.6 Inter-Domain Exchange of IPFIX data.....................13 66 2.7 Export of Derived Metrics...............................14 67 2.8 Summary.................................................14 68 3. Relation of IPFIX to Other Frameworks and Protocols.....15 69 3.1 IPFIX and IPv6..........................................15 70 3.2 IPFIX and PSAMP.........................................16 71 3.3 IPFIX and RMON..........................................16 72 3.4 IPFIX and IPPM..........................................17 73 3.5 IPFIX and AAA...........................................17 74 3.5.1 Connecting via an AAA Client...........................19 75 3.5.2 Connecting via an Application Specific Module (ASM)....19 76 3.6 IPFIX and RTFM..........................................20 77 3.6.1 Architecture...........................................20 78 3.6.2 Flow Definition........................................21 79 3.6.3 Configuration and Management...........................21 80 3.6.4 Data Collection........................................21 81 3.6.5 Data Model Details.....................................22 82 3.6.6 Transport Protocol.....................................22 83 3.6.7 Summary................................................22 84 4. Limitations.............................................23 85 4.1 Using IPFIX for other Applications than in RFC3917......23 86 4.2 Using IPFIX for Billing (Reliability Limitations).......23 87 4.3 Using a Different Transport Protocol than SCTP..........24 88 4.4 Push vs. Pull Mode......................................24 89 4.5 Template ID number......................................25 90 4.6 Exporting Bidirectional Flow Information................25 91 4.7 Remote Configuration....................................26 92 5. Security Considerations.................................26 93 6. IANA Considerations.....................................27 94 7. Normative References....................................27 95 8. Informative References..................................27 96 9. Acknowledgements........................................29 97 10. Authors' Addresses......................................29 98 11. Full Copyright Statement................................30 99 12. Intellectual Property Statement.........................30 100 13. Copyright Statement.....................................31 101 14. Disclaimer..............................................31 103 1. Introduction 105 The IPFIX protocol defines how IP Flow information can be 106 exported from routers, measurement probes or other devices. IP 107 flow information can be used as input to various applications. 108 IPFIX is a general data transport protocol, easily extensible to 109 suit the needs of different applications. This document 110 describes how typical applications can use the IPFIX protocol. 111 It shows opportunities and limitations of the protocol. 112 Furthermore, the relationship of IPFIX to other frameworks and 113 architectures is described. Although examples in this document 114 are shown for IPv4 only, the applicability statements apply to 115 IPv4 and IPv6. IPFIX provides appropriate Information Elements 116 for both IP versions. 118 2. Applications of IPFIX 120 IPFIX data enables several critical applications. The IPFIX 121 target applications and the requirements that originate from 122 those applications are described in [RFC3917]. Those 123 requirements were used as basis for the design of the IPFIX 124 protocol. This section describes how these target applications 125 can use the IPFIX protocol. Considerations for using IPFIX for 126 other applications than described in [RFC3917] can be found in 127 section 4.1. 129 2.1 Accounting 131 Usage-based accounting is one of the target applications for 132 IPFIX as defined in [RFC3917]. IPFIX records provide fine- 133 grained measurement results for highly flexible and detailed 134 usage reporting. Such data is often used to realize usage-based 135 accounting. Nevertheless, IPFIX does not provide the reliability 136 required by usage-based billing-systems as defined in [RFC2975] 137 (see section 4.2). The accounting scenarios described in this 138 document only provide limited reliability as explained in 139 section 4.2 and should not be used in environments where 140 reliability as demanded by [RFC2975] is mandatory. 142 In order to realize usage-based accounting with IPFIX the flow 143 definition has to be chosen in accordance to the tariff model. 144 Flows can be distinguished by various IEs (e.g. packet header 145 fields) from [IPFIX-INFO]. Due to the flexible IPFIX flow 146 definition, arbitrary flow-based accounting models can be 147 realized without extensions to the IPFIX protocol. 149 A tariff can, for instance, be based on individual end-to-end 150 flows, in which case accounting can be realized with a flow 151 definition determined by the quintuple consisting of source 152 address (sourceIPv4Address), destination address 153 (destinationIPv4Address), protocol (protocolIdentifier) and port 154 numbers (e.g., udpSourcePort, udpDestinationPort). Another 155 example is a class-dependent tariff (e.g. in a DiffServ 156 network). In this case flows could be distinguished just by the 157 DiffServ codepoint (DSCP) (ipDiffServCodePoint) and IP addresses 158 (sourceIPv4Address, destinationIPv4Address). The essential 159 elements needed for accounting are the number of transferred 160 packets and bytes per flow, which can be represented by the per- 161 flow counter IEs (e.g., packetTotalCount, octetTotalCount). 163 For accounting purposes, it would be advantageous to have the 164 ability to use IPFIX flow records as accounting input in an AAA 165 infrastructure. AAA servers then could provide the mapping 166 between user and flow information. Again for such scenarios the 167 limited reliability currently provided by IPFIX has to be taken 168 into account. 170 2.1.1 Example 172 Please note: As noted in [RFC3330] the address block 173 192.0.2.0/24 may be used for example addresses. In the example 174 below we use two example networks. In order to be conformant to 175 [RFC3330] we divide the given address block into two networks by 176 subnetting with a 25 bit netmask (192.0.2.0/25) as follows: 178 Network A: 192.0.2.0 ... 192.0.2.127 179 Network B: 192.0.2.128 ... 192.0.2.255 181 Let's suppose someone has a Service Level Agreement (SLA) in a 182 DiffServ network requiring accounting based on traffic volume. 183 Flows are distinguished by source and destination address. The 184 information to export in this case is: 185 - IPv4 source IP address: sourceIPv4Address in [IPFIX-INFO], 186 with a length of 4 octets 187 - IPv4 destination IP address: destinationIPv4Address in 188 [IPFIX-INFO], with a length of 4 octets 189 - DSCP: ipDiffServCodePoint in [IPFIX-INFO], with a length of 190 1 octet 191 - Number of octets of the Flow: octetDeltaCount in [IPFIX- 192 INFO], with a length of 4 octets 194 The template set will look as follows: 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Set ID = 2 | Length = 24 octets | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Template ID 256 | Field Count = 4 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 |0| sourceIPv4Address = 8 | Field Length = 4 | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |0| destinationIPv4Address = 12 | Field Length = 4 | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 |0| ipDiffServCodePoint = 195 | Field Length = 1 | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 |0| octetDeltaCount = 1 | Field Length = 4 | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 The information to be exported might be as listed in the 211 following example table: 213 Src. IP addr. | Dst. IP addr. | DSCP | Octets Number 214 --------------+---------------+--------+-------------- 215 192.0.2.12 | 192.0.2.144 | 46 | 120868 216 192.0.2.24 | 192.0.2.156 | 46 | 310364 217 192.0.2.36 | 192.0.2.168 | 46 | 241239 219 In the example we use Diffserv CodePoint 46, recommended for the 220 Expedited Forwarding Per Hop Behavior (EF PHB) in [RFC2598]. 222 The Flow Records will then look as follows: 224 0 1 2 3 225 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Set ID = 256 | Length = 43 | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | 192.0.2.12 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | 192.0.2.144 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | 46 | 120868 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | | 192.0.2.24 | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 192.0.2.156 | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | | 46 | 310364 | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | | 192.0.2.36 | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | | 192.0.2.168 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 46 | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | 241239 | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 2.2 Traffic Profiling 252 Measurement results reported in IPFIX records can be used for 253 traffic profiling. IPFIX records captured over a long period of 254 time can be used to track and anticipate network growth and 255 usage. Such Information is valuable for trend analysis and 256 network planning. 258 The parameters of interest are determined by the profiling 259 objectives. Example parameters for traffic profiling are flow 260 duration, flow volume, burstiness, the distribution of used 261 services and protocols, the amount of packets of a specific 262 type, etc. [RFC3917]. 264 The distribution of services and protocols in use can be 265 analyzed by configuring appropriate flows keys for flow 266 discrimination. Protocols can be distinguished by the 267 protocolIdentifier IE. Portnumbers (e.g., udpDestinationPort) 268 often provide information about services in use. Those flow keys 269 are defined in [IPFIX-INFO]. If portnumbers are not sufficient 270 for service discrimination, further parts of the packet may be 271 needed. Header fields can be expressed by IEs from [IPFIX-INFO] 272 Packet payload can be reported by using the IE 273 ipPayloadPacketSection in [PSAMP-INFO]. 275 The flow duration can be calculated from the flow time stamp IEs 276 defined in [IPFIX-INFO] (e.g., flowEndMicroseconds - 277 flowStartMicroseconds). The number of packets and number of 278 bytes of a flow are represented in the per-flow counter IEs 279 (e.g., packetTotalCount, octetTotalCount). The burstiness of a 280 flow can be calculated from the flow volume measured at 281 different time intervals. 283 2.3 Traffic Engineering 285 Traffic engineering aims at the optimization of network resource 286 utilization and traffic performance [RFC2702]. Typical 287 parameters are link utilization, load between specific network, 288 nodes, number, size and entry/exit points of active flows and 289 routing information [RFC3917]. 291 Size of flows in packets and bytes can be reported by IEs 292 packetTotalCount, octetTotalCount. Physical link utilization can 293 be reported by using a coarse grained flow definition (e.g. 294 based on identifier IEs such as egressInterface or 295 ingressInterface) and per-flow counter IEs (e.g. 296 packetTotalCount, octetTotalCount) defined in [IPFIX-INFO]. 298 The load between specific network nodes can be reported in the 299 same way if one interface of a network node receives only 300 traffic from exactly one neighbor node (as is usually the case). 301 If the ingress interface is not sufficient for an unambiguous 302 identification of the neighbor node, sub-IP header fields IEs 303 (like sourceMacAddress) can be added as flow keys. 305 The IE observedFlowTotalCount provides the number of all flows 306 exported for the observation domain since the last 307 initialization of the metering process [IPFIX-INFO]. If this IE 308 is exported at subsequent points in time, one can derive the 309 number of active flows in a specific time interval from the 310 difference of the reported counters. The configured flow 311 termination criteria have to be taken into account to interpret 312 that numbers correctly. 314 Entry and exit points can be derived from flow records if 315 metering processes are installed at all edges of the network and 316 results are mapped in accordance to flow keys. For this and 317 other analysis methods that require the mapping of records from 318 different observation points, the same flow keys should be used 319 at all observation points. The path that packets take through a 320 network can be investigated by using hash-based sampling 321 techniques as described in [DuGr00] and [PSAMP-TECH]. For this 322 IEs from [PSAMP-INFO] are needed. 324 Neither [IPFIX-INFO] nor [PSAMP-INFO] defines IEs suitable for 325 exporting routing information. 327 2.4 Network Security 329 Attack and intrusion detection are among the IPFIX target 330 applications described in [RFC3917]. Due to the enormous amount 331 of different network attack types, only general requirements 332 could be addressed in [RFC3917]. 334 IPFIX can export flow information for arbitrary flow definitions 335 as defined in [IPFIX-PROTO]. Packet information can be exported 336 with IPFIX by using the additional information elements 337 described in [PSAMP-INFO]. With this theoretically all 338 information about traffic in the network at IP layer and above 339 is accessible. This data can be used either directly to detect 340 anomalies or can provide the basis for further post processing 341 to generate more complex attack detection metrics. 343 Depending on the attack type different metrics are useful. A 344 sudden increase of traffic load can be a hint that an attack has 345 been launched. The overall traffic at an observation point can 346 be monitored using per-flow counter IEs like packetTotalCount, 347 octetTotalCount as described in 2.3. The number of active flows 348 can be monitored by regular reporting of the 349 observedFlowTotalCount. 351 A sudden increase of flows from different sources to one 352 destination may be caused by an attack on a specific host or 353 network node using spoofed addresses. Many flows to the same 354 machine but on different ports or many flows to the same port 355 and different machines may be an indicator for vertical or 356 horizontal port scanning activities. An unusual ratio of TCP-SYN 357 to TCP-FIN packets can refer to SYN-flooding. Worms may leave 358 signatures in traffic patterns. Detecting such events requires 359 more detailed measurements and post processing than detecting 360 simple changes in traffic volumes 362 The amount of metrics useful for attack detection is as diverse 363 as attack patterns themselves. Attackers adapt rapidly to 364 circumvent detection methods and try to hide attack patterns 365 using slow or stealth attacks. Furthermore, unusual traffic 366 patterns are not always caused by malicious activities. A sudden 367 traffic increase may be caused by legitimate users who seek 368 access to a recently published content. Strange traffic patterns 369 may also be caused by mis-configuration. 371 The difficult task is the separation of good from bad packets to 372 prepare and launch counteraction. This may require a deeper look 373 into packet content by using further header field IEs from 374 [IPFIX-INFO] and/or packet payload from IE 375 ipPayloadPacketSection in [PSAMP-INFO]. Multi-step analysis 376 techniques may be useful, e.g., to launch an in-depth analysis 377 (e.g. based on packet information) in case the flow information 378 shows suspicious patterns. In order to supervise traffic to a 379 specific host or network node one has to apply filtering methods 380 as those described in [PSAMP-TECH]. 382 Mapping the two directions of a communication is often useful 383 for checking correct protocol behavior (see section 4.6). A 384 correlation of IPFIX data from multiple observation points (see 385 section 2.5.1) allows assessing the propagation of an attack and 386 can help to locate its source. 388 The integration of previous measurement results helps to review 389 traffic changes over time for detection of traffic anomalies and 390 provides the basis for forensic analysis. A standardized storage 391 format for IPFIX data would support the offline analysis of data 392 from different operators. 394 Nevertheless, capturing full packet traces at all observation 395 points in the network is not viable due to resource limitations 396 and privacy concerns. Therefore metrics should be chosen wisely 397 to allow a solid detection with minimal resource consumption. 398 Resources can be saved for instance by using coarser grained 399 flow definitions, reporting pre-processed metrics (e.g. with 400 additional information elements) or deployment of sampling 401 methods. 403 Detecting security incidents in real-time often requires the 404 pre-processing of data already at the measurement device. That 405 means that measured data need to be processed already in the 406 measurement device in order to generate useful metrics for 407 detecting an attack as early as possible. Immediate data export 408 in case of a potential incident is desired. IPFIX supports such 409 source-triggered exporting of information due to the push model 410 approach. Nevertheless, further exporting criteria have to be 411 implemented to export IPFIX records upon incident detection 412 events and not only upon flow end or fixed time intervals. 414 Intrusion detection would profit from the combination of IPFIX 415 functions with AAA functions (see section 3.5). Such an 416 interoperation enables further means for attacker detection, 417 advanced defense strategies and secure inter-domain cooperation. 419 2.5 QoS Monitoring 421 QoS monitoring is one target application of the IPFIX protocol 422 [RFC3917]. QoS monitoring is the passive observation of the 423 transmission quality for single flows or traffic aggregates in 424 the network. One example of its use is the validation of QoS 425 guarantees in service level agreements (SLAs). Typical QoS 426 parameters are loss [RFC2680], one-way [RFC2679] and round-trip 427 delay [RFC2681] and delay variation [RFC3393]. Whenever 428 applicable the metric definitions of the IPPM group should be 429 used when reporting QoS Metrics. 430 The calculation of those QoS metrics requires per-packet 431 processing. Reporting packet information with IPFIX is possible 432 by simply considering a single packet as flow. [IPFIX-PROTO] 433 also allows the reporting of multiple identical information 434 elements in one flow record. Using this feature for reporting 435 information about multiple packets in one record would require 436 additional agreement on semantics regarding the order of 437 information elements (e.g. which timestamp belongs to which 438 packet payload in a sequence of information elements). [PSAMP- 439 INFO] defines useful additional information elements for 440 exporting per packet information with IPFIX. 442 2.5.1 Correlating Events from Multiple Observation Points 444 Some QoS metrics require the correlation of data from multiple 445 observation points. For this the clocks of the involved metering 446 processes must be synchronized. Furthermore, it is necessary to 447 recognize that the same packet was observed at different 448 observation point. 450 This can be done by capturing parts of the packet content 451 (packet header and/or parts of the payload) that do not change 452 on the way to the destination. Based on the packet content it 453 can be recognized when the same packet arrived at another 454 observation point. To reduce the amount of measurement data a 455 unique packet ID can be calculated from the packet content e.g. 456 by using a CRC or hash function instead of transferring and 457 comparing the unprocessed content. Considerations on collision 458 probability and efficiency of using such packet IDs are 459 described in [GrDM98, DuGr00, ZsZC01]. 461 IPFIX allows the reporting of several IP and transport header 462 fields (see section 5.3 and 5.4 in [IPFIX-INFO]). Using only 463 those fields for packet recognition or ID generation can be 464 sufficient in scenarios where those header fields vary a lot 465 among subsequent packets, where a certain amount of packet ID 466 collisions is tolerable or where packet IDs need to be unique 467 only for a small time interval. 469 For including packet payload information the information element 470 ipPayloadPacketSection defined in [PSAMP-INFO] can be used. The 471 information element ipHeaderPacketSection can also be used. But 472 header fields that can change on the way from source to 473 destination have to be excluded from the packet ID generation, 474 because they may differ at different observation points. 476 For reporting packet IDs generated by a CRC or hash function the 477 information element digestHashValue defined in [PSAMP-INFO] can 478 be used. 480 2.5.2 Examples 482 The following examples show which information elements need to 483 be reported by IPFIX to generate specific QoS metrics. As an 484 alternative the metrics can be generated directly at the 485 exporter and IPFIX can be used to export the metrics (see 486 section 2.7) 488 2.5.2.1 RTT measurements with packet pair matching (single-point) 490 The passive measurement of round-trip-times (RTT) can be 491 performed by using packet pair matching techniques as described 492 in [Brow00]. For the measurements, request/response packet pairs 493 from protocols such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK, 494 DATA/ACK) are utilized to passively observe the RTT [Brow00]. 495 This technique requires the correlation of data from both 496 directions. 498 Required information elements per packet (DNS example): 499 - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO] 500 - DNS header: ipPayloadPacketSection [PSAMP-INFO] 502 Required functions: 503 - Recognition of request/response packet pairs 505 Remarks: 506 - Requires information elements from [PSAMP-INFO] 507 - observationTimeMicroseconds can be substituted by 508 flowStartMicroseconds [IPFIX-INFO], because a single packet 509 can be represented as a flow. 510 - If time values with a finer granularity are needed 511 observationTimeNanoseconds can be used. 513 2.5.2.2 One-way Delay Measurements (multi-point) 515 Passive one-way-delay measurements require the collection of 516 data at two observation points. As mentioned above synchronized 517 clocks are needed to avoid time-differences at the involved 518 observation points. 520 The recognition of packets at the second observation point can 521 be based on parts of the packet content directly. A more 522 efficient way is to use a packet ID (generated from packet 523 content). 525 Required information elements per packet (with packet ID): 526 - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO] 527 - Packet ID: digestHashValue [PSAMP-INFO] 529 Required functions: 530 - packet ID generation 531 - delay calculation (from arrival times at the two observation 532 points) 534 Remarks: 535 - Requires information elements from [PSAMP-INFO] 536 - observationTimeMicroseconds can be substituted by 537 flowStartMicroseconds [IPFIX-INFO], because a single packet 538 can be represented as a flow. 539 - If time values with a finer granularity are needed 540 observationTimeNanoseconds can be used. 541 - The amount of content used for ID generation influences the 542 number of collisions (different packets that map to the same 543 ID) that can occur. Investigations on this and other 544 considerations on packet ID generation can be found in 545 [GrDM98], [DuGr00], and [ZsZC01]. 547 2.6 Inter-Domain Exchange of IPFIX data 549 IPFIX data can be used to share information with neighbor 550 providers. A few recommendations should to be considered if 551 IPFIX records travel over the public Internet compared to its 552 usage within a single domain. First of all, security threat 553 levels are higher if data travels over the public Internet. 554 Protection against disclosure or manipulation of data is even 555 more important than for intra-domain usage. Therefore IPsec or 556 Transport Layer Security (TLS) should be used as described in 557 [IPFIX-PROTO]. 559 Furthermore data transfer should be congestion-aware in order to 560 allow untroubled co-existence with other data flows in public or 561 foreign networks. That means transport over SCTP or TCP is 562 required. 564 Some ISPs are still reluctant to share information due to 565 concerns that competing ISPs might exploit network information 566 from neighbor providers to strengthen their own position in the 567 market. Nevertheless, technical needs have already triggered the 568 exchange of data in the past (e.g. exchange of routing 569 information by BGP). The need to provide inter-domain guarantees 570 is one big incentive to increase inter-domain cooperation. The 571 necessity to defend networks against current and future threats 572 (denial of service attacks, worm distributions, etc.) will 573 hopefully increase the willingness to exchange measurement data 574 between providers. 576 2.7 Export of Derived Metrics 578 The IPFIX protocol is used to transport flow and packet 579 information to provide the input for the calculation of a 580 variety metrics (e.g. for QoS validation or attack detection). 581 IPFIX can also be used to transfer these metrics directly, e.g. 582 if the metric calculation is co-located with measurement and 583 exporting process. 585 It doesn't matter which measurement and post-processing 586 functions are applied to generate a specific metric. IPFIX can 587 be used to transport the results from passive and active 588 measurements and from post-processing operations. For the 589 reporting of derived metrics additional information elements 590 need to be defined. 592 For most QoS metrics like like loss, delay, delay variation etc. 593 standard definitions exist from the IPPM group. In case such 594 metrics are reported with IPIFX, the IPPM standard definition 595 should be used. 597 2.8 Summary 599 The following table shows an overview of the information 600 elements required for the target applications described in 601 [RFC3917] (M-mandatory, R-recommended, O-optional). 603 | Application |[IPFIX-INFO]| [PSAMP-INFO] | additional IEs | 604 +-------------+------------+--------------+-----------------+ 605 | Accounting | M | - | - | 606 +-------------+------------+--------------+-----------------+ 607 | Traffic | M | O | - | 608 | Profiling | | | | 609 +-------------+------------+--------------+-----------------+ 610 | Traffic | M | - | O | 611 | Engineering | | | (routing info) | 612 +-------------+------------+--------------+-----------------+ 613 | Attack | M | R | R | 614 | Detection | | |(derived metrics)| 615 +-------------+------------+--------------+-----------------+ 616 | QoS | M | M | O | 617 | Monitoring | |(most metrics)|(derived metrics)| 618 +-------------+------------+--------------+-----------------+ 620 For accounting the IEs in [IPFIX-INFO] are sufficient. As 621 mentioned above, IPFIX does not conform to the reliability 622 requirements demanded by [RFC2975] for usage-based billing 623 systems (see section 4.2). For traffic profiling additionally 624 IEs from [PSAMP-INFO] can be useful to gain more insight into 625 the traffic. For traffic engineering flow information from 626 [IPFIX-INFO] is sufficient but it would profit from routing 627 information, which could be exported by IPFIX. Attack detection 628 usually profits from further insight into the traffic. This can 629 be achieved with IEs from [PSAMP-INFO]. Furthermore the 630 reporting of derived metrics in additional IEs would be useful. 631 Most QoS metrics require the use of IEs from [PSAMP-INFO]. IEs 632 from [PSAMP-INFO]are also useful for the mapping of results from 633 different observation points as described in section 2.5.1. 635 3. Relation of IPFIX to Other Frameworks and Protocols 637 3.1 IPFIX and IPv6 639 IPFIX has been designed from the beginning for IPv4 and IPv6. 640 Therefore IPFIX can be used in IPv4 and IPv6 networks without 641 limitations. The usage of IPFIX in IPv6 networks has two 642 aspects: 644 - Generation and reporting of IPFIX records about IPv6 traffic 645 - Exporting IPFIX records over IPv6 647 The generation and reporting of IPFIX records about IPv6 traffic 648 is possible. Appropriate information elements for the reporting 649 of IPv6 traffic are defined in [IPFIX-INFO]. 651 Exporting IPFIX records over IPv6 is not explicitly addressed in 652 [IPFIX-PROTO]. Since IPFIX runs over a transport protocol (SCTP, 653 SCTP-PR, UDP or TCP) and all potential IPFIX transport protocols 654 can run in IPv6 networks one just need to provide the chosen 655 transport protocol in the IPv6 network to run IPFIX over IPv6. 657 3.2 IPFIX and PSAMP 659 PSAMP defines packet selection methods, their configuration at 660 routers and probes and the reporting of packet information. 662 PSAMP uses IPFIX as basis for exporting packet information 663 [PSAMP-PROTO]. [PSAMP-INFO] describes further information 664 elements for exporting packet information and reporting 665 configuration information. 667 The main difference between IPFIX and PSAMP is that IPFIX 668 addresses the export of flow records whereas PSAMP addresses the 669 export of packet records. Furthermore, PSAMP explicitly 670 addresses remote configuration. It defines a MIB for the 671 configuration of packet selection processes. Remote 672 configuration is not (yet) addressed in IPFIX, but one could 673 consider extending the PSAMP MIB to also allow configuration of 674 IPFIX processes. 676 3.3 IPFIX and RMON 678 RMON [RFC3577] is a widely used monitoring system that gathers 679 traffic data from RMON Agents in network devices. One major 680 difference between RMON and IPFIX is that RMON uses SNMP for 681 data export whereas IPFIX defines an own push-oriented protocol. 682 RMON defines MIBs that contain the information to be exported. 683 In IPFIX the data to be exported is defined as information 684 elements. 686 The most relevant MIBs for a comparison with IPFIX are the 687 Application Performance Measurement MIB (APM-MIB) [RFC3729] and 688 the Transport Performance Metrics MIB (TPM-MIB) [RFC4150]. 689 The APM-MIB has a complex system for tracking user application 690 performance, with reporting about transactions and SLA threshold 691 notification-trigger configuration, and persistence across DHCP 692 lease expirations. It requires full RMON2-MIB protocolDirTable 693 implementation. 695 The APM-MIB reports the performance of transactions. A 696 transaction is a service oriented term and describes the data 697 exchange from the transaction start (when a user requests a 698 service) until its completion. The performance parameters 699 include response times, throughput, streaming responsiveness and 700 availability of services. 701 The RMON transaction concept differs from the IPFIX flow 702 concept. A flow is a very generic term and allows to group IP 703 packets in accordance to common properties. In contrast to 704 this, the term transaction is service-oriented and contains all 705 data exchange required for service completion. 706 In order to report such data with IPFIX one would probably need 707 a specific combination of multiple flows and the ability to map 708 those to the transaction. Due to the service-orientated focus of 709 APM, also the required metrics differ. For instance, the RMON 710 APM requires a metric for the responsiveness of services. Such 711 metrics are not addressed in IPFIX. 713 Furthermore, the APM-MIB allows the configuration of the 714 transaction type to be monitored, i.e., it addresses the 715 configuration of the metering process, which is currently not 716 addressed in IPFIX. 718 The APM MIB could be considered as an extension of the IPFIX 719 metering process where the application performance of a 720 combination of multiple flows is measured. If appropriate IEs 721 would be defined in the IPFIX information model and the IPFIX 722 device would support the APM MIB data collection, the solutions 723 could be complimentary. That means one could use IPFIX to export 724 APM MIB transaction information. 726 The TPM-MIB breaks out the APM-MIB transactions into sub- 727 application level transactions. For instance a web request is 728 broken down into DNS, TCP and HTTP sub-transactions. 729 Such sub-transactions can be considered as bi-directional flows. 730 With an appropriate flow definitions and the ability to map both 731 directions of a flow (see section 4.6), one could measure and 732 report flow characteristics of such sub-application level 733 transaction with IPFIX. 735 The TPM-MIB requires APM-MIB and RMON2-MIB. 737 3.4 IPFIX and IPPM 739 The IPFIX protocol can be used to carry IPPM network performance 740 metrics or information that can be used to calculate those 741 metrics (see sections 2.5 and 2.7 for details and references). 743 3.5 IPFIX and AAA 745 AAA defines a protocol and architecture for authentication, 746 authorization and accounting for service usage [RFC2903]. The 747 DIAMETER protocol [RFC3588] is used for AAA communication, which 748 is needed for network access services (Mobile IP, NASREQ, and 749 ROAMOPS). The AAA architecture [RFC2903] provides a framework 750 for extending AAA support to other services. DIAMETER defines 751 the exchange of messages between AAA entities, e.g. between AAA 752 clients at access devices and AAA servers, and among AAA 753 servers. DIAMETER is used for the transfer of accounting 754 records. In order to form accounting records for usage-based 755 accounting measurement data from the network is required. IPFIX 756 defines a protocol to export such data from routers, measurement 757 probes and other devices. Therefore it looks promising to 758 connect those two architectures. 760 For all scenarios described here one has to keep in mind that 761 IPFIX does not conform to the reliability requirements for 762 usage-based billing described in [RFC2975] (see section 4.2). 763 Using IPFIX without reliability extensions together with AAA 764 would result in accounting scenarios that do not conform to 765 usage-based billing requirements described in [RFC2975]. 767 As shown in section 2.1 accounting applications can directly 768 incorporate an IPFIX collecting process to receive IPFIX records 769 with information about the transmitted volume. Nevertheless, if 770 an AAA infrastructure is in place, the cooperation between IPFIX 771 (and especially IPFIX with reliability extensions) and AAA 772 provides many valuable synergistic benefits. IPFIX records can 773 provide the input for AAA accounting functions and provide the 774 basis for the generation of DIAMETER accounting records. 776 Further potential features include the mapping of a user ID to 777 flow information (by using authentication information) or using 778 the secure authorized exchange of DIAMETER accounting records 779 with neighbor domains. The last feature is especially useful in 780 roaming scenarios where the user connects to a foreign network 781 and the home provider generates the invoice. 783 Coupling an IPFIX collecting process with AAA functions has also 784 high potential for intrusion and attack detection. AAA controls 785 network access and maintains data about users and nodes. AAA 786 functions can help to identify the source of malicious traffic. 787 Authorization functions are able to deny access to suspicious 788 users or nodes. Therefore coupling those functions with an IPFIX 789 collecting process can provide an efficient defense against 790 network attacks. Sharing IPFIX records (either directly or 791 encapsulated in DIAMETER) with neighbor providers allows an 792 efficient inter-domain attack detection. The AAA infrastructure 793 can also be used to configure measurement functions in the 794 network as proposed in [RFC3334]. 796 Two possibilities exist to connect IPFIX and AAA: 798 - Connecting via an AAA Client 799 - Connecting via an Application Specific Module (ASM) 801 Both are explained in the following sections. The approaches 802 only require few additional functions. They do not require any 803 changes to IPFIX or DIAMETER. 805 3.5.1 Connecting via an AAA Client 807 One possibility of connecting IPFIX and AAA is to run an AAA 808 client on the IPFIX collector. This client can generate DIAMETER 809 accounting messages and send them to an AAA server. The mapping 810 of the flow information to a user ID can be done in the AAA 811 server by using data from the authentication process. DIAMETER 812 accounting messages can be sent to the accounting application or 813 to other AAA servers (e.g. in roaming scenarios). 815 +---------+ DIAMETER +---------+ 816 | AAA-S |------------->| AAA-S | 817 +---------+ +---------+ 818 ^ 819 | DIAMETER 820 | 821 | 822 +--+--------+--+ 823 | | AAA-C | | 824 + +--------+ | 825 | | 826 | Collector | 827 +--------------+ 828 ^ 829 | IPFIX 830 | 831 +------------+ 832 | Exporter | 833 +------------+ 835 Figure 2: IPFIX collector connects to AAA server via AAA client 837 3.5.2 Connecting via an Application Specific Module (ASM) 839 Another possibility is to directly connect the IPFIX collector 840 with the AAA server via an application specific module (ASM). 841 Application specific modules have been proposed by the IRTF AAA 842 architecture research group (AAARCH) in [RFC2903]. They act as 843 an interface between AAA server and service equipment. In this 844 case the IPFIX collector is part of the ASM. The ASM acts as an 845 interface between the IPFIX protocol and the input interface of 846 the AAA server. The ASM translates the received IPFIX data into 847 an appropriate format for the AAA server. The AAA server then 848 can add information about the user ID and generate a DIAMETER 849 accounting record. This accounting record can be sent to an 850 accounting application or to other AAA servers. 852 +---------+ DIAMETER +---------+ 853 | AAA-S |------------->| AAA-S | 854 +---------+ +---------+ 855 ^ 856 | 857 +------------------+ 858 | ASM | 859 | +------------+ | 860 | | Collector | | 861 +------------------+ 862 ^ 863 | IPFIX 864 | 865 +------------+ 866 | Exporter | 867 +------------+ 869 Figure 3: IPFIX connects to AAA server via ASM 871 3.6 IPFIX and RTFM 873 The Real-time Traffic Flow Measurement (RTFM) working group 874 defined an architecture for flow measurement [RFC2722]. This 875 section compares the Real-time Traffic Flow Measurement (RTFM) 876 framework with the IPFIX framework. 878 3.6.1 Architecture 880 The RTFM architecture is very similar to the IPFIX architecture. 881 It defines meter, meter reader and a manager as building blocks 882 of the measurement architecture. The manager configures the 883 meter and the meter reader collects data from the meter. 884 In RTFM the building blocks communicate via SNMP. 885 The IPFIX architecture [IPFIX-ARCH] defines metering, exporting 886 and collecting processes. IPFIX speaks about processes instead 887 of devices to clarify that multiple of those processes may be 888 collocated on the same machine. 890 Both definitions do not contradict each other. One could see the 891 metering process as part of the meter and the collecting process 892 as part of the meter reader. 894 One difference is that IPFIX currently does not define a 895 managing process, because remote configuration was at least 896 initially out of scope for the working group. 898 3.6.2 Flow Definition 900 RTFM and IPFIX both consider flows as a group of packets which 901 share a common set of properties. A flow is completely specified 902 by that set of values, together with a termination criterion 903 (like inactivity timeout). 905 A difference is that RTFM defines flows as bidirectional. An 906 RTFM meter matches packets from B to A and A to B as separate 907 parts of a single flow, and maintains two sets of packet and 908 byte counters, one for each direction. 910 IPFIX does not explicitly state whether flows are uni- or 911 bidirectional. Nevertheless information elements for describing 912 flow properties were defined only for one direction in [IPFIX- 913 INFO]. Nevertheless, there are several solutions for reporting 914 bi-directional flow information (see section 4.6). 916 3.6.3 Configuration and Management 918 In RTFM, remote configuration is the only way to configure a 919 meter. This is done by using SNMP and a specific Meter MIB 920 [RFC2720]. The IPFIX group currently does not address IPFIX 921 remote configuration. 923 IPFIX metering processes export the layout of data within their 924 templates, from time to time. IPFIX collecting processes use 925 that template information to determine how they should interpret 926 the IPFIX flow data they receive. 928 3.6.4 Data Collection 930 One major difference between IPFIX and RTFM is the data 931 collection model. RTFM retrieves data in pull mode whereas IPFIX 932 uses a push mode model to send data to collecting processes. 934 An RTFM meter reader pulls data from a meter by using SNMP. SNMP 935 security on the meter determines whether a reader is allowed to 936 pull data from it. An IPFIX exporting process is configured to 937 export records to a specified list of IPFIX collecting 938 processes. The condition when to send IPFIX records (e.g. flow 939 termination) has to be configured in the exporting or metering 940 process. 942 3.6.5 Data Model Details 944 RTFM defines all its attributes in the RTFM Meter MIB [RFC2720]. 945 IPFIX information elements are defined in [IPFIX-INFO]. 947 RTFM uses continuously-incrementing 64-bit counters for the 948 storage of the number of packets of a flow. The counters are 949 never reset and just wrap back to zero if the maximum value is 950 exceeded. Flows can be read at any time. The difference between 951 counter readings gives the counts for activity in the interval 952 between readings. 954 IPFIX allows absolute (totalCounter) and relative counters 955 (deltaCounter) [IPFIX-INFO]. The totalCounter is never reset and 956 just wraps to zero if values are too large, exactly as the 957 counters used in RTFM. The deltaCounter is reset to zero when 958 the associated flow record is exported. 960 3.6.6 Transport Protocol 962 RTFM has a standards-track Meter MIB [RFC2720], which is used 963 both to configure a meter and to store metering results. The 964 MIB provides a way to read lists of attributes with a single 965 Object Identifier (called a 'package'), which reduces the SNMP 966 overhead for flow data collection. SNMP, of course, normally 967 uses UDP as its transport protocol. Since RTFM requires a 968 reliable flow data transport system, an RTFM meter reader must 969 time out and resend unanswered SNMP requests. Apart from being 970 clumsy, this can limit the maximum data transfer rate from meter 971 to meter reader. 973 IPFIX is designed to work over a variety of different transport 974 protocols. SCTP [RFC2960] and SCTP-PR [RFC3758] are mandatory. 975 UDP and TCP are optional. In addition, the IPFIX protocol 976 encodes data much more efficiently than SNMP does, hence IPFIX 977 has lower data transport overheads than RTFM. 979 3.6.7 Summary 981 IPFIX exports flow information in push model by using SCTP, TCP 982 or UDP. It currently does not address remote configuration. RTFM 983 data collection is using the pull model and runs over SNMP. RTFM 984 addresses remote configuration which also runs over SNMP. Both 985 frameworks allow a very flexible flow definition, although RTFM 986 is based on a bi-directional flow definition. 988 4. Limitations 990 The goal of this section is to show the limitations of IPFIX and 991 to give advice where not to use IPFIX or in which cases 992 additional considerations are required. 994 4.1 Using IPFIX for other Applications than in RFC3917 996 IPFIX provides a generic export mechanism. Due to its template 997 based structure, it is a quite flexible protocol. Network 998 operators and users may want to use it also for other 999 applications than those described in [RFC3917]. 1001 Apart from sending raw flow information it can be used to send 1002 aggregated or post-processed data. For this new templates and 1003 information elements can be defined if needed. Due to its push 1004 mode operation IPFIX is also suited to send network initiated 1005 events like alarms and other notifications. It can be used for 1006 exchanging information among network nodes to autonomously 1007 improve network operation. 1009 Nevertheless, the IPFIX design is based on the requirements that 1010 originate only from the target applications stated in [RFC3917]. 1011 Using IPFIX for other purposes requires a careful checking of 1012 IPFIX capabilities against application requirements. Only with 1013 this, can one decide whether IPFIX is a suitable protocol to 1014 meet the needs of a specific application. 1016 4.2 Using IPFIX for Billing (Reliability Limitations) 1018 The reliability requirements defined in [RFC3917] are not 1019 sufficient to guarantee the level of reliability that is needed 1020 for usage-based billing systems as described in [RFC2975]. In 1021 particular IPFIX does not support the following features 1022 required by [RFC2975]: 1024 - Record loss: IPFIX allows the usage of different transport 1025 protocols for the transfer of data records. Resilience against 1026 the loss of IPFIX data records can be only provided if TCP or 1027 SCTP-PR is used for the transfer of data records. 1028 - Network or device failures: IPFIX does allow the usage of 1029 multiple collectors for one exporter, but it does neither 1030 specify nor demand the usage of multiple collectors for the 1031 provisioning of fault tolerance. 1032 - Detection and elimination of duplicate records: This is 1033 currently not supported by IPFIX. 1034 - Application layer acknowledgements: IPFIX does not support the 1035 control of measurement and exporting processes by higher level 1036 applications. Application layer acknowledgements are necessary 1037 e.g. to inform the exporter in case the application is not 1038 able to process the data exported with IPFIX. Such 1039 acknowledgements are not supported in IPFIX. 1041 Further features like archival accounting and pre-authorization, 1042 are out of scope of the IPFIX specification but need to be 1043 realized in billing system architectures as described in 1044 [RFC2975]. 1046 4.3 Using a Different Transport Protocol than SCTP 1048 SCTP is the preferred protocol for IPFIX, i.e. a conforming 1049 implementation must work over SCTP. Although IPFIX can also work 1050 over TCP or UDP, both protocols have drawbacks [IPFIX-PROTO]. 1051 Users should make sure they have good reasons befor using 1052 protocols other than SCTP in a specific environment. 1054 4.4 Push vs. Pull Mode 1056 IPFIX works in push mode. That means IPFIX records are 1057 automatically exported without waiting for a request. 1058 The responsibility for initiating a data export lies with the 1059 exporting process. 1061 Criteria for exporting data need to be configured at the 1062 exporting process. Therefore push mode has more benefits if the 1063 trigger for data export is related to events at the exporting 1064 process (e.g. flow termination, memory shortage due to large 1065 amount of flows, etc.). If the protocol used pull mode, the 1066 exporting process would need to wait for a request to send the 1067 data. With push mode it can send data immediately e.g. before 1068 memory shortage would require a discarding of data. 1070 With push mode one can prevent the overloading of resources at 1071 the exporting process by simply exporting the information as 1072 soon as certain thresholds are about to be exceeded. Therefore 1073 exporting criteria are often related to traffic characteristics 1074 (e.g. flow timeout) or resource limitations (e.g. size of flow 1075 cache). But traffic characteristics are usually quite dynamic 1076 and often impossible to predict. If those are used to trigger 1077 flow export, the exporting rate and the resource consumption for 1078 flow export becomes variable and unpredictable. 1080 Pull mode has advantages if the trigger for data export is 1081 related to events at the collecting process (e.g. a specific 1082 application requests immediate input). 1084 In a pull mode, a request could simply be forwarded to the 1085 exporting process. In a push mode, the exporting configuration 1086 must be changed to trigger the export of the requested data. 1087 Furthermore, with pull mode one can prevent the overloading of 1088 the collecting process by the arrival of more records than it 1089 can process. 1091 Whether this is a relevant drawback depends on the flexibility 1092 of the IPFIX configuration and how IPFIX configuration rules are 1093 implemented. 1095 4.5 Template ID number 1097 The IPFIX specification limits the different template ID numbers 1098 that can be assigned to the newly generated template records in 1099 an observation domain. In particular, template IDs up to 255 are 1100 reserved for Template or option sets (or other sets to be 1101 created) and template IDs from 256 to 65535 are assigned to data 1102 sets. In the case of many exports requiring many different 1103 templates, the set of Template IDs could be exhausted. 1105 4.6 Exporting Bidirectional Flow Information 1107 Although IPFIX does not explicitly state that flows are 1108 unidirectional, information elements that describe flow 1109 characteristics are defined only for one direction in [IPFIX- 1110 INFO]. [IPFIX-PROTO] allows the reporting of multiple identical 1111 information elements in one flow record. With this information 1112 elements for forward and reverse direction can be reported in 1113 one flow record. 1115 But this is not sufficient. Using this feature for reporting 1116 bidirectional flow information would require an agreement on the 1117 semantic of information elements (e.g. first counter is counter 1118 for the forward direction, second counter for reverse 1119 direction). 1121 Another option is to use two adjacent flow records to report 1122 both directions of a bidirectional flow separately. This 1123 approach requires additional means for mapping those records and 1124 is quite inefficient due to the redundant reporting of flow 1125 keys. 1127 4.7 Remote Configuration 1129 Remote configuration was initially out of scope of the IPFIX 1130 working group in order to concentrate on the protocol 1131 specification. Therefore there is currently no standardized way 1132 to configure IPFIX processes remotely. Nevertheless due to the 1133 broad need for this feature, it is quite likely that solutions 1134 for this will be standardized soon. 1136 5. Security Considerations 1138 This document describes the usage of IPFIX in various scenarios. 1139 Security requirements for IPFIX target applications and security 1140 considerations for IPFIX are addressed in [RFC3917] and [IPFIX- 1141 PROTO]. Those requirements have to be met for the usage of IPFIX 1142 for all scenarios described in this document. To our current 1143 knowledge, the usage scenarios proposed in section 2 do not 1144 induce further security hazards. 1145 The threat level to IPIFX itself may depend on the usage 1146 scenario of IPFIX. The usage of IPFIX for accounting or attack 1147 detection may increase the incentive to attack IPFIX itself. 1148 Nevertheless, security considerations have to be taken into 1149 account in all described scenarios. 1151 As described in the security considerations in [IPFIX-PROTO] 1152 security incidents can become a threat to IPFIX processes 1153 themselves, even if IPIFX is not the target of the attack. If an 1154 attack generates a large amount of flows (e.g. by sending 1155 packets with spoofed addresses or simulating flow termination) 1156 exporting and collecting process may get overloaded by the 1157 immense amount of records that are exported. A flexible 1158 deployment of packet or flow sampling methods can be useful to 1159 prevent the exhaustion of resources. 1161 Section 3 of this document describes how IPFIX can be used in 1162 combination with other technologies. New security hazards can 1163 arise when two individually secure technologies or architectures 1164 are combined. For the combination of AAA with IPFIX an 1165 application specific module (ASM) or an IPFIX collector can 1166 function as transit point for the messages. It has to be ensured 1167 that at this point the applied security mechanisms (e.g. 1168 encryption of messages) are maintained. 1170 6. IANA Considerations 1172 This document has no actions for IANA. 1174 7. Normative References 1176 [IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, "Information Model 1177 for IP Flow Information Export", Internet Draft 1178 , work in progress, May 1179 2005 1181 [IPFIX-PROTO] B. Claise (Editor), "IPFIX Protocol Specification", 1182 Internet Draft , 1183 work in progress, April 2006 1185 [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, 1186 "Information Model for Packet Sampling Exports", 1187 Internet Draft , work 1188 in progress, March 2006 1190 [RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander, 1191 "Requirements for IP Flow Information Export", RFC 1192 3917, October 2004 1194 8. Informative References 1196 [Brow00] Nevil Brownlee, "Packet Matching for NeTraMet 1197 Distributions", 1198 http://www2.auckland.ac.nz/net//Internet/rtfm/meeti 1199 ngs/47-adelaide/pp-dist/ 1201 [DuGr00] Nick Duffield, Matthias Grossglauser, "Trajectory 1202 Sampling for Direct Traffic Observation", 1203 Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 1204 August 28 - September 1, 2000 1206 [GrDM98] Ian D. Graham, Stephen F. Donnelly, Stele Martin, 1207 Jed Martens, John G. Cleary, "Nonintrusive and 1208 Accurate Measurement of Unidirectional Delay and 1209 Delay Variation on the Internet", INET'98, Geneva, 1210 Switzerland, 21-24 July, 1998 1212 [IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek, 1213 "Architecture for IP Flow Information Export", 1214 Internet Draft , work in progress, March 2005 1217 [PSAMP-PROTO] Benoit Claise (Ed.), Packet Sampling (PSAMP) 1218 Protocol Specifications, Internet Draft , work in progress, 1220 March 2006 1222 [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. 1223 Raspall, "Sampling and Filtering Techniques for IP 1224 Packet Selection" Internet Draft , work in progress, July 2005 1227 [RFC2598] V. Jacobson, K. Nichols, K. Poduri, "An Expedited 1228 Forwarding PHB", RFC 2598, June 1999 1230 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way 1231 Delay Metric for IPPM", RFC 2679, September 1999 1233 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way 1234 Packet Loss Metric for IPPM",RFC 2680, September 1235 1999 1237 [RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip 1238 Delay Metric for IPPM", RFC 2681, September 1999 1240 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. 1241 McManus, "Requirements for Traffic Engineering Over 1242 MPLS", RFC 2702, September 1999 1244 [RFC2720] N. Brownlee, Traffic Flow Measurement: Meter MIB, 1245 RFC2720 October 1999 1247 [RFC2722] Brownlee, N., Mills, C., G. Ruth, "Traffic Flow 1248 Measurement: Architecture", RFC 2722, October 1999 1250 [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. 1251 Spence, "Generic AAA Architecture", RFC 2903, 1252 August 2000 1254 [RFC2960] R. Stewart (ed.) "Stream Control Transmission 1255 Protocol", RFC 2960, October 2000 1257 [RFC2975] B. Aboba, J. Arkko, D. Harrington, "Introduction to 1258 Accounting Management", RFC 2975, October 2000 1260 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330 1261 September 2002 1263 [RFC3334] T. Zseby, S. Zander, G. Carle, "Policy-Based 1264 Accounting", RFC 3334, October 2002 1266 [RFC3393] C. Demichelis, P. Cimento, "IP Packet Delay 1267 Variation Metric for IPPM", RFC 3393, November 2002 1269 [RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch, 1270 D.Romascanu, "Introduction to the Remote Monitoring 1271 (RMON) Family of MIB Module", RFC 3577, August 2003 1273 [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. 1274 Arkko, "Diameter Base Protocol", RFC 3588, 1275 September 2003 1277 [RFC3729] S. Waldbusser, "Application Performance Measurement 1278 MIB", RFC 3729, March 2004 1280 [RFC3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. 1281 Conrad, "Stream Control Transmission Protocol 1282 (SCTP) Partial Reliability Extension", RFC 3758, 1283 May 2004 1285 [RFC4150] R. Dietz, R. Cole, "Transport Performance Metrics 1286 MIB", RFC 4150, August 2005 1288 [ZsZC01] T. Zseby, S. Zander, G. Carle, "Evaluation of 1289 Building Blocks for Passive One-way-delay 1290 Measurements", Proceedings of Passive and Active 1291 Measurement Workshop (PAM 2001), Amsterdam, The 1292 Netherlands, April 23-24, 2001 1294 9. Acknowledgements 1296 We would like to thank the following persons for their 1297 contribution, discussion on the mailing list and valuable 1298 comments: 1300 Sebastian Zander 1301 Robert Loewe 1302 Reinaldo Penno 1303 Lutz Mark 1304 Andy Biermann 1306 Part of the work has been developed in the research project 6QM 1307 co-funded with support from the European Commission. 1309 10.Authors' Addresses 1311 Tanja Zseby 1312 Fraunhofer Institute for Open Communication Systems (FOKUS) 1313 Kaiserin-Augusta-Allee 31 1314 10589 Berlin, Germany 1315 Phone: +49 30 3463 7153 1316 Email: zseby@fokus.fhg.de 1318 Elisa Boschi 1319 Hitachi Europe SAS 1320 Immeuble Le Theleme 1321 1503 Route des Dolines 1322 06560 Valbonne, France 1323 Phone: +33 4 89874180 1324 Email: elisa.boschi@hitachi-eu.com 1326 Nevil Brownlee 1327 CAIDA (UCSD/SDSC) 1328 9500 Gilman Drive 1329 La Jolla, CA 92093-0505 1330 Phone : +1 858 534 8338 1331 Email : nevil@caida.org 1333 Benoit Claise 1334 Cisco Systems 1335 De Kleetlaan 6a b1 1336 1831 Diegem 1337 Belgium 1338 Phone: +32 2 704 5622 1339 Email: bclaise@cisco.com 1341 11.Full Copyright Statement 1343 "Copyright (C) The Internet Society (2006). All Rights Reserved. 1344 This document and translations of it may be copied and furnished 1345 to others, and derivative works that comment on or otherwise 1346 explain it or assist in its implementation may be prepared, 1347 copied, published and distributed, in whole or in part, without 1348 restriction of any kind, provided that the above copyright 1349 notice and this paragraph are included on all such copies and 1350 derivative works. However, this document itself may not be 1351 modified in any way, such as by removing the copyright notice or 1352 references to the Internet Society or other Internet 1353 organizations, except as needed for the purpose of developing 1354 Internet standards in which case the procedures for copyrights 1355 defined in the Internet Standards process must be followed, or 1356 as required to translate it into. 1358 12. Intellectual Property Statement 1359 The IETF takes no position regarding the validity or scope of 1360 any Intellectual Property Rights or other rights that might be 1361 claimed to pertain to the implementation or use of the 1362 technology described in this document or the extent to which any 1363 license under such rights might or might not be available; nor 1364 does it represent that it has made any independent effort to 1365 identify any such rights. Information on the procedures with 1366 respect to rights in RFC documents can be found in BCP 78 and 1367 BCP 79. 1369 Copies of IPR disclosures made to the IETF Secretariat and any 1370 assurances of licenses to be made available, or the result of an 1371 attempt made to obtain a general license or permission for the 1372 use of such proprietary rights by implementers or users of this 1373 specification can be obtained from the IETF on-line IPR 1374 repository at http://www.ietf.org/ipr. 1376 The IETF invites any interested party to bring to its attention 1377 any copyrights, patents or patent applications, or other 1378 proprietary rights that may cover technology that may be 1379 required to implement this standard. Please address the 1380 information to the IETF at ietf-ipr@ietf.org. 1382 13. Copyright Statement 1384 Copyright (C) The Internet Society (2006). This document is 1385 subject to the rights, licenses and restrictions contained in 1386 BCP 78, and except as set forth therein, the authors retain all 1387 their rights. 1389 14. Disclaimer 1391 This document and the information contained herein are provided 1392 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1393 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1394 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1395 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1396 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1397 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1398 FOR A PARTICULAR PURPOSE.