Internet Draft Tom Taylor Document: draft-taylor-midcom-diameter-eval- Nortel Networks 01.txt 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. This version contains added details describing how to use Diameter to meet the requirements. Taylor Informational - Expires October 2002 1 Evaluation of Diameter April 2002 against MIDCOM requirements 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 Diameter nodes, which both act upon and route messages toward their final destinations. Endpoints are characterized as either clients, which perform network access control, or servers, which handle authentication, authorization and accounting requests for a particular realm. Intermediate nodes perform relay, proxy, redirect, and translation services. Design requirements for the protocol [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 in the base is the IPFilterRule, which may be sufficient to express the Policy Rules that Midcom deals with. Messaging takes the form of request-answer exchanges. Some exchanges may take multiple round-trips to complete. 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. Multiple sessions may be open simultaneously. 1.3 Comparison With MIDCOM Architectural Requirements The Midcom Agent does not perform the functions of a Diameter client, nor does the Middlebox support the functions of a Diameter server. Thus the Midcom application would introduce two new types of endpoints into the Diameter architecture. Moreover, the Midcom Taylor Informational - Expires October 2002 2 Evaluation of Diameter April 2002 against MIDCOM requirements requirements do not at this time imply any type of intermediate node. 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 the proxying and forwarding 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. ---------------------------------------------------------- Although this is out of scope, the Diameter specification describes several ways to discover a peer. Having done so, a Diameter node establishes a transport connection (TCP, TLS, or SCTP) to the peer. The two peers then exchange Capability Exchange Request/Answer messages to identify each other and determine the Diameter applications each supports. If the connection between two peers is lost, Diameter prescribes procedures whereby it may be re-established. To ensure that loss of connectivity is detected quickly, Diameter provides the Device- Watchdog Request/Answer messages, to be used when traffic between the two peers is low. Diameter provides an extensive state machine to govern the relationship between two peers. <2.1.2> Agent can relate to multiple Middleboxes. ------------------------------------------------- Diameter allows connection to more than one peer (and encourages this for improved reliability). Whether the Diameter connection state machine is too heavy to support the number of connections needed is a matter for discussion. Taylor Informational - Expires October 2002 3 Evaluation of Diameter April 2002 against MIDCOM requirements <2.1.3> Middlebox can relate to multiple Agents. ------------------------------------------------ See previous answer. The Middlebox and Agent play symmetric roles as far as Diameter peering is concerned. <2.1.4> Deterministic outcome when multiple requests are presented to the Middlebox simultaneously. ------------------------------------------------------------------ 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 (DIAMETER_TOO_BUSY and DIAMETER_OUT_OF_SPACE result codes). <2.1.6> Middlebox status report. -------------------------------- Diameter provides a number of response codes by means of which a server can indicate error conditions reflecting status of the server as a whole. The Disconnect-Peer-Request provides a means in the extreme case to terminate a connection with a peer gracefully, informing the other end about the reason for the disconnection. <2.1.7> Middlebox can generate unsolicited messages. ---------------------------------------------------- The Diameter protocol permits either peer in a connection to originate transactions. Thus the protocol supports Middlebox- originated messages. <2.1.8> Mutual authentication. ------------------------------ The Diameter base protocol assumes that messages are secured by using either IP Security or TLS. Diameter requires that when using the latter, peers must mutually authenticate themselves. <2.1.9> Termination of session (connection, in Diameter terminology) by either party. -------------------------------------------------------------------- Either peer in a connection may issue a Disconnect-Peer-Request to end the connection gracefully. <2.1.10> Indication of success or failure. ------------------------------------------ Every Diameter request is matched by a response, and this response contains a result code as well as other information. Taylor Informational - Expires October 2002 4 Evaluation of Diameter April 2002 against MIDCOM requirements <2.1.11> Version interworking. ------------------------------ The Capabilities Exchange Request/Answer allows two peers to determine information about what each supports, including protocol version and specific applications. <2.1.12> Deterministic behaviour in the presence of overlapping rules. --------------------------------------------------------------- The IPFilterRule type specification, which would probably be used as the type of a Policy Rule AVP, comes with an extensive semantic description which provides for a deterministic outcome, but one which the individual Agent cannot know unless it knows all of the Policy Rules installed on the Middlebox. The IPFilterRule type is defined in [2] as follows: IPFilterRule The IPFilterRule format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. Packets may be filtered based on the following information that is associated with it: Direction (in or out) Source and destination IP address (possibly masked) Protocol Source and destination port (lists or ranges) TCP flags IP fragment flag IP options ICMP types Rules for the appropriate direction are evaluated in order, with the first matched rule terminating the evaluation. Each packet is evaluated once. If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny. IPFilterRule filters MUST follow the format: action dir proto from src to dst [options] action permit - Allow packets that match the rule. deny - Drop packets that match the rule. dir "in" is from the terminal, "out" is to the terminal. proto An IP protocol specified by number. The "ip" keyword means any protocol will match. Taylor Informational - Expires October 2002 5 Evaluation of Diameter April 2002 against MIDCOM requirements src and dst <address/mask> [ports] The <address/mask> may be specified as: ipno An IPv4 or IPv6 number in dotted- quad or canonical IPv6 form. Only this exact IP number will match the rule. ipno/bits An IP number as above with a mask width of the form 1.2.3.4/24. In this case, all IP numbers from 1.2.3.0 to 1.2.3.255 will match. The bit width MUST be valid for the IP version and the IP number MUST NOT have bits set beyond the mask. For a match to occur, the same IP version must be present in the packet that was used in describing the IP address. To test for a particular IP version, the bits part can be set to zero. The keyword "any" is 0.0.0.0/0 or the IPv6 equivalent. The keyword "assigned" is the address or set of addresses assigned to the terminal. For IPv4, a typical first rule is often "deny in ip! assigned" The sense of the match can be inverted by preceding an address with the not modifier (!), causing all other addresses to be matched instead. This does not affect the selection of port numbers. With the TCP, UDP and SCTP protocols, optional ports may be specified as: {port|port-port}[,ports[,...]] The '-' notation specifies a range of ports (including boundaries). Fragmented packets that have a non-zero offset (i.e. not the first fragment) will never match a rule that has one or more port specifications. See the frag option for details on matching fragmented packets. options: frag Match if the packet is a fragment and this is not Taylor Informational - Expires October 2002 6 Evaluation of Diameter April 2002 against MIDCOM requirements the first fragment of the datagram. frag may not be used in conjunction with either tcpflags or TCP/UDP port specifications. ipoptions spec Match if the IP header contains the comma separated list of options specified in spec. The supported IP options are: ssrr (strict source route), lsrr (loose source route), rr (record packet route) and ts (timestamp). The absence of a particular option may be denoted with a '!'. tcpoptions spec Match if the TCP header contains the comma separated list of options specified in spec. The supported TCP options are: mss (maximum segment size), window (tcp window advertisement), sack (selective ack), ts (rfc1323 timestamp) and cc (rfc1644 t/tcp connection count). The absence of a particular option may be denoted with a '!'. established TCP packets only. Match packets that have the RST or ACK bits set. setup TCP packets only. Match packets that have the SYN bit set but no ACK bit. tcpflags spec TCP packets only. Match if the TCP header contains the comma separated list of flags specified in spec. The supported TCP flags are: fin, syn, rst, psh, ack and urg. The absence of a particular flag may be denoted with a '!'. A rule that contains a tcpflags specification can never match a fragmented packet that has a non-zero offset. See the frag option for details on matching fragmented packets. icmptypes types ICMP packets only. Match if the ICMP type is in the list types. The list may be specified as any combination of ranges or individual types separated by commas. Both the numeric values and the symbolic values listed below can be used. The supported ICMP types are: echo reply (0), destination unreachable (3), Taylor Informational - Expires October 2002 7 Evaluation of Diameter April 2002 against MIDCOM requirements source quench (4), redirect (5), echo request (8), router advertisement (9), router solicitation (10), time-to-live exceeded (11), IP header bad (12), timestamp request (13), timestamp reply (14), information request (15), information reply (16), address mask request (17) and address mask reply (18). There is one kind of packet that the access device MUST always discard, that is an IP fragment with a fragment offset of one. This is a valid packet, but it only has one use, to try to circumvent firewalls. An access device that is unable to interpret or apply a deny rule MUST terminate the session. An access device that is unable to interpret or apply a permit rule MAY apply a more restrictive rule. An access device MAY apply deny rules of its own before the supplied rules, for example to protect the access device owner's infrastructure. The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the ipfw.c code may provide a useful base for implementations. <2.2.1> Extensibility. ---------------------- Diameter provides a great deal of flexibility for extensions, including allowance for vendor-defined commands and AVPs and the ability to flag each AVP as must-understand or ignorable if not understood. <2.2.3> Ruleset groups. ----------------------- Diameter allows message syntax definitions where multiple instances of the same AVP (for example, a Policy Rule AVP whose syntax and low-level semantics are defined by the IPFilterRule type definition) may be present. If a tighter grouping is required, the set of Diameter base types includes the Grouped type. Midcom can choose how to make use of these capabilities to meet the rulreset group requirement when defining its application extension to the Diameter protocol as discussed below. <2.2.4> Lifetime extension. --------------------------- The Diameter concept of a session includes the session lifetime, grace period, and lifetime extension. It may make sense to associate the Diameter session with the lifetime of a Midcom Policy Rule, in which case support for lifetime extension comes ready-made. Taylor Informational - Expires October 2002 8 Evaluation of Diameter April 2002 against MIDCOM requirements <2.2.6> Actionable failure reasons. ----------------------------------- Diameter provides an extensive set of failure reasons in the base protocol. <2.2.7> Multiple Agents operating on the same ruleset. ------------------------------------------------------ Diameter itself offers no impediment to such an operation. The Midcom application specification must avoid introducing such an impediment. <2.2.11> More precise rulesets contradicting overlapping rulesets. ------------------------------------------------------------------ Allowed by the IPFilterRule semantics described above. <2.3.1> Message authentication, confidentiality, and integrity. --------------------------------------------------------------- Diameter relies on either IPSEC or TLS for these functions. <2.3.2> Optional confidentiality. --------------------------------- Implementation support of IPSEC ESP in Diameter applications is not optional. Deployment of either IPSEC or TLS is optional. <2.3.3> Operation across untrusted domains. ------------------------------------------- The Diameter specification [2] recommends the use of TLS across untrusted domains. <2.3.4> Mitigation of replay attacks. ------------------------------------- Diameter requires that implementations support the replay protection mechanisms of IPSEC. 2.2 Requirements Partially Met Requirements have been placed here in most cases because it will be necessary to define a Midcom application extension of Diameter, and the satisfaction of the requirements depends on proper definition of the messages and AVPs in that extension. Taylor Informational - Expires October 2002 9 Evaluation of Diameter April 2002 against MIDCOM requirements <2.1.5> Known and stable state. ------------------------------- 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. -------------------------------------------- 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. -------------------------------------------------------- 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. ------------------------------------- While Diameter defines the promising IPFilterRule data type (see 2.1.12 above), 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. --------------------------- This capability is not part of the current IPFilterRule type definition. Rather than modify the IPFilterRule type, Midcom could group it with other AVPs which add the missing information. <2.2.10> Consecutive range of port numbers. ------------------------------------------- This capability is not part of the current IPFilterRule type definition. Rather than modify the IPFilterRule type, Midcom could group it with other AVPs which add the missing information. 2.3 Requirements Not Met None. Taylor Informational - Expires October 2002 10 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 11