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

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> Yet another revision:

  It's a little complicated.  If I try to shorten the sentences and chop
it into paragraphs, I get:

---
The DAC may require access to data from the RADIUS authentication or
accounting packets.  It uses this data to compose compliant
CoA-Request or Disconnect-Request packets.  For example, as described
in Section 3.3, a CoA-Request packet containing a Service-Type
Attribute with value "Authorize Only" is required to contain a State
Attribute.  The NAS will subsequently transmit this attribute to the
RADIUS server in an Access-Request.  In order for the DAC to include a
State Attribute that the RADIUS server will subsequently accept, some
coordination between the two parties may be required.

This coordination may be acheived in multiple ways.  The DAC may be
co-located with a RADIUS server, in which case it is presumed to have
access to the necessary data.  The RADIUS server may also store that
information in a common database.  The DAC may then be separated from
the RADIUS server, so long as it has access to that common database.

Where the DAC is not co-located with a RADIUS server, and does not have
access to a common database, the DAC SHOULD send CoA- Request or
Disconnect-Request packets to a RADIUS server acting as a proxy, rather
than sending them directly to the NAS.

A RADIUS server receiving a CoA-Request or Disconnect-Request packet
from the DAC MAY then add or update attributes (such as adding NAS or
session identification attributes or appending a State Attribute),
prior to forwarding the packet.  Having CoA/Disconnect-Requests
forwarded by a RADIUS server can also enable upstream RADIUS proxies
to perform a Reverse Path Forwarding (RPF) check (see Section 6.1).


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