RFC 3576 'Dynamic Authorization Extensions to RADIUS' describes a RADIUS protocol allows disconnect messages and change of authorization messages to be sent by servers to clients. These messages allow the server to attempt to disconnect a client or change some aspects oft he client session's properties.
In this discussion Disconnect messages and Change of Authorization messages will be referred to as DM messages as they share many of the same properties.
This is a departure from the usual RADIUS protocol in that packets must be sent 'upstream' or more precisely in the reverse direction of common RADIUS packets. While Access-Request messages must be sent from the client to server Disconnect-Messages and Coa-Requests must be send from server to client. This poses some significant difficulties for RADIUS servers if forwarding servers are between the server creating the Disconnect-Message and the targeted client.
To route a DM certain 'identifier' attributes must be saved by any Access-Request process. To forward to the correct NAS (client) the following attributes must be saved if they exist: NAS-IP-Address, NAS-Identifier, and NAS-IPv6-Address. Other attributes must be saved for the NAS to identifier which session to alter. These are described in RFC 3576 and will not be mentioned here as they do not affect packet routing, In the simplest scenario a DM sent from a server to a local client is the easiest to process. The server need only find the client whose identity matches that of the saved identifier attributes - same NAS-IP-Address for example. The next simplest routing is when there are no matching local clients but there is exactly one forwarding server available. In this case the forwarding server is given the responsibilityfor locating the client.
A routing table becomes necessary when multiple forwarding servers are connected to a server that sends DM messages. The table must hold any identifier attribute information for packets that arrives from any forwarding server. This is handled internally by the AXL RADIUS server. The routing tables are created only if a DMCOA routing server is enabled.
The class com.theorem.radserver3.dmcoaserver.SendDMCOA is used to send DM/COA messages and can be used from any process, even a different JVM on the same machine as the server.
The DMCOA server is started using the RADIUSServer.startDMCOAServer(int
port).
The default port is 3799. The constant RADIUSServer.DMCOA_PORT or the value 0 will use the default
port.
DMCOA messages are sent using the SendDMCOA class found in the com.theorem.radserver3.dmcoaserver package. You must know the originating NAS to send the packet. This should be saved just as theother identifying attributes are saved.
To assist in saving the state the static method SendDMCOA.extractIdentfiers(AttributeList
aList) will return an AttributeList of identifier attributes. The state should
be saved by either the authentication or accounting server code. An accounting stop message might be used as a signal
to remove a NAS.
The SendDMCOA class will send a given message and wait for the results. This
may require a separate
thread to avoid blocking sessions or other server code. An example using the
SendDMCOA class is found in the com/theorem/.radserver3/examples/dmcoaserver directory.
The RADIUSServer class can enable DMCOA proxy support using the RADIUSServer.startDMCOAServer(int
port) method. The NAS class and ProxyTarget class offer methods to
enable and test respectively for DM/COA support for a particular client or proxy
server: NAS.enableDMRequests(boolean enable), NAS.enableCoARequests(boolean
enable), NAS.allowCoARequests(), and NAS.allowDisconnectRequests().
The ProxyTarget class supports the same methods.
The example server in com/theorem/radserver3/examples/server/AXLServer.java
uses the following to enable the DMCOA functionality:
// Start the DM / COA server if enabled.
if (conf.dmcoaEnabled)
rs.startDMCOAServer(conf.dmcoaPort);
Where ever you need to send a Disconnect-Message or Change-of-Authorization you use the class com.theorem.radserverdemo.dmcoaserver.SendDMCOA. You will need to provide the identifying attributes from the original packet. These would be something like NAS-IP-Address, NAS-Identifier, or NAS-IPv6-Address. Whatever the NAS normally sends in it's packets.
For the particular NAS you may have to provide session identifiers such as User -Name, NAS-Port, Framed-IP-Address, Called-Station-Id, Calling-Station-Id, Acct-Session-Id, Acct-Multi-Session-Id, NAS-Port-Type, NAS-Port-Id, Originating -Line-Info, Framed-Interface-Id, orFramed-IPv6-Prefix. This allows an aggregating NAS to determine which session to change. Enough attributes should be sent to uniquely identify a session. What you need to send is determined by your client.