Issue: RPF Check

[Bernard Aboba <bernard_aboba@hotmail.com>]

Issue:  RPF Check
Submitter name: Bernard Aboba
Submitter email address: aboba@internaut.com
Date first submitted: May 24, 2007
Reference: 
Document: RFC3576bis-06
Comment type: Technical
Priority: S
Section: Various
Rationale/Explanation of issue:

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. 

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:

1. Change the term "RADIUS server" to "Dynamic Authorization Client" everywhere the term is being used to refer to the originator of CoA or Disconnect-Request packets.  Use the term "NAS" consistently when referring to the recipient of a CoA or Disconnect-Request packet. 

2. Add the following terms to the terminology section:

Dynamic Authorization Client (DAC)
     The entity originating Change of Authorization (CoA) 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.

Network Access Server (NAS)
     The device providing access to the network.  Sometimes also known
     as the Dynamic Authorization Server (DAS) or RADIUS client.

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. 
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 NAS or proxy 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 proxy 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 or
   Disconnect-Request is forwarded; otherwise it MUST be silently
   discarded.

   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.  Where no proxy is present, the RPF
   check will need to be performed by the NAS itself.

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