Internet Draft Sebastian Zander Document: draft-zander-ipfix-diameter-eval-00.txt Fraunhofer FOKUS Expires: February 2003 September 2002 Evaluation of Diameter Protocol against IPFIX Requirements 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 (2001). All Rights Reserved. Abstract This document provides an evaluation of the applicability of the Diameter protocol [DIAMETER] as an IPFIX protocol. It compares the properties and capabilities of the Diameter protocol to the IPFIX requirements [IPFIX-REQ]. Zander expires February 2003 [Page 1] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 Table of Contents 1 Introduction ................................................. 2 1.1 Diameter Standardization ................................... 2 1.2 Diameter Deployment and Evolution .......................... 3 2 Architectural Considerations ................................. 3 2.1 Diameter Protocol Overview ................................. 4 2.2 General Applicability ...................................... 5 2.3 Architectural Differences .................................. 5 3 Item Level Compliance Evaluation ............................. 6 4 Security Considerations ...................................... 11 5 Acknowledgements ............................................. 11 6 References ................................................... 11 7 Author's Addresses ........................................... 12 8 Full Copyright Statement ..................................... 12 1. Introduction This document provides an evaluation of the applicability of the Diameter protocol as an IPFIX protocol. First, the general Diameter architecture is introduced and its application to the communication between an IPFIX exporting process and an IPFIX collecting process is discussed in Section 2. Section 3 discusses in detail, to which degree requirements stated in [IPFIX-REQ] are met. This document uses the terminology defined in [IPFIX-REQ]. The Diameter protocol is the successor of the RADIUS protocol and was developed to overcome several limitations of RADIUS. The Diameter protocol was developed for the purpose of Authentication, Authorization and Accounting (AAA) and is standardized by the IETF Authentication, Authorization and Accounting Working Group (AAA WG). The Diameter base protocol is specified in draft-ietf-aaa- diameter-12.txt [DIAMETER]. The Diameter base protocol provides a AAA framework. Specific applications require extensions to the base protocol and are called Diameter applications. Currently applications are being standardized by the AAA WG for dial-up and mobile IPv4 services. These specific applications are considered out of scope for the purpose of this document. However there are two companion drafts to the Diameter base protocol which need to be considered here: the strong end-to-end security extension [DIAM_CMS] and the transport recommendations for the Diameter base protocol [AAA_TRANS]. Zander expires February 2003 [Page 2] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 1.1. Diameter Standardization The Diameter base protocol has passed Working Group last call after thorough review. The draft will now be reviewed by the IESG and afterwards become a Proposed Standard. The transport recommendations draft is very mature while the CMS draft needs more work. The Diameter protocol will become an open IETF standard and is not protected by any patents. The IETF copyright can be found at the end of [DIAMETER] or at the end of this draft. Currently there exist approximately 5 implementations from different vendors. One of the implementations is even freely available as binary [DIA_SUN]. Furthermore an open source project has been started to create an open source implementation of the protocol [DIA_OS]. 1.2. Diameter Deployment and Evolution The Diameter protocol is already commercially available but not widely used yet because it is not standardized. Also most ISPs will not switch from RADIUS to Diameter for their dial-up services. However if Diameter is used in Release 5 of 3GPP as planned it is expected that the protocol will be widely deployed as part of the 3GPP rollout. A further driver will be ISPs offering mobile IP support. Currently a standardized RADIUS AAA solution for mobile IP does not exist. The further activities of the AAA WG after standardization of Diameter base protocol and base applications are under discussion. The most likely scenario (advocates opinion) is that the AAA WG will continue to develop more Diameter applications (collaborating with other WGs if needed). Also the base protocol will probably be developed further in case the demand is there. 2. Architectural Considerations This section introduces the architecture of the Diameter protocol and suggests a way of applying it to the communication between an IPFIX exporting process and an IPFIX collecting process. The Diameter architecture consists of three different entities: Diameter clients, Diameter servers and Diameter agents. Diameter clients send requests for Authentication and/or Authorization to Diameter servers. Diameter clients also send Zander expires February 2003 [Page 3] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 accounting information to Diameter servers. Diameter clients are for example Network Access Servers (NASs) or foreign and home agents (mobile IPv4). Diameter servers perform authentication and authorization decisions based on Diameter clients requests and return answers to Diameter clients. Diameter servers configure accounting of the Diameter clients and get accounting information send by them. When Diameter servers get messages not destinated to themselves they forward both Authentication and Authorization request and accounting data to the appropriate servers. Diameter servers may also automatically direct the Diameter clients to send accounting information in a particular way. Four different types of Diameter agents have been identified and are described in Section 2.8 of [DIAMETER]. Diameter agents are used for a number of purposes: grouping of systems (security associations), request concentration, load balancing and value-added processing of requests/responses. Please note that despite the fact that the terms client and server are used the Diameter protocol is not a client server protocol but a peer-to-peer protocol. Any Diameter peer can start a messages exchange. This will be described in more detail in the next section. 2.1. Diameter Protocol Overview This section only provides a brief overview of the Diameter base protocol. Therefore it is mandatory to read the base protocol draft [DIAMETER] before evaluating the protocol. The Diameter base protocol is intended to provide an AAA framework for applications such as network access or mobile IP [DIAMETER]. is a peer-to-peer protocol allowing any peer to start a message exchange. The Diameter base protocol is never used on its own. It is always extended for a particular application e.g. mobile IPv4. The Diameter protocol is run on top of TCP [TCP] or SCTP [SCTP] which guarantee a reliable and congestion aware transport. Draft [AAA_TRANS] discusses the AAA transport issues in detail. Diameter has a build-in watchdog algorithm which can pro-actively detect transport failures. Also failback and failover procedures have been defined (section 5.5.4 [DIAMETER] and [AAA_TRANS]). Zander expires February 2003 [Page 4] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 Diameter supports dynamic peer discovery through different mechanisms e.g. DNS, SLPv2 [SLP] to enable a simpler and more robust deployment. Peers can also be configured manually. Diameter provides application layer sessions which abstracts from transport connections. Diameter messages for multiple sessions are multiplexed through a single transport connection. Diameter server and agents route messages to their final destination based on realms. The data model of Diameter is based on Attribute Value Pairs (AVPs). Each Diameter message consists of a fixed header and a number of AVPs carrying data. The fixed header contains a 16 bit command code which identifies the type of message. A number of data types for AVPs have been defined already. AVPs can be grouped into logical structures. Diameter can be extended by defining new AVP values, new AVPs and new applications (which includes definition of new command codes). The Diameter protocol supports capability negotiation between peers. This enables a more simpler and robust deployment. Diameter supports applications which support Authentication, Authorization and Accounting. It also supports applications which only make use of accounting (see section 8 [DIAMETER]). Diameter uses hop-by-hop security [DIAMETER] and a Diameter extension exists which supports end-to-end security [DIAM_CMS] (see security considerations for more details). 2.2. General Applicability The Diameter architecture consists of three different entities (client, server and agent) while the IPFIX architecture is comprised of: observation point, metering process, exporting process and collecting process. From the viewpoint of the IPFIX protocol only the exporting process and collection process are relevant because these are the entities communicating via the IPFIX protocol. However the IPFIX protocol must carry data generated by the metering process. The process of exporting IP flow information is similar to the accounting part of Diameter: The Diameter client sending accounting information is simlar to the IPFIX exporting process sending IP flow information. The Diameter server receiving accounting information is similar to the collecting process receiving IP flow information. Diameter Relay and Proxy Agents are similar to an IPFIX proxy (a Zander expires February 2003 [Page 5] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 combination of collecting and exporting process) as described in section 9 [IPFIX]. The Diameter Translation Agent is similar to the Protocol Converter as described in section 9 [IPFIX]. The metering process and observation point are similar to entities co-located with the Diameter client which collect the accounting information. The IPFIX protocol could be implemented with Diameter similar as a new Diameter accounting application can be defined. [DIAMETER] explicitly describes how new accounting applications can be defined in section 1.2.4. 2.3. Architectural Differences The Diameter architecture has been developed for providing a AAA framework while IPFIX is to be developed for exporting IP flow information. There are no major differences between both architectures. The Diameter architecture is more generic than IPFIX. It supports a number of different proxy types and message routing. Furthermore the functionality of the first two As is not useful for IPFIX. However IPFIX could be viewed as a subset of Diameter similar to the Diameter accounting functionality. The Diameter standard explicitly supports accounting-only Diameter applications. 3. Item Level Compliance Evaluation This section evaluates the compliance of the Diameter protocol with the IPFIX requirements item by item. Requirements are addressed by their section numbers and item numbers in [IPFIX-REQ]. For each requirement it is explained to what degree protocol Diameter meets the requirement and how this is achieved. The degree of compliancy is explicitly stated using five grades: -T Total compliance: The requirement is met completely by the protocol specification without any extensions required. -E Extension required for total compliance: The protocol is prepared to be extended and it is possible to extend it in a way that it meets the requirement. This grade is onLY applicable to protocols that are explicitly open to externally defined extensions, such as SNMP is extended by MIB modules or DIAMETER is extended by application modules. It is not applicable to protocols, where the protocol specification itself needs to be extended in order to comply with the requirement. Zander expires February 2003 [Page 6] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 -P Partial compliance: The requirement is met partially by the protocol specification. -U Upcoming compliance: The requirement is not met or met partially by the protocol specification, but there is a concrete plan for an upcoming version of the protocol. -F Failed compliance: The requirement is not met by the protocol specification. Requirement 4 (Distinguishing Flows): -E The following requirements assumes that Diameter is not only used for exporting IP flow information but also for configuration of the export. In case a different protocol is used for the configuration these requirements do not apply. As Diameter has not been developed for the purpose of IP flow export most of the attributes are not yet defined in the existing data model. To comply to the IPFIX protocol there are several possible options. Either all of the attributes are defined as new AVPs from the defined AVP types (and grouped where appropriate) (see Section 4.3,4.4 [DIAMETER]). Alternatively the existing QoS/IPFilterRule data types can be used and grouped with additional AVPs containing the attributes not yet defined in Diameter (see Section 4.4 [DIAMETER]). A further option is to extend the QoS/IPFilterRule types directly because most of the required attributes are covered already. Requirement 4.1 (Interfaces): -E Incoming interface and outgoing interface can be defined as AVPs. Requirement 4.2 (IP Header): -E Source IP and destination IP address can be defined as new AVPs. Note that Diameter supports both IPv4 and IPv6 addresses. Protocol Type and IP version number can be defined as AVPs. The existing IPFilterRule data type supports source, destination IP, protocol type. It also supports prefix matches of the addresses via masks. Requirement 4.3 (Transport Header): -T/E Source and destination port number can be defined as AVPs. The Zander expires February 2003 [Page 7] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 existing IPFilterRule data type supports ports, list of ports or ranges. Requirement 4.4 (MPLS): -E The MPLs label can be defined as AVP. Requirement 4.5 (DSCP): -T/E The Diffserv Code Point can be defined AVP. The existing QoSFilterRule supports a DSCP attribute. Requirement 4.6 (Header Compression): n/a This imposes no further requirements on the protocol Requirement 5.1 (Reliability): n/a This requirement does not apply to the protocol. Requirement 5.2 (Sampling): -E This requirement is a metering process requirement. However the IPFIX protocol must support to export some information about sampling configuration. New (grouped) AVPs can be defined for carrying the sampling configuration. Requirement 5.3 (Overload Behavior): -E This requirement is a metering process requirement. However some information must be send via the protocol e.g. to indicate overload behavior changes. New AVPs can be defined to signal changes of metering behaviour to the collecting process. Requirement 5.4 (Timestamps): -E This requirement is a metering process requirement. However a candidate protocol must support a proper timestamp format. Diameter does only support the Time data type which is UTC time in seconds. To meet the requirement a new AVP data type must be defined. Alternatively a Time AVP can be used for the seconds and grouped with an additional AVP for the centiseconds. Requirement 5.5 (Time Synchronization): n/a This requirement does not apply to the protocol. Zander expires February 2003 [Page 8] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 Requirement 5.6 (Flow Expiration): n/a This requirement does not apply to the protocol. Requirement 5.7 (Multicast Flows): n/a This requirement does not apply to the protocol. Requirement 5.8 (Ignore Port Copy): n/a This requirement does not apply to the protocol. Requirement 6.1 (Information Model): -E For most of the attributes required there currently exist no defined AVPs. But for all attributes listed AVPs can be easily derived from the base data types. Instead of using existing data types new data types could be defined. Requirement 6.2 (Data Model): -T The data model of Diameter is based on the Attribute Value Pair (AVP) concept. An attribute is identified uniquely by a numeric AVP code and AVP length. A number of base types for AVPs have been defined in [DIAMETER]. The data model of Diameter is extensible because new AVPs and new AVP types can be defined. Diameter supports grouping of AVPs and nesting of grouped AVPs to create more complex structure. The data model is flexible because each Diameter message only has a small fixed size header. After the header arbitrary AVPs (as defined for a message) follow. The data model is independent of the transport (TCP or SCTP are used). Requirement 6.3.1 (Congestion Awareness): -T Diameter uses TCP or SCTP as transport. Both protocols are congestion aware. Requirement 6.3.2 (Reliability): -T Diameter is an application layer protocol which uses TCP [TCP] or SCTP [SCTP] as transport protocols which are both reliable. To support application layer reliability the protocol supports application layer ACKs and error messages. Zander expires February 2003 [Page 9] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 A watch dog mechanism has been defined to detect transport problems and failover and failback procedures have been defined. Diameter also supports capability negotiation between peers which assures that both peers have the same capabilities. Requirement 6.3.3 (Security): -T Diameter provides end-to-end as well as hop-by-hop authentication, integrity and encryption. Some mechanisms are provided by underlying security protocols used such as IPSec or TLS. Since [DIAMETER] specifies how to use them this requirement is considered to be met by the protocol. Please read the security considerations section for more details. Requirement 6.3.4 (Push/Pull Mode): -T Diameter is a peer to peer protocol. The current Diameter accounting model uses the push mode (a Diameter client sends accounting information to a Diameter server). However a Diameter application could be defined which supports a pull mode as well. Requirement 6.4 (Regular Report Interval): -T Diameter can send accounting information in regular intervals. Requirement 6.5 (Event Notification): -T A Diameter peer can send messages at times of events. The events and messages must be defined for the specific application. A Diameter configuration message could configure when to send specific event messages. Currently the Diameter base protocol sends accounting messages at the start and end of a session. Requirement 6.6 (Anonymization): n/a Diameter does not support anonymization. However anonymization is not a protocol specific function and therefore the requirement does not apply to the protocol. A function can be integrated into a Diameter peer which anonymizes certain data before it is exported in AVPs. Requirement 7 (Metering Process Configuration): -E These requirements only apply if Diameter is used for configuration of the metering process. Since Diameter is not a protocol for exporting IP flow information the listed attributes are not specified yet. Since the data model is flexible all attributes can Zander expires February 2003 [Page 10] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 be specified as AVPs. Requirement 8.1 (Openness): -T The Diameter base protocol is open and has an extensibility concept specified in the standard. The flexible AVP model allows to support any information model. New Diameter applications can be created which can define application specific messages and message exchange. Requirement 8.2 (Scalability): -T A Diameter peer is not limited in the number of connections to other peers. In Diameter each peer has a unique identifier which must be present in each message (Origin-Host AVP). Furthermore Diameter uses session IDs to uniquely identify specific sessions. Requirement 8.3 (Several Collecting Processes): -T Diameter accounting records are usually only send to the home server. However there is no limitation in the protocol that restricts sending information to only one destination. Diameter supports duplicate data detection over multiple receivers because each accounting message contains client ID, session ID, timestamp and a sequence number in each message. 4. Security Considerations Security considerations for the IPFIX protocol are covered by the comparison against the specific Security requirements in the IPFIX requirements document [IPFIX-REQ] where they are specifically addressed by sections 6.3.3 and 10. The Diameter base protocol assumes that messages are secured by using either IPSec or TLS. This security model is acceptable in environments where there is no untrusted third party agents. The use of TLS, IPSEC and considerations of peer-to-peer security issues are discussed in the security considerations of [DIAMETER]. In situations of untrusted third party agents, end-to-end security is needed. [DIAM_CMS] describes how a security association is established by two peers through agents, and how authentication, integrity, confidentiality and data origin authentication are achieved using a mixture of symmetric and asymmetric transforms. Zander expires February 2003 [Page 11] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 5. Acknowledgements The authors would like to thank Jari Arkko for his valuable comments on the first version of the draft. 6. References [IPFIX-REQ] J. Quittek et al., "Requirements for IP Flow Information Export", draft-ietf-ipfix-reqs-05.txt, work in progress, July 2002. [DIAMETER] P. Calhoun et al. "Diameter Base Protocol", draft-ietf-aaa- diameter-12.txt, work in progress, July 2002. [AAA_TRANS] B. Aboba at al., "Authentication, Authorization and Accounting (AAA) Transport Profile", draft-ietf-aaa- transport-07.txt, work in progress, April 2002 [DIAM_CMS] P. Calhoun et al., "Diameter CMS Security Application", draft-ietf-aaa-diameter-cms-sec-04.txt, work in progress, March 2002 [TCP] Postel, J., "Transmission Control Protocol", RFC 793, January 1981. [SCTP] R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960. October 2000. [SLP] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Protocol, Version 2", RFC 2165, June 1999. [DIA_SUN] SUN Diameter implementation, http://playground.sun.com/diameter/ [DIA_OS] Diameter Open Source Project, http://sourceforge.net/projects/diameter/ Zander expires February 2003 [Page 12] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002 7. Author's Addresses Sebastian Zander Fraunhofer Institute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49 30 3463 7287 Email: zander@fokus.fhg.de 8. Full Copyright Statement Copyright (C) The Internet Society (2002). 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 implementation 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. Zander expires February 2003 [Page 13] Internet-Draft IPFIX Diameter Protocol Evaluation September 2002