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