[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Location draft issues raised today
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/>