Re: Location draft issues raised today

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

Emile van Bergen <openradius-radextwg@e-advies.nl> wrote:
> I agree that it would support the packing as it is, but I think the
> overriding criterium is whether or not the server wants access to
> individual members in order to apply administrator defined policy.

  I am hesitant to make gratuitous changes to existing location data
structures just to satisfy RADIUS historical practices.  Doing so
would affect interoperability and implementation.  It would make
location-based systems harder to implement, because of the pointless
translation from location structures to RADIUS-friendly structures.

  In addition, there is presumably already code to parse and process
the location data structures.  RADIUS implementations should be able
to re-use that code to abstract access to the information they need
for policy.

  This is *no* different than implementing EAP.  EAP implementors were
not forced to re-pack their data into RADIUS friendly structures.  I
do not believe it's necessary to require the location structures to be
re-pack, either.

> The repacking by the RADIUS client can be well defined and nonambiguous.
> I don't see any problem with that.

  It's more code.  It's gratuitous re-packing just to make location
data fit into the RADIUS data model (such as it is).

> It's in our scope anyway. It's not that "if there's any other encoding
> for this information, in any other protocol, we have nothing to say
> anymore". This is also what I seemed to hear from Bert as well as
> Bernard.

  It's not "if there's any other encoding", but: If RADIUS is being
(ab)used as a transport protocol for data, it should *not* mangle that
data.

  Nearly every transport implementation that has massaged the data it
transported has created bugs, interoperability issues, implementation
problems, and security breaches.  Much as I think the location
structure is a *terrible* one, I think mangling the data causes more
problems than it solves.

> It depends on whether there's any meaning to be attached to the elements
> *at our level*, that is, the RADIUS proxy or endpoint.

  Like EAP?  While the canonical diagrams of RADIUS to EAP
authenticators show separate RADIUS & EAP systems, in reality they're
almost always implemented in the RADIUS server.  RADIUS is just
transport for EAP data, which people *do* use to make policy
decisions.

  There are precedents for RADIUS being used as a transport protocol
for data that doesn't match the RADIUS data model.  There are
precedents for RADIUS servers implementing policy based on that data.

> It depends on whether there's any meaning to be attached to the elements
> *at our level*, that is, the RADIUS proxy or endpoint.

  Like the ARAP attributes?  Or the Login-LAT-* attributes?  RADIUS
has transported poorly formatted data, and made policy decisions on it
for a very long time now.  I just don't see why location is so special
that we have to enforce the RADIUS data model now.

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