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

Versions: 00 01 02 03 04 05                                             
INTERNET DRAFT                                            Pat R. Calhoun
Category: Informational                                     Erik Guttman
Title: draft-calhoun-diameter-impl-guide-00.txt   Sun Microsystems, Inc.
Date: December 1999                                      Allan C. Rubens
                                                       Tut Systems, Inc.
                                                           Haseeb Akhtar
                                                         Nortel Networks
                                                          William Bulley
                                                     Merit Network, Inc.
                                                               Jeff Haag
                                                           Cisco Systems



                   DIAMETER Implementation Guidelines



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.

   This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the diameter@ipass.com mailing list.

   Distribution of this memo is unlimited.

   Copyright   (C) The Internet Society 1999.  All Rights Reserved.





Calhoun et al.              expires May 2000                    [Page 1]


INTERNET DRAFT                                             December 1999


Abstract

   The DIAMETER protocol is used for Authentication, Authorization and
   Accounting (AAA) for Mobile-IP and NASREQ. This document contains
   implementation guidelines that may be useful to DIAMETER protocol
   developers.


Table of Contents

      1.0  Introduction
      2.0  Base Protocol
            2.1  Acknowledgment Timeouts
                  2.1.1  Calculating Adaptive Acknowledgment Timeout
                  2.1.2  Flow Control: Adjusting for Timeout
            2.2  Examples of sequence numbering
                  2.2.1  Lock-step tunnel establishment
                  2.2.2  Multiple messages acknowledged
                  2.2.3  Lost message with retransmission
            2.3  Backward Compatibility with RADIUS
            2.4  Delayed Acknowledgement Optimization
            2.5  Device-Reboot-Ind Message Flow
            2.6  Device-Watchdog-Ind Message Flow
            2.7  Message-Reject-Ind Message Flow
            2.8  Peer Fail-Over and Load Balancing
            3.0  NASREQ Extension
            3.1  EAP Retransmission and Timer
            3.2  Example of an EAP OTP Authentication
                  3.2.1  Successful Authentication
                  3.2.2  NAS Initiated EAP Authentication
                  3.2.3  Server-Initiated Authentication
                  3.2.4  Example of failed EAP Authentication
                  3.2.5  Example of DIAMETER Server not supporting EAP
                  3.2.6  Example of DIAMETER Proxy not supporting EAP
                  3.2.7  Example of PPP Client not supporting EAP
      4.0  References
      5.0  Acknowledgements
      5.0  Author's Addresses
      6.0  Full Copyright Statement












Calhoun et al.              expires May 2000                    [Page 2]


INTERNET DRAFT                                             December 1999


1.0  Introduction

   The DIAMETER protocol is used for Authentication, Authorization and
   Accounting (AAA) for Mobile-IP and NASREQ. This document contains
   implementation guidelines that may be useful to DIAMETER protocol
   developers.

   This specification contains implementation guidelines for both the
   DIAMETER base protocol [2] and the NASREQ extension [3].


2.0 Base Protocol

   This section contains implementation guidelines for the DIAMETER Base
   protocol [2].


2.1  Acknowledgment Timeouts

   DIAMETER uses sliding windows and timeouts to provide flow-control
   across the underlying medium and to perform efficient data buffering
   to keep two DIAMETER peers' receive window full without causing
   receive buffer overflow. DIAMETER requires that a timeout be used to
   recover from dropped messages.

   When the timeout for a peer expires, the previously transmitted
   message with Ns value equal to the highest in-sequence value of Nr
   received from the peer is retransmitted. The receiving peer does not
   advance its value for the receive sequence number state, Sr, until it
   receives a message with Ns equal to its current value of Sr.

   This rule assures that all subsequent acknowledgements to this peer
   will contain an Nr value equal to the Ns value of the first missing
   message until a message with the missing Ns value is received.

   The exact implementation of the acknowledgment timeout is vendor-
   specific.  It is suggested that an adaptive timeout be implemented
   with back-off for flow control.  The timeout mechanism proposed here
   has the following properties:

      Independent timeouts for each peer.  A device will have to
      maintain and calculate timeouts for every active peer.

      An administrator-adjustable maximum timeout, MaxTimeOut, unique to
      each device.

      An adaptive timeout mechanism that compensates for changing
      throughput.  To reduce message processing overhead, vendors may



Calhoun et al.              expires May 2000                    [Page 3]


INTERNET DRAFT                                             December 1999


      choose not to recompute the adaptive timeout for every received
      acknowledgment.  The result of this overhead reduction is that the
      timeout will not respond as quickly to rapid network changes.

      Timer back-off on timeout to reduce congestion.  The backed-off
      timer value is limited by the configurable maximum timeout value.
      Timer back-off is done every time an acknowledgment timeout
      occurs.

   In general, this mechanism has the desirable behavior of quickly
   backing off upon a timeout and of slowly decreasing the timeout value
   as messages are delivered without errors.


2.1.1  Calculating Adaptive Acknowledgment Timeout

   We must decide how much time to allow for acknowledgments to return.
   If the timeout is set too high, we may wait an unnecessarily long
   time for dropped messages.  If the timeout is too short, we may time
   out just before the acknowledgment arrives.  The acknowledgment
   timeout should also be reasonable and responsive to changing network
   conditions.

   The suggested adaptive algorithm detailed below is based on the TCP
   1989 implementation and is explained in Richard Steven's book TCP/IP
   Illustrated, Volume 1 (page 300).  'n' means this iteration of the
   calculation, and 'n-1' refers to values from the last calculation.

      DIFF[n] = SAMPLE[n] - RTT[n-1]
      DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1]))
      RTT[n] = RTT[n-1] + (alpha * DIFF[n])
      ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)

   DIFF represents the error between the last estimated round-trip time
   and the measured time.  DIFF is calculated on each iteration.

   DEV is the estimated mean deviation.  This approximates the standard
   deviation.  DEV is calculated on each iteration and stored for use in
   the next iteration.  Initially, it is set to 0.

   RTT is the estimated round-trip time of an average message.  RTT is
   calculated on each iteration and stored for use in the next
   iteration.  Initially, it is set to PPD.

   ATO is the adaptive timeout for the next transmitted message.  ATO is
   calculated on each iteration.  Its value is limited, by the MIN
   function, to be a maximum of the configure MaxTimeOut value.




Calhoun et al.              expires May 2000                    [Page 4]


INTERNET DRAFT                                             December 1999


   Alpha is the gain for the round trip estimate error and is typically
   1/8 (0.125).

   Beta is the gain for the deviation and is typically 1/4 (0.250).

   Chi is the gain for the timeout and is typically set to 4.

   To eliminate division operations for fractional gain elements, the
   entire set of equations can be scaled.  With the suggested gain
   constants, they should be scaled by 8 to eliminate all division.  To
   simplify calculations, all gain values are kept to powers of two so
   that shift operations can be used in place of multiplication or
   division.  The above calculations are carried out each time an
   acknowledgment is received for a message that was not retransmitted
   (no timeout occurred).


2.1.2  Flow Control: Adjusting for Timeout

   This section describes how the calculation of ATO is modified in the
   case where a timeout does occur.  When a timeout occurs, the timeout
   value should be adjusted rapidly upward. To compensate for shifting
   internetwork time delays, a strategy must be employed to increase the
   timeout when it expires.  A simple formula called Karn's Algorithm is
   used in TCP implementations and may be used in implementing the
   back-off timers for the DIAMETER peers.  Notice that in addition to
   increasing the timeout, we also shrink the size of the window as
   described in the next section.


   Karn's timer back-off algorithm, as used in TCP, is:

      NewTIMEOUT = delta * TIMEOUT

      Adapted to our timeout calculations, for an interval in which a
      timeout occurs, the new timeout interval ATO is calculated as:

      RTT[n] = delta * RTT[n-1]
      DEV[n] = DEV[n-1]
      ATO[n] = MIN (RTT[n] + (chi * DEV[n]), MaxTimeOut)

   In this modified calculation of ATO, only the two values that
   contribute to ATO and that are stored for the next iteration are
   calculated.  RTT is scaled by delta, and DEV is unmodified.  DIFF is
   not carried forward and is not used in this scenario.  A value of 2
   for Delta, the timeout gain factor for RTT, is suggested.





Calhoun et al.              expires May 2000                    [Page 5]


INTERNET DRAFT                                             December 1999


2.2  Examples of sequence numbering

   This appendix uses several common scenarios to illustrate how
   sequence number state progresses and is interpreted.


2.2.1  Lock-step session establishment

   In this example, a DIAMETER host establishes communication with a
   peer, with the exchange involving each side alternating in the
   sending of messages.  This example is contrived, in that the final
   acknowledgement typically would be included in the Device-Watchdog-
   Ind message.

        DIAMETER Host A                             DIAMETER Host B
             ->    Device-Reboot-Ind
                   Nr: 0, Ns: 0

                                                 (ZLB)   <-
                                          Nr: 1, Ns: 0

             ->    Device-Watchdog-Ind
                   Nr: 0, Ns: 1

             (delay)

                                                 (ZLB)    <-
                                          Nr: 2, Ns: 0


2.2.2  Multiple messages acknowledged

   This example shows a flow of messages from DIAMETER Host B to Host A,
   with Host A having no traffic of its own. Host A is waiting 1/4 of
   its timeout interval, and then acknowledging all messages seen since
   the last interval.















Calhoun et al.              expires May 2000                    [Page 6]


INTERNET DRAFT                                             December 1999


        DIAMETER Host A                             DIAMETER Host B
              (previous message flow precedes this)

              ->    (ZLB)
                    Nr: 7000, Ns: 1000
                                             (non-ZLB)    <-
                                    Nr: 1000, Ns: 7000
                                             (non-ZLB)    <-
                                    Nr: 1000, Ns: 7001
                                             (non-ZLB)    <-
                                    Nr: 1000, Ns: 7002

              (Host A's timer indicates it  should  acknowledge  pending
        traffic)

              ->    (ZLB)
                    Nr: 7003, Ns: 1000


2.2.3  Lost message with retransmission

   Host A attempts to communicate with Host B. The Device-Reboot-Ind
   sent from B to A is lost and must be retransmitted by Host B.




























Calhoun et al.              expires May 2000                    [Page 7]


INTERNET DRAFT                                             December 1999


        DIAMETER Host A                             DIAMETER Host B
             ->    Device-Reboot-Ind
                   Nr: 0, Ns: 0

                       (message lost) Device-Reboot-Ind    <-
                                          Nr: 1, Ns: 0

             (pause; Host A's timer started first, so fires first)

             ->    Device-Reboot-Ind
                   Nr: 0, Ns: 0

             (Host B realizes it has already seen this message)
             (Host B might use this as a cue to retransmit, as  in  this
        example)

                                     Device-Reboot-Ind    <-
                                          Nr: 1, Ns: 0
             ->    Device-Watchdog-Ind
                   Nr: 1, Ns: 1

             (delay)

                                                 (ZLB)    <-
                                          Nr: 2, Ns: 1


2.3  Backward Compatibility with RADIUS

   The DIAMETER protocol was designed with RADIUS [1] compatibility in
   mind.  A DIAMETER node MAY listen for incoming RADIUS and DIAMETER
   packets on the same UDP port. The first octet in the message would
   indicate whether the message is of type RADIUS or DIAMETER.

   The RADIUS protocol defines a one octet attribute space, and the
   DIAMETER protocol reserves the first 255 attribute identifiers to be
   the same as those defined in RADIUS. This allows DIAMETER servers to
   easily perform protocol conversion, since an additional dictionary
   lookup would not be necessary in order to map a RADIUS attribute to a
   DIAMETER AVP.

   By re-using the RADIUS attribute space, a DIAMETER server could
   easily read a typical RADIUS user profile without any additional
   conversions.  This reduces the need to create duplicate user profiles
   for both protocols, and also does not require any database conversion
   while reading the profiles.





Calhoun et al.              expires May 2000                    [Page 8]


INTERNET DRAFT                                             December 1999


2.4  Delayed Acknowledgement Optimization

   This optimization will potentially reduce the amount of traffic sent
   between DIAMETER peers.  This optimization affects when
   acknowledgments are sent, as presented in Section 3.1 of [2].

   If a peer does not have a message queued to transmit at the time a
   non-ZLB message is received then it should delay a short time before
   sending a ZLB message containing the latest values of Sr and Ss, as
   described above.  This short delay is to allow for the possible
   arrival of a message to be transmitted back to its peer, thus
   avoiding the need to issue a ZLB. The suggested value for this time
   delay is 1/4 the receiving peer's value of Round-Trip-Time (RTT - see
   Appendix A), if it computes RTT, or a maximum of 1/2 of its fixed
   acknowledgment timeout interval otherwise. This timeout should
   provide a reasonable opportunity for the receiving peer to obtain a
   payload message destined for its peer, upon which the ACK of the
   received message MAY be piggybacked. Note that if a peer's window is
   full, it MAY advertise an older Nr value if it is not ready to accept
   new messages.

   This delay value should be treated as a suggested maximum; an
   implementation could make this delay quite small without adversely
   affecting the protocol. The default time delay is 2 seconds. To
   provide for better throughput, the receiving peer should skip this
   delay entirely and send a ZLB message immediately in the case where
   its receive window is filled and it has no queued data to send for
   this connection or it can't send queued data because the transmit
   window is closed.


2.5  Device-Reboot-Ind Message Flow

   The following figure depicts a sample flow of Device-Reboot-Ind
   between three DIAMETER peers, one being a proxy or broker server. In
   this example DIA1 initiates the bootstrap sequence with DIA2, and
   later DIA3 initiates the bootstrap sequence with DIA2. After some
   time DIA1 needs to reboot and informs DIA2. The details of each
   message is provided below.












Calhoun et al.              expires May 2000                    [Page 9]


INTERNET DRAFT                                             December 1999


           +-------+            +-------+           +-------+
           | DIA1  |            | PROXY |           | DIA3  |
           |       |            | DIA2  |           |       |
           +-------+            +-------+           +-------+
               |                    |                   |
               |DRI (ns=0, nr=0)    |                   |
               |  Rebooted          |                   |
               |  version 1,        |                   |
               |  extensions 1, 4   |                   |
          (a)  |------------------->|                   |
               |DRI (ns=0, nr=1)    |                   |
               |  Rebooted          |                   |
               |  version 1,        |                   |
               |  extension 1       |                   |
          (b)  |<-------------------|                   |
               |ZLB (ns=0, nr=1)    |                   |
          (c)  |------------------->|                   |
               |         .          |DRI (ns=0, nr=0)   |
               |         .          |  Rebooted         |
               |                    |  version 1,       |
               |                    |  extensions 1, 2  |
          (d)  |                    |<------------------|
               |                    |DRI (ns=0, nr=1)   |
               |                    |  Rebooted         |
               |                    |  version 1,       |
               |                    |  extension 1      |
          (e)  |                    |------------------>|
               |                    |ZLB (ns=0, nr=1)   |
          (f)  |                    |<------------------|
               |DRI (ns=x, nr=y)    |         .         |
               |  Upcoming Reboot   |         .         |
          (g)  |------------------->|                   |
               |         .          |                   |
               |         .          |                   |
               |DRI (ns=0, nr=0)    |                   |
               |  Rebooted          |                   |
               |  version 1,        |                   |
               |  extensions 1, 4   |                   |
          (h)  |------------------->|                   |
               |                    |                   |
         Figure 1: Sample DRI Message Flow in a Proxy Environment

      (a) DIA1 sends a DRI message to DIA2 indicating that its version
          is one (1) and that its supported extensions are 1 (Roamops)
          and 4 (Mobile-IP).

      (b) DIA2 sends a DRI message to DIA1 indicating that its version
          is one (1) and that its supported extension is 1 (Roamops).



Calhoun et al.              expires May 2000                   [Page 10]


INTERNET DRAFT                                             December 1999


          This message also includes a piggy-backed acknowledgement of
          (a).

      (c) DIA1 sends an acknowledgement of (b)

      (d) DIA3 sends a DRI message to DIA2 indicating that its version
          is one (1) and that its supported extensions are 1 (Roamops)
          and 2 (Secure Proxy).

      (e) DIA2 sends a DRI message to DIA3 indicating that its version
          is one (1) and that its supported extension is 1 (Roamops).
          This message also includes a piggy-backed acknowledgement of
          (d).

      (f) DIA3 sends an acknowledgement of (e)

      (g) after some time DIA1 sends an indication to DIA2 that it is
          about to reboot. All messages destined to the domain for which
          DIA1 is responsible for should be redirected to an alternate
          DIAMETER Server.

      (h) Once the reboot is complete, DIA sends the DRI, which causes
          steps (a) through (c) to be repeated.


2.6  Device-Watchdog-Ind Message Flow

   The following figure provides an example of how the Device-Watchdog-
   Ind message is used in a proxy environment. The details of each
   message is provided below.





















Calhoun et al.              expires May 2000                   [Page 11]


INTERNET DRAFT                                             December 1999


           +-------+            +-------+            +-------+
           | DIA1  |            | PROXY |            | DIA3  |
           |       |            | DIA2  |            |       |
           +-------+            +-------+            +-------+
               |                    |                    |
               |CMD-X (ns=23, nr=40)|                    |
          (a)  |------------------->|                    |
               |ZLB (ns=40, nr=24)  |                    |
          (b)  |<-------------------|                    |
               |         .          |                    |
               |         .          |                    |
               |                    |CMD-Y (ns=12, nr=20)|
          (c)  |                    |------------------->|
               |                    |ZLB (ns=20, nr=13)  |
          (d)  |                    |<-------------------|
               |WDI (ns=24, nr=40)  |          .         |
          (e)  |------------------->|          .         |
               |ZLB (ns=40, nr=25)  |                    |
          (f)  |<-------------------|                    |
               |                    |WDI (ns=21, nr=13)  |
          (g)  |                    |<-------------------|
               |                    |ZLB (ns=13, nr=22)  |
          (h)  |                    |------------------->|
               |                    |                    |
            Figure 2: Sample WDI Message in a Proxy Environment

      (a) DIA1 issues a message to DIA2

      (b) DIA2 acknowledges the receipt of (a)

      (c) DIA2 issues a message to DIA3

      (d) DIA3 acknowledges the receipt of (c)

      (e) After some time of inactivity, DIA1 issues a WDI to DIA2

      (f) DIA2 acknowledges the receipt of (e)

      (g) After some period of inactivity, DIA3 issues a WDI to DIA2

      (h) DIA2 acknowledges the receipt of (g)


2.7  Message-Reject-Ind Message Flow

   The following figure show sample flows of MRI command between two
   DIAMETER peers. In this example DIA1 and DIA2 servers generates error
   messages. The details of the messages are provided below.



Calhoun et al.              expires May 2000                   [Page 12]


INTERNET DRAFT                                             December 1999


       +-------+                             +-------+
       | DIA1  |                             | DIA2  |
       +-------+                             +-------+
           |                                     |
           |Unknown command                      |
      (a)  |------------------------------------>|
           |MRI, err=DIAMETER_COMMAND_UNSUPPORTED|
      (b)  |<------------------------------------|
           |                 .                   |
           |                 .                   |
           |Unknown AVP                          |
      (c)  |<------------------------------------|
           |MRI, err=DIAMETER_AVP_UNSUPPORTED    |
      (d)  |------------------------------------>|
           |                 .                   |
           |                 .                   |
           |Bad value in a valid AVP             |
      (e)  |------------------------------------>|
           |MRI, err=DIAMETER_INVALID_AVP_VALUE  |
      (f)  |<------------------------------------|
                     Figure 3: Sample MRI Message Flow

      (a) DIA2 receives an unknown command from DIA1.

      (b) DIA2 recognizes that it received an unknown command and hence
          sends an MRI with the Result-Code AVP set to
          DIAMETER_COMMAND_UNSUPPORTED and the Command-Code AVP
          encapsulated within the Failed-AVP AVP.

      (c) DIA1 receives an unknown AVP in a message sent by DIA2.

      (d) DIA1 recognizes that it received an unknown AVP and returns an
          MRI with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED
          and the offending AVP encapsulated within a Failed-AVP AVP.

      (e) DIA2 receives a bad parameter within a otherwise valid AVP
          from DIA1.

      (f) As soon as it discovers that it has received a bad parameter,
          it returns an MRI message to DIA1 with the Result-Code AVP set
          to DIAMETER_INVALID_AVP_VALUE and the offending AVP
          encapsulated within a Failed-AVP AVP.


2.8  Peer Fail-Over and Load Balancing

   Although not a function of the DIAMETER protocol, in some networks it
   is desirable to ensure resilient service by providing alternate



Calhoun et al.              expires May 2000                   [Page 13]


INTERNET DRAFT                                             December 1999


   peers, should communication with a peer fail. Figure 4 provides an
   example of such a network, where the client communicates with one of
   two servers providing proxying services. The proxy servers, in turn,
   communicate with one of two servers in the home domain.

                                          +--------+
                                          |  DIAM  |
                                          | Primary|
                       +--------+         |  Home  |
                       |  DIAM  +---------+ Server +----+
                       | Primary|         +--------+    |
     +--------+        | Proxy  |         +--------+    |
     |        +--------+ Server +---------+  DIAM  |    |
     |  DIAM  |        +--------+         |Alternat|    |
     | Client |        +--------+         |  Home  |    |
     |        +--------+  DIAM  +---------+ Server |    |
     +--------+        |Alternat|         +--------+    |
                       | Proxy  |                       |
                       | Server +-----------------------+
                       +--------+
                   Figure 4: Redundant DIAMETER Servers

   Each node in the network MUST know a priori about its communicating
   peers, and each peer MAY have a relative priority, forcing all
   traffic to be sent through a preferred server, if it is available.
   When a node detects that a communicating peer is no longer available,
   it MUST attempt to redirect all traffic (including the packets in the
   retransmission queue destined for the former peer) to the new peer.
   It is possible that an alternate path not exist, such would be the
   case if the DIAMETER Client was no longer reachable. In this case,
   the DIAMETER proxy servers SHOULD drop all responses directed to the
   client, and MUST respond to all requests directed to the client with
   an appropriate Result Code.

   An implementation MAY also make use of the multiple peer arrangement
   described above to balance the load between a set of peers. A clever
   implementation MAY also redirect traffic to an alternate peer when it
   detects that its primary communicating peer's window is full.


3.0  NASREQ Extension

   This section contains implementation guidelines for the NASREQ
   DIAMETER Extension [3].


3.1  EAP Retransmission and Timers




Calhoun et al.              expires May 2000                   [Page 14]


INTERNET DRAFT                                             December 1999


   As noted in [4], the EAP authenticator (NAS) is responsible for
   retransmission of packets between the authenticating peer and the
   NAS.  Thus if an EAP packet is lost in transit between the
   authenticating peer and the NAS (or vice versa), the NAS will
   retransmit. As defined in the base protocol [2], a DIAMETER node is
   responsible to retransmit all packets with its peer.

   Note that it may be necessary to adjust authentication timeouts in
   certain cases. For example, when a token card is used additional time
   may be required to allow the user to find the card and enter the
   token. Since the NAS will typically not have knowledge of the
   required parameters, these need to be provided by the DIAMETER
   server. This can be accomplished by inclusion of the Idle-Timeout in
   the DIAMETER-EAP-Answer message.


3.2  Example of an EAP OTP Authentication

   This section provides sample messages exchanges between an
   Authenticating Peer, which is typically a dial-up PPP client, a NAS
   and a DIAMETER server.  The protocol used between the Dial-up PPP
   client and the NAS is EAP over PPP as defined in [4]. The protocol
   between the NAS and the DIAMETER Server is EAP encapsulated within
   DIAMETER, as described in this specification.

   For all PPP packets, the messages are formatted as:
         [LCP Packet Type]
         [EAP Packet Type]/[EAP Payload]

   For all DIAMETER packets, the messages are formatted as:
         [DIAMETER Command Code]/[EAP Packet Type]/[EAP Payload]

   In the example provided below, the PPP client attempts to
   authenticate using a One-Time-Password [5] encapsulated within EAP
   [4].


3.2.1  Successful Authentication

   The example below shows the conversation between the authenticating
   peer, NAS, and server, for the case of a One Time Password (OTP)
   authentication. OTP is used only for illustrative purposes; other
   authentication protocols could also have been used, although they
   would show somewhat different behavior.







Calhoun et al.              expires May 2000                   [Page 15]


INTERNET DRAFT                                             December 1999


      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                            <- PPP LCP Request-EAP
                            auth
      PPP LCP ACK-EAP
      auth ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/Start ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-
  Payload/Identity
                            <- PPP EAP-Request/
                            Identity
      PPP EAP-Response/
      Identity (MyID) ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/
                            EAP-Response/
                            (MyID) ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload/EAP-
  Request
                                                     OTP/OTP Challenge
                            <- PPP EAP-Request/
                            OTP/OTP Challenge
      PPP EAP-Response/
      OTP, OTPpw ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/
                            EAP-Response/
                            OTP, OTPpw ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload/EAP-
  Success
                                                     (other AVPs)
                            <- PPP EAP-Success
      PPP Authentication
      Phase complete,
      NCP Phase starts





Calhoun et al.              expires May 2000                   [Page 16]


INTERNET DRAFT                                             December 1999


3.2.2:  NAS Initiated EAP Authentication

   In the case where the NAS sends the authenticating peer an EAP-
   Request/Identity packet without first sending an EAP-Start packet to
   the DIAMETER server, the conversation would appear as follows:

      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------


                            <- PPP LCP Request-EAP
                            auth
      PPP LCP ACK-EAP
      auth ->
                            <- PPP EAP-Request/
                            Identity
      PPP EAP-Response/
      Identity (MyID) ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/
                            EAP-Response/
                            (MyID) ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload/EAP-Request
                                                     OTP/OTP Challenge
                            <- PPP EAP-Request/
                            OTP/OTP Challenge
      PPP EAP-Response/
      OTP, OTPpw ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/
                            EAP-Response/
                            OTP, OTPpw ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload/EAP-Success
                                                     (other AVPs)
                            <- PPP EAP-Success
      PPP Authentication
      Phase complete,
      NCP Phase starts


  3.2.3:  Server-Initiated Authentication




Calhoun et al.              expires May 2000                   [Page 17]


INTERNET DRAFT                                             December 1999


   As described in [6], when a server has successfully authenticated and
   authorized a user, it may include a timeout period to the
   authorization.  The server can later initiate an unsolicited re-
   authentication request to the user, through the NAS. This method has
   the advantage of reducing the number of round trips required for re-
   authentication/authorization.

      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                                                     <- DIAMETER-EAP-Ind/
                                                     EAP-Payload/EAP-Request
                                                     OTP/OTP Challenge
                            <- PPP EAP-Request/
                            OTP/OTP Challenge
      PPP EAP-Response/
      OTP, OTPpw ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/
                            EAP-Response/
                            OTP, OTPpw ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload/EAP-Success
                                                     (other AVPs)
                            <- PPP EAP-Success


3.2.4:  Example of failed EAP Authentication

   In  the  case  where  the  client  fails   EAP   authentication,
   the conversation would appear as follows:


















Calhoun et al.              expires May 2000                   [Page 18]


INTERNET DRAFT                                             December 1999


      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                            <- PPP LCP Request-EAP
                            auth
      PPP LCP ACK-EAP
      auth ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/Start ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload/Identity
                            <- PPP EAP-Request/
                            Identity
      PPP EAP-Response/
      Identity (MyID) ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/
                            EAP-Response/
                            (MyID) ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload/EAP-Request
                                                     OTP/OTP Challenge
                            <- PPP EAP-Request/
                            OTP/OTP Challenge
      PPP EAP-Response/
      OTP, OTPpw ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/
                            EAP-Response/
                            OTP, OTPpw ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload/EAP-Failure
                            <- PPP EAP-Failure

                            <- LCP Terminate


3.2.5:  Example of DIAMETER Server not supporting EAP

   In the case that the DIAMETER server or proxy does not support EAP
   extensions the conversation would appear as follows:




Calhoun et al.              expires May 2000                   [Page 19]


INTERNET DRAFT                                             December 1999


      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                            <- PPP LCP Request-EAP
                            auth
      PPP LCP ACK-EAP
      auth ->
                            DIAMETER
                            EAP-Request/
                            EAP-Payload/Start ->
                                                     <- DIAMETER
                                                     Command-Unrecognized
                            <- PPP LCP Request-CHAP
                            auth

      PPP LCP ACK-CHAP
      auth ->
                            <- PPP CHAP Challenge
      PPP CHAP Response ->
                            DIAMETER
                            AA-Request->
                                                     <- DIAMETER
                                                     AA-Answer
                            <- PPP LCP
                            CHAP-Success
      PPP Authentication
      Phase complete,
      NCP Phase starts


3.2.6:  Example of DIAMETER Proxy not supporting EAP

   In the case where the local DIAMETER Server does support the EAP
   extensions but the remote DIAMETER Server does not, the conversation
   would appear as follows:
















Calhoun et al.              expires May 2000                   [Page 20]


INTERNET DRAFT                                             December 1999


      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                            <- PPP LCP Request-EAP
                            auth
      PPP LCP ACK-EAP
      auth ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/Start ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload/Identity
                            <- PPP EAP-Request/
                            Identity
      PPP EAP-Response/
      Identity
      (MyID) ->
                            DIAMETER-
                            EAP-Request/
                            EAP-Payload/EAP-Response/
                            (MyID) ->
                                                     <- DIAMETER-
                                                     EAP-Answer
                                                     (proxied from remote
                                                     DIAMETER Server)
                            <- PPP LCP Request-CHAP
                            auth
      PPP LCP ACK-CHAP
      auth ->
                            <- PPP CHAP Challenge
      PPP CHAP Response ->
                            DIAMETER
                            AA-Request->
                                                     <- DIAMETER
                                                     AA-Answer
                                                     (proxied from remote
                                                     DIAMETER Server)
                            <- PPP LCP
                            CHAP-Success
      PPP Authentication
      Phase complete,
      NCP Phase starts


3.2.7:  Example of PPP Client not supporting EAP

   In the case where the authenticating peer does not support EAP, but



Calhoun et al.              expires May 2000                   [Page 21]


INTERNET DRAFT                                             December 1999


   where EAP is required for that user, the conversation would appear as
   follows:

      Authenticating Peer   NAS                      DIAMETER Server
      -------------------   ---                      ---------------

                            <- PPP LCP Request-EAP
                            auth
      PPP LCP NAK-EAP
      auth ->
                            <- PPP LCP Request-EAP
                            auth
      PPP LCP NAK-EAP
      auth ->
                            <- PPP LCP Request-CHAP
                            auth
      PPP LCP ACK-CHAP
      auth ->
                            <- PPP CHAP Challenge
      PPP CHAP Response ->

                            DIAMETER-
                            AA-Request/
                            User-Name,
                            CHAP-Password ->
                                                     <- DIAMETER-
                                                     EAP-Answer/
                                                     EAP-Payload
                            <- LCP Terminate Req


4.0  References

    [1]  Rigney, et alia, "RADIUS", RFC-2138, April 1997
    [2]  P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base
         Protocol", draft-calhoun-diameter-11.txt (work in progress),
         December 1999.
    [3]  P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ
         Extension", draft-calhoun-diameter-nasreq-00.txt (work in
         progress), December 1999.
    [4]  L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication
         Protocol (EAP)." RFC 2284, March 1998.
    [5]  N Haller, C. Metz, P. Nesset, M. Straw, "A One-Time Password
         (OTP) System", RFC 2289, February 1998.
    [6]  G. Zorn, P. Calhoun, "Limiting Fraud in Roaming", draft-ietf-
         roamops-fraud-limit-00.txt (work in progress), May 1999.





Calhoun et al.              expires May 2000                   [Page 22]


INTERNET DRAFT                                             December 1999


5.0  Acknowledgements

   The authors would like to thank Nenad Trifunovic, Tony Johansson and
   Pankaj Patel for their participation in the Document Reading Party.

   The authors would also like to acknowledge the following people for
   their contribution in the development of the DIAMETER protocol:

   Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant,
   Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal
   Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John
   R. Vollbrecht and Jeff Weisberg and Glen Zorn.


6.0  Author's Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Network and Security Research Center, Sun Laboratories
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-7733
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@eng.sun.com


      Allan C. Rubens
      Tut Systems, Inc.
      220 E. Huron, Suite 260
      Ann Arbor, MI 48104
      USA

       Phone:  1-734-995-1697
      E-Mail:  arubens@tutsys.com


      Haseeb Akhtar
      Wireless Technology Labs
      Nortel Networks
      2221 Lakeside Blvd.
      Richardson, TX 75082-4399
      USA

       Phone: 1-972-684-8850



Calhoun et al.              expires May 2000                   [Page 23]


INTERNET DRAFT                                             December 1999


      E-Mail: haseeb@nortelnetworks.com


      Erik Guttman
      Network and Security Research Center, Sun Laboratories
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  49-7263-911-701
      E-mail:  erik.guttman@germany.sun.com


      William Bulley
      Merit Network, Inc.
      Building One, Suite 2000
      4251 Plymouth Road
      Ann Arbor, Michigan  48105-2785
      USA

       Phone:  1-734-764-9993
         Fax:  1-734-647-3185
      E-mail:  web@merit.edu


      Jeff Haag
      Cisco Systems
      7025 Kit Creek Road
      PO Box 14987
      Research Triangle Park, NC 27709

       Phone:  1-919-392-2353
      E-Mail:  haag@cisco.com


7.0  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  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 docu- ment itself may not be modified in any
   way, such as  by  removing  the copyright notice or references to the



Calhoun et al.              expires May 2000                   [Page 24]


INTERNET DRAFT                                             December 1999


   Internet Society or other Inter- net 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 permis- sions 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  WAR- RANTY  THAT  THE  USE  OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS  FOR  A PARTICULAR PURPOSE."






































Calhoun et al.              expires May 2000                   [Page 25]