Re: RFC 3576bis Question: DAC and RADIUS server not co-located

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> What happens if the DAC and RADIUS server are not co-located?

  The simplest thing to do is to have the DAC send the CoA to the RADIUS
server, which then sends it to the NAS.  The RADIUS server can add
information such as State.

>  Is that
> viable in situations where a Service-Type="Authorize Only" is used on a
> CoA-Request?

  I can see it being useful.  The issue for me is that RADIUS is
normally controlling the users session information.  If a DAC sends
requests directly to the NAS, then it is out of the normal AAA policy.
By proxying through the RADIUS server, it gains capabilities (i.e.
adding State), and works through the normal AAA process.

> However, the Access-Request is received by the RADIUS server, not the
> DAC that sent the State Attribute.  Are we assuming that the RADIUS
> server is able to validate a State Attribute sent by the DAC?

  If that is possible, how this is done is out of scope.

> Or perhaps that the DAC will provide the NAS with a State Attribute
> obtained from the RADIUS server?

  It would be easier to have the DAC proxy through the RADIUS server,
which would in turn supply a State in the CoA packet.

> Since the DAC needs access to a database of State in order to track
> sessions, that database could contain the required State attribute.

  The RADIUS server already tracks sessions.  I would recommend against
DACs re-implementing that.

  I understand that this proposed architecture may limit certain
implementations, but it should make implementations much easier, too.

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