Internet Draft J. Quittek Document: draft-quittek-ipfix-middlebox-00.txt M. Stiemerling Expires: August 2004 NEC Europe Ltd. January 2004 Guidelines for IPFIX Implementations on Middleboxes <draft-quittek-ipfix-middlebox-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Distribution of this document is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo gives recommendations for the implementation of IP Flow Information eXport (IPFIX) metering processes and IPFIX exporting processes on middleboxes, such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc. Middlebox functions potentially change properties of traffic flows passing the box, for example NATs change addresses in header fields and firewalls change the numbers of packets and bytes belonging to a traffic flow. An IPFIX implementation on a middlebox should reflect this by the way it selects and reports the observation point and by the way it measures and reports traffic flows. Quittek, Stiemerling [Page 1]
Internet-Draft IPFIX for Middleboxes February 2004 Table of Contents 1 Introduction ................................................. 3 2 Terminology .................................................. 3 3 Middleboxes .................................................. 3 4 Traffic Flow Scenarios at Middleboxes ........................ 4 5 Location of the Observation Point ............................ 5 6 Reporting Flow-related Middlebox Internals ................... 6 6.1 Packet Dropping Middleboxes ................................ 7 6.2 Middleboxes Changing the DSCP .............................. 7 6.3 Middleboxes Changing IP Addresses and Port Numbers ......... 7 6.4 Tunnel Endpoints ........................................... 8 7 Security Considerations ...................................... 8 8 Acknowledgements ............................................. 9 9 Open Issues .................................................. 9 10 Normative References ........................................ 9 11 Informative References ...................................... 9 12 Authors' Addresses .......................................... 10 13 IPR Notices ................................................. 10 14 Full Copyright Statement .................................... 11 Quittek, Stiemerling [Page 2]
Internet-Draft IPFIX for Middleboxes February 2004 1. Introduction The IP Flow Information eXport (IPFIX) protocol is defined in [IPFIX- PR] and [IPFIX-IM]. The protocol describes how information about traffic flows observed at an observation point can be exported via the Internet. The protocol can transfer information about traffic flow properties as well as information about where and how a certain traffic flow was measured. The IPFIX architecture description gives insight in how to measure traffic flows at hosts, routers and passive probes, but at middleboxes more complicated situations may occur. Middleboxes change properties of IP traffic flows: NATs change addresses in header fields, firewalls change the numbers of packets and bytes belonging to a traffic flow, traffic shapers drop or delay packets, etc. 2. Terminology The terminology used in this document is fully aligned with the terminology defined in [IPFIX-PR]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Middleboxes The term middlebox is defined in RFC 3234 [RFC3234] by: "A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host." The list of middleboxes discussed in RFC 3234 contains: 1. NAT, 2. NAT-PT, 3. SOCKS gateway, 4. IP tunnel endpoints, 5. packet classifiers, markers, schedulers, 6. transport relay, 7. TCP performance enhancing proxies, 8. load balancers that divert/munge packets, 9. IP firewalls, 10. application firewalls, Quittek, Stiemerling [Page 3]
Internet-Draft IPFIX for Middleboxes February 2004 11. application-level gateways, 12. gatekeepers / session control boxes, 13. transcoders, 14. proxies, 15. caches, 16. modified DNS servers, 17. content and applications distribution boxes, 18. load balancers that divert/munge URLs, 19. application-level interceptors, 20. application-level multicast, 21. involuntary packet redirection, 22. anonymizers. It is likely that since the publication of RFC 3234 new kinds of middleboxes have been added. 4. Traffic Flow Scenarios at Middleboxes Middleboxes may delay, re-order, drop, or multiply packets, they may change packet header fields and change the payload. All these action have an impact on traffic flow properties. In general, a middlebox transforms a uni-directional original traffic flow T that arrives at the middlebox into a transformed traffic flow T' that leaves the middlebox. +-----------+ T ---->| middlebox |----> T' +-----------+ Uni-directional traffic flow traversing a middlebox Note that in an extreme case, T' may be an empty traffic flow (a flow with no packets), for example, if the middlebox is a firewall and blocks the flow. In case of a middlebox performing a multicast function, a single original traffic flow may be transformed into a more than one transformed traffic flow. +------> T' | +---------+-+ T ---->| middlebox |----> T'' +---------+-+ | +------> T''' Uni-directional traffic flow traversing a middlebox with multicast function Quittek, Stiemerling [Page 4]
Internet-Draft IPFIX for Middleboxes February 2004 For bi-directional traffic flows we can not identify original and transformed traffic flow, we can just identify flows on different sides of the middlebox, say T_l on the left side and T_r on the right side. +-----------+ T_l <--->| middlebox |<---> T_r +-----------+ Bi-directional unicast traffic flow traversing a middlebox In case of a NAT T_l might be a traffic flow in a private address realm and T_r the translated traffic flow in the public address realm. If the middlebox is a NAT-PT, then T_l may be an IPv4 traffic flow and T_r the translated IPv6 traffic flow. At tunnel endpoints, flows are multiplexed or de-multiplexed. In general, tunnel endpoints can deal with bi-directional traffic flows. +------> T_r1 v +---------+-+ T_l <--->| middlebox |<---> T_r2 +---------+-+ ^ +------> T_r3 Bi-directional traffic flow traversing a tunnel endpoint An example is a traffic flow T_l of a tunnel and flows T_rx that are multipled into or de-multiplexed out of a tunnel. According to the IPFIX definiton of traffic flows in [IPFIX-PR] T and T' or T_l and T_ri, respectively, are different flows in general. However, from an application point of view, they might be considered as closely related or even as the same flow, for example if the payloads they carry are identical. 5. Location of the Observation Point Middleboxes might be integrated with other devices. An example is a router with a NAT or a firewall at a line card. If an IPFIX observation point is located at the line card, then the measured properties of measured traffic flows may depend on the side of the integrated middlebox at which packets were captured for traffic flow measurement. Consequently, an exporting process reporting traffic flows measured at a device that hosts one or more middleboxes MUST clearly indicate Quittek, Stiemerling [Page 5]
Internet-Draft IPFIX for Middleboxes February 2004 to collecting processes the location of the used observation point(s) with respect to the middlebox(es). Otherwise, processing the measured flow data could lead to wrong results. At the first glance, choosing an observation point that covers the entire middlebox looks like an attractive choice for the location of the observation point. But this leads to ambiguities for all kinds of middleboxes. Within the middlebox properites of packets are modified and it MUST be clear at a collecting process whether packets were observed and measured before or after modification, for example it must be clear whether a reported source IP address was observed before or after a NAT changed it or whether a reported packet count was measured before or after a firewall dropped packets. Only in case of composed middleboxes with well defined and well separated internal middlebox functions, for example a combined NAT and firewall, an observation point MAY be inside a middlebox, but in any case it MUST be located in between the middlebox functions. 6. Reporting Flow-related Middlebox Internals While this document requests IPFIX implementations using observations points outside of middlebox functions, there are cases, where reporting flow-related internals of a middlebox is of interest. For many application that use traffic measurement results it is desirable to get more information than can be derived from just observing packets on one side of a middlebox. If, for example, packets are dropped by the middlebox acting as firewall, NAT or traffic shaper, then information about how many packets of the observed packets are dropped may be of high interest. This section gives recommendations on middlebox internal information that SHOULD or MAY be reported if the IPFIX observation point is co- located with one or more middleboxes. Since the internal information to be reported depends on the kind of middlebox, it is discussed per kind. The recommendations cover middleboxes that act per packet and that do not modify the application level payload of the packet (except by dropping the entire packet) and that do not insert additional packets into an application level or transport level traffic stream. Covered are the packet level middleboxes of kind 1 - 6, 8 - 10, 21, and 22 (according to the enumeration given in Sestion 3). Not covered are 7 and 11 - 20. TCP performance enhancing proxies (7) are not covered because they may add ACK packets to a TCP connection. Still, if possible, IPFIX implementation co-located with not covered middleboxes MAY follow the recommendations given in this section if Quittek, Stiemerling [Page 6]
Internet-Draft IPFIX for Middleboxes February 2004 they can be applied in a way that reflects the intention of the recommendations. 6.1. Packet Dropping Middleboxes If an IPFIX observation point is co-located with one or more middleboxes that potentially drop packets, then the corresponding IPFIX exporter SHOULD be able to report the number of packets that were dropped per reported flow. Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS gateway (3), packet schedulers (5), IP firewalls (9) and application level firewalls (10). 6.2. Middleboxes Changing the DSCP If an IPFIX observation point is co-located with one or more middleboxes that potentially modify the DiffServ Code Point (DSCP, see [RFC2474]) in the IP header, then the corresponding IPFIX exporter SHOULD be able to report besides the observed value of the DSCP also the value of the DSCP on the 'other' side of the middlebox if this is a constant value for the particular traffic flow. Note that the 'other' side of the middlebox can be before or after changing the DSCP value depending on the location of the middlebox. Note also that a classifier may change the same DSCP value of packets from the same flow to different values depending on the packet or other conditions. Also it is possible that packets of a single uni- directional arriving flow contain packets with different DSCP values that are all set to the same value by the middlebox. In both cases there is a constant value for the DSCP field in the IP packets header to be observed on one side of the middlebox, but on the other side the value may vary. In such a case reliable reporting of the DSCP value on the 'other' side of the middlebox is not possible by just reporting a single value. This recommendation concerns packet markers (5). 6.3. Middleboxes Changing IP Addresses and Port Numbers If an IPFIX observation point is co-located with one or more middleboxes that potentially modify the - IP version field, - IP source address header field, - IP destination header field, - TCP source port number, - TCP destination port number, - UDP source port number and/or Quittek, Stiemerling [Page 7]
Internet-Draft IPFIX for Middleboxes February 2004 - UDP destination port number in one of the headers, then the corresponding IPFIX exporter SHOULD be able to report besides the observed value of the particular header fields also the 'translated' value of these fields, as far as they have constant values for the particular traffic flow. Note that the 'translated' values of the fields can be the fields values before or after the translation depending on the flow direction and the location of the observation point with respect to the middlebox. We alway call the value that is not the one observed at the observation point the translated value. This paragraph needs to be adapted from DSCP to addresses and port numbers: Note also that a classifier may change the same DSCP value of packets from the same flow to different values depending on the packet or other conditions. Also it is possible that packets of a single uni-directional arriving flow contain packets with different DSCP values that are all set to the same value by the middlebox. In both cases there is a constant value for the DSCP field in the IP packets header to be observed on one side of the middlebox, but on the other side the value may vary. In such a case reliable reporting of the DSCP value on the 'other' side of the middlebox is not possible by just reporting a single value. Concerned kinds of middleboxes are NAT (1), NAT-PT (2), SOCKS gateway (3) and involuntary packet redirection (21). This recommendation MAY also be applied to anonymizers (21), but it should be noted that this includes the risk of loosing the effect of anonymisation. 6.4. Tunnel Endpoints If an IPFIX observation point is co-located with one or more tunnel endpoints such that it observes packets that will be multiplexed into a tunnel or that have been de-multiplexed out of a tunnel, then the corresponding IPFIX exporter SHOULD be able to report the corresponding tunnel ID. 7. Security Considerations Section 6 recommends that IPFIX exporting processes report internals about middleboxes. These internals may be security-relevant and the reported information needs to be protected appropriately for reasons given below. Reporting the packets dropped by firewalls and other packet dropping middleboxes imply the risk that this information is used by attackers Quittek, Stiemerling [Page 8]
Internet-Draft IPFIX for Middleboxes February 2004 for analyzing the configuration of the packet dropper and for developing attacks that pass the middlebox. Address translation may be used for hiding the network structure behind an address translator. If an IPFIX exporting process reports the translations performed by an address tranlator, then parts of the network structure may get uncovered. If an IPFIX exporting process reports the translations performed by an anonymizer, the main function of the anonymizer might get lost. Also information about which packet enters of leaves which tunnel may need protection. 8. Acknowledgements Many thanks to Reinaldo Penno who raised the issue of IPFIX observation points co-located with middleboxes by a contribution to an earlier version of the IPFIX applicability statements. 9. Open Issues - Do NATs (1-3) change DSCP? - Are reports on DSCP modifications relevant for security? 10. Normative References [IPFIX-PR] Claise, B., Fullmer, M., Calato, P. and R. Penno, "IPFIX Protocol Specifications", work in progress, <draft-ietf- ipfix-protocol-02.txt>, January 2003. [IPFIX-IM] Calato, P., Meyer, J. and J. Quittek, "Information Model for IP Flow Information Export", work in progress, <draft-ietf- ipfix-info-02>, November 2003. [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 11. Informative References [RFC3415] Carpenter, B., and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. Quittek, Stiemerling [Page 9]
Internet-Draft IPFIX for Middleboxes February 2004 12. Authors' Addresses Juergen Quittek NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-15 EMail: quittek@netlab.nec.de Martin Stiemerling NEC Europe Ltd. Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221 90511-13 Email: stiemerling@netlab.nec.de 13. IPR Notices The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Quittek, Stiemerling [Page 10]
Internet-Draft IPFIX for Middleboxes February 2004 14. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Quittek, Stiemerling [Page 11]