Hello everyone, Is Freeradius able to send Change of Authorization Messages and Disconnect messages (RFC 3576) According to http://www.freeradius.org/features/ Freeradius supports RFC 3576. According to this http://wiki.freeradius.org/RFC: Freeradius does not support RFC 3576. I can't find any information on the site on how ro configure this.
From this it appears only a test client RadClient is supporting this: http://www.usenet-forums.com/freeradius-users/280002-re-change-authorization...
Is there any development? Has RFC 3576 support has been introduced for Server and not for client. I want to send CoA and DM form the server. Thank you
vmx vmx wrote:
Hello everyone,
Is Freeradius able to send Change of Authorization Messages and Disconnect messages (RFC 3576) According to http://www.freeradius.org/features/ Freeradius supports RFC 3576. According to this http://wiki.freeradius.org/RFC: Freeradius does not support RFC 3576. FreeRADIUS does not currently support 3575, it's on the development roadmap. When support is added to the server core it will only be for *proxying* CoA messages not generating them. You can generate your own CoA messages using the radius client bundled with the server distribution.
It is unlikely that the FreeRADIUS daemon itself will ever support CoA message generation. Arran
I can't find any information on the site on how ro configure this. From this it appears only a test client RadClient is supporting this: http://www.usenet-forums.com/freeradius-users/280002-re-change-authorization...
Is there any development? Has RFC 3576 support has been introduced for Server and not for client. I want to send CoA and DM form the server.
Thank you
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
FreeRADIUS does not currently support 3575, it's on the development roadmap. When support is added to the server core it will only be for *proxying* CoA messages not generating them. You can generate your own CoA messages using the radius client bundled with the server distribution.
I think it's possible to do both. A goal of the project is to do almost everything RADIUS related. So generating && proxying CoA are both on the roadmap. If someone is interested in it, there's always the possibility of accelerating the time frame... Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
FreeRADIUS does not currently support 3575, it's on the development roadmap. When support is added to the server core it will only be for *proxying* CoA messages not generating them. You can generate your own CoA messages using the radius client bundled with the server distribution.
I think it's possible to do both. A goal of the project is to do almost everything RADIUS related. So generating && proxying CoA are both on the roadmap.
Ok just the asynchronous nature of CoA requests... It's not really the servers job to process feedback from the various SNMP probes, IDS's , or track changes in the authorisation of users or their equipment. I guess I can see very few usage cases for CoA where the server will actually make the decision to send a CoA request on it's own, so why not just use the client or client libraries ? How were you thinking of triggering CoA events? Didn't you say there were issues with an instance of the server being both a CoA proxy and a CoA generator ?
If someone is interested in it, there's always the possibility of accelerating the time frame...
Have to wait for vendor support *grumble*. Let me know when you get your trapeze kit so we can compare notes :)
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
Ok just the asynchronous nature of CoA requests... It's not really the servers job to process feedback from the various SNMP probes, IDS's , or track changes in the authorisation of users or their equipment.
Yes. That's what proxying is for.
I guess I can see very few usage cases for CoA where the server will actually make the decision to send a CoA request on it's own, so why not just use the client or client libraries ?
if user uses more than 2G of bandwidth, then kick them off. This is a valid decision for a server to make. Forking an external program means that it's independent of the server core, and is more difficult to integrate with SQL, etc.
How were you thinking of triggering CoA events? Didn't you say there were issues with an instance of the server being both a CoA proxy and a CoA generator ?
Yes. If you're going to proxy CoA requests, there's no need to *generate* a CoA request for the one you're proxying. On the other hand, if you're receiving an accounting request, it may make sense to generate a CoA request.
Have to wait for vendor support *grumble*.
Let me know when you get your trapeze kit so we can compare notes :)
Will do. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Ok just the asynchronous nature of CoA requests... It's not really the servers job to process feedback from the various SNMP probes, IDS's , or track changes in the authorisation of users or their equipment.
Yes. That's what proxying is for.
I guess I can see very few usage cases for CoA where the server will actually make the decision to send a CoA request on it's own, so why not just use the client or client libraries ?
if user uses more than 2G of bandwidth, then kick them off. This is a valid decision for a server to make.
(that was one of the very few)
Forking an external program means that it's independent of the server core, and is more difficult to integrate with SQL, etc.
It's useful knowing the secrets for the NAS you want to send a CoA request too. In which case if you are going to include CoA generation, it would be good to have a way of signalling the server to generate a CoA request. In our implementation were not looking to trigger CoA as a result of anything available in the RADIUS protocol, but instead from data received from the aforementioned probes and systems.
How were you thinking of triggering CoA events? Didn't you say there were issues with an instance of the server being both a CoA proxy and a CoA generator ?
Yes. If you're going to proxy CoA requests, there's no need to *generate* a CoA request for the one you're proxying.
Ok take eduroam for example. A change in user authorisation at their home site may result in the generation of a CoA request for the user to be disconnected at the remote site, this would be proxied by the remote sites RADIUS server. That same server may also wish to generate it's own CoA request for the same user, because a local IDS system / traffic analysis probe has detected a bot net etc.. running on their equipment. Thus you have CoA requests being proxied, and CoA requests being generated, both going to the same NAS. If that's not the kind of conflict you were talking about...?
On the other hand, if you're receiving an accounting request, it may make sense to generate a CoA request.
Have to wait for vendor support *grumble*.
Let me know when you get your trapeze kit so we can compare notes :)
Will do.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
Ok take eduroam for example. A change in user authorisation at their home site may result in the generation of a CoA request for the user to be disconnected at the remote site, this would be proxied by the remote sites RADIUS server. That same server may also wish to generate it's own CoA request for the same user, because a local IDS system / traffic analysis probe has detected a bot net etc.. running on their equipment.
Not at the same time. The packets will be ordered. e.g CoA by local server because of botnet, to put them into a quarantine VLAN. Then, a CoA from the remote server, saying that they've just been fired, and they should be disconnected. If it's the other way around, the local system proxies the disconnect request. There's no need to put them into a quarantine vlan, because they've been disconnected. The requests *may* rarely happen at about the same time. But that's for the NAS to figure out. It's possible for the NAS to disconnect the user, ACK that, and then send a NAK to the CoA request, because the user has been disconnected. You might need logic on the server to handle these corner cases, but it's really not much different than out of order accounting packets, for example. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Ok take eduroam for example. A change in user authorisation at their home site may result in the generation of a CoA request for the user to be disconnected at the remote site, this would be proxied by the remote sites RADIUS server. That same server may also wish to generate it's own CoA request for the same user, because a local IDS system / traffic analysis probe has detected a bot net etc.. running on their equipment.
Not at the same time. The packets will be ordered. e.g CoA by local server because of botnet, to put them into a quarantine VLAN. Then, a CoA from the remote server, saying that they've just been fired, and they should be disconnected.
If it's the other way around, the local system proxies the disconnect request. There's no need to put them into a quarantine vlan, because they've been disconnected.
The requests *may* rarely happen at about the same time. But that's for the NAS to figure out. It's possible for the NAS to disconnect the user, ACK that, and then send a NAK to the CoA request, because the user has been disconnected.
New identifiers are assigned when forwarding RADIUS packets anyway (i'm guessing), so there's no problem with conflicts between remotely generated and locally generated CoA messages.
You might need logic on the server to handle these corner cases, but it's really not much different than out of order accounting packets, for example.
Quite. So in your implementation, we'll be able to fork off a CoA request on reciept of new accounting data. Or if we need to tie it in with a monitoring server, we can just use the RADIUS client and send a CoA request to the server which will then proxy it on to the correct NAS. I guess proxying behavior is arbitrary and decided on by local configuration. Routing CoA request through proxy chains is pretty much identical as routing standard requests. Arran
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Arran Cudbard-Bell wrote:
New identifiers are assigned when forwarding RADIUS packets anyway (i'm guessing), so there's no problem with conflicts between remotely generated and locally generated CoA messages.
Yes.
So in your implementation, we'll be able to fork off a CoA request on reciept of new accounting data. Or if we need to tie it in with a monitoring server, we can just use the RADIUS client and send a CoA request to the server which will then proxy it on to the correct NAS.
That's the theory. We'll have to see if it works out in practice. But yes, the intent is too allow generation AND proxying of CoA. The server doesn't currently support generation of authentication or accountng packets, but CoA is different.
I guess proxying behavior is arbitrary and decided on by local configuration. Routing CoA request through proxy chains is pretty much identical as routing standard requests.
No. It's horrible and evil. Hence the refusal to consider it until now. NAS vendors have recently started putting support for it into their products, so it's best to keep up with them. i.e. there's a "reverse proxy" check for security: If you receive a CoA, then it MAY be forged from someone who wasn't supposed to do it. So... pretend that it's an Access-Request, look up where you would have proxied it, and if that destination does not matche the source of the CoA, then send a CoA-NAK. Otherwise, process the CoA packet, and (perhaps) continue proxying it. Ugh. Alan DeKok.
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
vmx vmx