Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66

["Alan DeKok" <aland@nitros9.org>]

Emile van Bergen <openradius-radextwg@e-advies.nl> wrote:
> Agreed, however, the inner length field in the Lior proposal seems
> redundant, and instead of using attribute 26, vendor 0, I think its
> better to allocate a separate attribute

  I agree.  After seeing this discussion go around in circles for a
long time, I think enough is enough.

  Therefore, I'm happy to announce that FreeRADIUS now has an
implementation of the Extended-Attribute from
draft-wolff-radext-ext-attribute-00.txt.  For code, see the CVS
instructions on www.freeradius.org/development.html

  We'll reference the "Diameter-Encoded RADIUS Attributes" as DERA's,
to distinguish them from RADIUS or proper Diameter AVP's.

  * Extended-Attribute is attribute 192, because it's in the
    "Experimental" space from RFC 2865.  Changing this to an IANA
    allocated number will mean editing 2 lines of text.
  * The implementation can handle both the Extended-Attribute and
    Ascend's pseudo-VSA at attribute 192, simultaneously in one packet.
  * Data types supported include integer, date, IP address, IFID, IPv6
    address, IPv6 prefix, text and string (limited to 240 bytes or so)
  * Diameter-style VSA's via the "V" bit are fully supported, and are
    in a separate attribute space from RADIUS VSA's
  * no tag, encryption, or grouping is currently supported
  * no Diameter AVP flags other than "V" are supported
   (i.e. they're forbidden)
  * Each DERA must be in it's own Extended-Attribute
    (i.e. no concatenation, as of yet)
  * DERA attributes of less than 256 are forbidden, as they should be
    encoded as RADIUS attributes
  * DERA attributes of 256..32767 are forbidden, as they have meaning
    within Diameter, and RADIUS servers cannot properly deal with them
  * DERA's are arbitrarily assigned the attribute space 32768..65535.
  * Outside of the RADIUS marshalling/unmarshalling code, nothing else
    in the server is aware that the attributes are encoded in any
    special way.
  * The new attributes are indistinguishable (other than by name) 
    from existing RADIUS attributes to existing deployments
  * the RADIUS client included with FreeRADIUS has full support for
    DERA's in all RADIUS packets, with no code changes to the client.
  * less than 400 lines of code, limited to a packet handling library
  * can be easily extended to support multiple Diameter-style AVP's
    in one or more Extended-Attribute.
  * with a little more work, can be extended to support text/string
    DERA's with more than 240 bytes of data.

  The initial implementation exists.  Let's see if we can have
multiple inter-operable implementations.

  "Rough consensus and running code" has not been making progress.
Let's try "running code and rough consensus".

  Alan DeKok.

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