[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF Extended attribute and Vendor Id
Assuming we have an issue with SDOs and Vendor Ids.
I don't see how this is actually addressing some of the concerns raised
before with SDOs and Vendors.
We are still using Vendor ID to support extension.
To be clear I don't see SDOs going to the IETF to request codes. New codes
require some sort of IETF action.
> 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/>
>
--
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/>