On Mar 9, 2015, at 7:04 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
recv foo — run this section when receiving a packet “foo”. process foo - run this section to process a packet “foo” send foo - run this section before sending a packet “foo”
The coder part of me says "yes".
The sysadmin part says "when I was learning RADIUS, it was hard enough to work out what was happening, let alone know what each packet did on the network, so no”.
Hmm… I was thinking it would help. Q: What does the server do when it receives an Access-Request packet? A: process it through a “receive Access-Request” section. That seems pretty simple. Sure, it means people have to know what Access-Requests are, but… if you don’t know that, you won’t get very far with RADIUS.
The idea is great, but I'm not sure that the naming will be any more helpful for those not well versed in RADIUS (and it's obvious from the list that there are many people in this situation; that's just a fact of life, many probable only run the RADIUS server as a part time thing).
Sure. It’s a balance, right. Simple enough that the beginner can understand it, and complicated enough that the expert can get things done. Right now the complexity is a source of frustration and confusion. The code to implement it is awkward. It’s hard to reason about what each section does. The sections aren’t really handled consistently.
However, it _might_ be very powerful and work with some sort of templating or aliasing feature. This is completely off the top of my head, but maybe something like
Yes, that would be the idea. The templating would allow the *current* configuration to work unchanged. But would also allow for *updated* configurations to work better. And it would make the code much simpler.
This would also mean that a more advanced admin could quite happily write
send Access-Challenge { ... }
Exactly.
which doesn't appear at all in the default configuration, but could be useful in some circumstances.
You could also have for example:
sent Access-Accept { }
which gets called only after the packet has actually been sent, for final logging. Again, probably not in the default config (or aliased as "log-successful-authentication" maybe).
Hmm… maybe. I’d prefer to avoid that for a host of reasons.
process Access-Request == authenticate (mostly)
I'm not sure that the current config is helpful. It's quite confusing to work out which sections have sub-sections called automatically, or at least it was when still on the learning curve. So
Exactly.
Two ideas come to mind. The first is adding a parameter to the section name, such as (in current config terminology):
authenticate PAP { pap }
Sure, that could work.
The other, slightly less clear way is pull the hidden switch out into the open:
That I find a bit more confusing.
No stones :). Just don't think exposing RADIUS packets directly to end users at first sight is the most helpful thing. Yes, they'll hopefully learn them in time, so giving the tools to do this is good, but terms such as "pre-authentication" or "authenticate-user" are easier to begin with.
I think some of the above could also be a bit confusing to the advanced admin, such as:
send Access-Accept recv Access-Accept
are two _totally_ different things on opposide sides of the server (one as a server, the other as a client), yet look surprisingly similar. I'm not sure what else to suggest though.
Me either. They’re similar, but *named consistently*. If you get confused as to what’s going on, just look at the name. Alan DeKok.