Now we've gone completely insane
In the "master" branch, we now have two new protocols. ARP: https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-avai... BFD: https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-avai... We've been using BFD in customer sites for primary / secondary failover detection. It's weird, but useful. After 18 months, we've now made it public. ARP was done "just 'cause". i.e. adding a new protocol to the server is now trivial: $ wc -l src/modules/proto_arp/*.c 318 src/modules/proto_arp/proto_arp.c If anyone wants to add a schema for ARP, and implement the detection rules from "arpwatch", that would be welcome. :) Alan DeKok.
What is BFP? A google search for "bfp protocol" yields results describing in-vitro fertilisation... Josh. On 08/11/2013 17:39, "Alan DeKok" <aland@deployingradius.com> wrote:
In the "master" branch, we now have two new protocols.
ARP:
https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-av ailable/arp
BFD:
https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-av ailable/bfd
We've been using BFD in customer sites for primary / secondary failover detection. It's weird, but useful. After 18 months, we've now made it public.
ARP was done "just 'cause".
i.e. adding a new protocol to the server is now trivial:
$ wc -l src/modules/proto_arp/*.c 318 src/modules/proto_arp/proto_arp.c
If anyone wants to add a schema for ARP, and implement the detection rules from "arpwatch", that would be welcome. :)
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
bf DDDD On Nov 8, 2013, at 12:43 PM, Josh Howlett <Josh.Howlett@ja.net> wrote:
What is BFP? A google search for "bfp protocol" yields results describing in-vitro fertilisation...
Josh.
On 08/11/2013 17:39, "Alan DeKok" <aland@deployingradius.com> wrote:
In the "master" branch, we now have two new protocols.
ARP:
https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-av ailable/arp
BFD:
https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-av ailable/bfd
We've been using BFD in customer sites for primary / secondary failover detection. It's weird, but useful. After 18 months, we've now made it public.
ARP was done "just 'cause".
i.e. adding a new protocol to the server is now trivial:
$ wc -l src/modules/proto_arp/*.c 318 src/modules/proto_arp/proto_arp.c
If anyone wants to add a schema for ARP, and implement the detection rules from "arpwatch", that would be welcome. :)
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Not to sound like a nitpicking ass but the first line in the bfd source says "Bidirectional Failover Detection” Shouldn't that be Forwarding Detection? On Nov 8, 2013, at 12:39 PM, Alan DeKok <aland@deployingradius.com<mailto:aland@deployingradius.com>> wrote: In the "master" branch, we now have two new protocols. ARP: https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-avai... BFD: https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/sites-avai... We've been using BFD in customer sites for primary / secondary failover detection. It's weird, but useful. After 18 months, we've now made it public. ARP was done "just 'cause". i.e. adding a new protocol to the server is now trivial: $ wc -l src/modules/proto_arp/*.c 318 src/modules/proto_arp/proto_arp.c If anyone wants to add a schema for ARP, and implement the detection rules from "arpwatch", that would be welcome. :) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 8 Nov 2013, at 17:46, Gabriel Blanchard <gabe@teksavvy.ca> wrote:
Not to sound like a nitpicking ass but the first line in the bfd source says
"Bidirectional Failover Detection”
Shouldn't that be Forwarding Detection?
It should :) and that's BFD not BFP... and that isn't the most insane thing planned... ha.. ha.. ha. Arran Cudbard-Bell <a.cudbardb@freeradius.org> ... Development Team
Hi, of course...the obvious question is when are we able to do IPv6 ND and RA checks? ;-) PS any update on when TACACS+ comes into the tale? :-) alan
On 9 Nov 2013, at 14:36, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
of course...the obvious question is when are we able to do IPv6 ND and RA checks? ;-)
PS any update on when TACACS+ comes into the tale? :-)
Yeah, i've had a few requests for that too. The main reason for using it is the per command authorisation on Cisco kit, which could be done with RADIUS but apparently isn't supported... There was a draft RFC publicised a while back? Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
A.L.M.Buxey@lboro.ac.uk wrote:
of course...the obvious question is when are we able to do IPv6 ND and RA checks? ;-)
Send a patch. Base it on proto_arp, because it doesn't have to send packets. If it needs to send packets, it's a little more complex.
PS any update on when TACACS+ comes into the tale? :-)
TACACS+ is annoying. It's only 2K LoC, but there's minimal demand for it. Alan DeKok.
On 9 Nov 2013, at 16:36, Alan DeKok <aland@deployingradius.com> wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
of course...the obvious question is when are we able to do IPv6 ND and RA checks? ;-)
Send a patch. Base it on proto_arp, because it doesn't have to send packets.
If it needs to send packets, it's a little more complex.
PS any update on when TACACS+ comes into the tale? :-)
TACACS+ is annoying. It's only 2K LoC, but there's minimal demand for it.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Sat, Nov 09, 2013 at 08:36:35AM -0800, Alan DeKok wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
PS any update on when TACACS+ comes into the tale? :-)
TACACS+ is annoying. It's only 2K LoC, but there's minimal demand for it.
Weirdly enough, just two days ago I looked at switch authentication again, and (as often is the case) got annoyed at Cisco for not allowing RADIUS to do command authorization. I had a very brief look to see how hard it would be do do TACACS+ in FreeRADIUS, but couldn't easily find any documentation on it. I'm semi-interested in this, but I guess that's what you call "minimal demand". I would look at writing some code for it, but in all honesty I likely haven't got time at present (my wife is not going to appreciate it if I spend paternity leave coding...) Cheers Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 9 Nov 2013, at 23:26, Matthew Newton <mcn4@LEICESTER.AC.UK> wrote:
On Sat, Nov 09, 2013 at 08:36:35AM -0800, Alan DeKok wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
PS any update on when TACACS+ comes into the tale? :-)
TACACS+ is annoying. It's only 2K LoC, but there's minimal demand for it.
Weirdly enough, just two days ago I looked at switch authentication again, and (as often is the case) got annoyed at Cisco for not allowing RADIUS to do command authorization. I had a very brief look to see how hard it would be do do TACACS+ in FreeRADIUS, but couldn't easily find any documentation on it.
I'm semi-interested in this, but I guess that's what you call "minimal demand". I would look at writing some code for it, but in all honesty I likely haven't got time at present (my wife is not going to appreciate it if I spend paternity leave coding...)
It's not that minimal. I've come across three or four cases of people using it as justification to keep ACS. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
It's not that minimal. I've come across three or four cases of people using it as justification to keep ACS.
You can add us to the list of requiring ACS in order to support TACACS+. I bet a better description is non-vocal as opposed to minimal. Unfortunately, I don't have the time to help develop it, but I could help with testing and troubleshooting.
Hi,
It's not that minimal. I've come across three or four cases of people using it as justification to keep ACS.
You can add us to the list of requiring ACS in order to support TACACS+. I bet a better description is non-vocal as opposed to minimal. Unfortunately, I don't have the time to help develop it, but I could help with testing and troubleshooting.
Not that I have anything productive (=code) to add - but yes, we also have a Radiator server in a dark corner whose sole purpose is to proxy TACACS+ as RADIUS to FreeRADIUS. I'm sure a TACACS+ module would find quite a few friends. Greetings, Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg 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
Stefan Winter wrote:
Not that I have anything productive (=code) to add - but yes, we also have a Radiator server in a dark corner whose sole purpose is to proxy TACACS+ as RADIUS to FreeRADIUS. I'm sure a TACACS+ module would find quite a few friends.
OK... we'll add it to the list. The future plan for FreeRADIUS is now: Version 2: long term stability, no new features Version 3: minor new features as appropriate Version 4: massive re-write / cleanup, with many new protocols i.e. don't use git "master". The API may change massively from one day to the next. Alan DeKok.
Stefan Winter wrote:
Not that I have anything productive (=code) to add - but yes, we also have a Radiator server in a dark corner whose sole purpose is to proxy TACACS+ as RADIUS to FreeRADIUS. I'm sure a TACACS+ module would find quite a few friends.
OK... we'll add it to the list.
The future plan for FreeRADIUS is now:
Version 2: long term stability, no new features
Version 3: minor new features as appropriate
Version 4: massive re-write / cleanup, with many new protocols
+ diameter ?
On 11 Nov 2013, at 19:03, lscrlstld <lscrlstld@gmail.com> wrote:
Stefan Winter wrote:
Not that I have anything productive (=code) to add - but yes, we also have a Radiator server in a dark corner whose sole purpose is to proxy TACACS+ as RADIUS to FreeRADIUS. I'm sure a TACACS+ module would find quite a few friends.
OK... we'll add it to the list.
The future plan for FreeRADIUS is now:
Version 2: long term stability, no new features
Version 3: minor new features as appropriate
Version 4: massive re-write / cleanup, with many new protocols
+ diameter ?
Maybe. That'll happen faster if a company wishes to sponsor it, as with the TACACS+. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
participants (9)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Gabriel Blanchard -
Garber, Neal -
Josh Howlett -
lscrlstld -
Matthew Newton -
Stefan Winter