[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IETF Extended attribute and length



Jari,

Here are my comments/suggestions....


Length:
We need to be able to extend longer than 255 octets.  Why?
-We are had discussion on having something longer in at least one particular
case.
-If we want to be compatible with Diameter then the length should be longer.
-We are suggesting to use this for grouped AVPs this needs longer attributes

The current overhead for this attribute is 11 bytes add 4 for payload. We
therefore can encode 17 integers attributes.  Some examples are starting to
come close to that.

To maintain maximal backwards compatibility I suggest we keep the attribute
to a max 255 and overflow to the next attribute - as would be the normal way
we do this in RADIUS.  However, we need an explicit indication that we are
overflowing. That is when we have two consecutive attributes in a packet we
need to differentiate between two different GROUPed AVPs an overflow.
Perhaps using one of the 'r' bits to indicate a continuation.


> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> Sent: Wednesday, June 09, 2004 5:14 AM
> To: Bernard Aboba
> Cc: radiusext@ops.ietf.org
> Subject: 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/>
> 

--
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/>