Re: Sending Accounting Response
The only other option left is to use CoA. However, the radius client libraries that would form part of the NAS do not implement CoA. I have read up the source code of all radius client libraries offered part of FR and even made by others - none of them have a library which could be used to listen for radius packets on a given port and accept and acknowledge CoA/Packet of disconnect. So I would have to write this from scratch, and would be most happy to contribute back to community. But in all other world, CoA is a standart, that is used for purposes that you described. -- With best regards, Evgeniy Kozhuhovskiy Leader of Services group, MGTS, RUE Beltelecom - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending Accounting Response
Alan DeKok wrote: Padam J Singh wrote: The attributes I want to send are VSAs anyway, so I fail to see how this violates the RFC. It doesn't. Technically. But it's a bad idea. Can you explain why you need to send the attributes, and what the NAS does with them? The reason I would like to use this is because the NAS I am building is a network controller which offers advance features like speed select in the same session, add new IP filter policies applied live on an update. I do not want to implement an out of band service (SNMP/SOAP) to achieve the same for something what the RADIUS protocols says is allowed, and FR claiming it adheres to that RFC. I have also checked up the diameter protocol - sending attributes in an accounting answer is a *very* acceptable thing. I have even confirmed with the RADIUS Server used by Oracle in their BRM applications used in most telcos that sending VSAs in Accounting-Response is OK and supported. The only other option left is to use CoA. However, the radius client libraries that would form part of the NAS do not implement CoA. I have read up the source code of all radius client libraries offered part of FR and even made by others - none of them have a library which could be used to listen for radius packets on a given port and accept and acknowledge CoA/Packet of disconnect. So I would have to write this from scratch, and would be most happy to contribute back to community. The standard install of FR also includes the following in attr.accounting_response: Yes... I know. The filter does allow any VSA - I wonder why the modules are not written to facilitate sending the attributes to the NAS. Because only one out of ten thousand users need to send attributes in an Accounting-Response. And they can't explain why they need to do it. Googling for the same suggests a whole lot more users are asking the same question. In my opinion anyone implementing Voice billing and real time rating would love to have this. The reason it is traditionally not required is because NASs are generally dumb, and wouldn't require to even look for attributes in updates. However, the new generation billing requirements are forcing more intelligence onto these NASs. If the requested functionality isn't used for anything, it won't be added to the server. I guess the rational thing to do if the worlds best RADIUS server cannot do this out of the box, then use Diameter or implement CoA. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- PGP Id 9EED2E09 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending Accounting Response
Alan DeKok wrote: Padam J Singh wrote: The reason I would like to use this is because the NAS I am building is a network controller which offers advance features like speed select in the same session, add new IP filter policies applied live on an update. I do not want to implement an out of band service (SNMP/SOAP) to achieve the same for something what the RADIUS protocols says is allowed, The RFC's do NOT say this. They say that VSA's are permitted, but they do not say what changes the NAS is permitted (or not permitted) to do when it receives those VSA's. I agree on that completely - I am only looking for the ability to send attributes and not derive any semantics about it between RADIUS and NAS. and FR claiming it adheres to that RFC. We are not just following the RFC's, we are actively leading the creation of new standards. See RFC 5080, and the IETF RADEXT WG. (guidelines document, RADIUS over TCP document, Status-Server document, etc.) Again, I agree and quote that FR is the best, kudos to the whole community to make it the best. I have also checked up the diameter protocol - sending attributes in an accounting answer is a *very* acceptable thing. Yes. Diameter is not RADIUS. I have even confirmed with the RADIUS Server used by Oracle in their BRM applications used in most telcos that sending VSAs in Accounting-Response is OK and supported. That doesn't mean it's a good idea. Vendors implement all sorts of broken things that get forbidden by later documents. The only other option left is to use CoA. However, the radius client libraries that would form part of the NAS do not implement CoA. Adding CoA support to freeradius-client isn't hard. It's likely not more than 40-50 lines of code to enable sending receiving CoA packets. I have read up the source code of all radius client libraries offered part of FR and even made by others - none of them have a library which could be used to listen for radius packets on a given port and accept and acknowledge CoA/Packet of disconnect. So I would have to write this from scratch, and would be most happy to contribute back to community. What you are really talking about is a Dynamic Authorization *Server*. See Section 1.3 of RFC 5176. i.e. you do *not* want a RADIUS client. You want a RADIUS server that receives CoA packets, and processes them through a policy. This is a lot more complicated than just sending receiving CoA packets. It is vital that this is written in a way that this can either be part of the RADIUS Server, or can be embedded onto a NAS. It is vital that the consideration for the CoA component to be independent and also be available as a library. This would enable for example a call switching agent running on an embedded device to be able to directly receive CoA messages by enabling callbacks or message queues. I expect that FreeRADIUS will likely have complete support for CoA within 6-9 months. If you're willing to wait, you can just use that. I couldn't find any open implementation of CoA for NASs, so will start writing that. Googling for the same suggests a whole lot more users are asking the same question. In my opinion anyone implementing Voice billing and real time rating would love to have this. That's what CoA is for. Using Accounting-Response is wrong. The reason it is traditionally not required is because NASs are generally dumb, and wouldn't require to even look for attributes in updates. However, the new generation billing requirements are forcing more intelligence onto these NASs. Then they need to implement CoA. See the WiMAX standards, where they require CoA for next generation billing requirements. I guess the rational thing to do if the worlds best RADIUS server cannot do this out of the box, then use Diameter or implement CoA. FreeRADIUS can do this. See man unlang for how to add attributes to the Accounting-Response. But it's *not* tied into the default behavior, because almost no one needs it. I would be able to send back attributes using unlang, or jradius. And the people who need it *should* implement CoA. I agree to it - but in absence of a good client library to receive CoA messages, the simplest way out would be been account-response attributes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- PGP Id 9EED2E09 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending Accounting Response
Padam J Singh wrote: The reason I would like to use this is because the NAS I am building is a network controller which offers advance features like speed select in the same session, add new IP filter policies applied live on an update. I do not want to implement an out of band service (SNMP/SOAP) to achieve the same for something what the RADIUS protocols says is allowed, The RFC's do NOT say this. They say that VSA's are permitted, but they do not say what changes the NAS is permitted (or not permitted) to do when it receives those VSA's. and FR claiming it adheres to that RFC. We are not just following the RFC's, we are actively leading the creation of new standards. See RFC 5080, and the IETF RADEXT WG. (guidelines document, RADIUS over TCP document, Status-Server document, etc.) I have also checked up the diameter protocol - sending attributes in an accounting answer is a *very* acceptable thing. Yes. Diameter is not RADIUS. I have even confirmed with the RADIUS Server used by Oracle in their BRM applications used in most telcos that sending VSAs in Accounting-Response is OK and supported. That doesn't mean it's a good idea. Vendors implement all sorts of broken things that get forbidden by later documents. The only other option left is to use CoA. However, the radius client libraries that would form part of the NAS do not implement CoA. Adding CoA support to freeradius-client isn't hard. It's likely not more than 40-50 lines of code to enable sending receiving CoA packets. I have read up the source code of all radius client libraries offered part of FR and even made by others - none of them have a library which could be used to listen for radius packets on a given port and accept and acknowledge CoA/Packet of disconnect. So I would have to write this from scratch, and would be most happy to contribute back to community. What you are really talking about is a Dynamic Authorization *Server*. See Section 1.3 of RFC 5176. i.e. you do *not* want a RADIUS client. You want a RADIUS server that receives CoA packets, and processes them through a policy. This is a lot more complicated than just sending receiving CoA packets. I expect that FreeRADIUS will likely have complete support for CoA within 6-9 months. If you're willing to wait, you can just use that. Googling for the same suggests a whole lot more users are asking the same question. In my opinion anyone implementing Voice billing and real time rating would love to have this. That's what CoA is for. Using Accounting-Response is wrong. The reason it is traditionally not required is because NASs are generally dumb, and wouldn't require to even look for attributes in updates. However, the new generation billing requirements are forcing more intelligence onto these NASs. Then they need to implement CoA. See the WiMAX standards, where they require CoA for next generation billing requirements. I guess the rational thing to do if the worlds best RADIUS server cannot do this out of the box, then use Diameter or implement CoA. FreeRADIUS can do this. See man unlang for how to add attributes to the Accounting-Response. But it's *not* tied into the default behavior, because almost no one needs it. And the people who need it *should* implement CoA. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending Accounting Response
Alan DeKok wrote: Padam J Singh wrote: From the RFC 2866: Yes, I have read the RFC's. They're even in the FreeRADIUS source tree. They'are referenced from http://freeradius.org/rfc/, which was built by me. The RFC doesn't categorically say that an accounting response packet SHOULD NOT have attributes. Read the REST of the RFC. Specifically, the Table of Attributes. Citing the Table of Attributes: No attributes should be found in Accounting-Response packets except Proxy-State and possibly Vendor- Specific. The attributes I want to send are VSAs anyway, so I fail to see how this violates the RFC. The NAS is an application I have written - so I will be able to parse attributes in an accounting response. Your application is wrong. If it needs to have attributes sent back in an Accounting-Response packet, then it's not doing RADIUS properly. According to the RFC - VSAs are allowed, and it is up to the vendor to implement handling such responses. If the standard postgres module cannot be used to send back attributes in an accounting-response packet, can I do the same using any other module like JRadius? I have gone through the rlm_jradius source code, and it looks like it doesn't differentiate between accounting and authorization responses when reading value pairs. If you can get something to work, good luck. But the server is NOT intended to send attributes back in the Accounting-Response. The standard install of FR also includes the following in attr.accounting_response: DEFAULT Vendor-Specific =* ANY, Message-Authenticator =* ANY, Proxy-State =* ANY The filter does allow any VSA - I wonder why the modules are not written to facilitate sending the attributes to the NAS. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- PGP Id 9EED2E09 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending Accounting Response
Padam J Singh wrote: The attributes I want to send are VSAs anyway, so I fail to see how this violates the RFC. It doesn't. Technically. But it's a bad idea. Can you explain why you need to send the attributes, and what the NAS does with them? The standard install of FR also includes the following in attr.accounting_response: Yes... I know. The filter does allow any VSA - I wonder why the modules are not written to facilitate sending the attributes to the NAS. Because only one out of ten thousand users need to send attributes in an Accounting-Response. And they can't explain why they need to do it. If the requested functionality isn't used for anything, it won't be added to the server. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sending Accounting Response
Hello, According to the RFC 2866, it is possible to send back attributes to an accounting update packet sent from a NAS. What I have done is this: The authorization and authentication queries are basically calls to a stored procedure in postgres that returns a set of table type which contains the attribute, operator and value (for authorization), and encrypted password for authentication. I can write a stored procedure to return a set of attributes to send back in an accounting start/update/stop, but all the queries given as examples in the default dialup.conf are update queries that do not return any attribute. How do I configure the postgres module to return the attributes to the NAS? The NAS is an application I have written that parses all attributes sent back after an auth-request and acct-start/update/stop. Thanks, Padam -- PGP Id 9EED2E09 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending Accounting Response
Hello Alan, From the RFC 2866: 4.2. Accounting-Response 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier |Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Response Authenticator| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- The RFC doesn't categorically say that an accounting response packet SHOULD NOT have attributes. The NAS is an application I have written - so I will be able to parse attributes in an accounting response. If the standard postgres module cannot be used to send back attributes in an accounting-response packet, can I do the same using any other module like JRadius? I have gone through the rlm_jradius source code, and it looks like it doesn't differentiate between accounting and authorization responses when reading value pairs. Thanks, Padam Alan DeKok wrote: Padam J Singh wrote: According to the RFC 2866, it is possible to send back attributes to an accounting update packet sent from a NAS. *Please* use the correct terminology. It makes it easier for us to understand your question. If I read what I *think* you mean, then no, RFC 2866 does not allow attributes in an Accounting-Response. What I have done is this: The authorization and authentication queries are basically calls to a stored procedure in postgres that returns a set of table type which contains the attribute, operator and value. I can write a stored procedure to return a set of attributes to send back in an accounting start/update/stop, but all the queries given as examples in the default dialup.conf are update queries that do not return any attribute. How do I configure the postgres module to return the attributes to the NAS? You don't. Please explain why you think this is necessary. Also be aware that any attributes you send in an Accounting-Response will be ignored by *every* NAS that anyone has ever made. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- PGP Id 9EED2E09 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending Accounting Response
Padam J Singh wrote: From the RFC 2866: Yes, I have read the RFC's. They're even in the FreeRADIUS source tree. They'are referenced from http://freeradius.org/rfc/, which was built by me. The RFC doesn't categorically say that an accounting response packet SHOULD NOT have attributes. Read the REST of the RFC. Specifically, the Table of Attributes. The NAS is an application I have written - so I will be able to parse attributes in an accounting response. Your application is wrong. If it needs to have attributes sent back in an Accounting-Response packet, then it's not doing RADIUS properly. If the standard postgres module cannot be used to send back attributes in an accounting-response packet, can I do the same using any other module like JRadius? I have gone through the rlm_jradius source code, and it looks like it doesn't differentiate between accounting and authorization responses when reading value pairs. If you can get something to work, good luck. But the server is NOT intended to send attributes back in the Accounting-Response. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sending Accounting Response
Hello, According to the RFC 2866, it is possible to send back attributes to an accounting update packet sent from a NAS. What I have done is this: The authorization and authentication queries are basically calls to a stored procedure in postgres that returns a set of table type which contains the attribute, operator and value. I can write a stored procedure to return a set of attributes to send back in an accounting start/update/stop, but all the queries given as examples in the default dialup.conf are update queries that do not return any attribute. How do I configure the postgres module to return the attributes to the NAS? Thanks, Padam -- PGP Id 9EED2E09 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending Accounting Response
Padam J Singh wrote: According to the RFC 2866, it is possible to send back attributes to an accounting update packet sent from a NAS. *Please* use the correct terminology. It makes it easier for us to understand your question. If I read what I *think* you mean, then no, RFC 2866 does not allow attributes in an Accounting-Response. What I have done is this: The authorization and authentication queries are basically calls to a stored procedure in postgres that returns a set of table type which contains the attribute, operator and value. I can write a stored procedure to return a set of attributes to send back in an accounting start/update/stop, but all the queries given as examples in the default dialup.conf are update queries that do not return any attribute. How do I configure the postgres module to return the attributes to the NAS? You don't. Please explain why you think this is necessary. Also be aware that any attributes you send in an Accounting-Response will be ignored by *every* NAS that anyone has ever made. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
