RE: Issue: RPF Check

[Bernard Aboba <bernard_aboba@hotmail.com>]

Let me know whether this works for you. 
 
I have added a definition of "Dynamic Authorization Server" to the terminology section:
 
Dynamic Authorization Client (DAC)
     The entity originating Change of Authorization (CoA) Requests or
     Disconnect-Requests.  While it is possible that the DAC is co-
     resident with a RADIUS authentication or accounting server, this
     need not necessarily be the case.

Dynamic Authorization Server (DAS)
     The entity receiving CoA-Request or Disconnect-Request packets.
     The DAS may be a NAS or a RADIUS proxy.

Network Access Server (NAS)
     The device providing access to the network.
 
Here is the new text of Section 6.1:
 
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.

   A Dynamic Authorization Server MUST silently discard Disconnect-
   Request or CoA-Request packets from untrusted sources.  In situations
   where the Dynamic Authorization Client is co-resident with a RADIUS
   authentication or accounting server, a proxy MAY perform a "reverse
   path forwarding" (RPF) check to verify that a Disconnect-Request or
   CoA-Request originates from an authorized Dynamic Authorization
   Client.  In addition, it SHOULD be possible to explicitly authorize
   additional sources of Disconnect-Request or CoA-Request packets
   relating to certain classes of sessions.  For example, a particular
   source can be explicitly authorized to send CoA-Request packets
   relating to users within a set of realms.

   To perform the RPF check, the Dynamic Authorization Server uses the
   session identification attributes included in Disconnect-Request or
   CoA-Request packets, in order to determine the RADIUS server(s) to
   which an equivalent Access-Request could be routed.  If the source
   address of the Disconnect-Request or CoA-Request is within this set,
   then the CoA-Request or Disconnect-Request is forwarded; otherwise it
   MUST be silently discarded.

   Typically the Dynamic Authorization Server will extract the realm
   from the Network Access Identifier [RFC4282] included within the
   User-Name or Chargeble-User-Identity Attribute, and determine the
   corresponding RADIUS servers in the realm routing tables.  If the
   Dynamic Authorization Server maintains long-term session state, it
   MAY perform the authorization check based on the session
   identification attributes in the CoA-Request.  The session
   identification attributes can be used to tie a session to a
   particular proxy or set of proxies, as with the NAI realm.

   Where no proxy is present, the RPF check can only be performed by the
   NAS if it maintains its own a realm routing table.  If the NAS does
   not maintain a realm routing table (e.g. it selects forwarding
   proxies based on primary/secondary configuration and/or liveness
   checks), then an RPF check cannot be performed.

   Since authorization to send a Disconnect-Request or CoA-Request is
   determined based on the source address and the corresponding shared
   secret, the Dynamic Authorization Server SHOULD configure a different
   shared secret for each Dynamic Authorization Client."

==========================================
> Date: Sun, 27 May 2007 09:39:39 +0100
> From: aland@nitros9.org
> To: bernard_aboba@hotmail.com
> CC: radiusext@ops.ietf.org
> Subject: Re: Issue: RPF Check
> 
> 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.