idnits 2.17.1 draft-ietf-ipfix-architecture-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Bad filename characters: the document name given in the document, 'draft-ietf-ipfix-Architecture-00', contains other characters than digits, lowercase letters and dash. == Mismatching filename: the document gives the document name as 'draft-ietf-ipfix-Architecture-00', but the file name used is 'draft-ietf-ipfix-architecture-00' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 2002) is 8106 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IPFIX-DATA' is mentioned on line 372, but not defined == Missing Reference: 'RFC 1661' is mentioned on line 611, but not defined == Missing Reference: 'TBD' is mentioned on line 808, but not defined == Unused Reference: 'Brow00' is defined on line 970, but no explicit reference was found in the text == Unused Reference: 'DeCi01' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 977, but no explicit reference was found in the text == Unused Reference: 'ClPB93' is defined on line 980, but no explicit reference was found in the text == Unused Reference: 'GrDM98' is defined on line 986, but no explicit reference was found in the text == Unused Reference: 'DuGr00' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 997, but no explicit reference was found in the text == Unused Reference: 'ZsZC01' is defined on line 1001, but no explicit reference was found in the text == Unused Reference: 'MCFW' is defined on line 1008, but no explicit reference was found in the text == Unused Reference: 'NAT-TERM' is defined on line 1011, but no explicit reference was found in the text == Unused Reference: 'NAT-TRAD' is defined on line 1015, but no explicit reference was found in the text == Unused Reference: 'PPVPN-FR' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'VPN-L2' is defined on line 1022, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 1025, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1038, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Brow00' -- Possible downref: Non-RFC (?) normative reference: ref. 'DeCi01' ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) -- Possible downref: Non-RFC (?) normative reference: ref. 'ClPB93' -- Possible downref: Non-RFC (?) normative reference: ref. 'GrDM98' -- Possible downref: Non-RFC (?) normative reference: ref. 'DuGr00' ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) -- Possible downref: Non-RFC (?) normative reference: ref. 'ZsZC01' -- Possible downref: Non-RFC (?) normative reference: ref. 'MCFW' ** Downref: Normative reference to an Informational RFC: RFC 2663 (ref. 'NAT-TERM') ** Downref: Normative reference to an Informational RFC: RFC 3022 (ref. 'NAT-TRAD') -- Possible downref: Non-RFC (?) normative reference: ref. 'PPVPN-FR' -- Possible downref: Non-RFC (?) normative reference: ref. 'VPN-L2' ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 10 errors (**), 0 flaws (~~), 23 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPFIX working group EDITORS: K.C. Norseth 2 Internet Draft Enterasys Networks 3 draft-ietf-ipfix-Architecture-00.txt Ganesh Sadasivan 4 Expires: August 2002 Cisco Systems, Inc 5 February 2002 7 IPFIX Architecture 8 Architecture for IP Flow Information Export 9 draft-ietf-ipfix-architecture-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum 20 of six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as "work 23 in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document defines architecture for scalable monitoring, 33 measuring and exporting IP flow information to collectors. 35 Conventions used in this document 37 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 38 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 39 "OPTIONAL" in this document are to be interpreted as described in 40 RFC-2119 [ ]. 42 1. Introduction 2 43 2. Scope 3 44 3. Terminology 3 45 4. IPFIX reference Model 4 46 4.1. Exporter 6 47 4.2. IPFIX protocol 6 48 4.3. Observation Domain 7 49 4.4. Collector 8 50 4.5. Capabilities Management 8 51 4.6. Applications 9 52 5. IPFIX Protocol 9 53 5.1. Selection Criteria for IPFIX Protocol 9 54 5.1.1. Common for Exporting and Collecting Device 9 55 5.1.2. IPFIX Protocol on Exporting Device 9 56 5.1.3. IPFIX Protocol on Collecting Device 9 57 5.2. Export Models 9 58 5.2.1. A Simple Export Model 9 59 5.2.2. Export Model with Reliable Control Connection 9 60 5.3. Collector Crash Detection and Recovery 10 61 5.3.1. Simple Export Model 10 62 5.3.2. Export Model with Reliable Control Connection 10 63 5.4. Collector Crash Detection and Recovery 11 64 5.4.1. Simple Export Model 11 65 5.4.2. Export Model with Reliable Control Connection 11 66 5.5. Collector Redundancy 12 67 5.5.1. Simple Export Model 12 68 5.5.2. Export Model with Reliable Control Connection 12 69 5.6. Security 12 70 5.7. Capability Negotiation 12 71 5.7.1. Phase I - Capabilities and Capabilities Management 13 72 5.7.2. Phase II - Data Management and Data Transmission 14 73 5.7.3. Renegotiation of Capabilities 17 74 5.7.4. Caching of Negotiated Parameters 17 75 6. Security Consideration 17 76 6.1. Data security. 17 77 6.1.1. No security 18 78 6.1.2. Authentication only 18 79 6.1.3. Encryption 18 80 6.2. IPFIX end point authentication 18 81 6.3. Denial of service (DoS) attack prevention 19 82 6.3.1. Network under attack 19 83 6.3.2. Generic DoS attack on the IPFIX system 19 84 6.3.3. IPFIX Specific DoS attack 19 85 7. IANA Consideration 19 86 8. References 20 87 9. Acknowledgements 21 88 10. Author's Addresses 22 89 11. Full Copyright Statement 23 90 12. Issues 23 91 12.1. MIBS 24 92 12.2. Relationship to RTFM 24 94 1. Introduction 96 Many applications e.g., Intrusion detection, traffic engineering, 97 require the monitoring, measuring of IP traffic flows. It is hence 98 important to have a standard way of exporting information related 99 to IP flows. This document defines architecture for IP traffic 100 flow monitoring, measuring and exporting. It provides a high-level 101 description of the key components and their functions. 103 2. Scope 104 This document defines architecture for IPFIX[3]. The main objective 105 of this document is to: 107 * Describe the key architectural components of IPFIX. 108 * Define the architectural requirements, e.g., Recovery, 109 Security, etc for the IPFIX framework. 110 * Define the criteria to select the IPFIX Protocol. 111 * Specify the control/data message formats and handshaking 112 details to pass the IP flow information. 114 3. Terminology 115 Flow: 116 A flow is defined as a set of packets passing an observation point 117 in the network during a certain time interval. All packets belonging 118 to a particular flow have a set of common properties. Each property 119 is defined as the result of applying a function to the values of: 121 1 One or more of packet header fields (e.g. destination IP 122 address) 123 2 One or more properties of the packet itself (e.g. packet 124 length) 125 3 One or more of fields derived from packet treatment (e.g. AS 126 number) 128 Each of the fields from 1.,2. and 3. are referred to as keys. A 129 packet is defined to belong to a flow if it completely satisfies all 130 the defined properties of the flow. For a more detailed explanation 131 of flows, refer to [IPFIX-DATA]. 133 Flow Type: 134 A function F that would take input as a set of keys and the output 135 would be one or more flows depending on the combination of values 136 for the set of keys. 138 Observation Point: 139 The observation point may be one or a set of interfaces (physical or 140 logical) of the exporter. For a more detailed explanation of 141 Observation Point, refer to [IPFIX-DATA]. 143 Meter Process: 144 A set of actions like timestamping, sampling, filtering, performed 145 on packets received at an observation point to map them to flows. 146 For a more detailed explanation of Meter Process, refer to [IPFIX- 147 DATA]. 149 Observation Domain: 150 The set of observation points that is the largest aggregatable set 151 of flow information at the exporter is termed as an observation 152 domain. The observation domain presents itself a unique ID to the 153 collector for identifying the export packets generated by it. 155 Example: The observation domain could be a router line card, 156 composed of several interfaces with each interface being an 157 observation point. 159 Template: 160 Templates is a set of {type, length} ordered pairs, used to 161 completely identify the structure and semantics of a particular 162 information that needs to be communicated from the exporter to the 163 collector. Each template is uniquely identified by a Template ID. 165 4. IPFIX reference Model 167 The figure below shows the reference model for IPFIX. This figure 168 covers the various possible scenarios that can exist in an IPFIX 169 system. 171 +-------------------+ +----------------+ +----------------+ 172 |[Obsv Point(s)] | |[*Application 1]| ..|[*Application n]| 173 |[Meter Process(es)]| +--------+-------+ +-------+--------+ 174 +----------+--------+ ^ ^ 175 ^ ! ! 176 ! +~~~~~~~~~~+~~~~~~~~+ 177 ! ! 178 v v 179 +------------------+ +------------------+ 180 |IPFIX Device(1) | | Collector(1) | 181 |[Export Process] |<--------------->| | 182 | | | | 183 +------------------+ +------------------+ 184 .... .... 185 +-------------------+ +------------------+ 186 |IPFIX Device(i) | | Collector(j) | 187 |[Obsv Point(s)] |<-------------->| [*Application(s)]| 188 |[Meter Process(es)]| +---->| | 189 |[Export Process] | | +------------------+ 190 +-------------------+ . 191 .... . .... 192 +-------------------+ | +------------------+ 193 |IPFIX Device(m) | | | Collector(n) | 194 |[Obsv Point(s)] |<---------+---->| [*Application(s)]| 195 |[Meter Process(es)]| | | 196 |[Export Process] | +------------------+ 197 +-------------------+ 199 The various functional components are indicated within []. The 200 functional components within [*] are not part of the IPFIX 201 framework. The interfaces shown by "<-->" are defined by the IPFIX 202 framework and those shown by "<~~>" are not. 204 An IPFIX device is a unit that hosts at the minimum, flow 205 information export process but usually, the corresponding 206 Observation points, metering processes, and exporter processes are 207 co-located at this device. A group of Observation Points and their 208 corresponding meter processes form an Observation Domain. One or 209 more Observation Domains can interface with the same export process. 210 The figure below shows a typical IPFIX device. 212 +---------------------------------------------------+ 213 | IPFIX Device | 214 | +---------------------------------------+ +-----+ | 215 | | Capabilities Manager | |MGMT | | Import 216 | | | |Prcs |<------- 217 | |---------------------------------------+ +-----+ | the 218 | +---------------------------------------+ +-----+ | collector 219 | | Observation Domain 1 | | e | | 220 | | +--------------------------+ | | | | 221 | | | * Optional Meter Process +~~+---------> x | | 222 | | | Flow Level ({Fi}, {Si}) | | | | | | 223 | | +--------------------------+ | | | p | | 224 | | ^ ^ | | | | | 225 | | ! ! | | | o | | 226 | | +---......--+------------+ | | | | 227 | | | | | | r | | 228 | | +----+----+ Packet Level +----+----+ | | | | 229 | | |Meter | ({Fi}, {Si}) |Meter | | | | | 230 | | |Process 1| |Process N| | | t | | 231 | | +---------+ +---------+ | | | | 232 | | ^ ^ | | | | 233 | | | | | | | | 234 | | +-----+------+ +-----+------+| | | | 235 | | |Obsv Point 1| ... |Obsv Point M|| | | | 236 | | +------------+ +------------+| | | | 237 | +---------------------------------------+ | | |export 238 | .... | ------> 239 | +---------------------------------------+ | | |towards 240 | | Observation Domain K | | p | |the 241 | | | | | |collector 242 | | +--------------------------+ (*) | | r | | 243 | | | * Optional Meter Process +~~+---------> | | 244 | | | Flow Level ({Fi}, {Si}) | | | | o | | 245 | | +--------------------------+ | | | | | 246 | | ^ ^ | | | c | | 247 | | +---......--+------------+ | | | | 248 | | | | | | | | 249 | | +----+----+ Packet Level +----+----+ | | e | | 250 | | |Meter | ({Fi}, {Si}) |Meter | | | | | 251 | | |Process 1| |Process N| | | s | | 252 | | +---------+ +---------+ | | | | 253 | | ^ ^ | | s | | 254 | | | | | | | | 255 | | +-----+------+ +-----+------+| | | | 256 | | |Obsv Point 1| ... |Obsv Point M|| | | | 257 | | +------------+ +------------+| | | | 258 | +---------------------------------------+ +-----+ | 259 +---------------------------------------------------+ 260 In this figure, the functional blocks are shown in rectangular 261 boxes. The interface shown by "~~" is applicable only if the 262 optional Meter process at the flow level is present. Otherwise, the 263 meter process(es) at the packet level interfaces directly with the 264 exporting function. Note that in case of multiple observation 265 domains, a unique ID per observation domain must be transmitted as 266 parameters to the exporting function. For details on ({Fi}, {Si}) 267 which makeup a meter process, refer to [IPFIX-DATA]. 269 4.1.Exporter 271 The exporter is a subsystem that interacts with one or more 272 observation points. The functions of an exporter may include: 274 * Performing Flow ID management (capabilities negotiation) 275 that includes the creation of tags to refer a flow between 276 Exporter and the Collector for configuration and statistical 277 purpose. 278 * Assembling collected information into the right format to 279 be carried by the IPFIX protocol 280 * Configuring observation points with flow monitoring rules 281 * Measuring, aggregating and exporting IP Flow information 282 to the respective collectors. 283 * May perform appropriate middle-box functions to translate 284 the flow information. 286 The information collected can be either pushed periodically to the 287 collector or pulled by the collector on demand. 289 The Exporter Process is the functional block that interacts with 290 observation domain(s) on one side and collector(s) on the other 291 side. The typical functions of an exporter may include: 293 * Accept and separate flow records/control information from 294 different observation domains into separate export packet 295 streams. 296 * Run the part of the IPFIX protocol, which deals with 297 packetization, and transport of flow records/control 298 information with the collector. 300 4.2. IPFIX protocol 302 The information that needs to be exported from the exporting device 303 can be classified into the following categories: 305 1 Control Information - This includes the flow type definition, 306 selection criteria for packets within the flow etc. 307 2 Flow record - This includes data records corresponding to 308 the various observed flows at each of the observation point. 310 IPFIX protocol at the exporting device does the following: 312 1 Encode the control information into self-describing structures. 313 2 Encode the flows measured at the exporting device into flow 315 records. 316 3 Packetize the flow records and/or control information into 317 export packets. 318 4 Use the underlying transport layer to send the export packets 319 to the collector. 321 IPFIX protocol at the collecting device is responsible for 323 1 Receive and store the control information. 324 2 Decode and store the flow records using the control 325 information. 327 The information that needs to be exported from the IPFIX device can 328 be classified into the following categories: 330 * Control Information - This includes the flow type definition, 331 selection criteria for packets within the flow etc. 332 * Flow records. 334 At the IPFIX device, the protocol functionality may be split between 335 Observation domain and exporter process. IPFIX protocol at the IPFIX 336 device does the following: 338 1 Encode the control information into self-describing templates. 339 2 Encode the flows measured at the exporting device into flow 340 records. 341 3 Packetize the flow records and/or control information into 342 export packets. 343 4 Use the underlying transport layer to send the export packets 344 to the collector. 346 IPFIX protocol at the collector is responsible for 347 1 Receive and store the control information. 348 2 Decode and store the flow records using the control 349 information. 351 4.3. Observation Domain 353 The Observation Domain is the functional block which may be 354 capable of managing the flows generated from all the valid 355 {Observation Point, Meter Process} combination defined within 356 itself. The typical functions of an Observation Domain may 357 include: 359 * Run the part of the IPFIX protocol which deals with encoding 360 flow data and control information into flow records and 361 templates respectively. 362 * Decide which flow records/control information to export using 363 rules based on time, thresholds, configuration events etc. 364 * Aggregate flow records generated by one or more meter 365 processes. 366 * Add non-flow specific information (in some cases fields like 367 AS numbers) 368 * May perform appropriate middle-box functions to translate the 369 flow information. 371 The functionality of Meter Process is explained at length in 372 [IPFIX-DATA]. 374 4.4. Collector 376 Collector is a subsystem that interacts with one or more Exporters. 377 The functions of the collector may include: 379 * Performing Flow ID management (capabilities negotiation) that 380 includes the creation of tags to refer a flow between Exporter 381 and the Collector for configuration and statistical purpose. 382 * Requesting an exporter sub-system to collect IP flows. 383 * Communicating with different applications. 384 * Maintaining a repository of IP flow statistics 385 * Aggregating application level requests and form a template 386 that will suitable for exporter. 388 The application(s) and the collector may be tightly coupled in one 389 system. They may also be logically or physically a separate 390 subsystem from the application(s). In which case, the communication 391 between them is beyond the scope of IPFIX. 393 Collector is a subsystem that interacts with one or more IPFIX 394 devices. The functions of the collector MAY include: 396 * Identify and accept export packets from different {Export 397 Process, Observation Domain} pairs. 398 * Run IPFIX protocol. 399 * Store the control information and flow records received from 400 IPFIX device. 401 * Pass capabilities information to the IPFIX device. Notify the 402 IPFIX device of problems it is having 404 4.5. Capabilities Management 406 Basic capabilities contain information about the collector. It MAY 407 include: 409 * The collector availability - is it up? 410 * Maximum caching capability of the collector. 412 4.6.Applications 414 IPFIX applications may be things such as Billing and Intrusion 415 Detection sub-systems. etc.[3]. An application requests the 416 Collector to gather the relevant IP Flow information. 418 5. IPFIX Protocol 420 5.1. Selection Criteria for IPFIX Protocol 422 5.1.1. Common for Exporting and Collecting Device 424 1 Transparency over transport protocol. Ability to operate on top 425 of UDP or a reliable transport like TCP/SCTP. 426 2 Transparency over any underlying security protocols. 428 5.1.2. IPFIX Protocol on Exporting Device 430 1 Ability to detect loss of connectivity with the collector and 431 trigger a switch over to an alternate collector. 432 2 Optionally export flow records to multiple collecting devices. 433 3 Optionally perform load balancing of flow record export among 434 a set of collectors based on pre-defined set of rules. 435 4 Monitor control information/flow record export, detect overload 436 and switch to the overload behavior. 438 5.1.3.IPFIX Protocol on Collecting Device 440 Monitor the reception of export packets from IPFIX device. 442 5.2. Export Models 444 5.2.1. A Simple Export Model 446 If the network in which the exporter and collector are located 447 guarantees the security and reliability requirements, the transport 448 of the export flow packets MAY do over a lightweight transport like 449 UDP, for speed and simplicity. 451 5.2.2. Export Model with Reliable Control Connection 452 If the network in which the exporter and collector are located does 453 not guarantee reliability, at least the control information SHOULD 454 be exported over a reliable transport. There could be network 455 security concerns between exporter and collector. To avoid re- 456 inventing the wheel, and to reduce the complexity of flow export 457 protocol, one or a combination of the following methods MAY be 458 adopted as a solution to achieve security: 460 * IP Authentication Header MAY be used when the threat 461 environment requires stronger integrity protections, but does 462 not require confidentiality. 463 * IP Encapsulating Security Payload (ESP) MAY be used to provide 464 confidentiality and integrity. 465 * If the transport protocol used is TCP, optionally TCP MD5 466 signature option MAY be used to protect against spoofed TCP 467 segments. 469 The flow records MAY be exported over an unreliable or reliable 470 transport protocol. 472 As explained above the transport connection (in the case of a 473 connection oriented protocol) is pre-setup between the exporter and 474 the collector. Once connected, the collector side receives the 475 control information and uses this information to interpret the flow 476 records. The exporter SHOULD set the keepalive (in the case of TCP) 477 or the HEARTBEAT interval in the case of SCTP to a sufficiently low 478 value so that it can quickly detect a collector crash. 480 5.3. Collector Crash Detection and Recovery 482 The information that needs to be exported from the IPFIX device can 483 be classified into the following categories: 485 * Control Information - This includes the flow type definition, 486 selection criteria for packets within the flow. This is also 487 called as control stream. 489 * Flow record - This includes data records corresponding to the 490 various observed flows at each of the observation point. This 491 is also called as data stream. 493 5.3.1. Simple Export Model 495 If the network in which the exporter and collector are located 496 guarantees the security and reliability requirements, the transport 497 of the export flow packets MAY do over a lightweight transport like 498 UDP, for speed and simplicity. A single transport stream for control 499 and data would suffice here. 501 5.3.2. Export Model with Reliable Control Connection 502 If the network in which the exporter and collector are located does 503 not guarantee reliability, at least the control information SHOULD 504 be exported over a reliable transport. There could be network 505 security concerns between exporter and collector. To avoid re- 506 inventing the wheel, and to reduce the complexity of flow export 507 protocol, one or a combination of the following methods MAY be 508 adopted as a solution to achieve security: 510 * IP Authentication Header MAY be used when the threat 511 environment requires stronger integrity protections, but does 512 not require confidentiality. 514 * IP Encapsulating Security Payload (ESP) MAY be used to provide 515 confidentiality and integrity. 517 * If the transport protocol used is TCP, optionally TCP MD5 518 signature option MAY be used to protect against spoofed TCP 519 segments. 521 The data stream MAY be exported over a reliable or unreliable 522 transport protocol. 524 As explained above the transport connection (in the case of a 525 connection oriented protocol) is pre-setup between the exporter and 526 the collector. Once connected, the collector side receives the 527 control information and uses this information to interpret the flow 528 records. The exporter SHOULD set the keepalive (in the case of TCP) 529 or the HEARTBEAT interval in the case of SCTP to a sufficiently low 530 value so that it can quickly detect a collector crash. 532 5.4.Collector Crash Detection and Recovery 534 5.4.1. Simple Export Model 536 In this model, a collector crash can be detected if there is a 537 Keepalive mechanism available at the IPFIX protocol layer. On 538 detecting a Keepalive timeout, the exporter SHOULD stop sending the 539 flow export data to the collector but continue to send Keepalive 540 requests till a Keepalive response is received. 542 If there is an alternate collector which can has connectivity with 543 the exporter, the exporter SHOULD start exporting to this device. 545 5.4.2. Export Model with Reliable Control Connection 547 The collector crash is detected at the exporter by the break in 548 control connection (depending on the transport protocol the 550 connection timeout mechanisms differ). On detecting a Keepalive 551 timeout, the exporter SHOULD stop sending the flow export data to 552 the collector and try reconnecting the transport connection. This is 553 valid for a single collector scenario. 555 If there are multiple collectors for the same exporter, the exporter 556 opens control connections to each of the collectors. However, data 557 is sent only to one of the collectors, which is chosen as the 558 primary. There could be one or more collectors configured as 559 secondary and a priority assigned to them. The primary collector 560 crash is detected at the exporter by the break in control connection 561 (depending on the transport protocol the connection timeout 562 mechanisms differ). On detecting loss of connectivity, the exporter 563 opens data stream with the secondary collector of the next highest 564 priority. This collector now becomes the primary. The maximum export 565 data loss would be the amount of data exported in the time between 566 when the loss of connectivity to the collector happened, and the 567 time at which this was detected by the exporter. 569 5.5. Collector Redundancy 571 5.5.1. Simple Export Model 573 In case there are multiple collectors, the exporter MAY multicast 574 the flow records to the set of collectors that joined the export 575 multicast group, instead of sending several unicast streams towards 576 the different collectors. Multicast would lower the bandwidth 577 requirements on the export link in case that the collectors are on 578 the same media, and could lower the internal bus utilization on the 579 exporter. Using multicast session with more than one collector 580 joining the flow export multicast group, redundancy of collectors 581 can be easily achieved. 583 5.5.2. Export Model with Reliable Control Connection 585 The control information is exported through a reliable transport and 586 so cannot be multicast. The data stream MAY be multicast if it is 587 over an unreliable transport like UDP. However, the collector SHOULD 588 join the multicast group only after the control stream is 589 established and it has received the control information from the 590 exporter. Using multicast session with more than one collector 591 joining the flow export multicast group, redundancy of collectors 592 can be easily achieved. 594 5.6. Security 596 Refer Security Consideration section for details 598 5.7. Capability Negotiation 600 The capability negotiation is composed of two phases. In the first 601 Phase, basic capabilities regarding the exporting interface support 602 are negotiated between IPFIX end-points. If this phase fails, the 603 negotiation process will terminate and status information will be 604 provided to upper layers. 606 In the second phase, more capabilities that are specific are 607 negotiated, for instance, extended information model support, 608 redundancy support, templates, and supported messages. 610 One could use, for instance, a capability negotiation process 611 similar to LCP [RFC 1661]. For each capability proposed by one of 612 the peers in each of the phases, the answer can be a reject, ack or 613 nak. 615 More specifically, the system sending a Configure-Request is telling 616 the peer system that it is willing to receive data sent with the 617 enclosed options enabled. If the peer does not recognize (or 618 administratively prohibits) one or more options in the Configure- 619 Request message, it must return just these options in a Configure- 620 Reject message and the original sender must then remove the options 621 from a subsequent Configure-Request message. 623 If some of these options were recognized but unacceptable with the 624 supplied parameters, the peer would then respond with a Configure- 625 Nak containing only the offending options and a suggested modified 626 value for the parameters (called a hint). The receiver of the 627 Configure-Nak then should decide if the hinted value is acceptable 628 and, if so, send a new Configure-Request reflecting the requested 629 changes plus the original values for the unchanged options. The 630 sender of the Configure-Request may not send back any message other 631 than Configure-Request in response to Configure-Nak, so the only 632 recourses available if the hint is unreasonable are to drop the 633 option from subsequent Configure-Request messages, use Protocol- 634 Reject to disable the protocol, or disconnect the link entirely. 636 Finally, if all options are acceptable, the peer then responds with 638 Configure-Ack with the same options list as given in the Configure- 639 Request to indicate that all of the enclosed options were acceptable 640 and that are now enabled. 642 5.7.1. Phase I - Capabilities and Capabilities Management 644 In the first phase, basic capabilities regarding the exporting 645 interface support are negotiated between IPFIX end-points. If this 646 phase fails, the negotiation process will terminate and status 647 information will be provided to users. 649 The Phase I negotiation MAY be carried over UDP, as it is a widely 650 supported transport protocol. 652 5.7.1.1. Security support 653 The security support capability is used to negotiate which methods 654 (e.g. IPSec, TLS, MD5, etc) can be used to provide confidentiality, 655 integrity and protection against spoofed attacks. 657 5.7.1.2. IPFIX protocol 659 It is possible that several protocols (e.g. LFAP, CRANE, NetFlow, 660 and Diameter) meet the IPFIX requirements. In this case, this 661 capability is used to negotiate which protocol the end points will 662 use. 664 5.7.1.3. Version of Protocol 666 This capability is used to negotiate which version of the protocol 667 exporter and collector will use to communicate. Agreeing on a 668 specific version indicates that the end-points support all the 669 semantics and dynamic procedures specified by a version of the 670 protocol. 672 The protocol syntax (information model, data model, coding schemes, 673 etc) should be negotiated in Phase II. 675 5.7.1.4. Transport layer support 677 This capability is used to negotiate the transport layer protocol 678 used between the exporter and collector. 680 As the reliability is a key requirement of an IPFIX system, the 681 transport protocol should be connection oriented, congestion aware, 682 reliable, and providing in-sequence data delivery (e.g. TCP, SCTP). 684 Under some circumstances e.g., when the network path between 685 exporter and collectors ensures abundant bandwidth and 'no' packet 686 loss due to congestion, a lightweight transport protocol such as UDP 687 may be employed. In this case, the upper layer must provide 688 capabilities to ensure reliability, e.g. message integrity check, 689 loss detection, acknowledgment, etc. 691 5.7.2. Phase II - Data Management and Data Transmission 693 In this phase, the IPFIX protocol initiates its own connection setup 694 that involves further capability negotiation. 696 5.7.2.1. Data collection triggers and policies 698 *Update interval [TBD] 700 *Sampling [TBD] 701 *Aggregation rules[TBD] 703 * Caching 705 The exporter caches a certain amount of data before sending it to 706 the collector. If the collector fails, the exporter will need to 707 hold more data than normal while it waits for the collector to come 708 back or switch to different one. In order to provide for these two 709 modes of operation, the exporter could be configured with two levels 710 of caching. One level when the system is operating normally and a 711 second when a failure occurs. If the exporter detects that a server 712 is unavailable; it should use the higher cache level that allows it 713 to hold more data than it does in normal operation. 715 5.7.2.2. Reliability 717 This capability is used to negotiate parameters related to fail-over 718 support, load balancing, keepalives, etc. 720 For instance, exporter and collector SHOULD set the keepalive (in 721 the case of TCP) or the HEARTBEAT interval in the case of SCTP to a 722 sufficiently low value so that it can quickly detect a collector 723 crash. On detecting a Keepalive timeout, the exporter SHOULD stop 724 sending the flow export data to the collector and bring down the 725 transport connection. 727 If the exporter detects that a collector is unavailable and fail- 728 over was negotiated, it should try to switch to the stand-by 729 collector in order to resume service. If the exporter does not keep 730 a live connection to the stand-by collector, it MAY go through the 731 capabilities negotiation process described in this section before it 732 could export data. 734 IN the case of UDP, an exporter MAY send a Collector Health request 735 query. The collector MUST reply to this request. The exporter MUST 736 be able to accept a response from the collector. If the exporter 737 does not see the health query response from the collector, it 738 assumes the collector is unavailable and MAY switch to another 739 collector that is available. 741 In the case there are multiple collectors operating redundant mode, 742 the exporter MAY multicast the flow records to the set of collectors 743 that joined the export multicast group, instead of sending several 744 unicast streams towards the different collectors. Multicast would 745 lower the bandwidth requirements on the export link in case that the 746 collectors are on the same media, and could lower the internal bus 747 utilization on the exporter. 749 In the case there are multiple collectors operating in load- 750 balancing mode, a weight number associated with each server MAY be 751 used to infer the amount of exported flows each server should 752 receive. 754 It should be noted that servers operating in a redundant or load- 755 balancing mode could be running different version of the IPFIX 756 protocol and use different capabilities. 758 5.7.2.3. Templates 759 This capability is used to negotiate a common set of templates 760 corresponding to an IPFIX session between the exporter and 761 collector. A locally unique template identifier (template ID) MUST 762 be assigned to each template, and carried along with IPFIX user 763 messages to ensure correct decoding of IP flow information. Exporter 764 and collector MUST use the same set of templates during a session. 765 The templates can be renegotiated but MUST always be agreed on by 766 all IPFIX end-points participated in the IPFIX session before they 767 can be used. 769 The exporter and collector MUST agree on a common set of templates 770 before the collector can start sending data according to them. 772 The template negotiation follows the LCP method described earlier. 773 The collector may propose changes to the templates received from an 774 exporter (e.g. enabling some keys and disabling others), or it can 775 acknowledge the templates as is. In the case that a template or a 776 key is not recognized by the collector (e.g. they might be added to 777 the exporter after the collector configuration has completed), the 778 collector MAY choose to disable each unknown key or unknown 779 templates in order to avoid unnecessary traffic. A template is 780 disabled when all the keys are disabled. 782 5.7.2.4. Extended flow type support 783 Beside standardized minimum set of possible flow properties, the 784 exporter should be able to classify and export flows based on 785 extended information such as (but not limited to) URL, RTP Media 786 type and SIP Method. 788 This capability is used to negotiate what are those extended 789 properties. 791 5.7.2.5. Messages Supported 792 A particular protocol or version might have optional messages that 793 are not mandatory. This capability is used to negotiate what are 794 those optional messages types supported. 796 5.7.2.6. Overlapping flows 797 This capability is used to negotiate the support of overlapping flow 798 awareness, i.e., if exporter has the means of inferring if the same 799 will be exported more than once and letting the collector of this 800 fact. 802 In the absence of explicit negotiation of this capability, the 803 collector MUST consider that all flows reported can overlap. In the 804 case the device reports overlapping between certain flows, the 805 collector SHOULD take this into consideration, but MUST NOT assume 806 that other flows will not overlap 808 5.7.2.7. MIDCOM related Capabilities [TBD] 810 To Be Added 812 5.7.3. Renegotiation of Capabilities 814 Only renegotiation of capabilities agreed on phase II can be 815 performed without tearing down the connection. 817 The initial negotiation can deal with a wealth of settings and 818 assign ID's to various capability versions. The re-negotiation 819 needs only to refer these IDs and require simple acknowledgement. 821 5.7.4. Caching of Negotiated Parameters 823 Negotiation of parameters can be transmitted at any time by the 824 exporter. 826 It is also possible for the collector to request negotiation 827 parameters. The exporter MUST be able to receive a request from the 828 exporter. 830 6. Security Consideration 832 IP flow information can be used for various purposes, such as usage 833 accounting, traffic profiling, traffic engineering, and intrusion 834 detection. For each application, the security requirement may differ 835 significantly from one to another. To be able to satisfy the 836 security needs of various IPFIX users, the architecture of IPFIX 837 MUST provide different levels of security protection. 839 6.1. Data security. 841 IPFIX data consists the control stream and data stream generated by 842 the IPFIX device. 844 The IPFIX data may exist in both the IPFIX device and the collector. 845 In addition, the data is also transferred on the wire from the 846 exporter to the collector when it is reported. To provide security, 847 the data SHOULD be protected from adversary. 849 The protection of IPFIX data within the end system (IPFIX device and 850 collector) is out of the scope. It is assumed that the end system 851 operator will provide adequate security for the IPFIX data. 853 The IPFIX architecture MUST allow different levels of protection to 854 the IPFIX data on the wire. Whereever security functions are 855 required it is recommended to leverage to lower layers using either 856 IPsec or TLS, if they can successfully satisfy the security 857 requirement of IPFIX data protection. 859 To protect the data on the wire, three levels of granularity SHOULD 860 be supported: 862 6.1.1. No security 864 No security is required when the transport between the IPFIX device 865 and the collector is perceived as safe. This option allows the 866 protocol to run most efficiently without extra overhead and an IPFIX 867 solution MUST support it. 869 6.1.2. Authentication only 871 The authentication only protection provides the IPFIX users the 872 assurance of data integrity and authenticity. The data exchanged 873 between the IPFIX device and the collector is protected by 874 authentication signature. Any modification of the IPFIX data will be 875 detected by the recipient, resulting in discarding of the received 876 data. However, the authentication only option doesn't offer data 877 confidentiality. The IPFIX user SHOULD avoid use this option when 878 sensitive or confidential information is being exchanged. An IPFIX 879 solution SHOULD support this option. The authentication only option 880 SHOULD provide replay attack protection. Some means to achieve this 881 level of security are: 883 * TCP with MD5 options. 884 * IP Authentication Header 886 6.1.3. Encryption 888 Data encryption provides the best protection for IPFIX data. The 889 IPFIX data is encrypted at the sender and only the intended 890 recipient can decrypt and have access to the data. This option MUST 891 be used when the transport between the exporter and the collector 892 are unsafe and the IPFIX data needs to be protected. It is 893 recommended to use the underlying security layer functions for this 894 purpose. Some means to achieve this level of security are: 896 * Encapsulating Security Payload. 897 * Transport Layer Security Protocol 899 The data encryption option adds overhead to the IPFIX data transfer. 900 It may limit the rate that an export can report its flow to the 901 collector due to the heavy resource requirement of running 902 encryption. 904 6.2. IPFIX end point authentication 906 It is important to make sure that the IPFIX device is talking to the 907 "right" collector instead of a masqueraded collector. The same logic 908 also holds true from the collector point of view that it want to 909 make sure it is collecting the flow information from the "right" 910 IPFIX device. The IPFIX architecture SHOULD allow the authentication 911 capability so that either one-way or mutual authentication can be 912 performed between the IPFIX device and collector. 914 The IPFIX architecture SHOULD use the existing transport protection 915 protocols such as TLS to fulfill the authentication requirement. 917 6.3. Denial of service (DoS) attack prevention 919 Since one of the potential usages for IPFIX is for intrusion 920 detection, it is important for the IPFIX architecture to support 921 some kind of DoS resistance. 923 6.3.1. Network under attack 925 The Network itself may be under attack, resulting in an overwhelming 926 number of IPFIX messages. The IPFIX SHOULD try to capture as much 927 information as possible. However, when large amount IPFIX messages 928 are generated in a short period of time, the IPFIX may become 929 overloaded. The IPFIX system MUST provide enough performance 930 assurance so that the system can still function under heavy load. 931 Possible solutions include flow control and message threshold 932 information. 934 6.3.2. Generic DoS attack on the IPFIX system 936 The IPFIX system may subject to generic DoS attacks, just as any 937 system on any open networks. These types of attacks are not IPFIX 938 specific. Preventing and responding to such types of attacks are out 939 of the scope of IPFIX WG. 941 6.3.3. IPFIX Specific DoS attack 943 There is a specific attack on the IPFIX portion of the Exporter or 944 Collector. 946 (To be added and discussed on the general list). 948 7. IANA Consideration 950 Need Port number assigned from IANA 951 [more to be written] 953 8. References 955 3. J. Quittek ,et al.," Requirements for IP Flow Information 956 Export ", (work in progress) ,Internet Draft, Internet 957 Engineering Task Force, , November 958 2001 960 4. M. Wood ,et al.," Intrusion Detection Message Exchange 961 Requirements",(work in progress), Internet Draft, Internet 962 Engineering Task Force, draft-ietf-idwg-requirements-06,February 963 2002. 965 5. Daniel O. Awduche, et. al.," Overview and Principles of 966 Internet Traffic Engineering", (work in progress), Internet 967 Draft, Internet Engineering Task Force, draft-ietf-tewg- 968 principles-02.txt, May 2002 970 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions, 971 http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47- 972 adelaide/pp-dist/ 974 [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric 975 for IPPM, , November 2001 977 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet 978 Loss Metric for IPPM, September 1999 980 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: 981 Application of Sampling 982 Methodologies to Network Traffic Characterization, Proceedings of 983 ACM SIGCOMM'93, 984 San Francisco, CA, USA, September 13 - 17, 1993 986 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed 987 MARTENS, John G. CLEARY: 988 Nonintrusive and Accurate Measurement of Unidirectional Delay and 989 Delay Variation on 990 the Internet, INET'98, Geneva, Switzerland, 21-24 July, 1998 992 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling 993 for Direct Traffic Observation", 994 Proceedings of ACM SIGCOMM 2000, Stockholm, Sweden, 995 August 28 - September 1, 2000. 997 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay 998 Metric for IPPM, 999 Request for Comments: 2679, September 1999 1001 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation 1002 of Building Blocks 1003 for Passive One-way-delay Measurements, Proceedings of Passive and 1004 Active Measurement 1005 Workshop (PAM 2001), Amsterdam, The Netherlands, April 23-24, 2001 1006 (PAM 2001) 1008 [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture 1009 and framework," work in progress. October 2001. 1011 [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address 1012 Translator (NAT) Terminology and Considerations", RFC 2663, August 1013 1999. 1015 [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network 1016 address Translator (Traditional NAT)", RFC 3022, January 2001. 1018 [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider 1019 Provisioned Virtual Private Networks ", work in progress, , January 2002. 1022 [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft 1023 , July 2001. 1025 [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. 1026 and W. Weiss, "An Architecture for Differentiated Services", RFC 1027 2475, December 1998. 1029 [1] Requirements for IP Flow Export, 1030 1032 [2] K.Zhang, et al., "Common Reliable Accounting for Network Element 1033 (CRANE)", , February 2002 1035 [3] G. Sadasivan, et al., "Flow Export Architecture", , January 2002 1038 [4] Carlson, James, "PPP Design, Implementation and Debugging", 1039 Second Edition . 1041 9. Acknowledgements 1042 We like to thank all the people contributing to the requirements 1043 discussion on the mailing list, and the design teams for many 1044 valuable comments. 1046 George Carle 1047 Tanja Zseby 1048 Paul Calato 1049 Dave Plonka 1050 Kevin Zhang 1051 KC Norseth 1052 Benoit Claise 1053 Ganesh Sadasivan 1054 Vamsi Valluri 1055 Ram Gopal 1056 Jc Martin 1057 Carter Bullard 1058 Juergen Quittek 1059 Reinaldo Penno 1060 Nevil Brownlee 1061 Simon Leinen 1063 10. Author's Addresses 1065 Paul Calato 1066 Riverstone Networks, Inc. 1067 5200 Great America Parkway 1068 Santa Clara, CA 95054 USA 1069 Phone: +1 (603) 557-6913 1070 Email: calato@riverstonenet.com 1072 Benoit Claise 1073 Cisco Systems 1074 De Kleetlaan 6a b1 1075 1831 Diegem 1076 Belgium 1077 Phone: +32 2 704 5622 1078 Email: bclaise@cisco.com 1080 Ganesh Sadasivan 1081 Cisco Systems, Inc. 1082 170 W. Tasman Dr. 1083 San Jose, CA 95134 1084 USA 1085 Phone: +1 (408) 527-0251 1086 Email: gsadasiv@cisco.com 1088 Ram Gopal 1089 Nokia 1090 5 Wayside Road, 1091 Burlington, MA 01803 1092 Phone:+1 781 993 3685 1093 Email: ram.gopal@nokia.com 1095 Man Li 1096 Nokia 1097 5 Wayside Road, 1098 Burlington, MA 01803 1099 Phone: +1 781 993 3923 1100 Email: man.m.li@nokia.com 1102 K.C. Norseth 1103 Enterasys Networks 1104 2691 S. Decker Lake Lane 1105 Salt Lake City, Utah 84119 1106 Phone: +1 801 887 9823 1107 Email: knorseth@enterasys.com 1108 Reinaldo Penno 1109 Nortel Networks, Inc. 1110 2305 Mission College Boulevard 1111 Building SC9-B1240 1112 Santa Clara, CA 95134 1113 Email: rpenno@nortelnetworks.com 1115 Juergen Quittek 1116 NEC Europe Ltd. 1117 Adenauerplatz 6 1118 69115 Heidelberg 1119 Germany 1120 Phone: +49 6221 90511-15 1121 EMail: quittek@ccrle.nec.de 1123 Cliff Wang 1124 SmartPipes Inc. 1125 565 metro Place 1126 Dublin, OH 43017 1127 Phone: +1 614 923 6241 1128 Email: cwang@smartpipes.com 1130 Kevin Zhang 1131 XACCT Technologies, Inc. 1132 2900 Lakeside Drive 1133 Santa Clara, CA 95054 1134 Phone +1 301 992 4697 1135 Email: kevin.zhang@xacct.com 1137 Tanja Zseby 1138 GMD FOKUS 1139 Kaiserin-Augusta-Allee 31 1140 10589 Berlin, Germany 1141 Phone: +49 30 3463 7153 1142 Email: zseby@fokus.gmd.de 1144 11. Full Copyright Statement 1146 "Copyright (C) The Internet Society (date). All Rights Reserved. 1147 This document and translations of it may be copied and furnished 1148 to others, and derivative works that comment on or otherwise 1149 explain it or assist in its implementation may be prepared, 1150 copied, published and distributed, in whole or in part, without 1151 restriction of any kind, provided that the above copyright notice 1152 and this paragraph are included on all such copies and derivative 1153 works. However, this document itself may not be modified in any 1154 way, such as by removing the copyright notice or references to the 1155 Internet Society or other Internet organizations, except as needed 1156 for the purpose of developing Internet standards in which case the 1157 procedures for copyrights defined in the Internet Standards 1158 process must be followed, or as required to translate it into. 1160 12. Issues 1162 12.1. MIBS 1164 An SNMP MIB module should be made available to monitor 1165 the various components and to define, if any, standard 1166 configuration objects (Mike Mcfadden, Dave Harrington) 1168 12.2.Relationship to RTFM 1170 To be filled ouT