RE: Issue 272 resolution

["Glen Zorn" <glenzorn@comcast.net>]

Alan DeKok [mailto:aland@deployingradius.com] writes:

> Glen Zorn wrote:
> > No, they aren't, Extended Attributes are a slight extension of RFC
> 2865
> > VSAs.
> 
>   Which again begs the question.
> 
>   I offered a number of possible descriptions of what the change could
> be.  You haven't agreed with, or denied, any of them.

Actually, I did: VSAs have a fundamentally different structure from the rest
of the standard attributes (see below); therefore, your claim that "[t]he
extended types are just legacy RADIUS attributes with 16-bit types" is
patent nonsense.  

> 
>   If the proposed change has no clear definition, I don't see how it
> can
> be used by anyone.

I could have sworn that 272 was pretty clear.  Oh, well.  As noted above,
the Extended Attributes use a format directly derived from RFC 2865 VSAs
(the only difference is the addition of the 'More' and 'Tag' fields.  RFC
2865 states:

5.26.  Vendor-Specific

   Description

      This Attribute is available to allow vendors to support their own
      extended Attributes not suitable for general usage.  It MUST not
      affect the operation of the RADIUS protocol.

      Servers not equipped to interpret the vendor-specific information
      sent by a client MUST ignore it (although it may be reported).
      Clients which do not receive desired vendor-specific information
      SHOULD make an attempt to operate without it, although they may do
      so (and report they are doing so) in a degraded mode.

   A summary of the Vendor-Specific Attribute format is shown below.
   The fields are transmitted from left to right.

    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)           |  String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      26 for Vendor-Specific.

   Length

      >= 7

   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, as defined in the "Assigned Numbers" RFC [6].

   String

      The String field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

      It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields, as follows.  The Attribute-Specific field is
      dependent on the vendor's definition of that attribute.  An
      example encoding of the Vendor-Specific attribute using this
      method follows:

       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)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

Note the words "a sequence of vendor type / vendor length / value fields";
vendor Type/Length/Value == TLV, I'm not inventing any new terminology here.
There's just one problem with this definition, it doesn't allow the
assignment of a overall type (or name, if you like)  to a VSA that consists
of multiple TLVs.  This is understandable because IIRC the reason multiple
TLVs were allowed was just to conserve space in the packet.  It is that
problem that I'm attempting to solve with a simple 2 layer hierarchy of
grouping: tags group related Extended Attributes, while Extended Attributes
group related TLVs.  Both types of groupings are optional.  My suggestion is
to adopt an 8-bit type for both Extended Attributes and TLVs (I hope that
we've established the meaning of "TLV" now).  Actually, to do it right, one
would need a "More" flag in TLVs, too, however.
                  
> 
>   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/>