Re: [radext] Server identity and RFC7585bis

[Jan-Frederik Rieckers <[e-mail]>]

Hi Mark,

Thanks for your explanation.
Unfortunately, I'm still a bit in the dark here, what the error 
condition is, what causes the error and where we could fix that.

To me the problem (or the solution) seems pretty straight-forward, but I 
fear I'm missing something here.

What would the "other open sessions" be?
 From my understanding, if the discovery yielded different servers, they 
switch to the new server and the connections to the old servers 
eventually run into the timeout.

But if other sessions are still open, then either they are also 
configured dynamically (and therefore the DNS records for the second 
domain can just be changed) or it is configured statically, and then the 
problem isn't really with RFC7585.

If you could give an example playbook which server (or admin) does what 
at what time and what the actual and expected outcome would be, that 
would help me a lot to understand it.

Cheers,
Janfred

On 11.04.24 15:50, Mark Grayson (mgrayson) wrote:
> Hi Janfred
> 
> 7585 has the following
> 
> To allow for a change of
> 
> configuration, a RADIUS server SHOULD re-execute the discovery
> 
> algorithm after the Effective TTL that is associated with this
> 
> connection has expired.  The server SHOULD keep the session open
> 
> during this reassessment to avoid closure and immediate reopening of
> 
> the connection should the result not have changed.
> 
> This seems to miss when the existing session should be closed, only 
> covering when it
> 
> should be kept open. It sort of implies that the connection should be 
> closed if the
> 
> discovered host has changed configuration. But that seems to miss the 
> possibility that
> 
> the existing connection may be supporting other open sessions.
> 
> Cheers,
> 
> Mark
> 
> *From: *radext <[e-mail]> on behalf of Jan-Frederik 
> Rieckers <[e-mail]>
> *Date: *Thursday, 11 April 2024 at 13:09
> *To: *[e-mail] <[e-mail]>
> *Subject: *Re: [radext] Server identity and RFC7585bis
> 
> Hi Mark,
> 
> could you provide an example scenario for this? I can't really picture it.
> 
> My naïve understanding is that to phase a server out, you change the SRV
> records to point to a different server, then there should be a timeout
> for the dynamic lookup, and once this timeout triggers and the proxy
> gets the new server, it should redirect all traffic to the new and the
> old shouldn't see any traffic any more.
> 
> If it's something that is missing from RFC7585, then this might be
> another argument why we should work on a 7585bis document.
> 
> Cheers,
> Janfred
> 
> On 10.04.24 09:58, Mark Grayson (mgrayson) wrote:
>> As it relates to 7585, WBA recently had to clarify the same in terms of 
>> cache TTL,
>> 
>> but also recommendation on maximum TCP lifetime for dynamic connections:
>> 
>> there are some scenarios where significant traffic between access providers
>> 
>> and identity providers means any idle timeout is never triggered and the
>> 
>> dynamic connection becomes persistent, which then prevents the identity
>> 
>> provider from gracefully terminating connections on an old server instance.
>> 
>>   * M
> 
> -- 
> Herr Jan-Frederik Rieckers
> Security, Trust & Identity Services
> 
> E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
> Pronomen: er/sein | Pronouns: he/him
> __________________________________________________________________________________
> 
> DFN - Deutsches Forschungsnetz | German National Research and Education
> Network
> Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
> Alexanderplatz 1 | 10178 Berlin
> https://www.dfn.de <https://www.dfn.de>
> 
> Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser |
> Christian Zens
> Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
> VR AG Charlottenburg 7729B | USt.-ID. DE 136623822
> 

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822