[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
   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