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

From: "Mark Watson" <[email-masked]>
Date: Mon, 24 May 2004 18:04:26 +0100

Hi David,
 
I am not so much thinking of applications which directly interact with
RADIUS as cases where new applications are defined and have a requirement to
carry some information for which a RADIUS VSA sub-attribute has already been
defined (perhaps by a standardisation organisation, rather than a specific
vendor).
 
On the basis that re-use is better than re-invention, it would be nice if
such applications could re-use the RADIUS VSA sub-attribute definition, even
if there is no actual RADIUS interaction involved.
 
Comments ?
 
Another way to put my question would be, is it wise for a Diameter
implementation to assume that AVP x with Vendor-ID y always corresponds to
the same AVP, independent of the application. Or would it be wiser to assume
that the meaning of (AVP x, Vendor y) is application-dependent ? The current
specification situation suggests the latter, but I am not sure that is the
intention.
 
...Mark

-----Original Message-----
From: David Mitton [mailto:[email-masked]] 
Sent: 24 May 2004 17:50
To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

On 5/24/2004 04:48 PM +0100, Mark Watson wrote:

Hi all,
 
So, this rule will apply to NASREQ and DCC, but other applications are free
to do whatever they like ?

I would think, (subject to any dissent from the group) that any Diameter
application that interacts with RADIUS, would adhere to the specifications
in Diameter-NASreq as it's base.  Any exceptions would have to be justified
and dealt with when the specification was reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to cover all
issues, and parts out certain problems to other specifications.  RADIUS
interfacing is another one of these.

Dave.

That is, the AVP code codespace when the Vendor-specific flag is set to 1 is
application-specific. The same code may mean different things in different
applications. This is unlike the AVP code codespace when the Vendor-specific
flag is 0, right ?
 
Would it be better to (also) have a rule for all applications, or at least
an 'opt out' rule such as 'unless otherwise specified in a specific
application....' ?
 
Regards...Mark

-----Original Message-----

From: Richards, Christopher [RICH2:2Q40:EXCH] 

Sent: 07 May 2004 20:51

To: [email-masked]

Cc: [email-masked]; [email-masked]; [email-masked]

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

Marco,

That sounds good. Thanks.

Cheers, 

Chris. 

Shasta Wireless Development 

Nortel Networks 

Telephone: 

+1 972 684 3281 

ESN 444 3281 

-----Original Message-----

From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] 

Sent: Friday, May 07, 2004 2:47 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,

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 better see this kind of text in section 4.1, perhaps slightly modified as
follow:

When service specific documents include RADIUS vendor specific attributes in
a DCC message, the rules described in [NASREQ] ..........etc.

Regards

Marco

-----Original Message-----

From: ext Christopher Richards [mailto:[email-masked]
<mailto:[email-masked]> ]

Sent: 04 May, 2004 17:53

To: Stura Marco (Nokia-NET/Helsinki)

Cc: [email-masked]; [email-masked]; [email-masked]

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

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]
<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: Bernard Aboba <[email-masked]>
Date: Mon, 24 May 2004 11:31:34 -0700 (PDT)

Certain aspects of RADIUS/Diameter gateway interaction are valid for
*all* Diameter applications.  Others are specific to a given application.

Perhaps it would make sense to more clearly label the universal aspects
within the NASREQ specification, and maybe even note that it "updates RFC
3588" in those respects.