idnits 2.17.1 draft-zseby-ipfix-applicability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 1 longer page, the longest (page 1) being 907 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 34 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 554: '...rio the exporter SHOULD export private...' RFC 2119 keyword, line 578: '...NAT the exporter MUST export private a...' RFC 2119 keyword, line 731: '...address realms, it MUST include the VPN-ID [VPN-ID] in the exported...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2002) is 7980 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2722' is mentioned on line 416, but not defined == Missing Reference: 'RFC 2724' is mentioned on line 335, but not defined == Missing Reference: 'RFC 2723' is mentioned on line 363, but not defined == Missing Reference: 'RFC 2720' is mentioned on line 426, but not defined == Missing Reference: 'DIFF-ARCH' is mentioned on line 602, but not defined == Missing Reference: 'RFC2764' is mentioned on line 675, but not defined == Missing Reference: 'VPN-2547BIS' is mentioned on line 719, but not defined == Missing Reference: 'VPN-ID' is mentioned on line 731, but not defined == Missing Reference: 'TBD' is mentioned on line 734, but not defined == Unused Reference: 'QuZC02' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'Awdu02' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'NAT-TRAD' is defined on line 826, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 836, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'QuZC02' ** Downref: Normative reference to an Informational draft: draft-ietf-tewg-principles (ref. 'Awdu02') -- 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 ** Downref: Normative reference to an Experimental RFC: RFC 2903 Summary: 15 errors (**), 0 flaws (~~), 17 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Tanja Zseby 2 draft-zseby-ipfix-applicability-00.txt FhI FOKUS 3 Expires: November 2002 Reinaldo Penno 4 Nortel Networks 5 Nevil Brownlee 6 CAIDA 8 June 2002 10 IPFIX Applicability 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes how various applications can use the IP 34 Flow Information Export (IPFIX) protocol. It furthermore shows how 35 the IPFIX framework relates to other architectures and frameworks. 37 1. INTRODUCTION 2 38 2. APPLICATIONS OF IPFIX 2 39 2.1. ACCOUNTING WITH IPFIX 2 40 2.2. INTRUSION DETECTION WITH IPFIX 2 41 2.3. QOS MONITORING WITH IPFIX 3 42 2.3.1. Measurement of Round-trip-time (RTT) with IPFIX 3 43 2.3.2. Measurement of One-way-delay (OWD) with IPFIX 4 44 2.3.3. Measurement of Loss with IPFIX 4 45 2.3.4. Measurement of delay variation with IPFIX 4 46 2.3.5. Sampling for QoS Monitoring 5 47 3. RELATION OF IPFIX TO OTHER FRAMEWORKS AND PROTOCOLS 5 48 3.1. IPFIX AND AAA 5 49 3.1.1. Connecting via an AAA Client 6 50 3.1.2. Connecting via an Application Specific Module (ASM) 6 51 3.2. IPFIX AND RTFM 7 52 3.2.1. Definition of 'flow' 7 53 3.2.2. Configuration and Management 8 54 3.2.3. Data Model details 9 55 3.2.4. Application/transport protocol 9 56 3.3. IPFIX CONSIDERATIONS FOR MIDDLEBOXES 10 57 3.3.1. Firewall 11 58 3.3.2. Network Address Translation 11 59 3.3.3. Traffic Conditioners 13 60 3.3.4. Tunneling 14 61 3.3.5. VPNs 14 62 4. SECURITY CONSIDERATION 16 64 1. Introduction 66 The IPFIX protocol defines how IP Flow information can be exported 67 from routers, measurement probes or other devices. It is intended to 68 provide input for various applications. This document describes how 69 applications can use the IPFIX protocol. Furthermore the relationship 70 of IPFIX to other frameworks and architectures are described. 72 2. Applications of IPFIX 74 2.1.Accounting with IPFIX 76 Usage based accounting is one of the major application for which the 77 IPFIX protocol has been developed. IPFIX flow records contain the 78 number of transferred bytes per flow. This information is an 79 essential input for usage-based accounting. 81 In order to realize usage-based accounting with IPFIX the flow 82 definition has to be chosen in accordance to the tariff model. A 83 tariff can for instance be based on individual end-to-end stream. 84 Accounting in such a scenario can be realized for instance with a 85 flow definition determined by the quintuple that consists of source 86 address, destination address, protocol and portnumbers. Another 87 example is a class-dependent tariff (e.g. in a DiffServ networks). 88 For this flows could be distinguished just by DiffServ codepoint 89 (DSCP) and source address. 91 2.2.Intrusion detection with IPFIX 93 Intrusion detection systems (IDS) monitor and control security 94 incidents. A typical IDS system includes components like sensor, 95 event collector, and management stations. Sensors monitor network and 96 system traffic for attacks and other security-related events. Sensors 97 respond to and notify the administrator about these events as they 98 occur. Event collectors are a middle-tier component responsible for 99 transmitting events from sensors to the console and database. The 100 management component serves the following purposes: 102 - visually monitors events (with a console) 103 - collects data from sensors (with one or more event collectors) 104 - stores data from sensors (in a database) 106 With IPFIX, events of interest can be reported to the sensor either 107 by the collecting process or directly by the exporting process. It 108 depends on the scenario and the events of interest which solution is 109 better. Getting information directly from the exporting process has 110 the advantage that the sensor gets the information faster. It does 111 not need to wait for collector processing time or until the collector 112 has all relevant data. 113 Getting the information from a collector allows to correlate data 114 from different exporting processes (e.g. from different routers) to 115 get a better picture about what is going on in the network. 117 2.3.QoS Monitoring with IPFIX. 119 The performance of QoS monitoring is one target application for using 120 the IPFIX protocol. QoS monitoring is the passive observation of 121 transmission quality for single flows or traffic aggregates in the 122 network. One example of its usefulness is the validation of QoS 123 guarantees in service level agreements. Some QoS metrics require the 124 correlation of data from multiple measurement points. For this the 125 clock of the involved exporting devices need to be synchronized. 126 Furthermore such measurements would benefit from post-processing 127 functions (e.g. packet ID generation) at the exporter and/or 128 collector. This section describes how the monitoring of different 129 metrics can be performed with IPFIX. The following metrics are 130 considered: round trip time, one-way-delay, loss and delay variation. 132 2.3.1.Measurement of Round-trip-time (RTT) with IPFIX 134 The passive measurement of round-trip-times (RTT) can be performed by 135 using packet pair matching techniques as described in [Brow00]. For 136 the measurements, request/response packet pairs from protocols like 137 DNS, ICMP, SNMP or TCP (syn/syn-ack, data/ack) are utilized to 138 passively observe the RTT [Brow00]. As always for passive 139 measurements this only works if the required traffic of interest is 140 actually present in the network. In order to use this measurement 141 technique, the IPFIX metering process needs to measure both 142 directions. A classification of the protocols mentioned above has to 143 be done. That means parts of the transport header are used for the 144 classification. Since a differentiation of flows in accordance to the 145 transport header is one of the requirements for IPFIX, such 146 classification can be performed without extensions. Nevertheless, the 147 meter needs to recognize request and response packets for the given 148 protocols and therefore needs to look further into the packets. The 149 capability to do this analysis is not part of the IPFIX requirements 150 but can be achieved by optional extensions to the classification 151 process. The exporting device needs to assign a timestamp for the 152 arrival of the packets. The calculation of the RTT can be done 153 directly at the exporter or at the collector. In the first case IPFIX 154 would transfer the calculated RTT to the collector. In the second 155 case IPFIX needs to send the observed packet types and the timestamps 156 to the collector. 158 2.3.2.Measurement of One-way-delay (OWD) with IPFIX 160 Passive one-way-delay measurements require the collection of data at 161 two measurement points. It is necessary to recognize packets at the 162 second measurement point to correlate packet arrival events from both 163 points. This can be done by capturing packet header and parts of the 164 packet that can be used to recognize the same packet at the 165 subsequent measurement point. 166 To reduce the amount of measurement data a unique packet ID 167 can be calculated from the header and part of the content e.g. by 168 using a CRC or hash function [GrDM98, DuGr00, ZsZC01].Since IPFIX is 169 not targeted at packet capturing these functionalities do not need to 170 be supported by a standard IPFIX meter. Nevertheless, in some 171 scenarios it might be sufficient to calculate a packet ID under 172 consideration of header fields including datagram ID and maybe 173 sequence numbers (from transport protocols) without looking at parts 174 of the packet content. If packet IDs need to be unique 175 only for a certain time interval or a certain amount of packet ID 176 collisions is tolerable this can be a sufficient solution. 178 2.3.3.Measurement of Loss with IPFIX 180 Passive loss measurements for single flows can be performed at one 181 measurement point by using sequence numbers that are present in 182 higher layer protocols. This requires the capturing of the sequence 183 numbers of subsequent packets of the observed flow by the IPFIX 184 metering process. An alternative to this is to perform a two-point 185 measurement as described above and just consider packets as lost that 186 do not arrive at the second measurement point in a given maximum time 187 frame. 189 2.3.4.Measurement of delay variation with IPFIX 191 Delay variation is defined as the difference of one-way-delay values 192 for selected packets [DeCi01]. Therefore this metric can be 193 calculated by performing passive measurement of one-way-delay for 194 subsequent packets (e.g. of a flow) and then calculating the 195 differences. 197 2.3.5.Sampling for QoS Monitoring 199 Since QoS monitoring can produce an overwhelming amount of 200 measurement data, methods such as aggregation of results, and 201 sampling would greatly increase the efficiency of the collection and 202 analysis process. Sampling methods can be grouped according to the 203 sampling strategy (systematic, random or stratified) and the trigger 204 that starts a sampling interval (count-based, time-based or packet- 205 content-based) [ClPB93]. Sampling can also be used as a method to 206 dynamically reduce resource consumption if the meter is overloaded. 207 Then the IPFIX meter can switch to a sampling method if too many 208 packets have to be observed. Since the expected estimation error 209 heavily depends on the deployed sampling strategy, the application 210 that receives the data needs to be aware of the sampling scheme and 211 the parameters in use. Therefore it is important that the IPFIX 212 exporter informs the collector precisely about the used sampling 213 strategy. This is especially important if the metering process 214 dynamically invokes sampling. 216 3. Relation of IPFIX to other frameworks and protocols 218 3.1.IPFIX and AAA 220 AAA defines a protocol and architecture for authentication, 221 authorization and accounting for service usage. The DIAMETER protocol 222 is used for AAA communication for network access services (Mobile IP, 223 NASREQ, and ROAMOPS). The AAA architecture [RFC2903] provides a 224 framework for extending the AAA support also for other services. 225 DIAMETER defines the exchange of messages between AAA entities, e.g. 226 between AAA clients at access devices and AAA servers and among AAA 227 servers. It is used also for the transfer of accounting records. 228 Usage-based accounting requires measurement data from the network. 229 IPFIX defines a protocol to export such data from routers, 230 measurement probes and other devices. 232 The provisioning of accounting with IPFIX can be realized without an 233 AAA infrastructure. The collector can directly forward the 234 measurement information to an accounting application Nevertheless, if 235 an AAA infrastructure is in place, IPFIX can provide the input for 236 the generation of accounting records and several features of the AAA 237 architecture can be used. Features include the mapping of a user ID 238 to the flow information (by using authentication information), the 239 generation of DIAMETER accounting records and the secure exchange of 240 accounting records between domains with DIAMETER. Three possibilities 241 to connect IPFIX and AAA can be distinguished: 243 3.1.1.Connecting via an AAA Client 245 One possibility to connect IPFIX and AAA is to run an AAA client on 246 the IPFIX collector. This client can generate DIAMETER accounting 247 messages and send them to an AAA server. The mapping of the flow 248 information to a user ID can be done in the AAA server by using 249 data from the authentication process. DIAMETER accounting messages 250 can be sent to the accounting application or to other AAA servers 251 (e.g. in roaming scenarios). 253 +---------+ DIAMETER +---------+ 254 | AAA-S |------------->| AAA-S | 255 +---------+ +---------+ 256 ^ 257 | DIAMETER 258 | 259 | 260 +--+--------+--+ 261 | | AAA-C | | 262 + +--------+ | 263 | | 264 | Collector | 265 +--------------+ 266 ^ 267 | IPFIX 268 | 269 +------------+ 270 | Exporter | 271 +------------+ 273 Figure 2: IPFIX collector connects to AAA server via AAA client 275 3.1.2.Connecting via an Application Specific Module (ASM) 277 Another possibility is to directly connect the IPFIX collector with 278 the AAA server via an application specific module (ASM). 279 Application specific modules have been proposed by the IRTF AAA 280 architecture research group (AAARCH) in [RFC2903]. They act as an 281 interface between AAA server and service equipment. In this case 282 the IPFIX collector is part of the ASM. The ASM acts as an interface 283 between the IPFIX protocol and the input interface of the AAA server. 284 The ASM translates the received IPFIX data into an appropriate format 285 for the AAA server. The AAA server then can add information about the 286 user ID and generate a DIAMETER accounting record. This accounting 287 record can be sent to an accounting application or to other AAA 288 servers. 290 +---------+ DIAMETER +---------+ 291 | AAA-S |------------->| AAA-S | 292 +---------+ +---------+ 293 ^ 294 | 295 +------------------+ 296 | ASM | 297 | +------------+ | 298 | | Collector | | 299 +------------------+ 300 ^ 301 | IPFIX 302 | 303 +------------+ 304 | Exporter | 305 +------------+ 307 Figure 3: IPFIX connects to AAA server via ASM 309 3.2.IPFIX and RTFM 311 This section compares the Real-time Traffic Flow Measurement (RTFM) 312 framework with the IPFIX framework. 314 3.2.1.Definition of 'flow' 316 RTFM and IPFIX both use the same definition of flow; a flow is a set 317 of packets which share a common set of end-point address attribute 318 values.A flow is therefore completely specified by that set of 319 values, together with an inactivity timeout. A flow is considered to 320 have ended when no packets are seen for at least the inactivity time. 322 RTFM flows are bidirectional, which has given rise to some confusion. 323 At the simplest level, a flow information exporter may achieve this 324 by maintaining two unidirectional flows, one for each direcion. To 325 export bidirectional flow information, e.g. to- and from- packet 326 counts, for a flow from A to B, the exporter has only to search its 327 flow table to find the matching flow from B to A. 329 RTFM, however, takes bi-directionality a stage further, by including 330 in the RTFM architecture [RFC 2722] a fully-detailed algorithm for 331 realtime matching of the two directions of a flow. This was done 332 for two reasons, to reduce the memory required to store each 333 flow (common address attributes for each direction), and to allow 334 for attributes which required fine detail for the two directions, 335 e.g. short-term bit rate distributions [RFC 2724]. 336 ** So far there has been no suggestion that IPFIX should do this. 338 3.2.2.Configuration and Management 340 The RTFM architecture specifies a complete system for gathering 341 flow information. It defines three entities, 342 - Meters are very similar to IPFIX exporters. 343 - Meter Readers are very similar to IPFIX collectors. 344 - Managers co-ordinate the activities of meters and meter readers, 345 and download configuration to them. 347 Note that the whole RTFM system is asynchronous, many readers may 348 collector flow data from a meter, and any reader may collect flow 349 data from many meters. 351 Rulesets allow the user to specify which flows are of interest, 352 which are the source and destination ends of each flow, and 353 what level of address granularity is required in the metered flows. 354 For example, one may select all packets from 192.168/16, but 355 build flow information for 192.168/24. RTFM selection is done by 356 testing under masks, and the masks do not have to use consective ones 357 from the left. Non-contiguous masks were considered important for 358 handling some OSI protocols, but the need for that has diminished 359 considerably. 361 The RTFM approach is based on RMON, in that if a user wants to 362 collect flow data for some particular set of flows, this can be 363 achieved by writing a ruleset, i.e. an SRL program [RFC 2723], to 364 specify what flows are of interest, requesting a manager to download 365 that ruleset to a meter, and requesting the manager to have a meter 366 reader collect the flow data at specified intervals. 368 The details of how the manager communicates this information to 369 meters and meter readers is not specified in the architecture. RTFM 370 has a Meter MIB [RFC 2720], which is a standard which can be used to 371 configure a meter, but nothing is said about how to configure a meter 372 reader. 374 The extent to which IPFIX should specify how meters or exporters 375 should be configured is, at this stage, an open question. Clearly 376 a collector needs some way to be sure of what it's collecting, 377 e.g. by receiving 'templates' from the meter. 379 RTFM and IPFIX both leave parts of the system unspecified. For RTFM 380 flow data to be useful one must know the ruleset used to configure 381 the meter, but a user can specify the ruleset. For IPFIX one knows 382 what the data is from the templates, but we have yet to determine 383 whether in-band configuration will be supported. 385 3.2.3.Data Model details 387 3.2.3.1.Count in one bucket 389 Within a ruleset, a packet may only be counted on one bucket, i.e. it 390 may only be included in one flow. This means that the meter does not 391 have to keep track of overlapping flows - if such aggregation is 392 required, it must be done after the raw flow data has been read by a 393 meter reader. 395 >From time to time one may wish to collect flow data for different 396 levels of aggreation at the same time. RTFM allows a meter to run 397 several rulesets at the same time, and meter readers must specify 398 which rulesets they are collecting data from. 400 The 'count in one bucket' rule, together with the ability to run 401 multiple rulesets, has proved very simple and effective in practice. 403 3.2.3.2.Counter wrapping 405 For its packet- and byte-count attributes RTFM uses continuously- 406 incrementing 64-bit counters, which are never reset. This makes 407 asynchronous meter reading easy, any reader simply has to remember 408 its previous reading and compute the difference. The only caveat is that 409 the meter should be read often enough to avoid situations when the 410 counter has cycled more than once between readings. 412 3.2.3.3.Sampling issues 414 RTFM provides 1 out of N sampling as a configuration option, so 415 that some metering interfaces may only process every Nth packet. 416 The RTFM Arcitecture [RFC 2722] does not discuss the statistical 417 implications of this, merely saying that users will need to 418 satisfy themselves that sampling makes sense in their environment. 420 RTFM makes no provision for flow sampling. Recently there has been a 421 lot of interest in flow sampling schemes which favour the 'most 422 important' flows, perhaps we need to consider this for IPFIX. 424 3.2.4.Application/transport protocol 426 RTFM has a standards-track Meter MIB [RFC 2720], which can be used 427 both to configure a meter and to read flow data from it. The MIB 428 provides a way to read lists of attributes with a single Object 429 Identifier (called a 'package'), which dramatically reduces the SNMP 430 overhead for flow data collection. NeTraMet, a widely-used 431 open-source RTFM implementation, uses SNMPv2C for configuration and 432 data collection. 434 SNMP, of course, normally uses UDP as its transport protocol. 435 Since RTFM requires a reliable flow data transport system, 436 an RTFM meter reader must time out and resend unanswered SNMP 437 requests. 438 Apart from being clumsy, this can limit the maximum data transfer 439 rate from meter to meter reader. SNMP over TCP would be a better 440 approach, but that is currently an IRTF project. 442 On the other hand, RTFM does not specify an application protocol in 443 its architecture, leaving this as an implementation issue. For 444 example, a team at IBM Research implemented a RTFM meter and meter 445 reader in a single host, with the reader storing the flow data 446 directly into a large database system. Simlarly, many NeTraMet 447 user run the meter and meter reader on the same host system. 448 A need for high flow data rates highlights the need for careful 449 systems design when building a flow data collection system. When 450 data rates are high, and it is not possible to use a high level of 451 aggregation, then it makes sense to have the collectors very close to 452 their exporters. Once the data is safely on a dedicated host 453 machine, large volumes of it can be moved using 'background' 454 techniques such as FTP. 456 The RTFM architecture only specifies a pull model for getting 457 data out of a meter. To implement push mode data transfer would 458 require specification of triggers to indicate when data should 459 be sent for each flow. 461 3.3.IPFIX Considerations for Middleboxes 463 A Middlebox is a network intermediate device that implements one or 464 more of the middlebox services. Policy based packet filtering (a.k.a. 465 firewall), Network address translation (NAT), Intrusion detection, 466 Load balancing, Policy based tunneling and IPsec security are all 467 examples of a middlebox function (or service). [MCFW]. For instance, 468 a NAT middlebox is a middlebox implementing NAT service and a 469 firewall middlebox is a middlebox implementing firewall service. 471 It is expected that the exporter in the IPFIX architecture will 472 probably implement some form of middlebox service given its ubiquity 473 today. Since some of these middlebox services might affect flow 474 exportation and how the collector interprets them, there is a need to 475 provide an analysis of these implications in relation to the IPFIX 476 architecture and a set of recommendations. 478 The following sections provide a non-exhaustive analysis of middlebox 479 services, its implications on the IPFIX architecture and a 480 corresponding set of recommendations. 482 3.3.1.Firewall 484 Firewall is a policy based packet filtering middlebox function, 485 typically used for restricting access to/from specific devices and 486 applications. The policies are often termed Access Control Lists 487 (ACLs)[MCFW]. 489 The firewall middlebox service allows the exporter to explicitly drop 490 packets based on some administrative policy. In this case, the 491 exporter can take one of the following actions that will have a 492 direct impact on the information provided by the collector to the 493 user. 495 - Silently Discard 497 In this case the packet is discarded and no flow information record 498 is sent to the collector. 500 - Discard and export flow 502 In this case the packet is discarded, and the flow information record 503 is sent to the collector. 505 - Discard and export flow with discard notification 507 In this case the packet is discarded, and the flow information record 508 is sent to the collector with an indication that the packet was 509 discarded. 511 3.3.2.Network Address Translation 513 Network Address Translation is a method by which IP addresses are 514 mapped from one address realm to another, providing transparent 515 routing to end hosts. Transparent routing here refers to modifying 516 end-node addresses en-route and maintaining state for these updates 517 so that when a datagram leaves one realm and enters another, 518 datagrams pertaining to a session are forwarded to the right end-host 519 in either realm [NAT-TERM]. 521 >From an exporter (middlebox) perspective, a NAT is composed of two 522 flows, one from the client to the NAT middlebox and another from the 523 NAT middlebox to the destination. Based on this fact, the exporter 524 has several modes of operation, i.e., it can export the private realm 525 flow, the public realm, or both. This is further constrained by the 526 flavor of NAT implemented, meaning that in order for the exported 527 information to be useful for the collector, sometimes the associated 528 flows on the two realms need to be exported in the same flow record. 530 Although there are many flavors of address translation that lend 531 themselves to different applications, this section will only address 532 the IPFIX architecture implications of traditional NAT, bi- 533 directional NAT and twice NAT. 535 3.3.2.1.Traditional NAT 537 Traditional NAT would allow hosts within a private network to 538 transparently access hosts in the external network, in most cases. In 539 a traditional NAT, sessions are unidirectional, outbound from the 540 private network. This is in contrast with bi-directional NAT, which 541 permits sessions in both inbound and outbound directions. A detailed 542 description of traditional NAT may be found in section [NAT-TERM]. 544 If the exporter is providing traditional NAT service and only the 545 private realm flow is exported, only destination based information 546 can be inferred from the collector. The reason for this is twofold. 547 First, the collector will not be able to find the reverse flow (when 548 applicable) associated with a private realm flow record, and second 549 is that in the more general scenario the collector can be connected 550 to several exporters providing NAT service and there might be 551 overlapping private realm addresses between the networks connected to 552 these exporters. 554 In a traditional NAT scenario the exporter SHOULD export private and 555 public realm information in the same flow record or provide the 556 collector with a unique key to associate the two if exported on 557 different flow records. 559 3.3.2.2.Bi-Directional NAT 561 With a bi-directional NAT, sessions can be initiated from hosts in 562 the public network as well as the private network. Private network 563 addresses are bound to globally unique addresses, statically or 564 dynamically as connections are established in either direction. 565 Detailed description of Bi-Directional may be found in section [NAT- 566 TERM]. 568 3.3.2.3.Twice NAT 570 Twice NAT is a variation of NAT in that both the source and 571 destination addresses are modified by NAT as a datagram crosses 572 address realms. This is in contrast to Traditional-NAT and Bi- 573 Directional NAT, where only one of the addresses (either source or 574 destination) is translated. Note, there is no such term as 'Once- 575 NAT'. Detailed description of Bi-Directional may be found in section 576 [NAT-TERM]. 578 In the case of twice NAT the exporter MUST export private and public 579 realm information in the same flow record or provide the collector 580 with a unique key to associate the two if exported on different flow 581 records. 583 3.3.3.Traffic Conditioners 585 A traffic conditioner may contain the following elements: meter, 586 marker, shaper, and dropper. A traffic stream is selected by a 587 classifier, which steers the packets to a logical instance of a 588 traffic conditioner[DIFF-ARCH]. 590 >From an IPFIX architecture perspective we are going to address 591 marking, shaping and dropping services. 593 3.3.3.1.Marking 595 Diffserv packet markers set the DS field of a packet to a particular 596 codepoint, adding the marked packet to a particular DS behavior 597 aggregate. The marker may be configured to mark all packets which 598 are steered to it to a single codepoint, or may be configured to mark 599 a packet to one of a set of codepoints used to select a PHB in a PHB 600 group, according to the state of a meter. When the marker changes 601 the codepoint in a packet it is said to have "re-marked" the packet 602 [DIFF-ARCH]. 604 >From and IPFIX architecture perspective, the exporter can take one of 605 the following actions when it needs to remark a packet. 607 - Unmarked flow 609 The exporter can export the flow before it was remarked. This mode of 610 operation is strongly discouraged. 612 - Remarked flow 614 The exporter can export the flow after it was remarked. 616 - Unmarked and remarked flow. 618 The exporter can export the flow before and after it was remarked or 619 export the flow before it was remarked and an indication of what was 620 the DSCP after it was remarked. 622 3.3.3.2.Shapers 624 Shapers delay some or all of the packets in a traffic stream in Order 625 to bring the stream into compliance with a traffic profile. A shaper 626 usually has a finite-size buffer, and packets may be discarded if 627 there is not sufficient buffer space to hold the delayed packets. 629 For an IPFIX perspective, since the discard of a packet by a shaper 630 is not voluntary, no indication should be sent to the collector. 632 3.3.3.3.Droppers 634 Droppers discard some or all of the packets in a traffic stream in 635 order to bring the stream into compliance with a traffic profile. 636 This process is known as "policing" the stream. Note that a dropper 637 can be implemented as a special case of a shaper by setting the 638 shaper buffer size to zero (or a few) packets. 640 In a manner analogous to the middlebox firewall service, middlebox 641 policing services also allow the exporter to explicitly drop packets 642 based on some administrative policy. 644 The three possible export behaviors described for the firewall 645 service when a packet needs to be dropped are also applicable to 646 here, i.e., silent discard, discard and export flow, discard and 647 export flow with discard notification. 649 3.3.4.Tunneling 651 The exporter can export the flows before and/or after they get 652 tunneled. In the later case the encapsulated flow information might 653 not be available due to confidentiality precautions such as those 654 used by IPsec, or due to the fact the exporter lacks the necessary 655 intelligence to inspect the encapsulated packet. Moreover, depending 656 on where in the network the exporter is located, it might only be 657 able to export flows associated with the tunnel, without visibility 658 into the encapsulated packet. 660 Apart from what was said above, it should also be factored in the 661 fact that flows exported before they get tunneled, will provide 662 information about the private network sites, but not necessarily 663 about the backbone, since the route taken by the packet it's now know 664 at that point in time (and vice-versa). 666 3.3.5.VPNs 668 The term "Virtual Private Network" (VPN) refers to the communication 669 between a set of sites, making use of a shared network 670 infrastructure. Multiple sites of a private network may therefore 671 communicate via the public infrastructure, in order to facilitate the 672 operation of the private network. The logical structure of the VPN, 673 such as addressing, topology, connectivity, reachability, and access 674 control, is equivalent to part of or all of a conventional private 675 network using private facilities [RFC2764] [VPN-2547BIS]. 677 There are multiple flavors of VPNs, the one with more relevance to 678 the IPFIX architecture is the PE-based-VPN. A PE-based VPN (or 679 Provider Edge-based Virtual Private Network) is one in which PE 680 devices in the SP network provide the VPN. This allows the existence 681 of the VPN to be hidden from the CE devices, which can operate as if 682 part of a normal customer network. A detailed discussion of VPNs can 683 be found in [PPVPN-FR]. 685 3.3.5.1.Layer 3 PE-based VPN 687 A layer 3 PE-based VPN is one in which the SP takes part in IP level 688 forwarding based on the customer network's IP address space. In 689 general, the customer network is likely to make use of private and/or 690 non-unique IP addresses. This implies that at least some devices in 691 the provider network needs to understand the IP address space as used 692 in the customer network. Typically this knowledge is limited to the 693 PE device [PPVPN-FR] which is directly attached to the customer. 695 In a layer 3 PE-based VPN the provider will need to participate in 696 some aspects of management and provisioning of the VPNs, such as 697 ensuring that the PE devices are configured to support the correct 698 VPNs. This implies that layer 3 PE-based VPNs are by definition 699 provider provisioned VPNs [PPVPN-FR]. 701 In order to connect the different VPN sites belonging to the same VPN 702 the SP uses a tunneling technique such as MPLS, L2TP or IPsec. These 703 tunnels originate and terminate on PE devices. 705 One of the characteristics of a layer 3 PE-based VPNs is that they 706 offload some aspects of VPN management from the customer network. 707 >From an IPFIX architecture perspective, this means that the SP is the 708 one that potentially will be providing the IPFIX service for the VPNs 709 that it provides connectivity. 711 The exporter in Layer 3 PE-based VPN can be located on the customer's 712 network, on the SP's backbone (P Router) or on the edge (PE router). 713 The premise of this discussion is that the exporter is the one 714 providing middlebox services, so in the case of VPNs we assume that 715 the exporter is located in a PE device. 717 3.3.5.1.1.Overlapping Address Realms 719 In the case the exporter plays the role of a PE router [VPN-2547BIS] 720 in a provider provisioned VPN scenario and has VPNs with overlapping 721 private address realms, it can only provide useful non-conflicting 722 information to the provider for intra-VPN traffic if it uses a 723 technique that allows the collector to uniquely identify to which VPN 724 the flow belongs. 726 Several techniques could be used to accomplish this goal. One of 727 these techniques is to include the VPN Global unique identifier [VPN- 728 ID] as one of the keys in the flow record. 730 In the case the exporter supports VPNs with overlapping private 731 address realms, it MUST include the VPN-ID [VPN-ID] in the exported 732 flow record. 734 3.3.5.2.Layer 2 PE-based VPN [TBD] 736 A layer 2 PE-based VPN is one in which the network is aware of the 737 VPN, but does only layer 2 forwarding and signaling. This implies 738 that the SP provisions and maintains layer 2 connectivity between CE 739 devices [VPN-L2]. 741 Forwarding options include MAC addresses (such as LAN emulation), use 742 of point-to-point link layer connections (FR or ATM), multipoint-to- 743 point (using MPLS multipoint to point LSPs), and point-to-multipoint 744 (e.g. ATM VCCs). 746 For a layer 2 PE-based VPN, the PE device may be a router, LSR, or IP 747 switch. From the CE's perspective, the PE will be operating as a 748 switch. 750 4. Security Consideration 752 This document describes the usage of IPFIX in various scenarios. 753 Currently only the IPFIX target applications (accounting, QoS 754 monitoring, traffic profiling, traffic engineering and intrusion 755 detection) are addressed. The security requirements for those 756 applications are already addressed in the IPFIX requirements draft. 757 These requirements must be considered for the selection and 758 specification of the IPFIX protocol. The IPFIX extensions proposed in 759 this document do not induce further security hazards. 761 The second section of this document describes how IPFIX can be used 762 in combination with other frameworks. New security hazards can arise 763 when two individually secure frameworks are combined. For the 764 combination of AAA with IPFIX an ASM or an IPFIX collector can 765 function as transit point for the messages. It has to be ensured that 766 at this point the applied security mechanisms (e.g. encryption of 767 messages) are maintained. 769 6. References 771 [QuZC02] J. Quittek ,et. Al "Requirements for IP Flow Information 772 Export ", (work in progress) ,Internet Draft, Internet Engineering 773 Task Force, , February 2002 775 [Wood02]M. Wood ,et al.," Intrusion Detection Message Exchange 776 Requirements",(work in progress), Internet Draft, Internet 777 Engineering Task Force, draft-ietf-idwg-requirements-06,February 778 2002. 780 [Awdu02] Daniel O. Awduche, et. al.," Overview and Principles of 781 Internet Traffic Engineering", (work in progress), Internet Draft, 782 Internet Engineering Task Force, draft-ietf-tewg-principles-02.txt, 783 May 2002 785 [Brow00] Nevil Brownlee: Packet Matching for NeTraMet Distributions, 786 http://www2.auckland.ac.nz/net//Internet/rtfm/meetings/47- 787 adelaide/pp-dist/ 789 [DeCi01] C. Demichelis, P. Cimento: IP Packet Delay Variation Metric 790 for IPPM, , November 2001 792 [RFC2680] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Packet Loss 793 Metric for IPPM, September 1999 795 [ClPB93] K.C. Claffy, George C Polyzos, Hans-Werner Braun: 796 Application of Sampling Methodologies to Network Traffic 797 Characterization, Proceedings of ACM SIGCOMM'93, 798 San Francisco, CA, USA, September 13 - 17, 1993 800 [GrDM98] Ian D. GRAHAM, Stephen F. DONNELLY, Stele MARTIN, Jed 801 MARTENS, John G. CLEARY: Nonintrusive and Accurate Measurement of 802 Unidirectional Delay and Delay Variation on the Internet, INET'98, 803 Geneva, Switzerland, 804 21-24 July, 1998 806 [DuGr00] Nick Duffield, Matthias Grossglauser: "Trajectory Sampling 807 for Direct Traffic Observation", Proceedings of ACM SIGCOMM 2000, 808 Stockholm, Sweden, August 28 - September 1, 2000. 810 [RFC2679] G. Almes, S. Kalidindi, M. Zekauskas: A One-way Delay 811 Metric for IPPM, Request for Comments: 2679, September 1999 813 [ZsZC01] Tanja Zseby, Sebastian Zander, Georg Carle: Evaluation 814 of Building Blocks 815 for Passive One-way-delay Measurements, Proceedings of Passive and 816 Active Measurement Workshop (PAM 2001), Amsterdam, The Netherlands, 817 April 23-24, 2001 819 [MCFW] Srisuresh, S. et al. "Middlebox Communication Architecture 820 and framework," work in progress. October 2001. 822 [NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address 823 Translator (NAT) Terminology and Considerations", RFC 2663, August 824 1999. 826 [NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network 827 Address Translator (Traditional NAT)", RFC 3022, January 2001. 829 [PPVPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Provider 830 Provisioned Virtual Private Networks ", work in progress, , January 2002. 833 [VPN-L2] Rosen, E., "An Architecture for L2VPNs," Internet-draft 834 , July 2001. 836 [RFC2475] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and 837 W. Weiss, "An Architecture for Differentiated Services", RFC 2475, 838 December 1998. 840 [RFC2903] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence, 841 "Generic AAA Architecture", RFC 2903, August 2000 843 7. Acknowledgements 845 We would like to thank the following persons for their contribution, 846 discussion on the mailing list and valuable comments: 848 Robert Loewe 850 8. Author's Addresses 852 Tanja Zseby 853 Fraunhofer Institute for Open Communication Systems(FOKUS) 854 Kaiserin-Augusta-Allee 31 855 10589 Berlin 856 Germany 857 Phone: +49 30 3463 7153 858 Email: zseby@fokus.fhg.de 860 Reinaldo Penno 861 Nortel Networks, Inc. 862 2305 Mission College Boulevard 863 Building SC9-B1240 864 Santa Clara, CA 95134 865 Email: rpenno@nortelnetworks.com 867 Nevil Brownlee 868 CAIDA (UCSD/SDSC) 869 9500 Gilman Drive 870 La Jolla, CA 92093-0505 871 Phone : +1 858 534 8338 872 Email : nevil@caida.org 874 9. Full Copyright Statement 876 Copyright (C) The Internet Society (date). All Rights Reserved. 877 This document and translations of it may be copied and furnished to 878 others, and derivative works that comment on or otherwise explain 879 it or assist in its implementation may be prepared, copied, 880 published and distributed, in whole or in part, without restriction 881 of any kind, provided that the above copyright notice and this 882 paragraph are included on all such copies and derivative works. 883 However, this document itself may not be modified in any way, such 884 as by removing the copyright notice or references to the Internet 885 Society or other Internet organizations, except as needed for the 886 purpose of developing Internet standards in which case the 887 procedures for copyrights defined in the Internet Standards process 888 must be followed, or as required to translate it into.