One document matched: draft-quittek-ipfix-middlebox-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 08:34:12 |