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

["Bernard Aboba" <bernard_aboba@hotmail.com>]

The DAC is normally assumed to have access to data gleaned from the RADIUS 
traffic flow (such as mapping of User-Names to NASes), regardless of whether 
it is co-located with the RADIUS server.  However, this would not 
necessarily allow it to construct a valid State Attibute.

Note that the RADIUS server/proxy cannot do an RPF check on the incoming 
packet, since the DAC would presumably not be a acting as a RADIUS server 
and therefore would fail the RPF check.  However, an upstream RADIUS proxy 
could successfully conduct the check.

How about this?

"Regardless of whether it is co-located with a RADIUS server, the DAC is 
assumed
to have access to data gleaned from the RADIUS traffic flow (such as the NAS 
and
NAS-Port corresponding to a User-Name) in order to use that data to compose
CoA-Request or Disconnect-Request packets.   However, where the DAC is not
co-located with a RADIUS server, it may not have access to all the data
necessary to build a compliant CoA-Request or Disconnect-Request packet
(such as the ability to construct a State Attribute that the RADIUS server 
can
subsequently validate).  In those deployments, the DAC SHOULD send
CoA or Disconnect-Requests to a RADIUS server acting as a proxy, rather than
sending them directly to the NAS.

A RADIUS server receiving a CoA or Disconnect-Request from the DAC may then 
add or
update attributes (such as adding a State Attribute), prior to forwarding 
the
packet.  Having CoA/Disconnect-Requests forwarded by a RADIUS server may
also enable upstream RADIUS proxies to perform an RPF check.
The result is a simpler and more flexible network configuration."



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