Internet Draft E. Boschi draft-boschi-ipfix-implementation-guidelines-00.txt Hitachi Europe Expires: April 2006 L. Mark Fraunhofer FOKUS J. Quittek NEC Europe Ltd. M. Stiemerling NEC Europe Ltd. October 2005 IPFIX Implementation Guidelines draft-boschi-ipfix-implementation-guidelines-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 20, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 1] IPFIX implementation guidelines October 2005 Abstract The IP Flow Information eXport (IPFIX) protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. This document provides guidelines for the implementation and use of the IPFIX protocol. A set of these guidelines refers to the implementation on middleboxes, such as firewalls, network address translators, tunnel endpoints, packet classifiers, etc. Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 2] IPFIX implementation guidelines October 2005 Table of Contents 1. Introduction...........................................3 2. Terminology............................................4 3. Implementation Guidelines..............................4 3.1 IPFIX Message Format...................................4 3.1.1 Set Format............................................4 3.1.2 Template Format.......................................5 3.2 Padding................................................6 3.3 IPFIX Message Header Export Time and Data Record Time..6 3.4 Template Management....................................6 3.5 The Collecting Process's side..........................6 3.6 Transport Protocol.....................................7 3.6.1 SCTP..................................................7 3.6.2 UDP...................................................7 3.7 Extensions.............................................7 4. Guidelines for implementation on Middleboxes...........8 4.1 Traffic Flow Scenarios at Middleboxes..................9 4.2 Location of the Observation Point.....................10 4.3 Reporting Flow-related Middlebox Internals............11 4.3.1 Packet Dropping Middleboxes..........................12 4.3.2 Middleboxes Changing the DSCP........................12 4.3.3 Middleboxes Changing IP Addresses and Port Numbers...13 4.3.4 Tunnel Endpoints ....................................14 5. Implementation mistakes...............................14 5.1 IPFIX and Netflow v9..................................14 5.2 Padding of the data set...............................15 5.3 Field ID Numbers......................................15 5.4 Template ID Numbers...................................15 6. Open issues...........................................15 6.1 Enterprise specific IEs types.........................15 7. Security Considerations...............................16 8. Code availability.....................................16 9. Normative References..................................17 10. Informative References................................17 11. Acknowledgements......................................17 12. Author's Addresses....................................18 13. Intellectual Property Statement.......................18 14. Copyright Statement...................................19 15. Disclaimer............................................19 1. Introduction The IPFIX protocol defines how IP Flow information can be exported from routers, measurement probes or other devices. In this document, we provide guidelines for its implementation, highlighting at the same time open issues, and unclear definitions. Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 3] IPFIX implementation guidelines October 2005 We also provide some guidelines for the implementation on middleboxes. 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. 2. Terminology The terminology used in this document is fully aligned with the terminology defined in [IPFIX-PROTO]. 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. Implementation Guidelines 3.1 IPFIX Message Format An IPFIX message consists of a Message Header and one or more Template, Option Template, or Data Sets. 3.1.1 Set Format A Set is a collection of records of the same type. Template Sets, Option Template Sets, and Data Sets contain records of the same type, respectively template records, option template records, and data records. A Set is identified by a Set ID. A Set ID has an integral data type and its value is in the range of 2 - 65535. A value of 2 identifies a Template Set. A value of 3 identifies an Option Template Set. All other values from 4 to 255 are reserved for future use. Values above 255 are used for Data Sets. In this case the SetID correspond to the TemplateID of the used template. The Set ID values of 0 and 1 are not used for historical reasons [RFC3954]. A Set with a reserved or unknown or unused (value of 0 or 1) Set ID SHOULD be ignored. Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 4] IPFIX implementation guidelines October 2005 3.1.2 Template Format IPFIX is template based. Templates define the structure of data to be exported, describing data fields together with their type and meaning. Therefore, the exporter can export all kind of data records composed of information elements from [IPFIX-INFO] or vendor specific information elements. This offers a great flexibility to the exporter. [IPFIX-PROTO] and [IPFIX-INFO| define the IPFIX protocol and information elements which can be exported using the protocol. There are no hints how to compose a template or pre-defined templates for the most common use cases. The absence of common templates complicates the interworking of applications using IPFIX even if the application can communicate at the protocol level. 3.1.2.1 Multiple IE of same field type Exporters and collectors SHOULD support the use of multiple IEs of the same field type for scope elements. Exporters SHOULD avoid the use of templates containing multiple non-scope IEs of the same field type. Collectors not capable of handling multiple non-scope IEs of the same field type should log a warning and MAY accept the IEs using a first match semantic. 3.1.2.2 Order of IEs within the template Although it is not explicitly mentioned in the protocol draft the order of IEs within the template SHOULD NOT be changed by exporting or collecting processes. 3.1.2.3 Coding of IEs of unknown type The exporting process SHOULD NOT export Information Elements of unknown type. The collecting process MAY accept templates with Information Elements of unknown types. In this case these data should be decoded as an octet array. Alternatively the collecting process MAY ignore templates and subsequent data sets that contain Information Elements of unknown types. Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 5] IPFIX implementation guidelines October 2005 3.1.2.4 Using Scopes The default scope for exported IPFIX data is the observation domain. One can further limit the scope via option records. 3.2 Padding [TODO] 3.3 IPFIX Message Header Export Time and Data Record Time This section contains recommendations on when to use this method and when not. Additionally, some general comments how to use timestamps in data records are provided. Section 5 of the [IPFIX-PROTO] defines a method for an optimized export of time related information elements. [IPFIX-ARCH] distinguishes the Metering Process and the Exporting Process. The problem is that the Metering Process does not know when the IPFIX-Message leaves the exporter. This implies that the metering process has to store timestamp information i.e. in a 64 bit memory cell and has to provide the exporting process with these 64 bit data, while the exporting process hat to convert these data e.g. to a 32 bit offset value. 3.4 Template Management The exporter has to take care that the templates are sent prior to the related data records. For SCTP and TCP the templates have to be resent on a connection reestablishment. For UDP templates have to be resent after a configured timeout. In either case this requires the exporting process to store all active template definitions. 3.5 The Collecting Process's side The IPFIX collector has to maintain a list of sources and per source a list of templates to decode incoming data templates. Because of the template feature of IPFIX the collector does not need any knowledge of the transferred data. All information needed to decode all kind of data is transferred via template records. Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 6] IPFIX implementation guidelines October 2005 3.6 Transport Protocol IPFIX messages can be transferred using SCTP, TCP or UDP as bearer protocol. An IPFIX implementation MUST support SCTP-PR whereas support for TCP and UDP is optional. 3.6.1 SCTP Preference to SCTP-PR was given because it is congestion-aware and reduces bandwidth in case of congestion but still has a much simpler state machine than TCP. This saves resources on lightweight probes and router line cards. As October 2005, there is no major operating system with full support for SCTP-PR (at least the authors are not aware of one). So at present an application has to use TCP to enable the export over ipv6 networks. One option to test the SCTP code is to use Linux with kernel 2.6 that has support for SCTP-PR over IPv4. 3.6.2 UDP UDP is not a reliable transport protocol, and therefore IPFIX messages sent using UDP might be lost. [IPFIX-PROTO] specifies that templates sent from the Exporting Process to the Collecting Process using UDP MUST be resent at regular intervals. The frequency of template transmission MUST be configurable. The protocol allows resending templates depending on the number of packets sent. The resend time shouldn't be lower than 10 seconds or bigger than one hour. 3.7 Extensions New Information Elements can be added to the protocol in two different ways: - If the IEs are considered of general interest they could be added to the group of IETF specified IEs and extend the current IPFIX Information Model. The list of IETF specified IEs is going to be administered by IANA, after being administered for an initial period by the IPFIX WG. The introduction of new IE in the IANA registry is subjected to expert review. Those experts will initially be drawn from the Working Group Chairs and document editors of the IPFIX and PSAMP Working Groups (cf. [IPFIX-INFO]). Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 7] IPFIX implementation guidelines October 2005 [IPFIX-INFO] defines an XML schema, which may be used to create consistent machine-readable extensions to the IPFIX information model. - A faster way of introducing new IEs or the way for vendors to integrate proprietary IEs in IPFIX is by using Enterprise IEs (cf. [IPFIX-PROTO]). Developers having no enterprise ID, or waiting for IANA to assign new IDs can temporary use IDs from 10000-11000. These numbers are reserved for developers and are not assigned by IANA. [This is just a proposal. Maybe we can discuss this on the ipfix mailing list] The [IPFIX-INFO] document contains an XML-based specification of template, abstract data types and IPFIX Information Elements. This formal description can be used for automatically checking syntactical correctness of the specification of IPFIX IEs or for generating code that deals with processing IPFIX IEs. 4. Guidelines for implementation on 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, 11. application-level gateways, 12. gatekeepers / session control boxes, 13. transcoders, 14. proxies, 15. caches, 16. modified DNS servers, Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 8] IPFIX implementation guidelines October 2005 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.1 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' +-----------+ Figure 1: 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''' Figure 2:Uni-directional traffic flow traversing a middlebox with multicast function Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 9] IPFIX implementation guidelines October 2005 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 +-----------+ Figure 3: 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 Figure 4: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. 4.2 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 Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 10] IPFIX implementation guidelines October 2005 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 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 properties 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. 4.3 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 Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 11] IPFIX implementation guidelines October 2005 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 at the beginning of section 4). 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 they can be applied in a way that reflects the intention of the recommendations. 4.3.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). 4.3.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). Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 12] IPFIX implementation guidelines October 2005 4.3.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 - 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 always 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. Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 13] IPFIX implementation guidelines October 2005 4.3.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. 5. Implementation mistakes It seems useful to list a few things that were clear in the document and not needing clarification that some implementers didn't do correctly. All of these things caused or may cause interoperability problems. 5.1 IPFIX and Netflow v9 A large group of mistakes stems from the fact that many implementers started implementing IPFIX from an existing version of Netflow v9. Despite their similarity, the two protocols differ in many aspects. We list here some of the most important differences. - Transport protocol: Netflowv9 runs over UDP while IPFIX must be reliable and has SCTP as its mandatory protocol, while TCP and UDP are optional - IPFIX differentiates between IETF and non-IETF defined fields. Non-IETF Information Elements can be specified by coupling the non IETF IE identifier with an Enterprise ID (corresponding to the vendor that defined the IE). - Option templates: in IPFIX an option template must have a scope, the scope is not allowed to be of length zero. This is not the case in Netflow v9. Message header: - Length field: in Netflow v9 this field (called count) contains the number of records, in IPFIX indicates the total length of the IPFIX message, measured in Octets (including message header and Set(s)) - Timestamp: Netflow v9 has an additional timestamp: Sysuptime. It indicates the time in milliseconds since the last reboot of the exporter Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 14] IPFIX implementation guidelines October 2005 5.2 Padding of the data set In [IPFIX-PROTO] it is specified that he exporting process MAY insert some padding octets to align IEs within a data record. The padding length MUST be anyway shorter than any allowable record in that set. It is important to respect this limitation: if the padding length is equal or longer that the length of the shorter record, it will be interpreted as another record. 5.3 Field ID Numbers If the Information Element identifier in the data record has a value such that the first bit is "1", the collector interprets the fields following the length fields as enterprise number. There is no way to tell that this is wrong, if it wasn't meant as enterprise data record. 5.4 Template ID Numbers Template IDs are generated on demand by the exporting process. When exporting the same template at different times or using the same template multiple times simultaneously different template IDs are generated. So the collecting process does not know in advance which template id a special template will get. 6. Open issues 6.1 Enterprise specific IEs types When receiving information elements from vendors the following information is directly available to the collector: - the vendor specific IE identifier - its length - the enterprise ID. While enterprise IDs are publicly available and is therefore straightforward to identify the enterprise, how to obtain the type of the given information element requires some clarification. Open Issue: Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 15] IPFIX implementation guidelines October 2005 How to provide this information to the collector? Which general mechanism(s) should be used? One first solution could be to make it available on the web via some automatable external lookup (e.g. XDS). Another solution would be to send the enterprise specific information element description with the data stream, in an option record. 7. Security Considerations This document describes the implementation of IPFIX. The security requirements for the IPFIX target applications are addressed in the IPFIX requirements draft. These requirements must be considered for the specification of the IPFIX protocol. Section 4.3 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 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. Code availability This section provides links where to gather IPFIX implementations (or code related to IPFIX) that have been made freely available by their implementers. Link: http://libipfix.sourceforge.net Organisation: Fraunhofer FOKUS Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 16] IPFIX implementation guidelines October 2005 Description: IPFIX C library, distributed under the BSD license. Full support for SCTP, UDP, TCP, IPv4 and IPv6 over Linux, FreeBSD, Solaris Link: http://www.ntop.org/ Organisation: Netikos S.p.A. Description: distributed under the GPL2 license. Runs over Linux 9. Normative References [RFC3917] J. Quittek, T. Zseby, B. Claise, S. Zander, Requirements for IP Flow Information Export, October 2004 [IPFIX-PROTO] B. Claise (Editor), IPFIX Protocol Specification, Internet Draft , work in progress, September 2005 [IPFIX-INFO] J. Quittek, S. Bryant, J. Meyer, Information Model for IP Flow Information Export, Internet Draft , work in progress, September 2005 [RFC2474] K. Nichols, S. Blake, F. Baker, and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 10. Informative References [IPFIX-ARCH] G. Sadasivan, N. Brownlee, B. Claise, J. Quittek: Architecture for IP Flow Information Export, Internet Draft < draft-ietf-ipfix-architecture- 09.txt>, work in progress, August 2005 [RFC3415] B. Carpenter, and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. 11. Acknowledgements We would like to thank the MoMe project for organising the IPFIX Interoperability Event in July 2005 that provided us precious input for this draft. Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 17] IPFIX implementation guidelines October 2005 12. Author's Addresses Elisa Boschi Hitachi Europe SAS Immeuble Le Theleme, 1503 Route des Dolines o6560 Valbonne, France Phone: +33 4 89874180 Email: elisa.boschi@hitachi-eu.com Lutz Mark Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin, Germany Phone: +49 30 3463 7306 Email: mark@fokus.fraunhofer.de 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. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 18] IPFIX implementation guidelines October 2005 Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 14. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 15. Disclaimer This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Boschi, Mark, Quittek, Stiemerling Expires April 2006 [Page 19]