Re: Issue 63: Request-ID Supplementation

["Alan DeKok" <aland@ox.org>]

A long time ago, Bernard Aboba <aboba@internaut.com> wrote:
> [ request Id supplementation ]
>
> This practice applies to other types of RADIUS requests, other than those
> involving EAP.
> 
> It is commonly a problem on high port density devices.
> Is this practice clearly defined?

  Yes.

> Is it commonly implemented?

  Not in FreeRADIUS.  Our implementation does not track EAP
identifiers by NAS-IP-Address or other attribute sent by the NAS.
Instead, it uses the EAP identifier, source IP address, and the State
attribute.  Since the State attribute is under the control of the
RADIUS server, this means that the "uniqueness" of each session is
under the control of the server, and not the NAS.

  Since proxies may play games with NAS-IP-Address (e.g. translating
private IP's to their own), depending on any attribute under control
of the NAS may result in deployment problems.

  A rough description of the algorithm used is as follows:

  if (EAP start, or EAP identity) {
     allocate unique State Attribute
     insert into "active" queue, with key (EAP identifier, State, source IP)
  } else {
     look up active session in queue, with above key
  }

  The algorithm appears to work in deployment, including home servers
which receive EAP sessions via intermediate RADIUS proxies.

> Is it sufficient to address the Request-ID number space
> "wrap-around" issue?

  For RADIUS Request ID's?  I'm unclear.

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