Re: Questions on RADIUS Extended attributes

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

"Nelson, David" <dnelson@enterasys.com> wrote:
> And we clearly require that attributes of type TBD never be re-ordered,
> added or deleted by proxies.

  The re-ordering requirement is already in RADIUS, of course.  The
requirement to not add or delete the attributes is limited to only
those proxies that are unaware of the new attribute format.  Those
proxies might remove an Extended-Type attribute from the *middle* of a
list of such attributes, which would be bad.

  We can try to work around that problem by increasing the complexity
of the solution, or we can see if that problem exists today.

  Personally, I don't see it as much of a problem.  Proxies generally
fall into one of two categories:

  1) blind forwarders who serve as aggregation points and/or
application-layer routers.  These forwarders don't modify the packet
contents.  The Extended-Type proposal doesn't affect these.

  2) policy-limiting forwarders.  These servers act as forwarders that
authenticate remotely, but enforce local policy.  In that case, the
Extended-Type attributes will either be understood locally (and thus
not mangled), or not understood (in which case mangling won't be
noticed)

> There are other issues that we have *not* yet agreed to, such as how to
> standardize structured data (grouping, sub-types, etc.).

  The main problem with this proposal is that it doesn't easily
support nested grouping.  For that to work would require defining yet
another attribute packing format.  Or, Emile's tag suggestion would
seem to work.

  My only requirement for a tagged format is that as Glen pointed out,
the tags MUST ALWAYS exist.  Optional tags are a nightmare.

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