idnits 2.17.1 draft-quittek-ipfix-middlebox-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 Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 464 has weird spacing: '...for the purpo...' -- 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 (January 2004) is 7397 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: 'RFC3234' is mentioned on line 98, but not defined == Unused Reference: 'RFC3415' is defined on line 405, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX-PR' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFIX-IM' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft J. Quittek 2 Document: draft-quittek-ipfix-middlebox-00.txt M. Stiemerling 3 Expires: August 2004 NEC Europe Ltd. 4 January 2004 6 Guidelines for IPFIX Implementations on Middleboxes 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Distribution of this document is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This memo gives recommendations for the implementation of IP Flow 38 Information eXport (IPFIX) metering processes and IPFIX exporting 39 processes on middleboxes, such as firewalls, network address 40 translators, tunnel endpoints, packet classifiers, etc. Middlebox 41 functions potentially change properties of traffic flows passing the 42 box, for example NATs change addresses in header fields and firewalls 43 change the numbers of packets and bytes belonging to a traffic flow. 44 An IPFIX implementation on a middlebox should reflect this by the way 45 it selects and reports the observation point and by the way it 46 measures and reports traffic flows. 48 Table of Contents 50 1 Introduction ................................................. 3 51 2 Terminology .................................................. 3 52 3 Middleboxes .................................................. 3 53 4 Traffic Flow Scenarios at Middleboxes ........................ 4 54 5 Location of the Observation Point ............................ 5 55 6 Reporting Flow-related Middlebox Internals ................... 6 56 6.1 Packet Dropping Middleboxes ................................ 7 57 6.2 Middleboxes Changing the DSCP .............................. 7 58 6.3 Middleboxes Changing IP Addresses and Port Numbers ......... 7 59 6.4 Tunnel Endpoints ........................................... 8 60 7 Security Considerations ...................................... 8 61 8 Acknowledgements ............................................. 9 62 9 Open Issues .................................................. 9 63 10 Normative References ........................................ 9 64 11 Informative References ...................................... 9 65 12 Authors' Addresses .......................................... 10 66 13 IPR Notices ................................................. 10 67 14 Full Copyright Statement .................................... 11 69 1. Introduction 71 The IP Flow Information eXport (IPFIX) protocol is defined in [IPFIX- 72 PR] and [IPFIX-IM]. The protocol describes how information about 73 traffic flows observed at an observation point can be exported via 74 the Internet. The protocol can transfer information about traffic 75 flow properties as well as information about where and how a certain 76 traffic flow was measured. 78 The IPFIX architecture description gives insight in how to measure 79 traffic flows at hosts, routers and passive probes, but at 80 middleboxes more complicated situations may occur. Middleboxes 81 change properties of IP traffic flows: NATs change addresses in 82 header fields, firewalls change the numbers of packets and bytes 83 belonging to a traffic flow, traffic shapers drop or delay packets, 84 etc. 86 2. Terminology 88 The terminology used in this document is fully aligned with the 89 terminology defined in [IPFIX-PR]. 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in RFC 94 2119. 96 3. Middleboxes 98 The term middlebox is defined in RFC 3234 [RFC3234] by: 100 "A middlebox is defined as any intermediary device performing 101 functions other than the normal, standard functions of an IP 102 router on the datagram path between a source host and destination 103 host." 105 The list of middleboxes discussed in RFC 3234 contains: 107 1. NAT, 108 2. NAT-PT, 109 3. SOCKS gateway, 110 4. IP tunnel endpoints, 111 5. packet classifiers, markers, schedulers, 112 6. transport relay, 113 7. TCP performance enhancing proxies, 114 8. load balancers that divert/munge packets, 115 9. IP firewalls, 116 10. application firewalls, 117 11. application-level gateways, 118 12. gatekeepers / session control boxes, 119 13. transcoders, 120 14. proxies, 121 15. caches, 122 16. modified DNS servers, 123 17. content and applications distribution boxes, 124 18. load balancers that divert/munge URLs, 125 19. application-level interceptors, 126 20. application-level multicast, 127 21. involuntary packet redirection, 128 22. anonymizers. 130 It is likely that since the publication of RFC 3234 new kinds of 131 middleboxes have been added. 133 4. Traffic Flow Scenarios at Middleboxes 135 Middleboxes may delay, re-order, drop, or multiply packets, they may 136 change packet header fields and change the payload. All these action 137 have an impact on traffic flow properties. 139 In general, a middlebox transforms a uni-directional original traffic 140 flow T that arrives at the middlebox into a transformed traffic flow 141 T' that leaves the middlebox. 143 +-----------+ 144 T ---->| middlebox |----> T' 145 +-----------+ 147 Uni-directional traffic flow traversing a middlebox 149 Note that in an extreme case, T' may be an empty traffic flow (a flow 150 with no packets), for example, if the middlebox is a firewall and 151 blocks the flow. 153 In case of a middlebox performing a multicast function, a single 154 original traffic flow may be transformed into a more than one 155 transformed traffic flow. 156 +------> T' 157 | 158 +---------+-+ 159 T ---->| middlebox |----> T'' 160 +---------+-+ 161 | 162 +------> T''' 164 Uni-directional traffic flow traversing a middlebox 165 with multicast function 167 For bi-directional traffic flows we can not identify original and 168 transformed traffic flow, we can just identify flows on different 169 sides of the middlebox, say T_l on the left side and T_r on the right 170 side. 172 +-----------+ 173 T_l <--->| middlebox |<---> T_r 174 +-----------+ 176 Bi-directional unicast traffic flow traversing a middlebox 178 In case of a NAT T_l might be a traffic flow in a private address 179 realm and T_r the translated traffic flow in the public address 180 realm. If the middlebox is a NAT-PT, then T_l may be an IPv4 traffic 181 flow and T_r the translated IPv6 traffic flow. 183 At tunnel endpoints, flows are multiplexed or de-multiplexed. In 184 general, tunnel endpoints can deal with bi-directional traffic flows. 186 +------> T_r1 187 v 188 +---------+-+ 189 T_l <--->| middlebox |<---> T_r2 190 +---------+-+ 191 ^ 192 +------> T_r3 194 Bi-directional traffic flow traversing a tunnel endpoint 196 An example is a traffic flow T_l of a tunnel and flows T_rx that are 197 multipled into or de-multiplexed out of a tunnel. 199 According to the IPFIX definiton of traffic flows in [IPFIX-PR] T and 200 T' or T_l and T_ri, respectively, are different flows in general. 201 However, from an application point of view, they might be considered 202 as closely related or even as the same flow, for example if the 203 payloads they carry are identical. 205 5. Location of the Observation Point 207 Middleboxes might be integrated with other devices. An example is a 208 router with a NAT or a firewall at a line card. If an IPFIX 209 observation point is located at the line card, then the measured 210 properties of measured traffic flows may depend on the side of the 211 integrated middlebox at which packets were captured for traffic flow 212 measurement. 214 Consequently, an exporting process reporting traffic flows measured 215 at a device that hosts one or more middleboxes MUST clearly indicate 216 to collecting processes the location of the used observation point(s) 217 with respect to the middlebox(es). Otherwise, processing the 218 measured flow data could lead to wrong results. 220 At the first glance, choosing an observation point that covers the 221 entire middlebox looks like an attractive choice for the location of 222 the observation point. But this leads to ambiguities for all kinds 223 of middleboxes. Within the middlebox properites of packets are 224 modified and it MUST be clear at a collecting process whether packets 225 were observed and measured before or after modification, for example 226 it must be clear whether a reported source IP address was observed 227 before or after a NAT changed it or whether a reported packet count 228 was measured before or after a firewall dropped packets. 230 Only in case of composed middleboxes with well defined and well 231 separated internal middlebox functions, for example a combined NAT 232 and firewall, an observation point MAY be inside a middlebox, but in 233 any case it MUST be located in between the middlebox functions. 235 6. Reporting Flow-related Middlebox Internals 237 While this document requests IPFIX implementations using observations 238 points outside of middlebox functions, there are cases, where 239 reporting flow-related internals of a middlebox is of interest. 241 For many application that use traffic measurement results it is 242 desirable to get more information than can be derived from just 243 observing packets on one side of a middlebox. If, for example, 244 packets are dropped by the middlebox acting as firewall, NAT or 245 traffic shaper, then information about how many packets of the 246 observed packets are dropped may be of high interest. 248 This section gives recommendations on middlebox internal information 249 that SHOULD or MAY be reported if the IPFIX observation point is co- 250 located with one or more middleboxes. Since the internal information 251 to be reported depends on the kind of middlebox, it is discussed per 252 kind. 254 The recommendations cover middleboxes that act per packet and that do 255 not modify the application level payload of the packet (except by 256 dropping the entire packet) and that do not insert additional packets 257 into an application level or transport level traffic stream. 259 Covered are the packet level middleboxes of kind 1 - 6, 8 - 10, 21, 260 and 22 (according to the enumeration given in Sestion 3). Not 261 covered are 7 and 11 - 20. TCP performance enhancing proxies (7) are 262 not covered because they may add ACK packets to a TCP connection. 263 Still, if possible, IPFIX implementation co-located with not covered 264 middleboxes MAY follow the recommendations given in this section if 265 they can be applied in a way that reflects the intention of the 266 recommendations. 268 6.1. Packet Dropping Middleboxes 270 If an IPFIX observation point is co-located with one or more 271 middleboxes that potentially drop packets, then the corresponding 272 IPFIX exporter SHOULD be able to report the number of packets that 273 were dropped per reported flow. 275 Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS gateway 276 (3), packet schedulers (5), IP firewalls (9) and application level 277 firewalls (10). 279 6.2. Middleboxes Changing the DSCP 281 If an IPFIX observation point is co-located with one or more 282 middleboxes that potentially modify the DiffServ Code Point (DSCP, 283 see [RFC2474]) in the IP header, then the corresponding IPFIX 284 exporter SHOULD be able to report besides the observed value of the 285 DSCP also the value of the DSCP on the 'other' side of the middlebox 286 if this is a constant value for the particular traffic flow. 288 Note that the 'other' side of the middlebox can be before or after 289 changing the DSCP value depending on the location of the middlebox. 291 Note also that a classifier may change the same DSCP value of packets 292 from the same flow to different values depending on the packet or 293 other conditions. Also it is possible that packets of a single uni- 294 directional arriving flow contain packets with different DSCP values 295 that are all set to the same value by the middlebox. In both cases 296 there is a constant value for the DSCP field in the IP packets header 297 to be observed on one side of the middlebox, but on the other side 298 the value may vary. In such a case reliable reporting of the DSCP 299 value on the 'other' side of the middlebox is not possible by just 300 reporting a single value. 302 This recommendation concerns packet markers (5). 304 6.3. Middleboxes Changing IP Addresses and Port Numbers 306 If an IPFIX observation point is co-located with one or more 307 middleboxes that potentially modify the 309 - IP version field, 310 - IP source address header field, 311 - IP destination header field, 312 - TCP source port number, 313 - TCP destination port number, 314 - UDP source port number and/or 315 - UDP destination port number 317 in one of the headers, then the corresponding IPFIX exporter SHOULD 318 be able to report besides the observed value of the particular header 319 fields also the 'translated' value of these fields, as far as they 320 have constant values for the particular traffic flow. 322 Note that the 'translated' values of the fields can be the fields 323 values before or after the translation depending on the flow 324 direction and the location of the observation point with respect to 325 the middlebox. We alway call the value that is not the one observed 326 at the observation point the translated value. 328 This paragraph needs to be adapted from DSCP to addresses and port 329 numbers: Note also that a classifier may change the same DSCP value 330 of packets from the same flow to different values depending on the 331 packet or other conditions. Also it is possible that packets of a 332 single uni-directional arriving flow contain packets with different 333 DSCP values that are all set to the same value by the middlebox. In 334 both cases there is a constant value for the DSCP field in the IP 335 packets header to be observed on one side of the middlebox, but on 336 the other side the value may vary. In such a case reliable reporting 337 of the DSCP value on the 'other' side of the middlebox is not 338 possible by just reporting a single value. 340 Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS gateway 341 (3) and involuntary packet redirection (21). 343 This recommendation MAY also be applied to anonymizers (21), but it 344 should be noted that this includes the risk of loosing the effect of 345 anonymisation. 347 6.4. Tunnel Endpoints 349 If an IPFIX observation point is co-located with one or more tunnel 350 endpoints such that it observes packets that will be multiplexed into 351 a tunnel or that have been de-multiplexed out of a tunnel, then the 352 corresponding IPFIX exporter SHOULD be able to report the 353 corresponding tunnel ID. 355 7. Security Considerations 357 Section 6 recommends that IPFIX exporting processes report internals 358 about middleboxes. These internals may be security-relevant and the 359 reported information needs to be protected appropriately for reasons 360 given below. 362 Reporting the packets dropped by firewalls and other packet dropping 363 middleboxes imply the risk that this information is used by attackers 364 for analyzing the configuration of the packet dropper and for 365 developing attacks that pass the middlebox. 367 Address translation may be used for hiding the network structure 368 behind an address translator. If an IPFIX exporting process reports 369 the translations performed by an address tranlator, then parts of the 370 network structure may get uncovered. 372 If an IPFIX exporting process reports the translations performed by 373 an anonymizer, the main function of the anonymizer might get lost. 375 Also information about which packet enters of leaves which tunnel may 376 need protection. 378 8. Acknowledgements 380 Many thanks to Reinaldo Penno who raised the issue of IPFIX 381 observation points co-located with middleboxes by a contribution to 382 an earlier version of the IPFIX applicability statements. 384 9. Open Issues 386 - Do NATs (1-3) change DSCP? 387 - Are reports on DSCP modifications relevant for security? 389 10. Normative References 391 [IPFIX-PR] Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX 392 Protocol Specifications", work in progress, , January 2003. 395 [IPFIX-IM] Calato, P., Meyer, J. and J. Quittek, "Information Model for 396 IP Flow Information Export", work in progress, , November 2003. 399 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition 400 of the Differentiated Services Field (DS Field) in the IPv4 401 and IPv6 Headers", RFC 2474, December 1998. 403 11. Informative References 405 [RFC3415] Carpenter, B., and S. Brim, "Middleboxes: Taxonomy and 406 Issues", RFC 3234, February 2002. 408 12. Authors' Addresses 410 Juergen Quittek 411 NEC Europe Ltd. 412 Network Laboratories 413 Kurfuersten-Anlage 36 414 69115 Heidelberg 415 Germany 417 Phone: +49 6221 90511-15 418 EMail: quittek@netlab.nec.de 420 Martin Stiemerling 421 NEC Europe Ltd. 422 Network Laboratories 423 Kurfuersten-Anlage 36 424 69115 Heidelberg 425 Germany 427 Phone: +49 6221 90511-13 428 Email: stiemerling@netlab.nec.de 430 13. IPR Notices 432 The IETF takes no position regarding the validity or scope of any 433 intellectual property or other rights that might be claimed to 434 pertain to the implementation or use of the technology described in 435 this document or the extent to which any license under such rights 436 might or might not be available; neither does it represent that it 437 has made any effort to identify any such rights. Information on the 438 IETF's procedures with respect to rights in standards-track and 439 standards-related documentation can be found in BCP-11. Copies of 440 claims of rights made available for publication and any assurances of 441 licenses to be made available, or the result of an attempt made to 442 obtain a general license or permission for the use of such 443 proprietary rights by implementors or users of this specification can 444 be obtained from the IETF Secretariat. 446 The IETF invites any interested party to bring to its attention any 447 copyrights, patents or patent applications, or other proprietary 448 rights which may cover technology that may be required to practice 449 this standard. Please address the information to the IETF Executive 450 Director. 452 14. Full Copyright Statement 454 Copyright (C) The Internet Society (2004). All Rights Reserved. 456 This document and translations of it may be copied and furnished to 457 others, and derivative works that comment on or otherwise explain it 458 or assist in its implmentation may be prepared, copied, published and 459 distributed, in whole or in part, without restriction of any kind, 460 provided that the above copyright notice and this paragraph are 461 included on all such copies and derivative works. However, this 462 document itself may not be modified in any way, such as by removing 463 the copyright notice or references to the Internet Society or other 464 Internet organizations, except as needed for the purpose of 465 developing Internet standards in which case the procedures for 466 copyrights defined in the Internet Standards process must be 467 followed, or as required to translate it into languages other than 468 English. 470 The limited permissions granted above are perpetual and will not be 471 revoked by the Internet Society or its successors or assigns. 473 This document and the information contained herein is provided on an 474 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 475 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 476 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 477 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 478 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.