Hi,

I've been looking into this more deeply. Using the "limit" field does 
not seem the best way to go, as they are used to construct the sockets, 
but not associated to the lifetime of the REALM or home_server_t 
structures. Even setting the limit->lifetime to 30 does not seem to have 
an effect on the REALM life-cycle.

We might want to:

1) Define a expiration time associated to the home_server_t struct.
#ifdef HAVE_TRUST_ROUTER_TR_DH_H
     time_t    tr_dh_expiration;
#endif

2) When the server is created (i.e. on reception of the TID response), 
assign the expiration time of the key to the server

hs->tr_dh_expiration = tid_srvr_get_expiration(server) // This accessor 
is yet to be done.
                                                        // MUST return 
time_t struct.

3) On the update_required(REALM*) function, within the inner loop, and 
before checking anything else, check whether it has expired, and return 
true in such a case.

     for (i = 0; i < pool->num_home_servers; i++) {
         server = pool->servers[i];
         /*
          * If the server key has expired, we need to update
          */
         if (server->tr_dh_expiration - now < 0) {
             return true;
         }

Thetr_dh_expiration could be associated to the tls field of 
thehome_server_t structure instead, if that seems more natural.

I have tried this in a quick proof-of-concept, and it works using 
"time(NULL) + 60" as a dummy replacement for the missing accessor function.

Hope this helps.

Regards,
Alejandro


El 22/02/17 a las 16:52, Alejandro Pérez Méndez escribió:
> Ok, that raises me another question.
>
> On the RRP (RADIUS client), is the dynamically created REALM structure 
> bound to the lifetime of the TLS socket? On the IDP (RADIUS server) it 
> is, since what you do is to retrieve the key information from the 
> sqlite DB on socket creation, so that's naturally supported. But on 
> the RRP, even if you expire the socket, does it mean that the REALM 
> disappears? If not, when a new request comes, a new socket is created 
> using the same REALM and hence, the same key.
>
> Regards,
> Alejandro
>
> El 22/02/17 a las 15:52, Stefan Paetow escribió:
>>> Had a quick look, and we need to modify the REALM we return an 
>>> fr_socket_limit_t in the home_server_t based on the key lifetime 
>>> sent by the trust router.
>>> Shouldn't be a massive amount of work, thanks for spotting it.
>> Ok, that's the lifetime of the socket, yes? Can you just help me 
>> understand how this changes things?
>>
>> Let's take an example. You have a fresh request, you get the key 
>> lifetime (in this example, 11 minutes) back from the TR, so let's 
>> call that time zero elapsed. So you set lifetime in fr_socket_t to 
>> 660 (11m * 60), yes? However, you don't want to have the socket 
>> hanging around for the entire time (and because you're nice), you set 
>> an idle_timeout of what... 30 sec (the default I think). For the next 
>> 4 minutes, stuff happens. So that's 240 seconds elapsed. After 30 
>> seconds of idle, the socket closes. That's 270 sec elapsed.
>>
>> Then 2 minutes (at 390 sec elapsed) later you get another request, so 
>> you need to set the socket up again. You don't set the lifetime back 
>> to 660, right? You set it to (660 - 390) = 270 sec, because the key 
>> will expire then?
>>
>> Or is this countdown handled somewhere?
>>
>> Regards
>>
>> Stefan Paetow
>> Moonshot Industry & Research Liaison Coordinator
>>
>> t: +44 (0)1235 822 125
>> gpg: 0x3FCE5142
>> xmpp: [log in to unmask]
>> skype: stefan.paetow.janet
>>
>> jisc.ac.uk
>>
>> Jisc is a registered charity (number 1149740) and a company limited 
>> by guarantee which is registered in England under Company No. 
>> 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One 
>> Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
>>
>>
>>
>>