Bug on Accouting-Requests proxying

Geoffroy Arnoud garnoud at yahoo.co.uk
Fri Oct 27 10:02:04 CEST 2006


FreeRADIUS 1.1.3 bug - Accounting requests reemission by FreeRADIUS

In file "main\request_list.c", function "refresh_request".

In the case of an accounting request (request->proxy->code == 
PW_ACCOUNTING_REQUEST), FreeRADIUS adds to the proxied packet the 
attribute "Acct-Delay-Time" (or updates it, if it was present in 
previous emission) with value set to the time difference between current 
time and time of initial proxied request.

According to RFC 2866, chapter 4.1 :

"The Identifier field MUST be changed whenever the content of the 
Attributes field changes, and whenever a valid reply has been received 
for a previous request.  For retransmissions where the contents are 
identical, the Identifier MUST remain unchanged.

Note that if Acct-Delay-Time is included in the attributes of an 
Accounting-Request then the Acct-Delay-Time value will be updated when 
the packet is retransmitted, changing the content of the Attributes 
field and requiring a new Identifier and Request Authenticator."

FreeRADIUS updates the content of the packet when reemitting the 
accounting request, but does not change the Identifier. Thus, those 
packets sent after the first one are *not* true reemissions.

This is a problem to us. For instance, we have the following setup :

A client (A) sending an accounting request to FreeRADIUS (B), which 
retransmits the request to a proxy FreeRADIUS server (C). FreeRADIUS C 
is slow to respond, so FreeRADIUS B reemits the request, with different 
packet attributes (Acct-Delay-Time added), but keeps the same identifier.

FreeRADIUS C receives the second request, but discards it since it has 
the same identifier as the request currently being processed. FreeRADIUS 
C then decides to finally respond (to the first request). FreeRADIUS B 
receives this response, and verifies if the request (the reemission) and 
response match. They do not, thus FreeRADIUS B drops the response and 
logs an error.

FreeRADIUS should either :
- NOT add Acct-Delay-Time attribute in accounting reemissions, thus 
preserving the content of the attributes in the packet.
- or, add an Acct-Delay-Time, but change the identifier and handle the 
proxied packet as a new request.

The second solution seems overly complicated, because FreeRADIUS would 
have to handle the second proxied request as a completely new request, 
but would also have keep the first one, as the proxy server can respond 
to any of the reemissions.

The first solution is very simple to correct: it simply involves 
removing the block "if (request->proxy->code == PW_ACCOUNTING_REQUEST) 
{" in function "refresh_request" of file "main\request_list.c".

I don't know if Acct-Delay-Time attribute is really useful to someone, 
I've never seen it used in any implementation of a RADIUS server. 
Anyhow, it seems way too much hassle to correctly handle this attribute 
in accounting reemissions.

If tehre is any any objection, we will develop a patch to remove Acct-Delay-Time and provide it soon.

Best regards,

Geoff.




	

	
		
___________________________________________________________________________ 
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses 
http://fr.answers.yahoo.com




More information about the Freeradius-Devel mailing list