Internet Draft Tom Taylor Document: draft-taylor-midcom-diameter-eval-00.txt Nortel Networks Expires: October 2002 April 2002 Evaluation Of DIAMETER Against MIDCOM Requirements Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document is submitted as part of the Midcom protocol selection process. It evaluates the suitability of the Diameter protocol as a transport for Midcom. The general conclusions are: . the Diameter architecture may be too heavy for the Midcom application, although this is a matter for discussion. It is clear in any event that much of the Diameter base is not needed; . a new application extension to Diameter would have to be defined to meet Midcom's requirements; . with these reservations, the protocol is a good fit to Midcom requirements. Taylor Informational - Expires October 2002 1 Evaluation of Diameter April 2002 against MIDCOM requirements Table of Contents 1. Introduction 1.1 Background The Midcom Working Group has created a set of requirements for a protocol to control Middleboxes [1]. The Working Group is currently evaluating a number of protocols as a basis for development of the Midcom protocol. Diameter [2] is one of the candidates. This document reports on how well Diameter meets the Midcom requirements, using the template provided in [5]. 1.2 Diameter Architecture Diameter is designed to support AAA for network access. It is meant to operate through networks of servers, which both act upon and route messages toward their final destinations. Design requirements [3] include robustness in the face of bursty message loads and server failures, resistance to specific DOS attacks and protection of message contents, and extensibility including support for vendor- specific attributes and message types. The protocol is designed as a base protocol to be supported by all implementations, plus extensions devoted to specific applications. Messages consist of a header and an aggregation of "Attribute-Value Pairs (AVPs)", each of which is a tag-length-value construct. The header includes a command code, which determines the processing of the message and what other AVP types must or may be present. AVPs are strongly typed. Some basic and compound types are provided by the base protocol specification, while others may be added by application extensions. One of the types provided is the IPFilterRule, which may be sufficient to express the Policy Rules that Midcom deals with. Messaging takes the form of request-answer exchanges. The protocol is connection-oriented at both the transport and application levels. In addition, the protocol is tied closely to the idea of sessions, which relate sequences of message exchanges through use of a common session identifier. Each application provides its own definition of the semantics of a session. 1.3 Comparison With MIDCOM Architectural Requirements A general assessment might be that Diameter meets and exceeds Midcom architectural requirements. The connection orientation may be too heavy for the number of relationships the Middlebox must support: this is a point for discussion. Certainly the focus on extensibility, request-response messaging orientation, and treatment of the session, are all well-matched to what Midcom needs. At this point, MIDCOM is focussed on simple point-to-point relationships, so Taylor Informational - Expires October 2002 2 Evaluation of Diameter April 2002 against MIDCOM requirements the networking capabilities provided by Diameter are not needed. Most of the commands and AVPs defined in the base protocol are also surplus to MIDCOM requirements. 2. Detailed Comparison With Requirements <x.x.x> indicates the requirement documented in section x.x.x of [1]. 2.1 Requirements Fully Met <2.1.1> Ability to establish association between Agent and Middlebox. <2.1.2> Agent can relate to multiple Middleboxes. <2.1.3> Middlebox can relate to multiple Agents. <2.1.4> Deterministic outcome when multiple requests are presented to the Middlebox simultaneously. Comment: Diameter depends partly upon the transport protocol to provide flow control when the server becomes heavily loaded. It also has application-layer messaging to indicate that it is too busy or out of space. <2.1.6> Middlebox status report. <2.1.7> Middlebox can generate unsolicited messages. <2.1.8> Mutual authentication. <2.1.9> Termination of session (connection, in Diameter terminology) by either party. <2.1.10> Indication of success or failure. <2.1.11> Version interworking. <2.1.12> Deterministic behaviour in the presence of overlapping rules. Comment: the IPFilterSpec type specification comes with an extensive semantic description. <2.2.1> Extensibility. <2.2.3> Ruleset groups. Comment: Diameter supports the grouped AVP syntactic construct. <2.2.4> Lifetime extension. Taylor Informational - Expires October 2002 3 Evaluation of Diameter April 2002 against MIDCOM requirements Comment: The Diameter concept of a session includes the session lifetime, grace period, and lifetime extension. <2.2.6> Actionable failure reasons. <2.2.7> Multiple Agents operating on the same ruleset. Comment: no impediment in Diameter itself. The Midcom application specification must avoid introducing such an impediment. <2.3.1> Message authentication, confidentiality, and integrity. <2.3.2> Optional confidentiality. <2.3.3> Operation across untrusted domains. <2.3.4> Mitigation of replay attacks. 2.2 Requirements Partially Met <2.1.5> Known and stable state. Comment: Diameter documentation does not discuss the degree of atomicity of message processing, so this would have to be specified in the Midcom extension. <2.2.2> Support of multiple Middlebox types. Comment: any necessary additional AVPs or values must be specified as part of the Midcom application extension (see <2.2.8> below). <2.2.5> Mandatory/optional nature of unknown attributes. Comment: indication of the mandatory or optional status of AVPs is fully supported, provided it is enabled in the AVP definition. No guidance is imposed regarding the return of diagnostic information for optional AVPs. <2.2.8> Transport of filtering rules. Comment: While Diameter defines the promising IPFilterRule data type, there is no existing message which would convey this to a Middlebox along with other Midcom-required attributes. A new Midcom application extension of Diameter would have to be defined. <2.2.9> Mapped port parity. Comment: any necessary additional AVPs or values must be specified as part of the Midcom application extension. <2.2.10> Consecutive range of port numbers. Taylor Informational - Expires October 2002 4 Evaluation of Diameter April 2002 against MIDCOM requirements Comment: any necessary additional AVPs or values must be specified as part of the Midcom application extension. <2.2.11> More precise rulesets contradicting overlapping rulesets. Must be specified as part of the Midcom application extension. 2.3 Requirements Not Met This space for rent. Taylor Informational - Expires October 2002 5 Evaluation of Diameter April 2002 against MIDCOM requirements References 1. R. Swale, P. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox Communications (midcom) Protocol Requirements", draft-ietf- midcom-requirements-05.txt (approved as RFC), November 2001. 2. P. Calhoun, J. Arkko, E. Guttman, G. Zorn, J. Loughney, "Diameter Base Protocol", draft-ietf-aaa-diameter-10.txt, IETF work in progress, April 2002. 3. P. Calhoun, G. Zorn, P. Pan, H. Akhtar, "Diameter Framework Document", draft-ietf-aaa-diameter-framework-01.txt, IETF work in progress, March 2001. 4. P. Calhoun, W. Bulley, A. Rubens, J. Haag, G. Zorn, D. Spence, "Diameter NASREQ Application", draft-ietf-aaa-diameter-nasreq- 09.txt, IETF work in progress, March 2002. 5. M. Barnes, "MIDCOM Protocol Evaluation Template", draft-midcom- protocol-eval-template.txt, March 2002. Author's Addresses Tom Taylor Nortel Networks 1852 Lorraine Ave. Ottawa, Ontario, Phone: +1 613 736 0961 Canada K1H 6Z8 Email: taylor@nortelnetworks.com Taylor Informational - Expires October 2002 6