FR 3.0 radsec : dynamic home server discovery status
Hello, We are upgrading our federation eduroam servers to Radius over tcp. Regarding the dynamic home server discovery feature through naptr record, is it available in FR 3.0 ? I don't think so, but I'm not sure. Regards, Arnaud Lauriou
On 3 Mar 2020, at 13:46, Arnaud LAURIOU <arnaud.lauriou@renater.fr> wrote:
Hello,
We are upgrading our federation eduroam servers to Radius over tcp.
Why the reason to use TCP instead of UDP? Just curiosity….
Regarding the dynamic home server discovery feature through naptr record, is it available in FR 3.0 ?
We don’t support NAPTR records.
I don't think so, but I'm not sure.
Regards,
Arnaud Lauriou - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Mar 3, 2020, at 11:46 AM, Arnaud LAURIOU <arnaud.lauriou@renater.fr> wrote:
We are upgrading our federation eduroam servers to Radius over tcp. Regarding the dynamic home server discovery feature through naptr record, is it available in FR 3.0 ? I don't think so, but I'm not sure.
It doesn't, sorry. Generally if there's no reference to something in the configuration files, the server doesn't do it. Alan DeKok.
On Mar 3, 2020, at 12:10 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 3, 2020, at 11:46 AM, Arnaud LAURIOU <arnaud.lauriou@renater.fr> wrote:
We are upgrading our federation eduroam servers to Radius over tcp. Regarding the dynamic home server discovery feature through naptr record, is it available in FR 3.0 ? I don't think so, but I'm not sure.
It doesn't, sorry.
Generally if there's no reference to something in the configuration files, the server doesn't do it.
I wasn't aware that anyone was doing dynamic home server discovery. I know there's a standard for it, but wasn't aware there was support within the federation. Have you got any official docs? It's not that hard to implement in v4. Many Thanks, -Arran
hi,
I wasn't aware that anyone was doing dynamic home server discovery. I know there's a standard for it, but wasn't aware there was support within the federation.
oh yes. at the national level theres been a few federations using it to then send the requests directly to the relevant federation and not through the very top level proxies. but for end sites using it directly. not much lift (historically thats been due to individual sites not doing relevant logging so the national proxies lose visibility of traffic/usage alan
March 4, 2020 12:26 AM, "Alan Buxey" <alan.buxey@gmail.com> wrote:
hi,
I wasn't aware that anyone was doing dynamic home server discovery. I know there's a standard for it, but wasn't aware there was support within the federation.
oh yes. at the national level theres been a few federations using it to then send the requests directly to the relevant federation and not through the very top level proxies. but for end sites using it directly. not much lift (historically thats been due to individual sites not doing relevant logging so the national proxies lose visibility of traffic/usage
I think it is also used in (Cisco) OpenRoaming.
Hello, many hundreds of realms set NAPTR records in eduroam. Those typically point to an approximate dozen of country-level endpoints which take the traffic from there over RADIUS/UDP. Similarly, eduroam hotspots typically send traffic via RADIUS/UDP to their country-level, and those do the NAPTR lookups to find the destination country server. That way, dynamic lookups and shorter proxy chains are possible, but the complexity of having TLS certs for the realms and hotspots directly goes away. To be honest, the lack of NAPTR lookup capability is my #1 reason why I'm using Radiator and radsecproxy as the two RADIUS implementations for my own country-level servers. Both allow dynamic lookups. Greetings, Stefan Winter Am 03.03.20 um 23:25 schrieb Alan Buxey:
hi,
I wasn't aware that anyone was doing dynamic home server discovery. I know there's a standard for it, but wasn't aware there was support within the federation. oh yes. at the national level theres been a few federations using it to then send the requests directly to the relevant federation and not through the very top level proxies. but for end sites using it directly. not much lift (historically thats been due to individual sites not doing relevant logging so the national proxies lose visibility of traffic/usage
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On Mar 13, 2020, at 8:57 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
many hundreds of realms set NAPTR records in eduroam. Those typically point to an approximate dozen of country-level endpoints which take the traffic from there over RADIUS/UDP.
That makes sense.
To be honest, the lack of NAPTR lookup capability is my #1 reason why I'm using Radiator and radsecproxy as the two RADIUS implementations for my own country-level servers. Both allow dynamic lookups.
We'll take a look at this for v3. If it's important to the community, we're happy to add features. The main concern is how much needs to change in v3. The architecture there is fairly limited for things like dynamic DNS queries. If admins are happy with *blocking* DNS queries, it's a lot easier to add. And then if DNS goes down, so does FreeRADIUS. But the solution there is "don't do that..." Alan DeKok.
On Mar 13, 2020, at 9:54 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 13, 2020, at 8:57 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
many hundreds of realms set NAPTR records in eduroam. Those typically point to an approximate dozen of country-level endpoints which take the traffic from there over RADIUS/UDP.
That makes sense.
To be honest, the lack of NAPTR lookup capability is my #1 reason why I'm using Radiator and radsecproxy as the two RADIUS implementations for my own country-level servers. Both allow dynamic lookups.
Out of interest, is it a mix of UDP+DTLS and TCP+TLS? Is there a way of specifying a preference via the NAPTR records? - For v3 I think poking via radmin to add new destinations might be a reasonably simple way to do this asynchronously. Request comes in for new realm, calls exec to trigger a script to do the resolution and insert the realm info via radmin (maybe just have the ability to define new realms via config snippets?). FR doesn't responsd to the original request. Retransmit comes in, gets forwarded to realm that's now magically appeared. Synchronisation for the realm rbtree would be a pain, but as this is relatively low volume, maybe just add a toggle that puts a mutex around the tree? - For v4 the other thing that occurred to me, is that it wouldn't be *that* hard to fix the exec calls to be async. You just need to stick the server ends of stdout/stderr into the event loop. I think kqueue also has a notification system for process exits too... So one quick/hacky way of doing the lookups could just be calling out to dig and parsing the results. Actually adding radsec and dynamic realm support is much much easier in v4. -Arran
Arran wrote:
Synchronisation for the realm rbtree would be a pain, but as this is relatively low volume, maybe just add a toggle that puts a mutex around the tree?
I think locking primitives for rbtrees were something I tackled in my DDDS tree. Looking... yeah... https://github.com/skids/freeradius-server/commit/e5f3da60317a68657587555a36...
On Mar 13, 2020, at 11:57 AM, Brian Julin <BJulin@clarku.edu> wrote:
I think locking primitives for rbtrees were something I tackled in my DDDS tree.
Looking... yeah...
https://github.com/skids/freeradius-server/commit/e5f3da60317a68657587555a36...
The code in that branch looks pretty good. If it still works, it would be good to add it to v3. Alan DeKok.
Alan DeKok wrote:
The code in that branch looks pretty good. If it still works, it would be good to add it to v3.
I think if I understood correctly the problem is that the subsequent mods to rlm_unbound to more correctly integrate it into the event loop use an alternate pathway through the unbound API which cannot take advantage of unbound's parser for NAPTR records. But at this point I've probably forgotten more about all that than I learned in the first place :-) BTW, as far as why I stopped working on that... I'm at a SP/IDP not a federation, and it looked like the prospects of DDDS were dimming at least here in the USA -- since even using TCP/TLS was experimental with the federation servers and was discontinued during an upgrade. The workings of the federation servers were pretty opaque from where I was standing so it looked like another standard that was going to get about as much market share as DNSSec... which is to say even less used than IPv6. - List info/subscribe/unsubscribe? See https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.freeradius.org%2Flist%2Fusers.html&data=02%7C01%7Cbjulin%40clarku.edu%7Caf2e814795294d7810ff08d7c781adb0%7Cb5b2263d68aa453eb972aa1421410f80%7C1%7C0%7C637197232094454443&sdata=yrgwUsBt2DXPyjagnPKam%2BNqZLeX8CaNAFspzP7E1%2Bw%3D&reserved=0
hi,
Out of interest, is it a mix of UDP+DTLS and TCP+TLS?
mainly TCP+TLS IIRC. the issue with using UDP+DTLS (one of anyway) is the lack of connection which can be useful when there is ongoing traffic , using TCP avoids fragmented UDP packets being chucked away by overzealous end point protection... alan
On Mar 13, 2020, at 2:20 PM, Alan Buxey <alan.buxey@gmail.com> wrote:
hi,
Out of interest, is it a mix of UDP+DTLS and TCP+TLS?
mainly TCP+TLS IIRC. the issue with using UDP+DTLS (one of anyway) is the lack of connection which can be useful when there is ongoing traffic , using TCP avoids fragmented UDP packets being chucked away by overzealous end point protection...
Yeah I was thinking for mobile APs and that sort of thing. Lots of ephemeral connections. -Arran
On Mar 13, 2020, at 11:44 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
For v3 I think poking via radmin to add new destinations might be a reasonably simple way to do this asynchronously.
I agree.
Request comes in for new realm, calls exec to trigger a script to do the resolution and insert the realm info via radmin (maybe just have the ability to define new realms via config snippets?). FR doesn't responsd to the original request.
Retransmit comes in, gets forwarded to realm that's now magically appeared.
Sure.
Synchronisation for the realm rbtree would be a pain, but as this is relatively low volume, maybe just add a toggle that puts a mutex around the tree?
There's already a mutex for the moonshot / trust router stuff.
Actually adding radsec and dynamic realm support is much much easier in v4.
Yeah. One simple reason is that in v4, the realms are *not* part of the core server configuration / code. So it's easy to add / edit / delete them. Alan DeKok.
Arran, Maybe we could use the libcares instead of parser the dig output. e.g: [jpereira@jorge-sugarloaf sample-c-ares.git]$ ./naptr 0.2.0.1.1.6.5.1.0.3.1.loligo.com <http://loligo.com/>. [**] Looking for NAPTR records from 0.2.0.1.1.6.5.1.0.3.1.loligo.com <http://loligo.com/>. [1] { .order=25, .preference=100, .flags='u', .service='E2U+sip', .regexp='!^\+13015611020$!sip:2203@sip.fox-den.com!' <sip:2203@sip.fox-den.com!'> } [2] { .order=21, .preference=100, .flags='u', .service='E2U+tel', .regexp='!^\+13015611020$!tel:+14155551212!' <tel:+14155551212!'> } [3] { .order=30, .preference=100, .flags='u', .service='E2U+sip', .regexp='!^\+*([^\*]*)!sip:\1@sip-3.fox-den.com!' <sip:\1@sip-3.fox-den.com!'> } [4] { .order=26, .preference=100, .flags='u', .service='E2U+sip', .regexp='!^\+13015611020$!sip:1234@sip-2.fox-den.com!' <sip:1234@sip-2.fox-den.com!'> } [5] { .order=55, .preference=100, .flags='u', .service='E2U+mailto', .regexp='!^\+13015611020$!mailto:jtodd@fox-den.com <mailto:jtodd@fox-den.com>!' } [6] { .order=10, .preference=100, .flags='u', .service='E2U+tel', .regexp='!^\+13015611020$!tel:+12125551212!' <tel:+12125551212!'> } [jpereira@jorge-sugarloaf sample-c-ares.git]$ Same as “dig” [jpereira@jorge-sugarloaf sample-c-ares.git]$ dig NAPTR 0.2.0.1.1.6.5.1.0.3.1.loligo.com <http://loligo.com/>. +short 26 100 "u" "E2U+sip" "!^\\+13015611020$!sip:1234@sip-2.fox-den.com <sip:1234@sip-2.fox-den.com>!" . 25 100 "u" "E2U+sip" "!^\\+13015611020$!sip:2203@sip.fox-den.com <sip:2203@sip.fox-den.com>!" . 21 100 "u" "E2U+tel" "!^\\+13015611020$!tel:+14155551212 <tel:+14155551212>!" . 30 100 "u" "E2U+sip" "!^\\+*([^\\*]*)!sip:\\1@sip-3.fox-den.com <sip:\\1@sip-3.fox-den.com>!" . 10 100 "u" "E2U+tel" "!^\\+13015611020$!tel:+12125551212 <tel:+12125551212>!" . 55 100 "u" "E2U+mailto" "!^\\+13015611020$!mailto:jtodd@fox-den.com <mailto:jtodd@fox-den.com>!" . [jpereira@jorge-sugarloaf sample-c-ares.git]$ --- Jorge Pereira jpereira@freeradius.org
On 13 Mar 2020, at 12:44, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Mar 13, 2020, at 9:54 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 13, 2020, at 8:57 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
many hundreds of realms set NAPTR records in eduroam. Those typically point to an approximate dozen of country-level endpoints which take the traffic from there over RADIUS/UDP.
That makes sense.
To be honest, the lack of NAPTR lookup capability is my #1 reason why I'm using Radiator and radsecproxy as the two RADIUS implementations for my own country-level servers. Both allow dynamic lookups.
Out of interest, is it a mix of UDP+DTLS and TCP+TLS?
Is there a way of specifying a preference via the NAPTR records?
-
For v3 I think poking via radmin to add new destinations might be a reasonably simple way to do this asynchronously.
Request comes in for new realm, calls exec to trigger a script to do the resolution and insert the realm info via radmin (maybe just have the ability to define new realms via config snippets?). FR doesn't responsd to the original request.
Retransmit comes in, gets forwarded to realm that's now magically appeared.
Synchronisation for the realm rbtree would be a pain, but as this is relatively low volume, maybe just add a toggle that puts a mutex around the tree?
-
For v4 the other thing that occurred to me, is that it wouldn't be *that* hard to fix the exec calls to be async. You just need to stick the server ends of stdout/stderr into the event loop. I think kqueue also has a notification system for process exits too...
So one quick/hacky way of doing the lookups could just be calling out to dig and parsing the results.
Actually adding radsec and dynamic realm support is much much easier in v4.
-Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <http://www.freeradius.org/list/users.html>
On Mar 13, 2020, at 2:49 PM, Jorge Pereira <jpereira@freeradius.org> wrote:
Arran,
Maybe we could use the libcares instead of parser the dig output.
We can't yield requests in v3, so there's no way to use an asynchronous DNS resolution library. getdns seems to be the best candidate for something in v4, as much as I hate to throw away the stuff I did for libunbound :(. -Arran
On 3/3/20 11:01 PM, Arran Cudbard-Bell wrote:
On Mar 3, 2020, at 12:10 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 3, 2020, at 11:46 AM, Arnaud LAURIOU <arnaud.lauriou@renater.fr> wrote:
We are upgrading our federation eduroam servers to Radius over tcp. Regarding the dynamic home server discovery feature through naptr record, is it available in FR 3.0 ? I don't think so, but I'm not sure. It doesn't, sorry.
Generally if there's no reference to something in the configuration files, the server doesn't do it. I wasn't aware that anyone was doing dynamic home server discovery. I know there's a standard for it, but wasn't aware there was support within the federation.
Have you got any official docs? It's not that hard to implement in v4.
Well the eduroam RFC (7593) has a section about dynamic discovery. I am quite in favour for this feature to be implemented ... Regards, Arnaud Lauriou
On Mar 4, 2020, at 4:48 AM, Arnaud LAURIOU <arnaud.lauriou@renater.fr> wrote:
Well the eduroam RFC (7593) has a section about dynamic discovery. I am quite in favour for this feature to be implemented ...
It might not be *too* difficult to do in v3. But... it would involve some fairly detailed work. We're buy with v4 at the moment, among other things. :( v4 doesn't yet have all of the functionality of v3 (i.e. radsec), but the rest of the functionality far surpasses v3. And, it's the design we've been working towards for 10 years. Alan DeKok.
On Mar 4, 2020, at 4:48 AM, Arnaud LAURIOU <arnaud.lauriou@renater.fr> wrote:
Well the eduroam RFC (7593) has a section about dynamic discovery. I am quite in favour for this feature to be implemented ... It might not be *too* difficult to do in v3. But... it would involve some fairly detailed work.
In v3 we've got the rlm_realm module, which we use for the Trust Router protocol, which is somewhat a dynamic discovery mechanism. Would it be very difficult to add another discovery mechanism there? Cheers
We're buy with v4 at the moment, among other things. :(
v4 doesn't yet have all of the functionality of v3 (i.e. radsec), but the rest of the functionality far surpasses v3. And, it's the design we've been working towards for 10 years.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Alejandro Perez-Mendez Technical Specialist (AAA), Trust & Identity Skype alejandro_perez_mendez jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under company number. 05747339, VAT number GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice
On Mar 4, 2020, at 9:53 AM, Alejandro Perez-Mendez <alex.perez-mendez@JISC.AC.UK> wrote:
In v3 we've got the rlm_realm module, which we use for the Trust Router protocol, which is somewhat a dynamic discovery mechanism. Would it be very difficult to add another discovery mechanism there?
The issue is DNS lookups. We would need to do them via some async method, otherwise the server just shuts down. The internals of v4 are 100% async, so this is almost trivial to do there. In v3, it's just a lot more complex. Alan DeKok.
El 4/3/20 a las 16:16, Alan DeKok escribió:
On Mar 4, 2020, at 9:53 AM, Alejandro Perez-Mendez <alex.perez-mendez@JISC.AC.UK> wrote:
In v3 we've got the rlm_realm module, which we use for the Trust Router protocol, which is somewhat a dynamic discovery mechanism. Would it be very difficult to add another discovery mechanism there? The issue is DNS lookups. We would need to do them via some async method, otherwise the server just shuts down.
That's right, but for the TR we make this sync anyway, and it works good enough, since the blocking method only happens once per realm during the first attempt. Just mentioning that for providing a just-works solution it might be an approach to take into account.
The internals of v4 are 100% async, so this is almost trivial to do there. In v3, it's just a lot more complex.
Agreed. But for v3 it could be synchronous. Best
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Alejandro Perez-Mendez Technical Specialist (AAA), Trust & Identity Skype alejandro_perez_mendez jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under company number. 05747339, VAT number GB 197 0632 86. Jisc’s registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 02881024, VAT number GB 197 0632 86. The registered office is: 4 Portwall Lane, Bristol, BS1 6NB. T 0203 697 5800. For more details on how Jisc handles your data see our privacy notice here: https://www.jisc.ac.uk/website/privacy-notice
There's some stale... geez 7 years stale I can't believe it's been that long... code in my github tree that does async lookups via NAPTR. But it's just the lookup. It doesn't touch the home server config to add or remove home servers and I think given what the core devs say about v4, you'd be much better off trying to pull that off under v4's architecture. https://github.com/skids/freeradius-server/tree/ddds
Alejandro Perez-Mendez <alex.perez-mendez@jisc.ac.uk> El 4/3/20 a las 16:16, Alan DeKok escribió:
On Mar 4, 2020, at 9:53 AM, Alejandro Perez-Mendez <alex.perez-mendez@JISC.AC.UK> wrote:
In v3 we've got the rlm_realm module, which we use for the Trust Router protocol, which is somewhat a dynamic discovery mechanism. Would it be very difficult to add another discovery mechanism there? The issue is DNS lookups. We would need to do them via some async method, otherwise the server just shuts down.
That's right, but for the TR we make this sync anyway, and it works good enough, since the blocking method only happens once per realm during the first attempt.
Just mentioning that for providing a just-works solution it might be an approach to take into account.
The internals of v4 are 100% async, so this is almost trivial to do there. In v3, it's just a lot more complex.
Agreed. But for v3 it could be synchronous.
There's some stale... geez 7 years stale I can't believe it's been that long... code in my github tree that does async lookups via NAPTR over libunbound. But it's just the lookup. It doesn't touch the home server config to add or remove home servers and I think given what the core devs say about v4, you'd be much better off trying to pull that off under v4's architecture. You might be able to cram that into doing a sync lookup at boot time and then figure out how to alter the config before the home servers are instantiated, I dunno. https://github.com/skids/freeradius-server/tree/ddds
On Mar 4, 2020, at 10:38 AM, Brian Julin <BJulin@clarku.edu> wrote:
There's some stale... geez 7 years stale I can't believe it's been that long... code in my github tree that does async lookups via NAPTR. But it's just the lookup. It doesn't touch the home server config to add or remove home servers and I think given what the core devs say about v4, you'd be much better off trying to pull that off under v4's architecture.
I wrote the async glue for our rlm_unbound module, https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_... but it turns out libunbound doesn't expose the same decode functions to callers that implement their own I/O routines. If someone knowledgable wanted to figure out the decoding, and add a NAPTR xlat (there are multiple existing examples for other record types) then that'd probably move things forward the fastest. -Arran
On Mar 4, 2020, at 4:52 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Mar 4, 2020, at 10:38 AM, Brian Julin <BJulin@clarku.edu> wrote:
There's some stale... geez 7 years stale I can't believe it's been that long... code in my github tree that does async lookups via NAPTR. But it's just the lookup. It doesn't touch the home server config to add or remove home servers and I think given what the core devs say about v4, you'd be much better off trying to pull that off under v4's architecture.
I wrote the async glue for our rlm_unbound module,
https://github.com/FreeRADIUS/freeradius-server/blob/master/src/modules/rlm_...
but it turns out libunbound doesn't expose the same decode functions to callers that implement their own I/O routines.
If someone knowledgable wanted to figure out the decoding, and add a NAPTR xlat (there are multiple existing examples for other record types) then that'd probably move things forward the fastest.
Ah I thought I recognised that GitHub handle :) Well I guess we've found our knowledgable person! -Arran
participants (9)
-
Alan Buxey -
Alan DeKok -
Alejandro Perez-Mendez -
Arnaud LAURIOU -
Arran Cudbard-Bell -
Brian Julin -
Jorge Pereira -
Stefan Winter -
Zenon Mousmoulas