AAA policy types

Overview

AAA policies provide security for network traffic on one or more NEs. You can use the NFM-P to create AAA policies that provide authentication, authorization, and accounting functionality. The NFM-P supports the following AAA policies:

Accounting on/off groups

An accounting on/off group defines a group of RADIUS server policies for the purpose of synchronizing accounting on/off messages across all policies in the group. It establishes which policy in the group acts as the controller policy, and which policies act as monitors. The accounting on/off state of the monitor policies is set by the controller policy.

The controller/monitor designation is configured on each RADIUS server policy in the group. Only one policy in a group can be designated as the controller.

ISA RADIUS policies

An ISA RADIUS policy defines the network security requirements used when an ISA server is configured to use a RADIUS server for AAA client requests.

The policy can also be configured to limit the sending rate of periodic logging messages to the RADIUS server, thereby reducing the chance of a backlog of pending messages accumulating at the RADIUS server.

L2TP RADIUS accounting policies

An L2TP RADIUS accounting policy defines the usage data collected for subscribers based on either an L2TP tunnel or an L2TP session and sends this data to a RADIUS server.

NAT RADIUS accounting policies

To increase logging performance (messages-per-second) and provide a reliable logging facility, a RADIUS accounting option is provided for Large Scale NAT. The configuration of a NAT RADIUS policy and its assignment to a NAT ISA group (NAT or WLAN GW) will cause the node to instruct the RADIUS user to start logging when a port-range-block is assigned to a user, or to stop logging when this block is released back into the pool.

RADIUS-based accounting policies

A RADIUS-based accounting policy is used to send accounting information to a RADIUS server.

When an NE uses a RADIUS-based accounting policy and the creation of a subscriber host invokes the policy, the NE generates an accounting-start packet that includes the policy parameters, and forwards the packet to a RADIUS server. Depending on the policy specifications, the NE also sends interim update messages that contain usage statistics. When a policy is no longer used by any subscriber host, the NE sends an accounting-stop packet that contains the final usage statistics.

A RADIUS-based accounting policy specifies the type of accounting information that is forwarded to a RADIUS server. The information is one of the following:

• per-SLA profile—forwards start, stop, and interim update messages regarding SLA profile usage

• per-host and per-SLA profile—forwards the following:

  • start, stop, and interim update messages regarding SLA profile usage

  • start and stop messages for individual host sessions

• per-host only—forwards start, stop, and interim update messages for each subscriber host session

When a subscriber host disconnects, the NE sends an accounting-stop packet that contains the final usage statistics. An accounting-stop packet is also sent when a subscriber or subscriber host is deleted, or when an SLA profile instance (non-HSMDA) or subscriber instance (HSMDA) is changed.

You can reduce the volume of data that is generated by the accounting policy and sent to the RADIUS server by defining custom records. Custom records include specific counters in RADIUS accounting messages. Custom records eliminate queues or selected counters within these queues, that are not relevant for billing.

You can further decrease the number of accounting messaging by including only objects which have experienced a significant change in the specified counters. When this significant change is met, the record is generated.

RADIUS script policies

The RADIUS script policy references python scripts for RADIUS AAA packet manipulation in a subscriber management application. See To configure a RADIUS script policy.

Operational states of primary and secondary RADIUS scripts

When the Up state is selected for primary or secondary scripts, the NE downloads the Python script from the specified path and copies it to the memory. If the path is invalid or the script is too long or contains syntax errors, the operational state of the script will change to the Down state. If the Python script installs correctly, the operational state of the script will remain in the Up state.

Script modifications are only applied by the NE after the script admin state has been changed to Down and then Up again.

RADIUS server policies

A RADIUS server policy is used to configure access to a group of RADIUS servers.

A maximum of five RADIUS server entries can be created under each RADIUS server policy. These RADIUS server entries must be created under the specified routing instance. For the global policy, the RADIUS server entries can be created within all base routing instances if Base routing instance is specified, or within the sites of the specified VPRN service if VPRN routing instance is specified. A RADIUS server entry cannot be created if Management routing instance is specified.

You can associate RADIUS server policies to Ethernet ports under 802.1x. See To associate a RADIUS Server policy to an Ethernet port for dot1x authentication for information.

Route download policies

A route download policy provides a mechanism for an NE to download (in advance) customer-assigned subnets from a RADIUS server, so that they can be re-advertised to the corresponding routing protocols. In this manner, subscriber connections can potentially be established faster because the routes are already in place. Routing protocol churn is reduced as subscribers connect and disconnect.

Subscriber authentication policies

A subscriber authentication policy uses RADIUS authentication to grant network access to a dynamic host. These DHCP-based policies define the parameters for dynamically-created subscriber host sessions and authenticate the sessions. They can be applied to a VPLS or IES SAP, or to a VPRN or IES group interface.

You can configure a subscriber authentication policy for LLID pre-authentication. The policy is specified as a pre-authentication policy on a local user database, as described in To configure a local user database for subscriber host authentication.

Diameter peer policies

Diameter peer policies are used in a subscriber management context to provide a credit control mechanism. The diameter peer policy establishes a server/peer configuration. The NE functions as the credit control client, while the peer acts as the credit control server. The diameter peer policy is used to specify common diameter protocol parameters, while the diameter peer defines the relationship with an external diameter server. The diameter peer policy can be configured with a python policy, allowing the diameter policy to be modified by python scripts and diameter python messages.

A diameter peer policy can be configured to function as part of a redundancy configuration, based on a Gx proxy model. Two NEs run instances of Gx proxy, with one Gx proxy instance active and the other inactive. The active instance has a peering connection to DRA. The purpose of the redundancy is predictable operations recovery after an NE failure. A diameter peer policy with proxy configuration is associated with a diameter application policy which, in turn, is applied to a group interface. The diameter proxy monitors the group interface.

Peers

The diameter peer policy defines a set of peers with which to establish diameter sessions. Peers share the configuration of the policy with which they are associated, but can override individual timer parameters inherited from the policy. In addition, each peer defines transport and connection-specific parameters, values for destination-specific AVPs, and a preference value.