[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Object identifier and type spaces in a rationalized RADIUS data model
I have a concrete suggestion.
One of the problems in the current data model(s)
is that we have technically and administratively
different identifier spaces and data types for the
various objects (attributes) in the AAA protocols and
their extensions. While its desirable to provide
a different set of administrative rules to allocate
local and standard extensions, it is not desirable
to fragment the spaces so that different specifications
are needed to document the formats of these extensions.
It is also not desirable to have more than one space
for new standard attributes at the IETF, because
this would create a need for translation.
With this in mind, the following proposal defines
a new IETF extended RADIUS attribute that provides
extended data types, supports vendor, SDO, and IETF
attributes and avoids different spaces for RADIUS
and Diameter. This has obvious advantages going forward,
but it also eliminates the need for a few attributes
from the currently proposed filter extensions, as
existing specifications could be used as is.
The format supports a variety of data types, including
IPv6 addresses, floating point numbers, and subattributes.
Here it 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Code
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code (cont) |V M r r r r r r| Vendor-ID (opt)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-ID (opt, cont) | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
<To Be Allocated By IANA> for IETF Extended
Length
>= 7
Code
This field identifies the attribute. Only values greater than
or equal to 256 are allowed. Current values are defined in
[RFC 3588], and if V = 0, new ones may be allocated following
Designated Expert with Specification Required [IANA].
Release of blocks of AVPs (more than 3 at a time
for a given purpose) should require IETF Consensus. If V != 0,
the indicated vendor is responsible for managing the allocations.
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.
M
The 'M' Bit, known as the Mandatory bit, indicates whether support
of the attribute is required. If an attribute with the 'M' bit set is
received by a client, server, proxy, or translation agent
and either the attribute or its value is unrecognized, the message MUST
be rejected. Relay and redirect agents MUST NOT reject
messages with unrecognized attributes.
The 'M' bit MUST be set according to the rules defined for the attribute
containing it. In order to preserve interoperability, an
implementation MUST be able to exclude from a message any
Mandatory attribute which is not defined for the specific
standard that this node claims conformance to. It MAY do this in one
of the following ways:
1) If a message is rejected because it contains a Mandatory AVP
which is not defined in the relevant standard, the implementation
may resend the message without the attribute, possibly inserting
additional standard attributes instead.
2) A configuration option may be provided on a system wide, per
peer, or per realm basis that would allow/prevent particular
Mandatory attributes to be sent. Thus an administrator could change
the configuration to avoid interoperability problems.
Implementations are required to support all Mandatory
attributes which are defined in the relevant standard.
Attributes with the 'M' bit cleared are informational only and a
receiver that receives a message with such an attribute that is not
supported, or whose value is not supported, MAY simply ignore the
attribute.
V
The 'V' bit, known as the Vendor-Specific bit, indicates whether
the optional Vendor-ID field is present in the header. When
set the Code belongs to the specific vendor code address
space.
r
The 'r' (reserved) bits are unused and SHOULD be set
to 0. Note that subsequent specifications MAY define
additional bits within the header, and an unrecognized bit
SHOULD be considered an error.
Data
The Data field is zero or more octets and contains
information specific to the atribute. The format
and length of the Data field is determined by the
Code and Length fields. The format of the Data field
MUST be one of the following base data types or a data
type derived from the base data types. In the event
that a new base format is needed, a new version of
this RFC must be created.
string
The data contains arbitrary data of variable length.
See [RFC 2865].
integer
32 bit unsigned value, in network byte order. See [RFC 2865].
integer64
64 bit signed value, in network byte order. See [RFC 3588].
signed32
32 bit signed value, in network byte order. See [RFC 3588].
signed64
64 bit signed value, in network byte order. See [RFC 3588].
float32
This represents floating point values of single precision as
described by [FLOATPOINT]. The 32-bit value is transmitted in
network byte order. See [RFC 3588].
float64
This represents floating point values of double precision as
described by [FLOATPOINT]. The 64-bit value is transmitted in
network byte order. See [RFC 3588].
grouped
The Data field is specified as a sequence of attributes.
Each of these attributess follows - in the order in which
they are specified - including their headers.
generic address
This format is derived from the string base format. It
is a discriminated union, representing, for example a
32-bit (IPv4) [IPV4] or 128-bit (IPv6) [IPV6] address, most
significant octet first. The first two octets of the Address
attribute represents the AddressType, which contains an Address Family
defined in [IANAADFAM]. The AddressType is used to discriminate
the content and format of the remaining octets. See [RFC 3588].
generic time
This format is derived from the string base format.
The string MUST contain four octets, in the same format as the
first four bytes are in the NTP timestamp format. The NTP
Timestamp format is defined in chapter 3 of [SNTP].
This represents the number of seconds since 0h on 1 January 1900
with respect to the Coordinated Universal Time (UTC).
On 6h 28m 16s UTC, 7 February 2036 the time value will overflow.
SNTP [SNTP] describes a procedure to extend the time to 2104.
This procedure MUST be supported by all nodes.
text
This format is derived from the string base format.
This is a human readable string represented using the
ISO/IEC IS 10646-1 character set, encoded as an OctetString using
the UTF-8 [UFT8] transformation format described in RFC 2279.
See [RFC 2865] and [RFC 3588].
enumerated
Enumerated is derived from the integer base format. The
definition contains a list of valid values and their
interpretation and is described in the specification
introducing the attribute.
ipfilterrule
This format is derived from the string base
format. It uses the ASCII charset. See [RFC 3588].
(Open issues: inclusion of Diameter Identity data type, and
the support for >255 long attributes. Either one is doable,
though.)
--Jari
--
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/>