Re: Issue: RPF Check

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> It has been pointed out that the Dynamic Authorization Client (the 
> entity originating the CoA or Disconnect-Request) need not be 
> co-resident with a RADIUS authentication or accounting server.   
> However, Section 6.1 seems to assume that this is the case.  In cases 
> where the Dynamic Authorization Client is not co-resident with the 
> RADIUS authentication or authorization server, the RPF check cannot be 
> applied.  I would therefore question whether it is appropriate to 
> recommend use of the RPF check by default.

  I agree.  However, the RPF check was an attempt to prevent 
unauthorized servers from performing CoA requests.  We should make a 
note of that problem, and potential methods for addressing it.  See below.

> Note that this is not the only place where the distinction between a 
> RADIUS server and a Dynamic Authorization Client needs to be made.  
>
> The proposed resolution is as follows:
...

  I agree.

> 2. Add the following terms to the terminology section:
...

  I agree.

  We may also want to note that a proxying server acts as a NAS to the 
Dynamic Authorization Client, and as a Dynamic Authorization Client to 
the NAS.  We should probably use new terminology for such a server, 
rather than calling it a RADIUS server.  Maybe a "Dynamic Authorization 
Server".

> 3. Change Section 6.1 to the following, downgrading the RPF check to a 
> MAY and clarifying that it is only applicable when the RADIUS server and 
> Dynamic Authorization Client are co-resident.

  OK.

> 6.1.  Authorization Issues
>
>    Where a NAS is shared by multiple providers, it is undesirable for
>    one provider to be able to send Disconnect-Request or CoA-Requests
>    affecting the sessions of another provider.
...
>    Typically the proxy will extract the realm from the Network Access
>    Identifier [RFC4282] included within the User-Name Attribute, and
>    determine the corresponding RADIUS servers in the proxy routing
>    tables.  The RADIUS servers for that realm are then compared against
>    the source address of the packet.  

  Do we want to add "or the CUI", since the NAI may be anonymized? 
Also, the proxying decision may be based on other attributes, such as 
client source IP, or calling station Id.

  I would then add:

  If the RADIUS server maintains long-term session state, it MAY 
perform the authorization checks based on the session identification 
attributes in the CoA request.  The session identification attributes 
can be used to tie a session to a particular forwarding server or set of 
servers, as with the NAI and realm, above.

> Where no proxy is present, the RPF
>    check will need to be performed by the NAS itself.

  Only if the NAS performs policy-based routing on the RADIUS requests. 
 If the NAS selects servers by live/dead status, or by load-balancing, 
then the RPF checks do not need to be performed.

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