Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

RADIUS Reauthentication As an Alternative to RADIUS CoA for DHCP Subscribers

RADIUS Change of Authorization (CoA) messages, specified in RFC 5176, Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS), are used to activate or deactivate client services and to change certain client session characteristics without logging out the client, thus avoiding interruption to the subscriber. In some circumstances, it may be preferable to use reauthentication of the subscriber as the method to alter client session services and characteristics without interruption.

For example, the following customer deployment modes both require changes in attributes during the life of a session.

  • Residential subscribers—Residential subscribers may change service plans throughout the life of a session by online service selection or direct calling to the provider. The change in service plan is propagated to the DHCP local server by changing the value of the DHCP client Agent Remote ID. The Agent Remote ID is conveyed in option 82, suboption 2, for DHCPv4 clients and in option 37 for DHCPv6 clients.

    When reauthentication is configured, the change in service plan is detected, triggering reauthentication; the new service plan and any changed attributes are returned by the RADIUS server and implemented for the subscriber.

  • Business subscribers—Business subscribers often need changes in attributes (particularly framed routes) during any given session. The desired change in attributes is not initiated by a change in service plans.

    When reauthentication is configured, negotiation of the lease renewal triggers reauthentication. Any changes in attributes or services are provided in the Access-Accept message from the RADIUS server and implemented for the subscriber.

Two alternatives to using reauthentication can both change many more session characteristics than are possible with reauthentication. CoA requests change characteristics without disrupting the subscriber. Logging the subscriber out and then back in can change many more session characteristics but is obviously disruptive.

Benefits of Reauthentication

  • Update or modify subscriber session attributes and service plans without using a CoA request.

  • Simplify activation of services resulting from frequent subscriber-initiated changes.

  • Enable reauthentication per family in dual-stack, single-session configurations.

  • Control reauthentication through CLI configuration or a RADIUS VSA.

Functionality

Reauthentication is supported for both DHCPv4 and DHCPv6. It can be triggered when the DHCP local server receives a renew, rebind, discover, or solicit message from a DHCP client. The discover and solicit messages support reauthentication starting in Junos OS Release 18.1R1. Support for the discover and solicit messages means that if a CPE with a bound client reboots and the client sends one of those messages to bring the session back up, reauthentication enables authd to obtain any updates that have been made for the subscriber.

Reauthentication behavior is determined as follows:

  • The reauthenticate lease-renewal statement specifies reauthentication is triggered when any of the four supported messages is received.

  • The reauthenticate remote-id-mismatch statement specifies reauthentication is triggered only when the received message includes a change in the value of the DHCP client’s Agent Remote ID. The attribute value includes the name of the subscriber service plan, so a change in value signifies a change in service for the subscriber.

  • The Juniper Networks reauthentication-on-renew VSA (26-206), when returned with a value of 1 in the Access-Accept message from the RADIUS server for the subscriber at login, triggers reauthentication on receipt of any of the four messages. A value of 0 disables reauthentication. The VSA value is stored in the session database whenever it is received. After this VSA has enabled reauthentication, it is checked at each reauthentication attempt. If the value has changed to 0—that is, if a subsequent Access-Accept returned the VSA with a value of 0—the reauthentication process stops for that subscriber.

    The CLI configuration (reauthenticate statement) and Reauthenticate-On-Renew behavior is additive. Disabling reauthentication with the VSA has an effect only when the reauthenticate statement is not configured. When the reauthenticate statement is configured with either option, it overrides a VSA value of 0. In the absence of the CLI configuration, the VSA can enable reauthentication by itself.

The reauthentication process is almost identical to the original authentication process. When reauthentication is triggered, the jdhcpd process on the local server submits an authentication request to authd, which in turn submits an Access-Request message to the RADIUS server to request a second authentication.

Note:

The reauthentication request fails for any authentication order other than radius or none. The authd process returns a negative acknowledgment (NAK) for any such request.

This Access-Request includes RADIUS state and class attributes that were returned in the original Access-Accept message. These attributes enable the RADIUS server to distinguish the reauthentication request from login (authentication) requests.

The RADIUS server returns an Access-Accept message to authd with new attributes for the subscriber. The authd process sends an acknowledgment (ACK) with the changes to jdhcpd, which sends a DHCP offer to the DHCP client with changed attributes. The DHCP negotiation continues as usual, as shown in Figure 1, and the subscriber session continues with the new attribute values. When the reauthentication includes a change in service plan, the RADIUS server returns the new plan with any other changed attributes, if it accepts the request, as shown in Figure 2. If the CPE hosting the DHCP client reboots during the process of changing a service plan, reauthentication with the new plan is supported with no disruption in service.

If the RADIUS server rejects a reauthentication request or times out, authd sends a NAK to jdhcpd, which reviews the included error code. If the error code indicates a timeout, jdhcpd sends an ACK to the DHCP client and the subscriber session is maintained with the original attributes and service. For any other error code, jdhcpd sends a DHCPv4 NAK or DHCPv6 REPLY (with the lifetime value set to 0) as a logical NAK, initiates subscriber logout, and deletes the subscriber from the session database.

Table 1 describes how authd processes requests when a different request type is already in progress for the same subscriber.

Table 1: Processing Multiple Request Types

Request in Progress

Additional Request Received for Same Subscriber

Action

Reauthentication

CoA

authd responds to the CoA with a NAK.

CoA

Reauthentication

authd queues the reauthentication request until the CoA is processed, then processes the reauthentication request.

Reauthentication

Disconnect

authd responds to the disconnect with a NAK.

Disconnect

Reauthentication

authd responds to the reauthentication request with a NAK and continues logging out the subscriber.

Best Practice:

Because the network family does not terminate or reinitiate as part of reauthentication, the subscriber content is not reevaluated with regards to subscriber secure policy mirroring. Do not use as a trigger for subscriber secure policy mirroring any attribute that can change during reauthentication processing.

When reauthentication results in a change in a DHCPv6 subscriber’s IP or IPv6 address after a client is bound, the DHCPv6 server evaluates the address change request. The server returns a status code to the client in the identity association (IA) of the reply PDU. Starting in Junos OS Release 18.4R1, when the DHCPv6 server discovers an issue with the address, a status code for NotOnLink is supported in addition to the previously supported codes for NoAddrsAvail and NoPrefixAvail. These status codes are defined as follows:

  • NoAddrsAvail (2)—The server cannot assign any addresses for the IA in the client request. It returns the IA with no addresses and NoAddrsAvail.

  • NotOnLink (4)—The server determines that the prefix for one or more addresses in any IA in the client request is not appropriate for the link connecting to the client. This code is also used in the event of a reauthentication failure (RADIUS Access-Reject).

  • NoPrefixAvail (6)—The server has no prefixes available for the IA in the client request.

If the client receives the NotOnLink status code, it can send another request without any addresses or it can restart the negotiation process. If it sends a request, the DHCPv6 local serer ignores the request, expecting a new renegotiation to begin.

Dual-Stack Subscribers

In releases earlier than Junos OS Release 18.1R1, dual-stack DHCP subscribers are treated as independent client sessions. Each stack renews and obtains new services independently.

Starting in Junos OS Release 18.1R1, per-family authentication and reauthentication are supported for dual-stack, single-session subscribers. A dual-stack, single-session subscriber is typically a household with its own VLAN in a 1:1 access model. The household is represented as a single subscriber with a single session in the session database, but it has two separate DHCP bindings, one for each family, DHCPv4 and DHCPv6. Consequently, authd sends separate Access-Requests as each family in the session logs in or attempts to reauthenticate:

  • Per-family authentication occurs when a discover or solicit message is received while a subscriber session is in the DHCP init state.

  • Per-family reauthentication occurs when reauthentication and on-demand address allocation are both configured and a renew, rebind, discover, or solicit message is received for the family session while it is in the DHCP bound state.

Note:

On-demand address allocation causes an address to be allocated separately for each family as it logs in. On-demand address allocation must be configured for dual-stack, single-session subscribers or per-family authentication and reauthentication cannot be enabled. For reauthentication, this is true whether it is configured in the CLI or with the Reauthenticate-On-Renew VSA (26-206).

Authentication and reauthentication are both processed per family. The first family to trigger the process is attended to before the other (second) family triggers authentication or reauthentication. Messages from the second family are ignored until the first family is bound. Then the second family request is processed.

If only one family of the dual-stack single session logs in, then only one authentication is processed. Reauthentications are processed for only the one client family.

The authd process classifies attributes as belonging to the DHCPv4 or DHCPv6 family and tags them accordingly. For both authentication and reauthentication, depending on which family initiates the request, authd includes either the DHCP-Options VSA (26-55) or the DHCPv6-Options VSA (26-65). Depending on its configuration, the RADIUS server might return information for only the family that initiated the request (the requesting family) or for both families.

When authd receives attributes in the Access-Accept message, the family tags enable authd to determine which attributes correspond to the requesting family or the other (nonrequesting) family. Only attributes for the requesting family are written to the session database.

For reauthentication requests, authd compares the returned attributes to the session database to determine whether any changes were made on the RADIUS server. Again, only changes that correspond to the requesting family are written to the session database, overwriting the old values.

Changes during reauthentication are processed as follows:

  • Attribute (other than address)—When authd determines that one or more of these attributes has changed for the requesting family, it stores the new values in the session database. After authd notifies jdhcpd, it sends an ACK to the DHCP client with the new attribute values.

  • Address or address pool—When authd detects a change for the requesting family, it notifies the DHCP local server, which in turn sends a NAK (DHCPv4) or logical NAK (DHCPv6) to the DHCP client.

    If the requesting family is the only family that is bound, jdhcpd gracefully logs out the subscriber. If the nonrequesting family is also bound, jdhcpd deactivates the requesting family, but leaves the nonrequesting family binding intact, with no disruption in service to the nonrequesting family. The deactivation of the requesting family has no effect on a subsequent triggering of reauthentication by the nonrequesting family.

    When the deactivated family subsequently sends a discover or solicit message to log back in, an Access-Request is sent for reauthentication as usual, and the new address received in the Access-Accept is applied to the subscriber.

If the RADIUS server responds to an authentication or reauthentication request with an Access-Reject message, authd notifies the DHCP local server, which in turns sends a NAK (DHCPv4) or logical NAK (DHCPv6) to the DHCP client. The requesting family is terminated gracefully; the family is deactivated and the subscriber is logged out. Then the nonrequesting family is deactivated and logged out, but the client is not notified about the termination.

If liveness detection is running on the nonrequesting family, the client detects loss of connection when the family is terminated, and subsequently sends a discover or solicit message to the DHCP local server. However, if liveness detection is not running, the client does not detect loss of connection until the rebinding time (T2, option 59) expires and service is lost. Depending on the duration of the lease, this could take a long time.

Best Practice:

Configure liveness detection for both address families to reduce the time to detect loss of connection. See DHCP Liveness Detection Overview for information about configuring liveness detection.

Packet Flow

The following figure describes the sequence for initial negotiation of a subscriber session between a DHCP client, a DHCP server, and the RADIUS server. The client’s service plan is specified in the second substring in the remote ID contained in DHCPv4 option 82, suboption 2, or DHCPv6 option 37.

Initial Negotiation

Figure 1 illustrates the sequence of steps in the initial negotiation between a DHCP client, a DHCP server, and the RADIUS server. The following terms are used in the figure:

CPE—Customer premises equipment (functions as the DHCP client or subscriber).

OLT—Optical line terminator—for example, a DSL access multiplexer (DSLAM) or other aggregation device.

MX Series device—Functions as the DHCP server.

Figure 1: Initial NegotiationInitial Negotiation

Service Plan Change

Figure 2 illustrates the sequence of steps in a change of service plans, from a 100 Mbps plan to a 1 Gbps plan.:

Figure 2: Service PlanService Plan

RADIUS Attributes Supported for Reauthentication

Table 2 lists the RADIUS standard attributes and VSAs that can be processed during reauthentication when received in the RADIUS Access-Accept message, and describes how authd handle changes in attributes. Attribute processing is consistent with CoA request processing. The characteristics of the reauthenticating subscriber session change only if new values or new attributes are received in the Access-Accept message.

Table 2: RADIUS attributes supported by reauthentication

Attribute Number

Attribute Name

Result of Processing

8

Framed-IP-Address

A new value is stored in the subscriber session database; old data is overwritten.

22

Framed-Route

A new value is stored in the subscriber session database; old data is appended.

24

State

A new value is stored in the subscriber session database; old data is overwritten.

25

Class

A new value is stored in the subscriber session database; old data is overwritten.

26-4

Primary-DNS

A new value is stored in the subscriber session database; old data is overwritten.

26-5

Secondary-DNS

A new value is stored in the subscriber session database; old data is overwritten.

26-6

Primary-WINS

A new value is stored in the subscriber session database; old data is overwritten.

26-7

Secondary-WINS

A new value is stored in the subscriber session database; old data is overwritten.

26-55

DHCP-Options

Value is sent to the DHCP local server for processing the changes to the subscriber’s DHCP configuration.

26-65

Activate-Service

The authd process compares the list of services in the VSA to the services that are already active for that subscriber session.

  • If the list on the VSA contains services not yet active, authd activates those services for the subscriber.

  • If any service already active for the subscriber session is not listed in the VSA, then authd deactivates that service.

For example, suppose services A and B are active on the session, but the VSA includes only services B and C. Service A is not on the VSA list and is deactivated. Service C is on the list but not currently active, so authd activates C. Service B is both already active and on the list, so it remains active.

26-161

IPv6-Delegated-Pool-Name

A new value is stored in the subscriber session database; old data is overwritten.

26-206

Reauthenticate-On-Renew

If the value is 1 (enable), authd adds the value to the subscriber session database if it is not already present.

If the value is 0 (disable) and a value of 1 is already present in the database, authd sets the database value to 0.

If the value in the message is missing or invalid, and a value is already present in the database, authd deletes the value from the database.

26-207

DHCPv6-Options

Value is sent to the DHCPv6 local server for processing the changes to the subscriber’s DHCP configuration.

88

Framed-Pool

A new value is stored in the subscriber session database; old data is overwritten.

97

Framed-IPv6-Prefix

A new value is stored in the subscriber session database; old data is overwritten.

100

Framed-IPv6-Pool

A new value is stored in the subscriber session database; old data is overwritten.

123

Delegated-IPv6-Prefix

A new value is stored in the subscriber session database; old data is overwritten.

168

Framed-IPv6-Address

A new value is stored in the subscriber session database; old data is overwritten.

Release History Table
Release
Description
18.4R1
Starting in Junos OS Release 18.4R1, when the DHCPv6 server discovers an issue with the address, a status code for NotOnLink is supported in addition to the previously supported codes for NoAddrsAvail and NoPrefixAvail.
18.1R1
The discover and solicit messages support reauthentication starting in Junos OS Release 18.1R1.