RADIUS CoA: changing a live subscriber's service

A subscriber upgrades a plan while a download is running. Billing marks an account suspended. Operations needs to contain a compromised connection. Waiting for the next login delays the policy change, while forcing every change through a reconnect interrupts service unnecessarily.

RADIUS Change of Authorization gives the policy system a way to reach the live NAS session. Netavo supports RFC 5176 CoA and Disconnect-Message, alongside normal RADIUS authentication and accounting. Use CoA for supported changes to an existing session and Disconnect when the intended result is teardown. Those are different operations with different consequences for the customer.

The request travels towards the NAS

During authentication, the NAS sends an Access-Request to RADIUS and receives the subscriber's policy. During dynamic authorization, a trusted sender initiates a request towards the NAS that currently owns the session.

Policy system -> NAS: CoA-Request identifying the live session
NAS -> Policy system: CoA-ACK or CoA-NAK

Policy system -> NAS: Disconnect-Request identifying the live session
NAS -> Policy system: Disconnect-ACK or Disconnect-NAK

An ACK reports successful handling of the requested operation; a NAK reports that it could not be carried out. Authentication or freshness failures can instead result in a silent drop. A timeout therefore needs investigation rather than being treated as an explicit policy rejection.

Use accounting to maintain the relationship between the subscriber, NAS and session identifier. A request sent to yesterday's NAS cannot change today's session on another edge. Prefer a precise session identifier over a broad username match, particularly where usernames can appear on multiple circuits.

For a Disconnect, success ends the current session. It does not permanently revoke the credentials. If the CPE reconnects and authentication still permits service, a new session can be established. Persist the intended policy in the authentication backend as well as acting on the live session.

Configure the listener and its trust boundary

The following overlay enables the RADIUS auth driver and supplies dynamic authorization settings. Merge it into an existing configuration that already defines the authentication servers and NAS identity. Replace the example address and secret before use.

{
  "auth": {
    "driver": "radius",
    "radius": {
      "coaPort": 3799,
      "coaSecret": "REPLACE_WITH_SHARED_SECRET",
      "coaAllowedSources": ["192.0.2.10"],
      "coaTimestampWindowSeconds": 300
    }
  }
}

The listener requires the RADIUS driver and a nonempty coaSecret. coaPort selects its UDP port. Restrict the source list to systems responsible for dynamic authorization, and make network filtering agree with that list.

The JSON spelling is auth.radius.coaAllowedSources, plural. If you are looking for coaAllowedSource, the corresponding CLI setting is auth radius coa-allowed-source; do not copy the singular form into JSON. This small distinction is worth checking before troubleshooting the network path.

Use the address the NAS actually sees as the sender. A management path involving address translation can otherwise make a legitimate policy server appear outside the configured allowlist. Keep dynamic authorization reachable only through the intended operational network.

What can change mid-session

Rate changes

The current live CoA path reads Broadband Forum rate VSAs: Max-Data-Rate-Upstream and Max-Data-Rate-Downstream. These are vendor 3561, types 135 and 136 respectively, with integer values in kbps. Upstream is subscriber upload; downstream is subscriber download.

Do not assume that every rate attribute accepted during login is also parsed during CoA. Netavo's Access-Accept handling supports additional rate families, but the current CoA rate path specifically reads the BBF attributes. Check the dictionary and packet contents generated by your sender.

For a plan upgrade, first save the new plan in billing or subscriber policy. Then send the live rate update to the current session. Verify an ACK, inspect the effective session rate and measure traffic in each direction. Netavo emits an immediate accounting interim update after applying a live policy change, which helps correlate the event.

Restricted service and walled garden

Netavo-Service-State can express restricted to place a session into the configured walled-garden forwarding context, and active to restore service. Configure and test that context before using it for suspension. The garden must provide the intended limited reachability without opening an unintended route to normal service.

A restricted state and a redirect URL are different controls. The current CoA worker does not apply an arbitrary redirect URL from a CoA packet. Design portal reachability and any redirect behaviour as part of the configured garden service, then use CoA to select the service state.

Moving forwarding contexts can interrupt existing application traffic even though the access session remains present. Describe this accurately to operations: a live policy update avoids requiring a new access login, but does not promise that every existing connection survives the policy change.

Forced logout

Use Disconnect-Message when the requirement is to remove the session. Examples include clearing a stale connection or forcing a fresh authentication after a policy change that cannot be applied live. Follow the result through accounting and subsequent authentication, rather than stopping at the response packet.

Three operational workflows

A workflow should record its target session, request time and result. If a customer reconnects while the change is in flight, reconcile against the new session instead of repeatedly addressing the old one. Make retries deliberate and observable.

For suspension, test restoration as a separate operation. Returning active must restore the intended forwarding context, while the durable account state must allow the same service after the next reconnect. A successful suspension test alone does not qualify the complete billing workflow.

Source authentication and clock skew

Netavo checks the request authenticator using the shared secret and validates Message-Authenticator when it is supplied. An allowlisted source address complements those checks; it is not a substitute for them. A secret shared by too many systems also broadens who can change subscriber service.

Event-Timestamp allows freshness checking. The default coaTimestampWindowSeconds is 300, giving a window of 300 seconds either side of the NAS clock. Keep the NAS and sender clocks synchronized and inspect clock skew when otherwise valid requests disappear.

Event-Timestamp is optional in the current listener: requests without it are accepted if the other checks pass. Configure the sender to include it; the skew setting alone does not make timestamps mandatory.

A stale timestamp is silently dropped. Widening the window to conceal a clock problem increases the accepted age of a captured request. Fix clock synchronization and packet generation before changing the window for an operational reason.

Verify the policy at the subscriber

Exercise a rate change, restriction, restoration and disconnect on a pilot session. Check responses and accounting, but also test actual forwarding with both IPv4 and IPv6. Include an unauthorized sender and a stale timestamp to establish that the trust boundary behaves as expected.

Use the free evaluation, the full production build licensed for up to 50 concurrent subscribers, to test your billing integration. The manual provides configuration and attribute details.