Re: [radext] Proposed charter text based on IETF-115 BoF

[Matthew Newton <[e-mail]>]

On 24/11/2022 18:09, Jan-Frederik Rieckers wrote:
> On 24.11.22 17:51, Matthew Newton wrote:
>> On 24/11/2022 16:23, Jan-Frederik Rieckers wrote:
>>> Of course you can do this locally if you have control over all 
>>> involved servers, but if you don't then this is not possible without 
>>> a flag day 
>>
>> I'm not sure why you would need a flag day? Or a configuration flag.
>>
>> There is no need to update all servers at once, just each hop. The 
>> "upstream" server can be configured to listen on the new SRADIUS port 
>> as well as e.g. 1812/udp. Then the "downstream" servers can in time be 
>> configured to connect over SRADIUS instead of UDP. Once nothing is 
>> using 1812/udp, the "upstream" server is reconfigured to stop 
>> listening on it.
> 
> The problem here is: As far as I understood Bernard (please correct me 
> if I misunderstood something here), the new spec for RADIUS without MD5 
> should run on the same port. And with this, the two variants cannot be 
> used in parallel, or you would have to have a means of negotiation.

draft-dekok-radext-sradius sect.10 requests two new ports.

> Especially in dynamic scenarios (e.g. OpenRoaming or eduroam on national 
> Level) you would have to specify a certain date and time when to switch 
> from the "legacy" RADIUS with MD5 to SRADIUS.

With new ports, national proxies could enable listening on SRADIUS 
immediately. Then as part of institution server configuration give a way 
for sites to identify when the site has enabled SRADIUS (in a similar 
way to sites currently being able to configure UDP or RadSec).

For the situation that e.g. NAPTR records are in use for dynamic 
discovery, using a new service name such as "x-eduroam:sradius" would 
work to identify that a site should use SRADIUS.

-- 
Matthew