Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

From: "Christopher Richards" <[email-masked]>
Date: Tue, 4 May 2004 09:52:58 -0500

Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter applications should
follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I
think it would be beneficial if some statement was added to DCC section 8.
E.g.

When including RADIUS vendor specific attributes in a DCC message, the rules
described in [NASREQ] for formatting the Diameter AVP MUST be followed. For
example, the AVP code used is the vendor attribute type code, the
Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the
IANA Vendor identification value. The Diameter AVP data field contains only
the attribute value of the RADIUS attribute.

I think it will save confusion in the future.

Cheers,
Chris.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to
>re-use existing RADIUS
>VSA AVPs. 
>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that
I now want to 
>use in Diameter. I want avoid having to completely redefine it.
>From my reading of RFC3588, it says something along the lines that all AVP
codes 0 to 255 
>are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26
was included.
>As an example, if you have access to 3GPP TS 29.061, take a look at the
RADIUS VSAs defined >for 3GPP. 

>When I want to put this information into a Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the generic RADIUS
replacement within Diameter. If you just use the NASREQ defined AVPs, that
practically uses those AVP numbers from 1 through 255 you're talking about,
you should be able to match the 3GPP TS 29.061 needs.

For those 3gpp vendor-specific attributes defined in TS 29.061 I think you
should follow the rules defined in NASREQ section 9.6.2, RADIUS
Interactions. According to the mentioned rules the V bit is to be set. 
I copied here sect. 9.4 of the NASREQ draft, that clearly state that
attribute code 26 must not appear in Diameter messages.

Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT appear in a Diameter
   message.  Instead, they are translated to other Diameter AVPs or
   handled in some special manner. The rules for the treatment of the
   attributes are discussed in Sections 9.1, 9.2 and 9.6.

   Attribute Description       Defined     Nearest Diameter AVP
   -----------------------------------------------------------------
    3 CHAP-Password            RFC 2865    CHAP-Auth Group
   26 Vendor-Specific          RFC 2865    Vendor Specific AVP
   29 Termination-Action       RFC 2865    Authorization-Lifetime
   40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
   42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets
   43 Acct-Output-Octets       RFC 2866    Accounting-Output-Octets
   47 Acct-Input-Packets       RFC 2866    Accounting-Input-Packets
   48 Acct-Output-Packets      RFC 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     RFC 2866    Termination-Cause
   52 Acct-Input-Gigawords     RFC 2869    Accounting-Input-Octets
   53 Acct-Output-Gigawords    RFC 2869    Accounting-Output-Octets
   80 Message-Authenticator    RFC 2869    none - check and discard

---

From: Jari Arkko <[email-masked]>
Date: Wed, 05 May 2004 13:22:45 +0300

This works for me.

--Jari

Christopher Richards wrote:
> follow the NASREQ specification when encoding RADIUS vendor specific 
> AVPs, I think it would be beneficial if some statement was added to DCC 
> section 8. E.g.
> 
> When including RADIUS vendor specific attributes in a DCC message, the 
> rules described in [NASREQ] for formatting the Diameter AVP MUST be 
> followed. For example, the AVP code used is the vendor attribute type 
> code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST 
> be set to the IANA Vendor identification value. The Diameter AVP data 
> field contains only the attribute value of the RADIUS attribute.
> 
>  >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, 
> that I now want to
>  >From my reading of RFC3588, it says something along the lines that all 
> AVP codes 0 to 255
>  >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP 
> code 26 was included.
>  >As an example, if you have access to 3GPP TS 29.061, take a look at 
> the RADIUS VSAs defined >for 3GPP.
> 
> replacement within Diameter. If you just use the NASREQ defined AVPs, 
> that practically uses those AVP numbers from 1 through 255 you're 
> talking about, you should be able to match the 3GPP TS 29.061 needs.
> 
> For those 3gpp vendor-specific attributes defined in TS 29.061 I think 
> you should follow the rules defined in NASREQ section 9.6.2, RADIUS