Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Session Options for Subscriber Access

Session options enable you to specify several characteristics for DHCP, L2TP, and terminated PPP subscriber sessions. Session options are configured in access profiles that determine the parameters for subscriber access, authentication, authorization, and accounting.

Understanding Session Options for Subscriber Access

You can use access profiles to configure several characteristics of the sessions that are created for DHCP, L2TP, and terminated PPP subscribers. You can place limits on subscriber access based on how long the session has been up, how long the user has been inactive, or both. You can limit subscriber sessions by username per access profile. You can also set parameters that modify a subscriber’s username at login based on the subscriber’s access profile.

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.

Note:

For all subscriber types other than DHCP (such as L2TP-tunneled and PPP-terminated subscribers), the session timeout value limits the subscriber session. For DHCP subscribers, the session timeout value is used to limit the lease when no other lease time configuration is present. The lease expires when the timeout value expires. If this value is not supplied by either the CLI or RADIUS, the DHCP lease does not expire.

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.

Note:

If the Session-Timeout value is 0, then any existing session timeout for that session is cancelled.

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.

Best Practice:

We recommend that you do not configure a session timeout for subscribers receiving voice services. Because the session timeout is based only on time and not user activity, it is likely to interrupt subscribers actively using a voice service and terminate their calls unexpectedly (from the subscriber viewpoint). This result is a particular concern for emergency services calls.

Best Practice:

We recommend that you do not configure an idle timeout for DHCP subscribers. When the timeout expires with no activity and the connection is terminated, the protocol has no means to inform the client. Consequently, these subscribers are forced to reboot their CPE device the next time they attempt to access the Internet.

Contrast the behavior when an idle timeout is configured for PPP subscribers. In this case, timeout expiration causes PPP to terminate the link with the peer. Depending on the CPE device, this termination enables the peer to automatically retry the connection either on demand or immediately. In either case, no subscriber intervention is required.

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.

Note:

For stacked subscriber sessions such as PPP with autoconfigured VLANs, both usernames in the stack are used for authentication and consequently both are counted against the session limit.

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.

Configuring Subscriber Session Timeout Options

Subscriber session timeout options enable you to place limits on subscriber access based on how long the session has been up, how long the user has been inactive, or both. The subscriber session options apply to both L2TP-tunneled and PPP-terminated subscriber sessions. For DHCP subscribers, the session timeout limits the DHCP lease time.

Note:

To configure the timeout attributes in RADIUS, refer to the documentation for your RADIUS server.

To configure limitations on subscriber sessions, configure the session options in the client profile that applies to the subscriber:

  • Terminate the subscriber when the configured session timeout expires, regardless of activity.

  • Terminate the subscriber when there is no ingress or egress data traffic for the duration of the configured idle timeout.

  • Terminate the subscriber when there is no ingress data traffic for the duration of the configured idle timeout; ignore egress traffic.

For example, to configure session timeout options in the acc-prof client profile, specifying an idle timeout of 15 minutes, that only ingress traffic is monitored, and that the session times out after 120 minutes:

Limiting the Number of Active Sessions per Username and Access Profile

You can control the degree to which legitimate subscribers can share their login credentials by limiting the number of active subscriber sessions that are allowed for a specific username associated with an access profile.

To limit the number of active sessions per username and access profile:

For example, to set the maximum number of active sessions per username to five for the access profile isp-weg-4:

You can use the show network-access aaa statistics session-limit-per-username command to view statistics for active sessions and blocked requests.

You can use the clear network-access aaa statistics session-limit-per-username username command as an aid to debugging by clearing the blocked request statistics for any of the following cases:

  • For all usernames across all access profiles.

  • For a specific username across all access profiles.

  • For a specific username in a specific access profile.

  • For all usernames in a specific access profile.

Configuring Username Modification for Subscriber Sessions

You can use subscriber session options to set parameters that modify a subscriber’s username at login based on the subscriber’s access profile. 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. This capability can be useful, for example, in Layer 2 wholesale implementations, where the network service providers employ username modification to direct subscribers to the appropriate retail enterprise network.

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.

To configure username modification:

  1. Define a profile consisting of a set of AAA options for authorizing and configuring a subscriber or set of subscribers with a subscriber access profile.
    1. Specify the name of the subscriber access profile that includes the username stripping configuration.
    2. (Optional) Specify the logical-system:routing-instance (LS:RI) that the subscriber session uses for AAA (RADIUS) interactions like authenticating and accounting. For example, this may correspond to the LS:RI for a retail ISP that provides services to the subscriber.
    3. (Optional) Specify the logical-system:routing-instance (LS:RI) in which the subscriber interface is placed. For example, this may correspond to the LAC-facing interface on the LNS that is accessed by all requests from a subscriber residence.
  2. Configure the session options in the access profile that specify how usernames are stripped.
    1. Specify one or more delimiters to mark the boundary between the discarded and retained portions of the original username.
    2. (Optional) Specify the direction in which the original username is examined to find a delimiter. The default direction is left-to-right.
  3. (Optional) Specify that the AAA options are on a per-interface basis when dynamic subscribers are authenticated.
  4. (Optional) Specify that the AAA options are part of the PPP options in a group profile that applies to tunneled PPP subscribers at the LNS.

In the following example, the AAA options profile, aaa1, specifies a subscriber access profile, entA, for subscribers in the default logical system and routing instance 1. The access profile, entA, specifies that usernames are examined from left to right until the delimiter, @, is found. The AAA options profile is applied to tunneled PPP subscribers that belong to the group profile, FD1.

Given that configuration, suppose a subscriber attempts to log in with the username, user1@example.com. When this name is examined, the delimiter and the string example.com are discarded, leaving a modified username of user1. Note that the result is the same if the parse direction is set to examine the name from right to left, because only one delimiter is defined and only one is present in the original username.

Now suppose the subscriber logs in with the username, user1@test@example.com. For a username like this, the parsing direction makes a difference in the modified username. The configuration determines that the first instance of the delimiter @ is found first, because the name is parsed from left to right. This delimiter and the string test@example.com are discarded, leaving user1 as the modified username.

What happens when the configuration sets a different parsing direction?

In this case, for the username user1@test@example.com, the second instance of the delimiter is identified and it is discarded with the string @example.com. The modified username is user1@test.

You can achieve the same results of different modified usernames based on parse direction by configuring more than one delimiter as in the following configuration, where you specify two delimiters, @ and /.

For the username user1@bldg1/example.com, parsing left to right identifies the @ delimiter first and the modified username is user1. Parsing right to left instead, identifies the / delimiter first and strips it away with the string example.com, leaving a modified username of user1@bldg1.

Removing Inactive Dynamic Subscriber VLANs

Subscriber session timeouts enable you to place limits on subscriber access based on how long the session has been up, how long the user has been inactive, or both. In configurations using dynamically created subscriber VLANS, the idle timeout also:

  • Deletes the inactive subscriber VLANs when the inactivity threshold has been reached.

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

Note:

Session timeouts are typically not used for deleting dynamic subscriber VLANs. The timeout might be useful only in very limited use cases. One case might be 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.

Note:

To configure the idle timeout attribute in RADIUS, refer to the documentation for your RADIUS server.

To remove inactive dynamic subscriber VLANS:

  1. Edit session options for the router access profile.
  2. Configure the maximum period a subscriber session can remain idle.
Release History Table
Release
Description
19.4R1
Starting in Junos OS Release 19.4R1, the Session-Timeout attribute [27] is supported in RADIUS CoA messages.
18.4R1
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.