Subject: [AAA-WG]: [issue] RADIUS/Diameter Protocol Interactions

From: David Spence <[email-masked]>
Date: Thu, 14 Mar 2002 22:12:54 -0500

Subject: [issue] RADIUS/Diameter Protocol Interactions
Submitter name: David Spence
Submitter email address: [email-masked]
Date first submitted: March 14, 2002
Reference: 
Document: NASREQ
Comment type: T
Priority: S
Section: 9
Rationale/Explanation of issue:

   Section 9 of the nasreq draft addresses RADIUS/Diameter Protocol 
   Interactions.  This issue documents protocol interaction questions 
   that still need to be addressed in section 9.

   1. I believe there are errors regarding the generation of Origin-Host 
      AVP when translating a RADIUS request to a Diameter request.
   
   2. How do we translate a RADIUS accounting request with an 
      Acct-Status-Type of Accounting-On or Accounting-Off?
   
   3. How do we deal with the requirement that accounting AVPs be 
      included in Accounting-Answer (ACA) messages when gatewaying 
      between RADIUS and Diameter?  (By the way, I've forgotten why do 
      accounting AVPs appear in ACAs?)

   4. Discuss how to translate a Diameter request not requiring 
      authentication into a RADIUS request.

   5. Specify what a gateway should do if it receives an 
      Authorization-Lifetime AVP in a Diameter AA-Answer (AAA) message 
      and needs to generate a RADIUS Access-Accept.  The result will not 
      be pretty.
   
   6. Specify how a gateway should process a Diameter Re-Auth-Request.  
      It will have to generate an answer saying that re-auth is not 
      possible.
   
   7. Specify how a gateway should process a Diameter 
      Abort-Session-Request (ASR) message.  It will have to generate an 
      answer saying that aborting the session is not possible.
   
   8. In Diameter, the Reply-Message AVP may have a value field longer 
      than 253 bytes.  If so, it will have to be split into multiple 
      Reply-Message attributes when creating the corresponding RADIUS 
      message.  However the converse -- recombining multiple 
      Reply-Message attributes into a single Reply-Message AVP -- is not 
      required.  There may be other attributes that fall into the same 
      category.  Generally, any Diameter AVP with a type based on octet 
      string where the AVP Code is less than 256 and the length of the 
      AVP data field is greater than 253 will need to be split into 
      multiple RADIUS attributes.
   
   9. When processing a Diameter AA-Request (AAR) message containing a 
      Session-Timeout AVP or an Idle-Timeout AVP, drop these attributes 
      when generating the corresponding RADIUS Access-Request.  These 
      attributes are allowed in Diameter requests as a hint to the 
      server but are not allowed in RADIUS requests.
   
   10. Explain how to encapsulate and decapsulate the RADIUS 
       Vendor-Specific attribute.  (This item is the same as issue 255.)
   
   11. Add an explicit list of RADIUS attributes that MUST NOT appear in 
       a Diameter message.  There are several of these that have been 
       superseded by Diameter AVPs of one sort or another.  In some 
       cases there is already text in section 9 explaining how to handle 
       these attributes.  We need to make sure all are covered.  The 
       following is the list of attributes I *think* should be excluded 
       from Diameter.
    
         CODE      NAME                            RADIUS RFC
        ------     ----                            ----------
            3      CHAP-Password                   RFC 2865
           26      Vendor-Specific                 RFC 2865
           40      Acct-Status-Type                RFC 2866
           42      Acct-Input-Octets               RFC 2866
           43      Acct-Output-Octets              RFC 2866
           47      Acct-Input-Packets              RFC 2866
           48      Acct-Output-Packets             RFC 2866
           49      Acct-Terminate-Cause            RFC 2866
           52      Acct-Input-Gigawords            RFC 2869
           53      Acct-Output-Gigawords           RFC 2869
           80      Message-Authenticator           RFC 2869

Requested change:

   Just do it!

-- 
David Spence                            email: [email-masked]
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.