Session Options for Subscriber Access

Subscriber Session Timeouts

You can limit subscriber access by configuring a session timeout or an idle timeout. Use a session timeout to specify a fixed period of time that the subscriber is permitted to have access. Use an idle timeout to specify a maximum period of time that the subscriber can be idle. You can use these timeouts separately or together. By default, neither timeout is present.

The idle timeout is based on accounting statistics for the subscriber. The router determines subscriber inactivity by monitoring data traffic, both upstream from the user (ingress) and downstream to the user (egress). Control traffic is ignored. The subscriber is not considered idle as long as data traffic is detected in either direction.

Optionally, you can specify that only subscriber ingress traffic is monitored; egress traffic is ignored. This configuration is useful in cases where the LNS sends traffic to the remote peer even when the peer is not up, such as when the LNS does not have PPP keepalives enabled and therefore cannot detect that the peer is not up. In this situation, because by default the LAC monitors both ingress and egress traffic, it detects the egress traffic from the LNS and either does not log out the subscriber or delays detection of inactivity until the egress traffic ceases. When you specify that only ingress traffic is monitored, the LAC can detect that the peer is inactive and then initiate logout.

When either timeout period expires, the non-DHCP subscribers are gracefully logged out, similarly to a RADIUS-initiated disconnect or a CLI-initiated logout. DHCP subscribers are disconnected. The Acct-Terminate-Cause [RADIUS attribute 49] value includes a reason code of 5 for a session timeout and a code of 4 for an idle timeout.

You can configure these limitations to subscriber access on a per-subscriber basis by using the RADIUS attributes Session-Timeout [27] and Idle-Timeout [28]. RADIUS returns these attributes in Access-Accept messages in response to Access-Request messages from the access server. Starting in Junos OS Release 19.4R1, the Session-Timeout attribute [27] is supported in RADIUS CoA messages. This capability is useful, for example, when subscribers purchase Internet access for a specific period of time and must log out when the session expires.

When a CoA arrives with Session-Timeout, the timeout is counted from the time that the session activated. This has the following consequences:

• If the attribute value is greater than the current session uptime and between the minimum and maximum timeout values, the subscriber is logged out when that number of seconds has passed since session activation. For example, suppose the session activated at 12:00:00 and the CoA is received at 12:00:30 with a value of 120 seconds. The subscriber is logged out at 12:02:00.

  Another way to look at this with the same values is that the current session uptime is 30 seconds and the attribute value is 120 seconds. The subscriber is logged out when 90 more seconds have passed.

• If the attribute value is greater than the current session uptime but less than the minimum timeout value of 60 seconds, then the subscriber is logged out when the uptime reaches 60 seconds.

• If the attribute value is greater than the current session uptime but more than the maximum timeout value of 31,622,400 seconds, then the subscriber is logged out when the uptime reaches 31,622,400 seconds.

• If the attribute value is less than the current session uptime, the session timeout is not applied. AAA replies to the CoA message with a NAK. For example, the session is unaffected if the Session-Timeout is 60 seconds, but the uptime is 100 seconds.

Applying a session timeout according to the rules above also depends on whether all other aspects of the CoA are successful. For example, if the CoA includes a service activation and that service activation fails, then the session timeout is not applied. AAA replies to the CoA message with a NAK.

Service providers often choose to apply the same limitations to large numbers of subscribers. You can reduce the RADIUS provisioning effort for this scenario by defining the limitations for subscribers in an access profile on a per-routing-instance basis. If you do so, RADIUS attributes subsequently returned for a particular subscriber logged in with the profile override the per-routing-instance values.

The available range for setting a timeout is the same whether you configure it in the CLI or through the RADIUS attributes:

• Session timeouts can be set for 1 minute through 527,040 minutes in the CLI and the corresponding number of seconds (60 through 31,622,400) in the Session-Timeout attribute [27].

• Idle timeouts can be set for 10 minutes through 1440 minutes in the CLI and the corresponding number of seconds (600 through 86,400) in the Idle-Timeout attribute [28].

The router interprets the values in the attributes to conform to the supported ranges. For example, for Session-Timeout [27]:

• A value of zero is treated as no timeout.

• A value in the range 1 through 59 is raised to 60 seconds.

• A value that exceeds 31,622,400 is reduced to 31,622,400 seconds.

For Idle-Timeout [28]:

• A value of zero is treated as no timeout.

• A value in the range 1 through 599 is raised to 600 seconds.

• A value that exceeds 86,400 is reduced to 86,400 seconds.

In configurations using dynamically created subscriber VLANs, the idle timeout also deletes the inactive subscriber VLANs when the inactivity threshold has been reached. In addition to deleting inactive dynamic subscriber VLANs, the idle timeout also removes dynamic VLANs when no client sessions were ever created (for example, in the event no client sessions are created on the dynamic VLAN or following the occurrence of an error during session creation or client authentication where no client sessions are created on the dynamic VLAN).

Session and idle timeouts for deleting dynamic subscriber VLANs are useful only in very limited use cases; typically neither timeout is configured for this purpose.

A possible circumstance when they might be useful is when the dynamic VLANs have no upper layer protocol that helps determine when the VLAN is removed with the remove-when-no-subscribers statement; for example, when the VLAN is supporting IP over Ethernet without DHCP in a business access model with fixed addresses. However, business access is generally a higher-tier service than residential access and as such typically is not subject to timeouts due to inactivity as might be desired for residential subscribers.

An idle timeout might be appropriate in certain Layer 2 wholesale situations, where the connection can be regenerated when any packet is received from the CPE.

When using the idle timeout for dynamic VLAN removal, keep the following in mind:

• The idle timeout period begins after a dynamic subscriber VLAN interface is created or traffic activity stops on a dynamic subscriber VLAN interface.

• If a new client session is created or a client session is reactivated successfully, the client idle timeout resets.

• The removal of inactive subscriber VLANs functions only with VLANs that have been authenticated.

Limits on Subscriber Sessions per Username and Access Profile

Legitimate subscribers might share their login credentials with unauthorized persons, expending service provider resources without benefit to the provider. Starting in Junos OS Release 18.4R1, you can control or prevent the sharing of login credentials by limiting the number of active subscriber sessions that are allowed for a specific username associated with an access profile. You can also achieve this control with RADIUS, but configuring the limit locally on the BNG eliminates dependency on an external server.

When you configure a limit, active sessions for the username/access profile combination are tracked. The number of tracked sessions is checked when authd receives a new session login request. If the number of tracked session matches the limit, the new login attempt is rejected and counted as a blocked request.

When authd receives a logout or client termination request for a session, the tracked-sessions count is decremented for that username/access profile entry. If this continues until there are no active sessions for the combination, the entry is removed from the session limit table. All associated username/access profile entries are removed from the table if you delete the access profile or the session-limit from your configuration.

The total number of sessions for a username can exceed the configured limit for a particular access profile, because the same username can be used with multiple access profiles.

The configured limit applies to existing active subscribers, but existing sessions are not torn down if number of active sessions exceeds the limit for a subscriber with that username and access profile combination.

Consider a situation where five sessions are currently active for a given username/access profile combination when you configure a limit of two.

1. The active sessions count is recorded as five in the session limit table entry for the combination.

2. A new subscriber with the same username and access profile tries to log in. The attempt is blocked because the limit of two sessions is already exceeded (five > two).

3. An existing subscriber logs out, decrementing the active sessions count to four.

4. A new subscriber with the same username and access profile tries to log in. The attempt is blocked because the limit of two sessions is still exceeded (four > two).

5. Three existing subscribers log out, reducing the active sessions count to one.

6. A new subscriber with the same username and access profile tries to log in. The attempt is allowed because the limit of two sessions has not yet been reached (one < two).

The session limit design prevents a denial-of-service event where a malicious user makes multiple login attempts with the correct username and access profile, but the wrong password. The numerous login attempts might exceed the configured session limit, but this does not occur because the tracked-sessions count is incremented only when the subscriber session state transitions to the active state, which the malicious logins do not achieve.

Benefits of Limiting Sessions for Usernames with the CLI

• Enables you to limit the number of sessions locally on the router, rather than being dependent on an external RADIUS server to provide the limit.

• Prevents some denial-of-service attacks based on multiple logins.

Subscriber Username Modification

For Layer 2 wholesale applications, some network service providers employ username modification to direct subscribers to the appropriate retail enterprise network. This modification is also called username stripping, because some of the characters in the username are stripped away and discarded. The remainder of the string becomes the new, modified username. The modified username is used by an external AAA server for session authentication and accounting. The modification parameters are applied according to a subscriber access profile that also determines the subscriber and session context; that is, the logical system:routing instance (LS:RI) used by the subscriber. Only the default (primary) logical system is supported. Because the wholesaler differentiates between multiple retailers by placing each in a different LS:RI, the usernames are appropriately modified for each retailer.

You can select up to eight characters as delimiters to mark the boundary between the discarded and retained portions of the original username; there is no default delimiter. The portion of the name to the right of the selected delimiter is discarded along with the delimiter. By configuring multiple delimiters, a given username structure can result in different modified usernames. You can configure the direction in which the original name is parsed to determine which delimiter marks the boundary. By default, the parse direction is from left to right.

Consider the following examples:

• You specify one delimiter, @. The username is user1@example.com. In this case, the parse direction does not matter. In either case, the single delimiter is found and example.com is discarded. The modified username is user1.

  

• You specify one delimiter, @. The username is user1@test@example.com. In this case, the parse direction results in different usernames.

  • Parse direction is left-to-right—The left-most @ is identified as the delimiter and test@example.com is discarded. The modified username is user1.

  • Parse direction is right-to-left—The right-most @ is identified as the delimiter and example.com is discarded. The modified username is user1@test.

  

• You specify two delimiters, @ and /. The username is user1@bldg1/example.com. The parse direction results in different usernames.

  • Parse direction is left-to-right—The @ is identified as the delimiter and bldg1/example.com is discarded. The modified username is user1.

  • Parse direction is right-to-left—The / is identified as the delimiter and example.com is discarded. The modified username is user1@bldg1.

  

You can configure a subscriber access profile so that a portion of each subscriber login string is stripped and subsequently used as a modified username by an external AAA server for session authentication and accounting. The modified username appears, for example, in RADIUS Access-Request, Acct-Start, and Acct-Stop messages, as well as RADIUS-initiated disconnect requests and change of authorization (CoA) requests.

Benefits of Subscriber Username Modification

• Enables Layer 2 wholesale network service providers to easily direct subscribers to the appropriate retail enterprise network.