Rationalizing the RADIUS data model

[Bernard Aboba <aboba@internaut.com>]

> So I don't know what the benefit of having a new class of attribute.  What
> are we really fixing here?

Presumably what we would be fixing is:

a. Providing a migration path from current SDO VSAs to the IETF standards
   space.

b. Rationalizing the RADIUS VSA data model with the IETF standard
   attribute data model.

Today because the data models are different and the IETF standards space
is only 8 bits, we have difficulties in migrating arbitrary SDO VSAs to
the IETF standards space.

To get there, I'd suggest we need to do the following:

1.  Take inventory of the data types used in current RADIUS RFCs.  We've
    discussed this on previous emails, but we still need to summarize this
    and draw conclusions from it so we can understand what the current
    RADIUS data model is.

2.  Take inventory of the data types that folks feel they need/want going
    forward.  Certainly sub-attributes are one element of this, but there
    is probably more as well (such as an IPv6 address type).

3.  Put together a draft summarizing what we have now, and analyzing
    where we need to go, including the Diameter/RADIUS translation
    issues.

In terms of attribute definition, we have two proposals on the table:

a.  Using a Vendor-Id of zero (0) within the existing VSA attribute 26,
    in order to define an extended IETF standard attribute space that
    would mirror the VSA data model, including support for sub-attributes.

b.  Creating a new attribute that would mirror the VSA data model,
    including support for subattributes.

As I understand it, the primary argument for b) over a) relates to
potential backward compatibility issues with a).  To determine whether
this is an issue or not we will need to survey existing implementations.

Proposal for an IETF extended attribute space:

       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)           |M|R|      Vendor type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vendor length |  Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      26 for Vendor-Specific

   Length

      >= 7

   Vendor-Id

      The high-order octet is 0 and the low-order 3 octets are the SMI
      Network Management Private Enterprise Code of the Vendor in
      network byte order.  A value of zero (0) denotes the IETF
      extended attribute space.

   M
      1 = Mandatory
      0 = Non-mandatory

   R
      Reserved for future use, and set to zero (0).

   Vendor type

      The vendor type field is 14 bits.

   Vendor length

      The Vendor Length field is one octet, and indicates the length of
      this Attribute in octets, including the M, R, Vendor type, Vendor
      length and Attribute-Specific fields.

   Attribute-specific

      The Attribute-Specific field is dependent on the definition of
      the Attribute.

   Multiple subattributes MAY be encoded within a
   single IETF extended attribute, although they do not have to be.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>