idnits 2.17.1 draft-ietf-ipfix-as-12.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, updated by RFC 4748 on line 1406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1441. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 22) being 59 lines 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 IETF Trust 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 (June 2007) is 6153 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) -- 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: 2 errors (**), 0 flaws (~~), 3 warnings (==), 13 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 Intended Status: Informational Elisa Boschi 5 Expires: December 2007 Hitachi 6 Nevil Brownlee 7 CAIDA 8 Benoit Claise 9 Cisco Systems 11 June 2007 13 IPFIX Applicability 14 draft-ietf-ipfix-as-12.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 IETF Trust (2007). 44 Abstract 46 In this document we describe the applicability of the IP Flow 47 Information Export (IPFIX) protocol for a variety of 48 applications. We show how applications can use IPFIX, describe 49 the relevant information elements (IEs) for those applications 50 and present opportunities and limitations of the protocol. We 51 furthermore describe 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......12 64 2.5.2 Examples.................................................12 65 2.6 Inter-Domain Exchange of IPFIX data.......................14 66 2.7 Export of Derived Metrics.................................14 67 2.8 Summary...................................................15 68 3. Relation of IPFIX to Other Frameworks and Protocols.......16 69 3.1 IPFIX and IPv6............................................16 70 3.2 IPFIX and PSAMP...........................................16 71 3.3 IPFIX and RMON............................................17 72 3.4 IPFIX and IPPM............................................18 73 3.5 IPFIX and AAA.............................................18 74 3.5.1 Connecting via an AAA Client.............................20 75 3.5.2 Connecting via an Application Specific Module (ASM)......20 76 3.6 IPFIX and RTFM............................................21 77 3.6.1 Architecture.............................................21 78 3.6.2 Flow Definition..........................................22 79 3.6.3 Configuration and Management.............................22 80 3.6.4 Data Collection..........................................22 81 3.6.5 Data Model Details.......................................23 82 3.6.6 Transport Protocol.......................................23 83 3.6.7 Summary..................................................23 84 4. Limitations...............................................24 85 4.1 Using IPFIX for other Applications than Listed in RFC3917.24 86 4.2 Using IPFIX for Billing (Reliability Limitations).........24 87 4.3 Using a Different Transport Protocol than SCTP............25 88 4.4 Push vs. Pull Mode........................................25 89 4.5 Template ID number........................................26 90 4.6 Exporting Bidirectional Flow Information..................26 91 4.7 Remote Configuration......................................26 92 5. Security Considerations...................................27 93 6. IANA Considerations.......................................27 94 7. Acknowledgement...........................................27 95 8. Normative References......................................28 96 9. Informative References....................................28 97 Authors' Addresses.............................................30 98 Full Copyright Statement.......................................31 99 Disclaimer.....................................................31 100 Intellectual Property Statement................................31 102 1. Introduction 104 The IPFIX protocol defines how IP Flow information can be 105 exported from routers, measurement probes or other devices. IP 106 flow information provides important input data for a variety of 107 applications. The IPFIX protocol is a general data transport 108 protocol that is easily extensible to suit the needs of such 109 applications. In this document we describe how typical 110 applications can use the IPFIX protocol and show opportunities 111 and limitations of the protocol. Furthermore, we describe the 112 relationship of IPFIX to other frameworks and architectures. 113 Although examples in this document are shown for IPv4 only, the 114 applicability statements apply to IPv4 and IPv6. IPFIX provides 115 appropriate Information Elements for both IP versions. 117 2. Applications of IPFIX 119 IPFIX data enables several critical applications. The IPFIX 120 target applications and the requirements that originate from 121 those applications are described in [RFC3917]. Those 122 requirements were used as basis for the design of the IPFIX 123 protocol. This section describes how these target applications 124 can use the IPFIX protocol. Considerations for using IPFIX for 125 other applications than described in [RFC3917] can be found in 126 section 4.1. 128 2.1 Accounting 130 Usage-based accounting is one of the target applications for 131 IPFIX as defined in [RFC3917]. IPFIX records provide fine- 132 grained measurement results for highly flexible and detailed 133 usage reporting. Such data is used to realize usage-based 134 accounting. Nevertheless, IPFIX does not provide the reliability 135 required by usage-based billing-systems as defined in [RFC2975] 136 (see section 4.2). The accounting scenarios described in this 137 document only provide limited reliability as explained in 138 section 4.2 and should not be used in environments where 139 reliability as demanded by [RFC2975] is mandatory. 141 In order to realize usage-based accounting with IPFIX the flow 142 definition has to be chosen in accordance to the accounting 143 purpose. 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 Accounting can, for instance, be based on individual end-to-end 150 flows. In this case it can be realized with a flow definition 151 determined by the quintuple consisting of source address 152 (sourceIPv4Address), destination address 153 (destinationIPv4Address), protocol (protocolIdentifier) and port 154 numbers (e.g., udpSourcePort, udpDestinationPort). Another 155 example is class-dependent accounting (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 [RFC3246]. 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 provide useful 253 input for traffic profiling. IPFIX records captured over a long 254 period of time can be used to track and anticipate network 255 growth and usage. Such Information is valuable for trend 256 analysis and 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]. 273 Packet payload can be reported by using the IE 274 ipPayloadPacketSection in [PSAMP-INFO]. 276 The flow duration can be calculated from the flow time stamp IEs 277 defined in [IPFIX-INFO] (e.g., flowEndMicroseconds - 278 flowStartMicroseconds). The number of packets and number of 279 bytes of a flow are represented in the per-flow counter IEs 280 (e.g., packetTotalCount, octetTotalCount). The burstiness of a 281 flow can be calculated from the flow volume measured at 282 different time intervals. 284 2.3 Traffic Engineering 286 Traffic engineering aims at the optimization of network resource 287 utilization and traffic performance [RFC2702]. Typical 288 parameters are link utilization, load between specific network, 289 nodes, number, size and entry/exit points of active flows and 290 routing information [RFC3917]. 292 The size of flows in packets and bytes can be reported by the 293 IEs packetTotalCount, octetTotalCount. Utilization of a physical 294 link can be reported by using a coarse grained flow definition 295 (e.g. based on identifier IEs such as egressInterface or 296 ingressInterface) and per-flow counter IEs (e.g. 297 packetTotalCount, octetTotalCount) defined in [IPFIX-INFO]. 299 The load between specific network nodes can be reported in the 300 same way if one interface of a network node receives only 301 traffic from exactly one neighbor node (as is usually the case). 302 If the ingress interface is not sufficient for an unambiguous 303 identification of the neighbor node, sub-IP header fields IEs 304 (like sourceMacAddress) can be added as flow keys. 306 The IE observedFlowTotalCount provides the number of all flows 307 exported for the observation domain since the last 308 initialization of the metering process [IPFIX-INFO]. If this IE 309 is exported at subsequent points in time, one can derive the 310 number of active flows in a specific time interval from the 311 difference of the reported counters. The configured flow 312 termination criteria have to be taken into account to interpret 313 those numbers correctly. 315 Entry and exit points can be derived from flow records if 316 metering processes are installed at all edges of the network and 317 results are mapped in accordance to flow keys. For this and 318 other analysis methods that require the mapping of records from 319 different observation points, the same flow keys should be used 320 at all observation points. The path that packets take through a 321 network can be investigated by using hash-based sampling 322 techniques as described in [DuGr00] and [PSAMP-TECH]. For this 323 IEs from [PSAMP-INFO] are needed. 325 Neither [IPFIX-INFO] nor [PSAMP-INFO] defines IEs suitable for 326 exporting routing information. 328 2.4 Network Security 330 Attack and intrusion detection are among the IPFIX target 331 applications described in [RFC3917]. Due to the enormous amount 332 of different network attack types, only general requirements 333 could be addressed in [RFC3917]. 335 The number of metrics useful for attack detection is as diverse 336 as attack patterns themselves. Attackers adapt rapidly to 337 circumvent detection methods and try to hide attack patterns 338 using slow or stealth attacks. Furthermore, unusual traffic 339 patterns are not always caused by malicious activities. A sudden 340 traffic increase may be caused by legitimate users who seek 341 access to a recently published web content. Strange traffic 342 patterns may also be caused by mis-configuration. 344 IPFIX can export flow information for arbitrary flow definitions 345 as defined in [IPFIX-PROTO]. Packet information can be exported 346 with IPFIX by using the additional information elements 347 described in [PSAMP-INFO]. With this theoretically all 348 information about traffic in the network at IP layer and above 349 is accessible. This data can be used either directly to detect 350 anomalies or can provide the basis for further post processing 351 to generate more complex attack detection metrics. 353 Depending on the attack type different metrics are useful. A 354 sudden increase of traffic load can be a hint that an attack has 355 been launched. The overall traffic at an observation point can 356 be monitored using per-flow counter IEs like packetTotalCount, 357 octetTotalCount as described in 2.3. The number of active flows 358 can be monitored by regular reporting of the 359 observedFlowTotalCount defined in [IPFIX-INFO]. 361 A sudden increase of flows from different sources to one 362 destination may be caused by an attack on a specific host or 363 network node using spoofed addresses. The number of flows from 364 or to specific networks or hosts can be observed by using source 365 and destination addresses as flow keys and observing the number 366 of active flows as explained above. 367 Many flows to the same machine but on different ports or many 368 flows to the same port and different machines may be an 369 indicator for vertical or horizontal port scanning activities. 370 The number of flows to different ports can be reported by using 371 the portnumber information elements (udpSourcePort, 372 udpDestinationPort, tcpSourcePort, tcpDestinationPort) defined 373 in [IPFIX-INFO] as flow keys. 375 An unusual ratio of TCP-SYN to TCP-FIN packets can refer to SYN- 376 flooding. The number of SYN and FIN packets in a flow can be 377 reported with the IPFIX information elements tcpSynTotalCount 378 and tcpFinTotalCount defined in [IPFIX-INFO]. 380 Worms may leave signatures in traffic patterns. Detecting such 381 events requires more detailed measurements and post processing 382 than detecting simple changes in traffic volumes. 384 A difficult task is the separation of good from bad packets to 385 prepare and launch counteraction. This may require a deeper look 386 into packet content by using further header field IEs from 387 [IPFIX-INFO] and/or packet payload from IE 388 ipPayloadPacketSection in [PSAMP-INFO]. 390 Furthermore the amount of resources needed for measurement and 391 reporting increases with the level of granularity required to 392 detect an attack. Multi-step analysis techniques may be useful, 393 e.g., to launch an in-depth analysis (e.g. based on packet 394 information) in case the flow information shows suspicious 395 patterns. In order to supervise traffic to a specific host or 396 network node it is useful to apply filtering methods as those 397 described in [PSAMP-TECH]. 399 Mapping the two directions of a communication is often useful 400 for checking correct protocol behavior (see section 4.6). A 401 correlation of IPFIX data from multiple observation points (see 402 section 2.5.1) allows assessing the propagation of an attack and 403 can help to locate its source. 405 The integration of previous measurement results helps to review 406 traffic changes over time for detection of traffic anomalies and 407 provides the basis for forensic analysis. A standardized storage 408 format for IPFIX data would support the offline analysis of data 409 from different operators. 411 Nevertheless, capturing full packet traces at all observation 412 points in the network is not viable due to resource limitations 413 and privacy concerns. Therefore metrics should be chosen wisely 414 to allow a solid detection with minimal resource consumption. 415 Resources can be saved for instance by using coarser grained 416 flow definitions, reporting pre-processed metrics (e.g. with 417 additional information elements) or deployment of sampling 418 methods. 420 In many cases only derived metrics provide sufficient evidence 421 about security incidents. For example comparing the number of 422 SYN and FIN packets for a specific time interval can reveal an 423 ongoing SYN attack, which is not obvious from unprocessed packet 424 and flow data. Further metrics like the cumulated sum of various 425 counters, distributions of packet attributes or spectrum 426 coefficients have been used to identify a variety of attacks. 428 In order to detect attacks early it is useful to process the 429 data as soon as possible in order to generate significant 430 metrics for the detection. Pre-processing of raw packet and flow 431 data already at the measurement device can speed up the 432 detection process and reduces the amount of data that need to be 433 exported. Furthermore it is possible to directly report derived 434 metrics by defining appropriate Information Elements. Immediate 435 data export in case of a potential incident is desired. IPFIX 436 supports such source-triggered exporting of information due to 437 the push model approach. Nevertheless, further exporting 438 criteria have to be implemented to export IPFIX records upon 439 incident detection events and not only upon flow end or fixed 440 time intervals. 442 Intrusion detection would profit from the combination of IPFIX 443 functions with AAA functions (see section 3.5). Such an 444 interoperation enables further means for attacker detection, 445 advanced defense strategies and secure inter-domain cooperation. 447 2.5 QoS Monitoring 449 QoS monitoring is one target application of the IPFIX protocol 450 [RFC3917]. QoS monitoring is the passive observation of the 451 transmission quality for single flows or traffic aggregates in 452 the network. One example of its use is the validation of QoS 453 guarantees in service level agreements (SLAs). Typical QoS 454 parameters are loss [RFC2680], one-way [RFC2679] and round-trip 455 delay [RFC2681] and delay variation [RFC3393]. Whenever 456 applicable the IPPM metric definitions [RFC4148] should be used 457 when reporting QoS metrics. 458 The calculation of those QoS metrics requires per-packet 459 processing. Reporting packet information with IPFIX is possible 460 by simply considering a single packet as flow. [IPFIX-PROTO] 461 also allows the reporting of multiple identical information 462 elements in one flow record. Using this feature for reporting 463 information about multiple packets in one record would require 464 additional agreement on semantics regarding the order of 465 information elements (e.g. which timestamp belongs to which 466 packet payload in a sequence of information elements). [PSAMP- 467 INFO] defines useful additional information elements for 468 exporting per packet information with IPFIX. 470 2.5.1 Correlating Events from Multiple Observation Points 472 Some QoS metrics require the correlation of data from multiple 473 observation points. For this the clocks of the involved metering 474 processes must be synchronized. Furthermore, it is necessary to 475 recognize that the same packet was observed at different 476 observation points. 478 This can be done by capturing parts of the packet content 479 (packet header and/or parts of the payload) that do not change 480 on the way to the destination. Based on the packet content it 481 can be recognized when the same packet arrived at another 482 observation point. To reduce the amount of measurement data a 483 unique packet ID can be calculated from the packet content e.g. 484 by using a CRC or hash function instead of transferring and 485 comparing the unprocessed content. Considerations on collision 486 probability and efficiency of using such packet IDs are 487 described in [GrDM98, DuGr00, ZsZC01]. 489 IPFIX allows the reporting of several IP and transport header 490 fields (see section 5.3 and 5.4 in [IPFIX-INFO]). Using only 491 those fields for packet recognition or ID generation can be 492 sufficient in scenarios where those header fields vary a lot 493 among subsequent packets, where a certain amount of packet ID 494 collisions are tolerable or where packet IDs need to be unique 495 only for a small time interval. 497 For including packet payload information the information element 498 ipPayloadPacketSection defined in [PSAMP-INFO] can be used. The 499 information element ipHeaderPacketSection can also be used. But 500 header fields that can change on the way from source to 501 destination have to be excluded from the packet ID generation, 502 because they may differ at different observation points. 504 For reporting packet IDs generated by a CRC or hash function the 505 information element digestHashValue defined in [PSAMP-INFO] can 506 be used. 508 2.5.2 Examples 510 The following examples show which information elements need to 511 be reported by IPFIX to generate specific QoS metrics. As an 512 alternative the metrics can be generated directly at the 513 exporter and IPFIX can be used to export the metrics (see 514 section 2 515 ..7) 517 2.5.2.1 RTT measurements with packet pair matching (single-point) 519 The passive measurement of round-trip-times (RTT) can be 520 performed by using packet pair matching techniques as described 521 in [Brow00]. For the measurements, request/response packet pairs 522 from protocols such as DNS, ICMP, SNMP or TCP (SYN/SYN_ACK, 523 DATA/ACK) are utilized to passively observe the RTT [Brow00]. 524 This technique requires the correlation of data from both 525 directions. 527 Required information elements per packet (DNS example): 528 - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO] 529 - DNS header: ipPayloadPacketSection [PSAMP-INFO] 531 Required functions: 532 - Recognition of request/response packet pairs 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. 542 2.5.2.2 One-way Delay Measurements (multi-point) 544 Passive one-way-delay measurements require the collection of 545 data at two observation points. As mentioned above synchronized 546 clocks are needed to avoid time-differences at the involved 547 observation points. 549 The recognition of packets at the second observation point can 550 be based on parts of the packet content directly. A more 551 efficient way is to use a packet ID (generated from packet 552 content). 554 Required information elements per packet (with packet ID): 555 - Packet arrival time: observationTimeMicroseconds [PSAMP-INFO] 556 - Packet ID: digestHashValue [PSAMP-INFO] 558 Required functions: 559 - Packet ID generation 560 - Delay calculation (from arrival times at the two observation 561 points) 563 Remarks: 564 - Requires information elements from [PSAMP-INFO] 565 - observationTimeMicroseconds can be substituted by 566 flowStartMicroseconds [IPFIX-INFO], because a single packet 567 can be represented as a flow. 568 - If time values with a finer granularity are needed 569 observationTimeNanoseconds can be used. 570 - The amount of content used for ID generation influences the 571 number of collisions (different packets that map to the same 572 ID) that can occur. Investigations on this and other 573 considerations on packet ID generation can be found in 574 [GrDM98], [DuGr00], and [ZsZC01]. 576 2.6 Inter-Domain Exchange of IPFIX data 578 IPFIX data can be used to share information with neighbor 579 providers. A few recommendations should be considered if IPFIX 580 records travel over the public Internet compared to its usage 581 within a single domain. First of all, security threat levels are 582 higher if data travels over the public Internet. Protection 583 against disclosure or manipulation of data is even more 584 important than for intra-domain usage. Therefore IPsec or 585 Transport Layer Security (TLS) should be used as described in 586 [IPFIX-PROTO]. 588 Furthermore data transfer should be congestion-aware in order to 589 allow untroubled co-existence with other data flows in public or 590 foreign networks. That means transport over SCTP or TCP is 591 required. 593 Some ISPs are still reluctant to share information due to 594 concerns that competing ISPs might exploit network information 595 from neighbor providers to strengthen their own position in the 596 market. Nevertheless, technical needs have already triggered the 597 exchange of data in the past (e.g. exchange of routing 598 information by BGP). The need to provide inter-domain guarantees 599 is one big incentive to increase inter-domain cooperation. The 600 necessity to defend networks against current and future threats 601 (denial of service attacks, worm distributions, etc.) will 602 hopefully increase the willingness to exchange measurement data 603 between providers. 605 2.7 Export of Derived Metrics 607 The IPFIX protocol is used to transport flow and packet 608 information to provide the input for the calculation of a 609 variety of metrics (e.g. for QoS validation or attack 610 detection). 611 IPFIX can also be used to transfer these metrics directly, e.g. 612 if the metric calculation is co-located with measurement and 613 exporting process. 615 It doesn't matter which measurement and post-processing 616 functions are applied to generate a specific metric. IPFIX can 617 be used to transport the results from passive and active 618 measurements and from post-processing operations. For the 619 reporting of derived metrics additional information elements 620 need to be defined. 622 For most QoS metrics like loss, delay, delay variation etc. 623 standard IPPM definitions exist. In case such metrics are 624 reported with IPIFX, the IPPM standard definition should be 625 used. 627 2.8 Summary 629 The following table shows an overview of the information 630 elements required for the target applications described in 631 [RFC3917] (M-mandatory, R-recommended, O-optional). 633 | Application |[IPFIX-INFO]| [PSAMP-INFO] | additional IEs | 634 +-------------+------------+--------------+-----------------+ 635 | Accounting | M | - | - | 636 +-------------+------------+--------------+-----------------+ 637 | Traffic | M | O | - | 638 | Profiling | | | | 639 +-------------+------------+--------------+-----------------+ 640 | Traffic | M | - | O | 641 | Engineering | | | (routing info) | 642 +-------------+------------+--------------+-----------------+ 643 | Attack | M | R | R | 644 | Detection | | |(derived metrics)| 645 +-------------+------------+--------------+-----------------+ 646 | QoS | M | M | O | 647 | Monitoring | |(most metrics)|(derived metrics)| 648 +-------------+------------+--------------+-----------------+ 650 For accounting the IEs in [IPFIX-INFO] are sufficient. As 651 mentioned above, IPFIX does not conform to the reliability 652 requirements demanded by [RFC2975] for usage-based billing 653 systems (see section 4.2). For traffic profiling additionally 654 IEs from [PSAMP-INFO] can be useful to gain more insight into 655 the traffic. For traffic engineering flow information from 656 [IPFIX-INFO] is sufficient but it would profit from routing 657 information, which could be exported by IPFIX. Attack detection 658 usually profits from further insight into the traffic. This can 659 be achieved with IEs from [PSAMP-INFO]. Furthermore the 660 reporting of derived metrics in additional IEs would be useful. 661 Most QoS metrics require the use of IEs from [PSAMP-INFO]. IEs 662 from [PSAMP-INFO] are also useful for the mapping of results 663 from different observation points as described in section 2.5.1. 665 3. Relation of IPFIX to Other Frameworks and Protocols 667 3.1 IPFIX and IPv6 669 IPFIX has been designed from the beginning for IPv4 and IPv6. 670 Therefore IPFIX can be used in IPv4 and IPv6 networks without 671 limitations. The usage of IPFIX in IPv6 networks has two 672 aspects: 674 - Generation and reporting of IPFIX records about IPv6 traffic 675 - Exporting IPFIX records over IPv6 677 The generation and reporting of IPFIX records about IPv6 traffic 678 is possible. Appropriate information elements for the reporting 679 of IPv6 traffic are defined in [IPFIX-INFO]. 680 Exporting IPFIX records over IPv6 is not explicitly addressed in 681 [IPFIX-PROTO]. Since IPFIX runs over a transport protocol (SCTP, 682 SCTP-PR, UDP or TCP) and all potential IPFIX transport protocols 683 can run in IPv6 networks one just needs to provide the chosen 684 transport protocol in the IPv6 network to run IPFIX over IPv6. 686 3.2 IPFIX and PSAMP 688 PSAMP defines packet selection methods, their configuration at 689 routers and probes and the reporting of packet information. 691 PSAMP uses IPFIX as basis for exporting packet information 692 [PSAMP-PROTO]. [PSAMP-INFO] describes further information 693 elements for exporting packet information and reporting 694 configuration information. 696 The main difference between IPFIX and PSAMP is that IPFIX 697 addresses the export of flow records whereas PSAMP addresses the 698 export of packet records. Furthermore, PSAMP explicitly 699 addresses remote configuration. It defines a MIB for the 700 configuration of packet selection processes. Remote 701 configuration is not (yet) addressed in IPFIX, but one could 702 consider extending the PSAMP MIB to also allow configuration of 703 IPFIX processes. 705 3.3 IPFIX and RMON 707 RMON [RFC3577] is a widely used monitoring system that gathers 708 traffic data from RMON Agents in network devices. One major 709 difference between RMON and IPFIX is that RMON uses SNMP for 710 data export whereas IPFIX defines an own push-oriented protocol. 711 RMON defines MIBs that contain the information to be exported. 712 In IPFIX the data to be exported is defined as information 713 elements. 715 The most relevant MIBs for a comparison with IPFIX are the 716 Application Performance Measurement MIB (APM-MIB) [RFC3729] and 717 the Transport Performance Metrics MIB (TPM-MIB) [RFC4150]. 718 The APM-MIB has a complex system for tracking user application 719 performance, with reporting about transactions and SLA threshold 720 notification-trigger configuration, and persistence across DHCP 721 lease expirations. It requires a full RMON2-MIB protocolDirTable 722 implementation. 724 The APM-MIB reports the performance of transactions. A 725 transaction is a service oriented term and describes the data 726 exchange from the transaction start (when a user requests a 727 service) until its completion. The performance parameters 728 include response times, throughput, streaming responsiveness and 729 availability of services. 731 The RMON transaction concept differs from the IPFIX flow 732 concept. A flow is a very generic term that allows one to group 733 IP packets in accordance with common properties. In contrast to 734 this, the term transaction is service-oriented and contains all 735 data exchange required for service completion. 737 In order to report such data with IPFIX one would probably need 738 a specific combination of multiple flows and the ability to map 739 those to the transaction. Due to the service-orientated focus of 740 APM, also the required metrics differ. For instance, the RMON 741 APM requires a metric for the responsiveness of services. Such 742 metrics are not addressed in IPFIX. 744 Furthermore, the APM-MIB allows the configuration of the 745 transaction type to be monitored, i.e., it addresses the 746 configuration of the metering process, which is currently not 747 addressed in IPFIX. 749 The APM MIB could be considered as an extension of the IPFIX 750 metering process where the application performance of a 751 combination of multiple flows is measured. If appropriate IEs 752 would be defined in the IPFIX information model and the IPFIX 753 device would support the APM MIB data collection, the solutions 754 could be complementary. That means one could use IPFIX to export 755 APM MIB transaction information. 757 The TPM-MIB breaks out the APM-MIB transactions into sub- 758 application level transactions. For instance a web request is 759 broken down into DNS, TCP and HTTP sub-transactions. 760 Such sub-transactions can be considered as bi-directional flows. 761 With an appropriate flow definitions and the ability to map both 762 directions of a flow (see section 4.6), one could measure and 763 report flow characteristics of such sub-application level 764 transaction with IPFIX. 766 The TPM-MIB requires APM-MIB and RMON2-MIB. 768 3.4 IPFIX and IPPM 770 The IPFIX protocol can be used to carry IPPM network performance 771 metrics or information that can be used to calculate those 772 metrics (see sections 2.5 and 2.7 for details and references). 774 3.5 IPFIX and AAA 776 AAA defines a protocol and architecture for authentication, 777 authorization and accounting for service usage [RFC2903]. The 778 DIAMETER protocol [RFC3588] is used for AAA communication, which 779 is needed for network access services (Mobile IP, NASREQ, and 780 ROAMOPS). The AAA architecture [RFC2903] provides a framework 781 for extending AAA support to other services. DIAMETER defines 782 the exchange of messages between AAA entities, e.g. between AAA 783 clients at access devices and AAA servers, and among AAA 784 servers. DIAMETER is used for the transfer of accounting 785 records. In order to form accounting records for usage-based 786 accounting measurement data from the network is required. IPFIX 787 defines a protocol to export such data from routers, measurement 788 probes and other devices. Therefore it looks promising to 789 connect those two architectures. 791 For all scenarios described here one has to keep in mind that 792 IPFIX does not conform to the reliability requirements for 793 usage-based billing described in [RFC2975] (see section 4.2). 794 Using IPFIX without reliability extensions together with AAA 795 would result in accounting scenarios that do not conform to 796 usage-based billing requirements described in [RFC2975]. 798 As shown in section 2.1 accounting applications can directly 799 incorporate an IPFIX collecting process to receive IPFIX records 800 with information about the transmitted volume. Nevertheless, if 801 an AAA infrastructure is in place, the cooperation between IPFIX 802 and AAA provides many valuable synergistic benefits. IPFIX 803 records can provide the input for AAA accounting functions and 804 provide the basis for the generation of DIAMETER accounting 805 records. However, as stated in section 4.2 the use of IPFIX as 806 described in [IPFIX-PROTO] is currently limited to situations 807 where the purpose of the accounting does not require 808 reliability. 810 Further potential features include the mapping of a user ID to 811 flow information (by using authentication information) or using 812 the secure authorized exchange of DIAMETER accounting records 813 with neighbor domains. The last feature is especially useful in 814 roaming scenarios where the user connects to a foreign network 815 and the home provider generates the invoice. 817 Coupling an IPFIX collecting process with AAA functions has also 818 high potential for intrusion and attack detection. AAA controls 819 network access and maintains data about users and nodes. AAA 820 functions can help to identify the source of malicious traffic. 821 Authorization functions are able to deny access to suspicious 822 users or nodes. Therefore coupling those functions with an IPFIX 823 collecting process can provide an efficient defense against 824 network attacks. 825 Sharing IPFIX records (either directly or encapsulated in 826 DIAMETER) with neighbor providers allows an efficient inter- 827 domain attack detection. For this it would be useful to allow 828 remote configuration of measurement and record generation in 829 order to provide information in the required granularity and 830 accuracy. Since remote configuration is currently not addressed 831 in IPFIX, this would require additional work. The AAA 832 infrastructure itself may be used to configure measurement 833 functions in the network as proposed in [RFC3334]. 835 Furthermore the transport of IPFIX records with DIAMETER would 836 require the translation of IPFIX Information Elements into 837 DIAMETER attribute value pairs (AVPs) defined in [RFC3588]. 838 Since the DIAMETER AVPs do not comprise all IPFIX Information 839 Elements it is necessary to define new AVPs to transport them 840 over DIAMETER. 842 Two possibilities exist to connect IPFIX and AAA: 844 - Connecting via an AAA Client 845 - Connecting via an Application Specific Module (ASM) 846 Both are explained in the following sections. The approaches 847 only require few additional functions. They do not require any 848 changes to IPFIX or DIAMETER. 850 3.5.1 Connecting via an AAA Client 852 One possibility of connecting IPFIX and AAA is to run an AAA 853 client on the IPFIX collector. This client can generate DIAMETER 854 accounting messages and send them to an AAA server. The mapping 855 of the flow information to a user ID can be done in the AAA 856 server by using data from the authentication process. DIAMETER 857 accounting messages can be sent to the accounting application or 858 to other AAA servers (e.g. in roaming scenarios). 860 +---------+ DIAMETER +---------+ 861 | AAA-S |------------->| AAA-S | 862 +---------+ +---------+ 863 ^ 864 | DIAMETER 865 | 866 | 867 +--+--------+--+ 868 | | AAA-C | | 869 + +--------+ | 870 | | 871 | Collector | 872 +--------------+ 873 ^ 874 | IPFIX 875 | 876 +------------+ 877 | Exporter | 878 +------------+ 880 Figure 2: IPFIX collector connects to AAA server via AAA client 882 3.5.2 Connecting via an Application Specific Module (ASM) 884 Another possibility is to directly connect the IPFIX collector 885 with the AAA server via an application specific module (ASM). 886 Application specific modules have been proposed by the IRTF AAA 887 architecture research group (AAARCH) in [RFC2903]. They act as 888 an interface between AAA server and service equipment. In this 889 case the IPFIX collector is part of the ASM. The ASM acts as an 890 interface between the IPFIX protocol and the input interface of 891 the AAA server. The ASM translates the received IPFIX data into 892 an appropriate format for the AAA server. The AAA server then 893 can add information about the user ID and generate a DIAMETER 894 accounting record. This accounting record can be sent to an 895 accounting application or to other AAA servers. 897 +---------+ DIAMETER +---------+ 898 | AAA-S |------------->| AAA-S | 899 +---------+ +---------+ 900 ^ 901 | 902 +------------------+ 903 | ASM | 904 | +------------+ | 905 | | Collector | | 906 +------------------+ 907 ^ 908 | IPFIX 909 | 910 +------------+ 911 | Exporter | 912 +------------+ 914 Figure 3: IPFIX connects to AAA server via ASM 916 3.6 IPFIX and RTFM 918 The Real-time Traffic Flow Measurement (RTFM) working group 919 defined an architecture for flow measurement [RFC2722]. This 920 section compares the Real-time Traffic Flow Measurement (RTFM) 921 framework with the IPFIX framework. 923 3.6.1 Architecture 925 The RTFM architecture [RFC2722] is very similar to the IPFIX 926 architecture. It defines meter, meter reader and a manager as 927 building blocks of the measurement architecture. The manager 928 configures the meter and the meter reader collects data from the 929 meter. 930 In RTFM the building blocks communicate via SNMP. 931 The IPFIX architecture [IPFIX-ARCH] defines metering, exporting 932 and collecting processes. IPFIX speaks about processes instead 933 of devices to clarify that multiple of those processes may be 934 collocated on the same machine. 935 Both definitions do not contradict each other. One could see the 936 metering process as part of the meter and the collecting process 937 as part of the meter reader. 939 One difference is that IPFIX currently does not define a 940 managing process, because remote configuration was at least 941 initially out of scope for the working group. 943 3.6.2 Flow Definition 945 RTFM and IPFIX both consider flows as a group of packets which 946 share a common set of properties. A flow is completely specified 947 by that set of values, together with a termination criterion 948 (like inactivity timeout). 950 A difference is that RTFM defines flows as bidirectional. An 951 RTFM meter matches packets from B to A and A to B as separate 952 parts of a single flow, and maintains two sets of packet and 953 byte counters, one for each direction. 955 IPFIX does not explicitly state whether flows are uni- or 956 bidirectional. Nevertheless information elements for describing 957 flow properties were defined only for one direction in [IPFIX- 958 INFO]. Nevertheless, there are several solutions for reporting 959 bi-directional flow information (see section 4.6). 961 3.6.3 Configuration and Management 963 In RTFM, remote configuration is the only way to configure a 964 meter. This is done by using SNMP and a specific Meter MIB 965 [RFC2720]. The IPFIX group currently does not address IPFIX 966 remote configuration. 968 IPFIX metering processes export the layout of data within their 969 templates, from time to time. IPFIX collecting processes use 970 that template information to determine how they should interpret 971 the IPFIX flow data they receive. 973 3.6.4 Data Collection 975 One major difference between IPFIX and RTFM is the data 976 collection model. RTFM retrieves data in pull mode whereas IPFIX 977 uses a push mode model to send data to collecting processes. 979 An RTFM meter reader pulls data from a meter by using SNMP. SNMP 980 security on the meter determines whether a reader is allowed to 981 pull data from it. An IPFIX exporting process is configured to 982 export records to a specified list of IPFIX collecting 983 processes. The condition when to send IPFIX records (e.g. flow 984 termination) has to be configured in the exporting or metering 985 process. 987 3.6.5 Data Model Details 989 RTFM defines all its attributes in the RTFM Meter MIB [RFC2720]. 990 IPFIX information elements are defined in [IPFIX-INFO]. 992 RTFM uses continuously-incrementing 64-bit counters for the 993 storage of the number of packets of a flow. The counters are 994 never reset and just wrap back to zero if the maximum value is 995 exceeded. Flows can be read at any time. The difference between 996 counter readings gives the counts for activity in the interval 997 between readings. 999 IPFIX allows absolute (totalCounter) and relative counters 1000 (deltaCounter) [IPFIX-INFO]. The totalCounter is never reset and 1001 just wraps to zero if values are too large, exactly as the 1002 counters used in RTFM. The deltaCounter is reset to zero when 1003 the associated flow record is exported. 1005 3.6.6 Transport Protocol 1007 RTFM has a standards-track Meter MIB [RFC2720], which is used 1008 both to configure a meter and to store metering results. The 1009 MIB provides a way to read lists of attributes with a single 1010 Object Identifier (called a 'package'), which reduces the SNMP 1011 overhead for flow data collection. SNMP, of course, normally 1012 uses UDP as its transport protocol. Since RTFM requires a 1013 reliable flow data transport system, an RTFM meter reader must 1014 time out and resend unanswered SNMP requests. Apart from being 1015 clumsy, this can limit the maximum data transfer rate from meter 1016 to meter reader. 1018 IPFIX is designed to work over a variety of different transport 1019 protocols. SCTP [RFC2960] and SCTP-PR [RFC3758] are mandatory. 1020 UDP and TCP are optional. In addition, the IPFIX protocol 1021 encodes data much more efficiently than SNMP does, hence IPFIX 1022 has lower data transport overheads than RTFM. 1024 3.6.7 Summary 1026 IPFIX exports flow information in push model by using SCTP, TCP 1027 or UDP. It currently does not address remote configuration. RTFM 1028 data collection is using the pull model and runs over SNMP. RTFM 1029 addresses remote configuration which also runs over SNMP. Both 1030 frameworks allow a very flexible flow definition, although RTFM 1031 is based on a bi-directional flow definition. 1033 4. Limitations 1035 The goal of this section is to show the limitations of IPFIX and 1036 to give advice where not to use IPFIX or in which cases 1037 additional considerations are required. 1039 4.1 Using IPFIX for other Applications than Listed in RFC3917 1041 IPFIX provides a generic export mechanism. Due to its template 1042 based structure, it is a quite flexible protocol. Network 1043 operators and users may want to use it also for other 1044 applications than those described in [RFC3917]. 1046 Apart from sending raw flow information it can be used to send 1047 per-packet data, aggregated or post-processed data. For this new 1048 templates and information elements can be defined if needed. Due 1049 to its push mode operation IPFIX is also suited to send network 1050 initiated events like alarms and other notifications. It can be 1051 used for exchanging information among network nodes to 1052 autonomously improve network operation. 1054 Nevertheless, the IPFIX design is based on the requirements that 1055 originate only from the target applications stated in [RFC3917]. 1056 Using IPFIX for other purposes requires a careful checking of 1057 IPFIX capabilities against application requirements. Only with 1058 this one can decide whether IPFIX is a suitable protocol to meet 1059 the needs of a specific application. 1061 4.2 Using IPFIX for Billing (Reliability Limitations) 1063 The reliability requirements defined in [RFC3917] are not 1064 sufficient to guarantee the level of reliability that is needed 1065 for usage-based billing systems as described in [RFC2975]. In 1066 particular IPFIX does not support the following features 1067 required by [RFC2975]: 1069 - Record loss: IPFIX allows the usage of different transport 1070 protocols for the transfer of data records. Resilience against 1071 the loss of IPFIX data records can be only provided if TCP or 1072 SCTP is used for the transfer of data records. 1073 - Network or device failures: IPFIX does allow the usage of 1074 multiple collectors for one exporter, but it neither specifies 1075 nor demands the use of multiple collectors for the 1076 provisioning of fault tolerance. 1077 - Detection and elimination of duplicate records: This is 1078 currently not supported by IPFIX. 1079 - Application layer acknowledgements: IPFIX does not support the 1080 control of measurement and exporting processes by higher level 1081 applications. Application layer acknowledgements are necessary 1082 e.g. to inform the exporter in case the application is not 1083 able to process the data exported with IPFIX. Such 1084 acknowledgements are not supported in IPFIX. 1086 Further features like archival accounting and pre-authorization, 1087 are out of scope of the IPFIX specification but need to be 1088 realized in billing system architectures as described in 1089 [RFC2975]. 1091 4.3 Using a Different Transport Protocol than SCTP 1093 SCTP is the preferred protocol for IPFIX, i.e. a conforming 1094 implementation must work over SCTP. Although IPFIX can also work 1095 over TCP or UDP, both protocols have drawbacks [IPFIX-PROTO]. 1096 Users should make sure they have good reasons before using 1097 protocols other than SCTP in a specific environment. 1099 4.4 Push vs. Pull Mode 1101 IPFIX works in push mode. That means IPFIX records are 1102 automatically exported without the need to wait for a request. 1103 The responsibility for initiating a data export lies with the 1104 exporting process. 1106 Criteria for exporting data need to be configured at the 1107 exporting process. Therefore push mode has more benefits if the 1108 trigger for data export is related to events at the exporting 1109 process (e.g. flow termination, memory shortage due to large 1110 amount of flows, etc.). If the protocol used pull mode, the 1111 exporting process would need to wait for a request to send the 1112 data. With push mode it can send data immediately e.g. before 1113 memory shortage would require a discarding of data. 1115 With push mode one can prevent the overloading of resources at 1116 the exporting process by simply exporting the information as 1117 soon as certain thresholds are about to be exceeded. Therefore 1118 exporting criteria are often related to traffic characteristics 1119 (e.g. flow timeout) or resource limitations (e.g. size of flow 1120 cache). But traffic characteristics are usually quite dynamic 1121 and often impossible to predict. If those are used to trigger 1122 flow export, the exporting rate and the resource consumption for 1123 flow export becomes variable and unpredictable. 1125 Pull mode has advantages if the trigger for data export is 1126 related to events at the collecting process (e.g. a specific 1127 application requests immediate input). 1129 In a pull mode, a request could simply be forwarded to the 1130 exporting process. In a push mode, the exporting configuration 1131 must be changed to trigger the export of the requested data. 1132 Furthermore, with pull mode one can prevent the overloading of 1133 the collecting process by the arrival of more records than it 1134 can process. 1136 Whether this is a relevant drawback depends on the flexibility 1137 of the IPFIX configuration and how IPFIX configuration rules are 1138 implemented. 1140 4.5 Template ID number 1142 The IPFIX specification limits the different template ID numbers 1143 that can be assigned to the newly generated template records in 1144 an observation domain. In particular, template IDs up to 255 are 1145 reserved for Template or option sets (or other sets to be 1146 created) and template IDs from 256 to 65535 are assigned to data 1147 sets. In the case of many exports requiring many different 1148 templates, the set of Template IDs could be exhausted. 1150 4.6 Exporting Bidirectional Flow Information 1152 Although IPFIX does not explicitly state that flows are 1153 unidirectional, information elements that describe flow 1154 characteristics are defined only for one direction in [IPFIX- 1155 INFO]. [IPFIX-PROTO] allows the reporting of multiple identical 1156 information elements in one flow record. With this information 1157 elements for forward and reverse direction can be reported in 1158 one flow record. 1160 But this is not sufficient. Using this feature for reporting 1161 bidirectional flow information would require an agreement on the 1162 semantic of information elements (e.g. first counter is counter 1163 for the forward direction, second counter for reverse 1164 direction). 1166 Another option is to use two adjacent flow records to report 1167 both directions of a bidirectional flow separately. This 1168 approach requires additional means for mapping those records and 1169 is quite inefficient due to the redundant reporting of flow 1170 keys. 1172 4.7 Remote Configuration 1174 Remote configuration was initially out of scope of the IPFIX 1175 working group in order to concentrate on the protocol 1176 specification. Therefore there is currently no standardized way 1177 to configure IPFIX processes remotely. Nevertheless due to the 1178 broad need for this feature, it is quite likely that solutions 1179 for this will be standardized soon. 1181 5. Security Considerations 1183 This document describes the usage of IPFIX in various scenarios. 1184 Security requirements for IPFIX target applications and security 1185 considerations for IPFIX are addressed in [RFC3917] and [IPFIX- 1186 PROTO]. Those requirements have to be met for the usage of IPFIX 1187 for all scenarios described in this document. To our current 1188 knowledge, the usage scenarios proposed in section 2 do not 1189 induce further security hazards. 1191 The threat level to IPIFX itself may depend on the usage 1192 scenario of IPFIX. The usage of IPFIX for accounting or attack 1193 detection may increase the incentive to attack IPFIX itself. 1194 Nevertheless, security considerations have to be taken into 1195 account in all described scenarios. 1197 As described in the security considerations in [IPFIX-PROTO] 1198 security incidents can become a threat to IPFIX processes 1199 themselves, even if IPIFX is not the target of the attack. If an 1200 attack generates a large amount of flows (e.g. by sending 1201 packets with spoofed addresses or simulating flow termination) 1202 exporting and collecting process may get overloaded by the 1203 immense amount of records that are exported. A flexible 1204 deployment of packet or flow sampling methods can be useful to 1205 prevent the exhaustion of resources. 1207 Section 3 of this document describes how IPFIX can be used in 1208 combination with other technologies. New security hazards can 1209 arise when two individually secure technologies or architectures 1210 are combined. For the combination of AAA with IPFIX an 1211 application specific module (ASM) or an IPFIX collector can 1212 function as transit point for the messages. One has to ensure 1213 that at this point the applied security mechanisms (e.g. 1214 encryption of messages) are maintained. 1216 6. IANA Considerations 1218 This document has no actions for IANA. 1220 7. Acknowledgement 1221 We would like to thank the following persons for their 1222 contribution, discussion on the mailing list and valuable 1223 comments: 1225 Sebastian Zander 1226 Robert Loewe 1227 Reinaldo Penno 1228 Lutz Mark 1229 Andy Biermann 1231 Part of the work has been developed in the research project 6QM 1232 co-funded with support from the European Commission. 1234 8. Normative References 1236 [IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, "Information Model 1237 for IP Flow Information Export", Internet Draft 1238 , work in progress, 1239 October 2006 1241 [IPFIX-PROTO] B. Claise (Editor), "IPFIX Protocol Specification", 1242 Internet Draft , 1243 work in progress, November 2006 1245 [PSAMP-INFO] T. Dietz, F. Dressler, G. Carle, B. Claise, 1246 "Information Model for Packet Sampling Exports", 1247 Internet Draft , work 1248 in progress, October 2006 1250 [RFC4148] E. Stephan, IP Performance Metrics (IPPM) Metrics 1251 Registry, RFC 4148, August 2005 1253 9. Informative References 1255 [Brow00] Nevil Brownlee, "Packet Matching for NeTraMet 1256 Distributions", 1257 http://www.caida.org/tools/measurement/netramet/pac 1258 ketmatching/ 1260 [DuGr00] Nick Duffield, Matthias Grossglauser, "Trajectory 1261 Sampling for Direct Traffic Observation", 1262 Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 1263 August 28 - September 1, 2000 1265 [GrDM98] Ian D. Graham, Stephen F. Donnelly, Stele Martin, 1266 Jed Martens, John G. Cleary, "Nonintrusive and 1267 Accurate Measurement of Unidirectional Delay and 1268 Delay Variation on the Internet", INET'98, Geneva, 1269 Switzerland, 21-24 July, 1998 1271 [IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek, 1272 "Architecture for IP Flow Information Export", 1273 Internet Draft , work in progress, March 2005 1276 [PSAMP-PROTO] Benoit Claise (Ed.), Packet Sampling (PSAMP) 1277 Protocol Specifications, Internet Draft , work in progress, 1279 October 2006 1281 [PSAMP-TECH] T. Zseby, M. Molina, N. Duffield, S. Niccolini, F. 1282 Raspall, "Sampling and Filtering Techniques for IP 1283 Packet Selection" Internet Draft , work in progress, July 2005 1286 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way 1287 Delay Metric for IPPM", RFC 2679, September 1999 1289 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas, "A One-way 1290 Packet Loss Metric for IPPM",RFC 2680, September 1291 1999 1293 [RFC2681] G. Almes, S. Kalidindi, M. Zekauskas, "A Round-trip 1294 Delay Metric for IPPM", RFC 2681, September 1999 1296 [RFC2702] D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. 1297 McManus, "Requirements for Traffic Engineering Over 1298 MPLS", RFC 2702, September 1999 1300 [RFC2720] N. Brownlee, Traffic Flow Measurement: Meter MIB, 1301 RFC2720 October 1999 1303 [RFC2722] Brownlee, N., Mills, C., G. Ruth, "Traffic Flow 1304 Measurement: Architecture", RFC 2722, October 1999 1306 [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. 1307 Spence, "Generic AAA Architecture", RFC 2903, 1308 August 2000 1310 [RFC2960] R. Stewart (ed.) "Stream Control Transmission 1311 Protocol", RFC 2960, October 2000 1313 [RFC2975] B. Aboba, J. Arkko, D. Harrington, "Introduction to 1314 Accounting Management", RFC 2975, October 2000 1316 [RFC3246] B. Davie, et al., "An Expedited Forwarding PHB", 1317 RFC 3246, March 2002 1319 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330 1320 September 2002 1322 [RFC3334] T. Zseby, S. Zander, G. Carle, "Policy-Based 1323 Accounting", RFC 3334, October 2002 1325 [RFC3393] C. Demichelis, P. Cimento, "IP Packet Delay 1326 Variation Metric for IPPM", RFC 3393, November 2002 1328 [RFC3577] S. Waldbusser, R. Cole, C. Kalbfleisch, 1329 D.Romascanu, "Introduction to the Remote Monitoring 1330 (RMON) Family of MIB Module", RFC 3577, August 2003 1332 [RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, J. 1333 Arkko, "Diameter Base Protocol", RFC 3588, 1334 September 2003 1336 [RFC3729] S. Waldbusser, "Application Performance Measurement 1337 MIB", RFC 3729, March 2004 1339 [RFC3758] R. Stewart, M. Ramalho, Q. Xie, M. Tuexen, P. 1340 Conrad, "Stream Control Transmission Protocol 1341 (SCTP) Partial Reliability Extension", RFC 3758, 1342 May 2004 1344 [RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander, 1345 "Requirements for IP Flow Information Export", RFC 1346 3917, October 2004 1348 [RFC4150] R. Dietz, R. Cole, "Transport Performance Metrics 1349 MIB", RFC 4150, August 2005 1351 [ZsZC01] T. Zseby, S. Zander, G. Carle, "Evaluation of 1352 Building Blocks for Passive One-way-delay 1353 Measurements", Proceedings of Passive and Active 1354 Measurement Workshop (PAM 2001), Amsterdam, The 1355 Netherlands, April 23-24, 2001 1357 Authors' Addresses 1359 Tanja Zseby 1360 Fraunhofer Institute for Open Communication Systems (FOKUS) 1361 Kaiserin-Augusta-Allee 31 1362 10589 Berlin, Germany 1363 Phone: +49 30 3463 7153 1364 Email: tanja.zseby@fokus.fraunhofer.de 1366 Elisa Boschi 1367 Hitachi Europe SAS 1368 Immeuble Le Theleme 1369 1503 Route des Dolines 1370 06560 Valbonne, France 1371 Phone: +33 4 89874180 1372 Email: elisa.boschi@hitachi-eu.com 1374 Nevil Brownlee 1375 CAIDA (UCSD/SDSC) 1376 9500 Gilman Drive 1377 La Jolla, CA 92093-0505 1378 Phone : +1 858 534 8338 1379 Email : nevil@caida.org 1381 Benoit Claise 1382 Cisco Systems 1383 De Kleetlaan 6a b1 1384 1831 Diegem 1385 Belgium 1386 Phone: +32 2 704 5622 1387 Email: bclaise@cisco.com 1389 Full Copyright Statement 1391 Copyright (C) The IETF Trust (2007). 1393 This document is subject to the rights, licenses and 1394 restrictions contained in BCP 78, and except as set forth 1395 therein, the authors retain all their rights. 1397 Disclaimer 1399 This document and the information contained herein are provided 1400 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1401 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1402 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 1403 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1404 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1405 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1406 OR FITNESS FOR A PARTICULAR PURPOSE. 1408 Intellectual Property Statement 1410 The IETF has been notified by Cisco Systems of intellectual 1411 property rights claimed in regard to some or all of the 1412 specification contained in this document. The IPR disclosure was 1413 submitted to the IETF Secretariat on 2007-01-03. More 1414 information can be found on the "IETF Page of Intellectual 1415 Property Rights Disclosures" 1416 (https://datatracker.ietf.org/public/ipr_list.cgi). The title of 1417 the IPR disclosure is "Cisco's Statement about IPR claimed in 1418 draft-ietf-ipfix-as-10.txt." 1420 The IETF takes no position regarding the validity or scope of 1421 any Intellectual Property Rights or other rights that might be 1422 claimed to pertain to the implementation or use of the 1423 technology described in this document or the extent to which any 1424 license under such rights might or might not be available; nor 1425 does it represent that it has made any independent effort to 1426 identify any such rights. Information on the procedures with 1427 respect to rights in RFC documents can be found in BCP 78 and 1428 BCP 79. 1430 Copies of IPR disclosures made to the IETF Secretariat and any 1431 assurances of licenses to be made available, or the result of an 1432 attempt made to obtain a general license or permission for the 1433 use of such proprietary rights by implementers or users of this 1434 specification can be obtained from the IETF on-line IPR 1435 repository at http://www.ietf.org/ipr. 1437 The IETF invites any interested party to bring to its attention 1438 any copyrights, patents or patent applications, or other 1439 proprietary rights that may cover technology that may be 1440 required to implement this standard. Please address the 1441 information to the IETF at ietf-ipr@ietf.org.