Cleanup of the "id" between NAS and radius server
I have a question about any settings that may effect the timing of the re-use of the "Identifier" as per the RFC: *Identifier * The Identifier field is /one octet/, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time. I am currently running radius 2.2.0 and in my radiusd.conf I have: # max_request_time: The maximum time (in seconds) to handle a request. # # Useful range of values: 5 to 120 # max_request_time = 5 # cleanup_delay: The time to wait (in seconds) before cleaning up # a reply which was sent to the NAS. # # The RADIUS request is normally cached internally for a short period # of time, after the reply is sent to the NAS. The reply packet may be # lost in the network, and the NAS will not see it. The NAS will then # re-send the request, and the server will respond quickly with the # cached reply. # # If this value is set too low, then duplicate requests from the NAS # MAY NOT be detected, and will instead be handled as seperate requests. # # If this value is set too high, then the server will cache too many # requests, and some new requests may get blocked. (See 'max_requests'.) # # Useful range of values: 2 to 10 # cleanup_delay = 2 # max_requests: The maximum number of requests which the server keeps # track of. This should be 256 multiplied by the number of clients. # e.g. With 4 clients, this number should be 1024. # # If this number is too low, then when the server becomes busy, # it will not respond to any new requests, until the 'cleanup_delay' # time has passed, and it has removed the old requests. # # If this number is set too high, then the server will use a bit more # memory for no real benefit. # # If you aren't sure what it should be set to, it's better to set it # too high than too low. Setting it to 1000 per client is probably # the highest it should be. # # Useful range of values: 256 to infinity # max_requests = 8500 I have posted my wireshark screen at: http://johnd.oit.gatech.edu/wp-content/uploads/2013/11/wireshark-discarding-... When I am looking at my TCPdumps (debugging duplicate requests) I see a duplicate request come in at Frame 6963 Frame 5475 at 10:20:07 - Access-Request id 76 Frame 5482 at 10:20:07 - Access Challenge response to 5475 id 76 Frame 6963 at 10:20:13 - Duplicate Request says response to this request id 76 is in frame 5482 Now, Frame 6963 is a full 5 seconds past the Access-Challenge of Frame 5482. My question is, is it the "cleanup_delay" setting that cleans up old identifiers for re-use? Does the "max_requests" value have any effect on when the identifiers are ready for re-use? Thanks, - John Douglass, Sr. Systems IT/Architect
I have posted my wireshark screen at:
http://johnd.oit.gatech.edu/wp-content/uploads/2013/11/wireshark-discarding-...
When I am looking at my TCPdumps (debugging duplicate requests) I see a duplicate request come in at Frame 6963
Frame 5475 at 10:20:07 - Access-Request id 76 Frame 5482 at 10:20:07 - Access Challenge response to 5475 id 76 Frame 6963 at 10:20:13 - Duplicate Request says response to this request id 76 is in frame 5482
Now, Frame 6963 is a full 5 seconds past the Access-Challenge of Frame 5482.
We'd have to see the debug output to know what was actually going on there. Wireshark is quite limited in it's duplicate detection. Just because it says there was a duplicate response, it does not mean the cached response was sent in response to a duplicate request. The NAS could be retransmitting something like an EAP Identity-Response, which would prompt an identical Access-Challenge from FreeRADIUS each time it was sent. The EAP fragment is so short that it suggests something like that may be the case.
My question is, is it the "cleanup_delay" setting that cleans up old identifiers for re-use?
It cleans up cached responses. The NAS should NOT re-use an identifier unless it has either timed out the request or received a response. Using the same ID alone does not make a request a retransmission. It has to be a combination of SRC port, SRC IP, DST Port, DST IP, ID and I believe in the case of FreeRADIUS the contents of the authenticator field. If the authenticator field contents changes but the rest of the values are the same, the old response should be removed from the cache, and the server should treat the Access-Requests as a new request. The key word there being *should*, i'll let Alan clarify whether it does or not.
Does the "max_requests" value have any effect on when the identifiers are ready for re-use?
No. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
John Douglass wrote:
I have a question about any settings that may effect the timing of the re-use of the "Identifier" as per the RFC:
The re-use is determined *solely* by the NAS. What's in your radiusd.conf doesn't matter.
I have posted my wireshark screen at:
http://johnd.oit.gatech.edu/wp-content/uploads/2013/11/wireshark-discarding-...
When I am looking at my TCPdumps (debugging duplicate requests) I see a duplicate request come in at Frame 6963
Frame 5475 at 10:20:07 - Access-Request id 76 Frame 5482 at 10:20:07 - Access Challenge response to 5475 id 76 Frame 6963 at 10:20:13 - Duplicate Request says response to this request id 76 is in frame 5482
What you're missing (and Wireshark has wrong) is the length. Frame 5482 has length 153. Frame 6963 has length 264. They are *not* duplicates. They are, in face, completely different. The NAS didn't get a response to 5482. So it re-used the ID, which it's allowed to do. And wireshark didn't notice.
Now, Frame 6963 is a full 5 seconds past the Access-Challenge of Frame 5482.
Which doesn't matter. The NAS is allowed to give up on the request 0.1s after it's sent. It's suggested to *not* give up that quickly, but it's allowed.
My question is, is it the "cleanup_delay" setting that cleans up old identifiers for re-use?
No. That has NOTHING to do with IDs. The NAS is in charge of allocating IDs.
Does the "max_requests" value have any effect on when the identifiers are ready for re-use?
No. See the answer above. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
John Douglass