RADIUS Reauthentication As an Alternative to RADIUS CoA for DHCP Subscribers

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.

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.

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.

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.

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
• Service Plan Change

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 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 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.