How are TLS session freed when the exchange fails?

[Yannick Koehler]

Thanks a lot and my apologies, seems like I looked at the wrong level
(tls instead of EAP for the session lifecycle).

I should have got that, started to read the code of the version I had
1.1.x and failed to re-read fully the code of 3.0.1 after my upgrade.


2014-02-18 15:36 GMT-05:00 Alan DeKok <aland at deployingradius.com>:
> Yannick Koehler wrote:
>>   First, I am new to this mailing list, so I am trying to be extra
>> careful.  I am using FreeRADIUS locally and its memory in a particular
>> situation keep increasing by a lot.  Basically, I see a RADIUS
>> exchange that fails (timeout) before reaching the ACCEPT/REJECT.  I
>> traced the memory and debugged a lot to find out that the
>> tls_new_session() inside tls.c is invoked and allocated a
>> tls_session_t of 64k, then that structure is kept in memory without
>> any means that I could found to be cleared when the RADIUS exchanged
>> terminate abruptly.
>
>   See "max_sessions" in the eap module.  Set it to "2", and you'll see
> that the third session will be refused.
>
>   See also "timer_expire".  Set it to "5", and when you try a new EAP
> session, any sessions older than 5 seconds will be removed.
>
>>   I can repeat this over and over and there appear to be no limit as
>> to how much FreeRADIUS can steal from my main memory.  Considering
>> that I saw that memory leak in the past are seen as security issue, I
>> am therefore wondering if I am right or not.  I could not find any
>> timeout or clean up behavior to ensure that first the number of TLS
>> session is capped and second that if the RADIUS exchange is stopped
>> before the end that the associated tls session gets cleared, so I help
>> here would be appreciated.
>
>   The tls data structure is tied to an EAP session.  The EAP session is
> managed by a handler.  That handler is in turn managed.  See
> src/modules/rlm_eap/mem.c.
>
>>  One could reproduce something like that by sending a RADIUS Access
>> Request with a EAP Identity Response and at the reception of the
>> RADIUS Access Challenge, just ignore it and keep sending new RADIUS
>> Access Request with new EAP Identity Response.
>
>   Try it with the above configuration.  You should see that there are
> limits both on the number of sessions, and how long each session is
> allowed to last.
>
>   Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html



-- 
Yannick Koehler
Courriel: yannick at koehler.name
Blog: http://corbeillepensees.blogspot.com