Re: REMINDER: RADEXT WG Last call on "Extended RADIUS Attributes"

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> This is a reminder of the RADEXT WG Last Call on "Extended 
> RADIUS Attributes", prior to requesting that the IESG publish it as a Proposed Standard. 

Submitter name: Alan DeKok
Submitter email address: aland@deployingradius.com
Date first submitted: Aug 14 2008
Reference:
Document: [EXTEN]
Comment type: T
Priority: 2

Section 4:
...
   o  The final octet of the header contains the More flag and Tag
      field.  If the one bit More flag is set (1) this indicates that
      the encapsulated TLV is continued in the following Extended
      Attribute; if the More flag is clear (0) then all of the
      encapsulated TLVs fit into the current Extended Attribute.  The
      More flag MUST NOT be set if the Extended Attribute contains more
      than one TLV.

  To be clear: this means that the Extended-Attribute can encapsulate
multiple TLV's if they're short, or only one TLV if it's long.


Section 5:

   M (More)

      The More Flag is one (1) bit in length and MUST be present.  When
      a value to be transmitted exceeds 246 octets in length it is
      fragmented over two or more Extended Attributes.  If the More Flag
      is set (1), this indicates that the Value field of the Extended
      Attribute contains a fragment of a larger value, which is
      continued in the next Extended Attribute of the same Ext-Type.

  Can we add a MUST?  i.e. If the More Flag is set, the next attribute
MUST be an Extended-Attribute of the same Extended-Type.

  Inserting *other* attributes in between a fragemented attribute is
annoying and pointless.  It's better to forbid this, and to declare that
packets failing this test are malformed, and SHOULD be silently discarded.

   Ext-Type

      Two (2) octets.  Up-to-date values of the Ext-Type field are
      specified in the most recent "Assigned Numbers" [IANA].  Values
      XXXX-YYYY are reserved.

  I would suggest reserving the top 1K: 64512-65535

6.  Examples

   Consider an attribute called Foo of type String.  Foo has been
   allocated an Extended-Type 0f 257 by IANA.  The following figure
   shows the encoding of Foo(0,4) = "Hello":

  What does "Foo(0,4)" mean?  This is the first reference in that
document to that attribute naming scheme.  (I presume it's an attribute
naming scheme).  Why not just refer to it as "Foo"?

  The diagram also has Ext-Type (16 bits) of 257 split between two bytes
(8 bits) of 0 and 257.  I welcome the novel ability to count to 257 in
an 8-bit field, but perhaps this could be corrected. :)

  The examples should use numbers from the reserved space (i.e. 64512),
and not from the IANA allocated space (257).  The examples also use the
attribute name "Foo" multiple times.  It should instead use unique names.

   Figure 2 below
   illustrates the encoding of the first 7 octets of the first Extended
   Attribute (Foo(0,6) = "Hello W"), while Figure 3 shows how the second
   attribute (Foo(246,250) = "e end.") is encoded.

  Hmm... So Foo(N,M) is a reference to the fragments?  I don't see why
this is necessary.  We don't do it for EAP-Message.  I would suggest
just referring to it as "Foo", and "the first fragment (octets 0 through
245)", and "the second fragment (octets 246 through 250).

...
   Consider the following structure:

     struct
       Integer a;
       String  b;
       Integer c;
     endStruct

  What syntax is this?  I think I understand it, but I'm not sure
everyone will come to a shared understanding.  Maybe instead the example
can be given by reference to existing RADIUS data types.  e.g. A
structure of RADIUS data types (integer, text, integer) would previously
have to be encoded as three separate and independent attributes.  Here,
it can be encoded as 3 attributes sharing a common tag.

  Reading the rest of the example, I find the b(4,5) syntax very
awkward.  I suggest discarding it, and just referring to the diagrams.

  The examples could also given broken-out hex encoding of the
attributes, which may be clearer than the ASCII art diagrams.  e.g.

  1a 0f 00 00 00 00 00 01 01 08 48 65 6c 6c 6f

7.  Security Considerations

   I suggest adding a note that a new attribute encoding is an
opportunity for buffer overflows, inadequate checks, etc.  Implementors
SHOULD take care to validate the lengths, etc. before decoding the
contents of the attributes.

8.  IANA Considerations
...
   It also requires that IANA set up a new registry for the RADIUS
   Extended Attribute Types.

  I suggest leaving the first 0..255 attributes as unallocated, in order
to avoid confusion with legacy RADIUS attributes.


9.  Open Issues

   What is the numbering scheme for attributes that will be used by RFC
   writers going forward?  For example today we write user-name(1).

  Uh... We do?  I've never seen that in an RFC.  I suggest deleting this
section entirely.

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