• Supported Platforms
• MX Series

• Related Topics
• Subscriber Secure Policy Traffic Mirroring Architecture
• RADIUS Attributes Used for Subscriber Secure Policy
• Configuring RADIUS-Initiated Subscriber Secure Policy Mirroring Overview
• SNMP Traps for Subscriber Secure Policy LAES Compliance
• Subscriber Secure Policy Licensing Requirements

Subscriber Secure Policy Overview

Subscriber secure policy enables you to configure traffic mirroring on a per-subscriber basis. Subscriber secure policy mirroring can be based on information provided by either RADIUS or Dynamic Tasking Control Protocol (DTCP).

Configuration of subscriber secure policy mirroring is independent of the actual mirroring session—you can configure the mirroring parameters at any time. Also, you can use a single RADIUS or DTCP server to provision mirroring operations on multiple routers in a service provider’s network. To provide security, the ability to configure, access, and view the subscriber secure policy components and configuration is restricted to authorized users.

Once subscriber secure policy is triggered, both the subscriber ingress and egress traffic are mirrored. The original traffic is sent to its intended destination and the mirrored traffic is sent to a mediation device for analysis. The actual mirroring operation is transparent to subscribers whose traffic is being mirrored. A special UDP/IP header is prepended to each mirrored packet sent to the mediation device. The prepended header is used as a demultiplexer, enabling the mediation device to differentiate the multiple mirrored streams that arrive from different sources.

Note: If both RADIUS-initiated and DTCP-initiated mirroring are configured for the same subscriber prior to login, the RADIUS-initiated configuration takes precedence. If both mirroring methods are configured for in-session mirroring, the first method that is triggered is used, and the other method is ignored.

Subscriber secure policy also supports the use of SNMPv3 traps to report mirroring information to an external device. The traps map to messages defined in the Lawfully Authorized Electronic Surveillance (LAES) for IP Network Access, American National Standard for Telecommunications.

Traffic mirroring has many uses, such as debugging network problems, troubleshooting specific user issues, and lawful intercept. For example, you might use RADIUS-based mirroring when debugging network problems related to mobile users, who do not always log in to the same router. Subscriber secure policy mirroring is particularly useful for large networks, in which you can use a single RADIUS or DTCP server to provision the mirroring operation.

The following list provides information about RADIUS-initiated and DTCP-initiated mirroring::

• RADIUS-initiated mirroring creates secure policies based on certain RADIUS VSAs and uses RADIUS attributes to identify the subscriber whose traffic is to be mirrored. There are two variations of RADIUS-initiated mirroring. For both types, the mirroring operation is initiated without regard to the subscriber location, router, interface, or type of traffic.

  • Subscriber login—The mirroring operation starts when the subscriber logs in and the trigger is received in a RADIUS Access-Accept message. Using triggers in RADIUS Access-Accept messages enables you to mirror per-subscriber traffic without regard to how often the subscriber logs in or out, or which router or interface the subscriber uses.
  • In-session—The mirroring operation starts when the trigger is received in a RADIUS Change-of-Authorization-Request (CoA-Request) message. Using triggers in CoA messages enables you to immediately mirror traffic of a subscriber who is already logged in.

• DTCP-initiated mirroring creates secure policies based on DTCP attributes to mirror traffic for the subscriber. The attributes in a DTCP ADD message trigger the router to start mirroring traffic and specify the interface on which the mirroring takes place. The following list describes the types of DTCP-initiated mirroring:

  • Subscriber login—If the DTCP ADD message with the trigger has been previously received, the subscriber traffic on the specified interface is then mirrored when the subscriber logs in.
  • In-session—If the subscriber is already logged in, the mirroring operation starts when the trigger is received in the DTCP ADD message.

Subscriber Secure Policy Terms

Table 1 defines terms that are used in the discussion of subscriber secure policy.