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

From: "Leena Mattila (TU/LMF)" <[email-masked]>
Date: Mon, 31 May 2004 11:40:21 +0200

Hi Chris,

yes, the draft-05 has been updated as discussed in the aaa mailing-list, see Marco's summary of changes at
http://www.merit.edu/mail.archives/aaa-wg/msg00598.html:
"6- Section 4.1: added rules how to include RADIUS vendor specific attributes in service specific documents as discussed in 
aaa mailing-list (http://www.merit.edu/mail.archives/aaa-wg/msg00537.html).
When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating 
process, 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."

BR,
Leena

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Christopher Richards
Sent: 28. toukokuuta 2004 16:50
To: Nelson, David; [email-masked]
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi All, 
So, back to the original question that started this whole discussion. Can the DCCA authors confirm that the encoding of RADIUS VSAs in Diameter is a closed issue?
---- Original email showing incorrect encoding of RADIUS VSA in Diameter --------> 
Hi All, 
Quick question I'm sure has been answered before. 
When sending a RADIUS VSA AVP (code 26) in a Diameter message, should the Diameter AVP header have the Vendor-Specific bit set (and so include the Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it is in RADIUS)?
My interpretation is that since AVP code 26 is not a Diameter vendor specific AVP code - but is a RADIUS defined AVP, so that the Vendor-Specific bit is NOT set in the Diameter AVP header.
RADIUS encoding of AVP code 26:- 
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Type      |  Length       |            Vendor-Id 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
        Vendor-Id (cont)           |  String... 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
Diameter encoding of a RADIUS VSA AVP (code 26):- 
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Type = 26                                                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Flags = 0     |      Length                                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Diameter AVP Data field... 
   +-+-+-+-+-+-+-+-+-+-+-+..... 
Where the Diameter AVP data field is:- 
    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Vendor-Id                                                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Vendor type   | Vendor length | Vendor Data field.... 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...... 
Is this the intention of RFC3588? 
Best Regards, 
Chris. 

Response -------------> 

Cheers, 
Chris.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 31 May 2004 07:10:39 -0700 (PDT)

What about if the Vendor-Specific attribute includes *multiple*
attributes?  This is allowed in RFC 2865.