[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Rationalizing the RADIUS data model
- To: Avi Lior <firstname.lastname@example.org>
- Subject: Rationalizing the RADIUS data model
- From: Bernard Aboba <email@example.com>
- Date: Fri, 28 May 2004 09:03:27 -0700 (PDT)
- Cc: firstname.lastname@example.org
- In-reply-to: <F17FB067A86B2D488382C923C532EAA7024A4A7E@exch01.bridgewatersys.com>
- References: <F17FB067A86B2D488382C923C532EAA7024A4A7E@exch01.bridgewatersys.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
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
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...
26 for Vendor-Specific
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.
1 = Mandatory
0 = Non-mandatory
Reserved for future use, and set to zero (0).
The vendor type field is 14 bits.
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.
The Attribute-Specific field is dependent on the definition of
Multiple subattributes MAY be encoded within a
single IETF extended attribute, although they do not have to be.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.