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

From: "Christopher Richards" <[email-masked]>
Date: Fri, 30 Apr 2004 11:02:11 -0500

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.

---

From: David Mitton <[email-masked]>
Date: Fri, 30 Apr 2004 16:29:35 -0400

On 4/30/2004 11:02 AM -0500, Christopher Richards wrote:

>Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it 
>is in RADIUS)?
>
>specific AVP code - but is a RADIUS defined AVP, so that the 
>Vendor-Specific bit is NOT set in the Diameter AVP header.
>

Chris,
         RFC3588 does not address this issue or any RADIUS interaction.
You need to look at draft-ietf-aaa-diameter-nasreq-14.txt

Or my latest copy of draft 15
http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt

In particular section 9, RADIUS Interactions, and more specific to your 
question section 9.6.2 page 71.

9.6.2.  Forwarding a RADIUS VSA to a Diameter Vendor AVP

    The Diameter AVP will consist of the following fields;
       Diameter Flags: V=1, M=0, P=0
       Diameter Vendor code = RADIUS VSA Vendor code
       Diameter AVP code = RADIUS VSA Vendor type code
       Diameter AVP length = length of AVP (header + data + padding)
       Diameter Data = RADIUS VSA vendor data

    NOTE: that the VSAs are considered as optional by RADIUS rules, and
    this specification does not set the Mandatory flag.  If a VSA is
    desired to be made mandatory, because it represents a required
    service policy, the RADIUS gateway should have a process to set the
    bit on the Diameter side.

    If the RADIUS receiving code knows of vendor specific fields
    interpretations  for the specific vendor, it may employ them to parse
    an extended AVP code or  data length, Otherwise the recommended
    standard fields will be used.

    Nested Multiple vendor data fields MUST be expanded into multiple
    Diameter AVPs.

<end quote>

The intention is that the Diameter VSA mechanism get used in the obvious 
way when interacting with a RADIUS application that follows the "SHOULD" 
format of attribute 26.  Non-standard VSA formats fall on the optional 
capability of the gateway.

Any round-trip interaction should have equivalent transforms, to the best 
manner possible.

>Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it 
>is in RADIUS)?

The vendor bit should be set, and the vendor-id value is provided by the 
VSA(26) format.

>specific AVP code - but is a RADIUS defined AVP, so that the 
>Vendor-Specific bit is NOT set in the Diameter AVP header.

That would cause RADIUS vendor defined attributes to appear to be Diameter 
standard AVPs.  This is not a desirable representation.

The RADIUS attribute code 26 (VSA) is explicitly listed as prohibited in 
section 9.4.

Dave.

---

From: "Christopher Richards" <[email-masked]>
Date: Fri, 30 Apr 2004 16:26:46 -0500

Thanks Dave.

Does the NASREQ draft apply to non-NASREQ Diameter applications?

Specifically, RFC3588 does not say that RADIUS code 26 is prohibited.

Should your description be added to the errata of RFC3588?

Cheers,
Chris.

-----Original Message-----
From: David Mitton [mailto:[email-masked]] 
Sent: Friday, April 30, 2004 3:30 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]; [email-masked]
Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

>RADIUS encoding of AVP code 26:-

Chris,
         RFC3588 does not address this issue or any RADIUS interaction. You
need to look at draft-ietf-aaa-diameter-nasreq-14.txt

<end quote>

Dave.

---

From: David Mitton <[email-masked]>
Date: Fri, 30 Apr 2004 18:18:10 -0400

>Should your description be added to the errata of RFC3588?

No.

NASreq is intended to be the generic RADIUS "replacement" within Diameter.
A RADIUS interaction such as VSAs is properly addressed there.

Even as it is, NASreq Section 9 does not explicitly address all potential 
RADIUS interaction problems.  We are certainly not going to backfill it 
into RFC 3588.

The Diameter drafts/RFCs are purposely segmented so that they may get 
finished within our useful lifetimes.  Expect more application bolt-ons, 
not less.

Dave.