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

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
>...
>>   It would be easier to have the DAC proxy through the RADIUS server,
>> which would in turn supply a State in the CoA packet.
> 
> Yes, I think this makes sense.  Can you suggest some text that would
> make this clear?

...
  A DAC is normally co-located with a RADIUS server.  This close
relationship permits the DAC to obtain information from the RADIUS
traffic flow, and then use that data to make informed decisions about
the contents of the CoA-Request or Disconnect-Request packets.  When a
DAC client is not co-located with a RADIUS server, it may not have
access to the data necessary to build a compliant CoA-Request or
Disconnect-Request packet.  In those deployments, the DAC SHOULD send
its request to a RADIUS proxy that is acting as a DAS, rather than
directly to the NAS.

  When the DAC's request is sent in this way, the DAS may use its
knowledge of the RADIUS traffic to add or update attributes in the
request.  It may also perform RPF checks, and direct the request to the
appropriate NAS.  The result is a simpler and more flexible network
configuration.

>> > 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.
> 
> Some how the DAC needs to know which NAS to send the
> CoA/Disconnect-Request to, correct?

  Normally, yes.  If it sends the request to the RADIUS server, we
presume that the RADIUS server figures it out.

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