Triple Play security

Triple Play security features

Anti-spoofing filters

Anti-spoofing filter types

A SAP or interface that supports anti-spoof filtering can be configured to use one of three types of anti-spoof tables. The type of table used by the SAP is dependent on the type of anti-spoof filtering needed, only one anti-spoofing table type is supported per SAP:

  • When only the incoming source MAC address is to be verified, the source MAC table must be defined (anti-spoof type mac).

  • When only the incoming source IP address is to be verified, the source IP table must be defined (anti-spoof type ip).

  • When both the incoming source MAC and source IP addresses are to be verified, the combination source IP and source MAC table must be defined (anti-spoof type ip-mac).

Note: Setting the anti-spoof filter type for the SAP is dependent on pre-existing static host definitions, for example, attempting to set the SAP anti-spoof filtering to mac fails if any static hosts exist that do not have a defined MAC address.

The anti-spoof table of a SAP or interface is populated from the DHCP lease state table and from any statically defined hosts on the SAP or interface.

Filtering packets

Packets from a client that match an anti-spoof filter entry when anti-spoof filtering is enabled can be further processed by the system. The matching packet is still subject to other forwarding criteria including potentially ACL filtering.

All packets that are not exempt from anti-spoofing and do not match an entry in the anti-spoof table are discarded. Every discard event increments the SAP discard packet counter. The discard event is not logged or alarmed, but a threshold alarm could be configured for the counter (see the Configuring System Monitoring Thresholds section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Basic System Configuration Guide).

Not all ingress packets are subject to the anti-spoof filtering when enabled. Non-IP packets are exempt for anti-spoof filter lookups and can be further processed by the system. This includes ARP requests and replies, as well as PPPoE packets. The only IP packets exempt from anti-spoof filtering are DHCP packets destined for the server UDP port 67. DHCP packets destined for the client UDP port number (port 68) are not exempt.

Layer 2 Triple Play security features

MAC pinning

This section describes the 7450 ESS and the 7750 SR acting as a Broadband Subscriber Aggregator (BSA).

DHCP snooping and IP and MAC auto-filters can be used to prevent Theft of Service (by a malicious user spoofing another user's address). However, these auto-filters do not discard non-IP packets such as PPPoE packets, potentially allowing a MAC address to be relearned on another SAP. MAC pinning closes this loophole, by not allowing a MAC address to be relearned on another SAP.

When MAC pinning is enabled, a MAC address learned on one SAP or SDP cannot be relearned on another SAP or SDP in the same VPLS, until the FDB entry for the MAC address times out. (If MAC aging is disabled, MAC entries on a SAP or SDP with MAC pinning enabled effectively becomes permanent.)

MAC pinning is implicitly enabled when DHCP auto-filters are enabled, and cannot be disabled. For MAC addressing learned during DHCP address assignment (when DHCP snooping function is active at least on one port of the VPLS), the MAC address is tied to a specific SAP for the duration of the DHCP lease.

MAC protection

In a Layer 2 environment, a malicious subscriber could create a denial-of-service (DoS) attack by sending Ethernet frames, with as source MAC address the address of a gateway (for example, the IP next hop upstream). As MAC learning is typically enabled, this would move the learned gateway MAC from the uplink SAP or SDP to the subscriber’s SAP, causing all communication to the gateway to be disrupted. If a local content server is attached to the same VPLS, a similar attack could be launched against it.

Communication between subscribers can be disallowed using Split Horizon Groups, but this by itself is not enough to prevent such an attack. The solution is to create a mechanism to explicitly protect some MAC addresses against being relearned on other SAPs.

The mac-protect feature on the 7450 ESS and 7750 SR allows a list of special MAC addresses to be configured in a VPLS. Two checks can then be made on incoming packets against these protected MAC addresses:

  • [no] auto-learn-mac-protect

    Used to enable the automatic protection of source MAC addresses learned on the associated object. MAC protection is used in conjunction with restrict-protected-src, restrict-unprotected-dst and mac-protect. When this command is applied or removed, the MAC addresses are cleared from the related object.

  • restrict-protected-src

    Used to prevent DoS attacks. If the source MAC address of a packet from a subscriber matches a protected entry, it is probable that this subscriber tried to impersonate the gateway or server. If no parameter is specified, such packets are discarded, a trap is generated, and the SAP on which it arrived is placed operationally down. If the alarm-only parameter is specified, the packet is forwarded, and an alarm is generated but the source MAC is not learned. If the discard-frame parameter is specified, the packet is discarded and an alarm generated.

  • restrict-unprotected-dst

    Used to force traffic from subscribers to only go toward a few defined destinations (the gateways or servers). Any packet from a subscriber whose destination MAC address does not match a protected entry is discarded.

DoS protection

This section describes the mechanisms and limitations of DoS protection related to subscriber management snooping functions. This feature is only supported on 7750 SR and 7450 ESS redundant chassis models. In subscriber aggregation networks, these routers play an active role in several protocols. Subscribers either intentionally or unknowingly interfere with the operation of the node’s processing capacity (for example, excessive ARP handling) or another user traffic.

Routing protocols such as OSPF and ISIS could also be a threat as packets can be injected by customers (erroneously or maliciously) which could cause high CPM overload. Service providers are concerned about DoS protection including DoS attacks when acting as a subscriber aggregation device and guarding against DoS attacks using unprovisioned protocols.

Subscriber aggregation network

In a subscriber aggregation network, multiple devices such as the 7750 SR or 7450 ESS routers provide access to a DHCP or a RADIUS server. These servers usually do not scale high enough to provide the means to control access to snooping functions through a controlled queue. It is possible, under severe conditions, that the network could become unavailable if the node cannot handle requests from subscribers.

Because the IOMs cannot be scaled to provide a per-subscriber queue to control traffic, a monitoring function, handled by the CPM, is provided. With this monitoring system, the CPM tracks the number of control plane messages set per subscriber and limits the rate to a specified level and provides feedback using event generation to alert a centralized system of a possible DoS attack.

The CPM provides a prioritized access to the CPU. Because the number of control packets expected from a subscriber should have a low rate, and under normal conditions, the system provides a rate limit on a per subscriber or MAC basis and drops a subscriber control packet before it is queued or processed by the CPU. The system is configured with expected arrival rate of per MAC or subscriber control packet rates and optionally total rate per interface or SAP.

The system maintains a per-second running rate monitor per SAP and per MAC. If an entry is using more than the configured rate, the system does not forward that packet to be queued. Every existing subscriber host is monitored. A subscriber host is flagged and the system observed with an excessive rate of control packets. With PPPoE, the CPM monitors subscriber hosts before the IP address is provided by the SAP, MAC, or session-id combination.

The control protocols affected by this mechanism include:

  • ARP (in arp-reply-agent)

  • DHCP (for discover and renew)

  • ICMP

  • PPPoE

  • IGMP

Network control filtering

The 7750 SR or 7450 ESS can block network control traffic for unconfigured protocols. For example, if OSPF is not configured on an IP interface, all OSPF- related traffic should be dropped before the traffic reaches the CPU.

Protocols are blocked based on whether that protocol is configured to run on the specific IP interface. It is not required to re-configure the permitted protocols.

Protocol traffic control by this mechanism includes:

  • OSPFv2

  • OSPFv3

  • IS-IS

  • RSVP-TE

  • LDP

  • RIP

  • PIM

  • MLD

  • IGMP

  • BGP

  • BFD

  • L2PT

  • PPP

  • DHCP

VPLS redirect policy

This section describes the 7450 ESS or 7750 SR acting as a Broadband Subscriber Aggregator (BSA) with Layer 2 aggregation toward a Broadband Subscriber Router (BSR).

In a Triple Play network it may be necessary to route some traffic from or to subscribers through a Deep Packet Inspection (DPI) device, for example, to limit peer-to-peer traffic. However such a DPI device typically has limited bandwidth available, so only those packets that need inspection should be sent to it.

In a Layer 3 network, such policy-based redirection can be achieved using ‟next-hop redirect” ACL entries. In a layer 2 (VPLS) aggregation network, the same result can be achieved using ‟redirect to SAP” or ‟redirect to SDP” policy.

See the ACL Next-Hop for VPLS section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide.

ARP handling

ARP reply agent

This section describes the 7450 ESS or 7750 SR acting as a Broadband Subscriber Aggregator (BSA).

In Triple Play networks, typically downstream broadcast is not allowed on subscriber SAPs. As a result, subscribers cannot receive ARP requests from the network. Instead, the 7450 ESS or 7750 SR responds to ARP requests from the network, with information from the DHCP lease state table.

In the upstream direction (toward the network), the ARP reply agent intercepts ARP Requests on subscriber SAPs, and checks them against the DHCP lease state table. The purpose is to prevent a malicious subscriber spoofing ARP request or ARP reply messages and therefore populating the upstream router's ARP table with incorrect entries.

When the keyword sub-ident is added in the ARP reply agent configuration, also the subscriber identity is checked. If an upstream ARP request is targeted to the same subscriber, it is dropped. Otherwise, it is flooded to all VPLS interfaces outside the received Split Horizon Group (SHG).

Static hosts can be defined on the SAP using the host command. Dynamic hosts are enabled on the system by enabling the lease-populate command in the SAP’s dhcp context. If both a static host and a dynamic host share the same IP and MAC address, the VPLS ARP reply agent retains the host information until both the static and dynamic information are removed. If both a static and dynamic host share the same IP address, but different MAC addresses, the VPLS ARP reply agent is populated with the static host information.

In brief, the ARP Replay Agent operation is as follows:

  • For ARP request received from a customer SAP:

    • first check in DHCP lease state table — if no match: discard

    • if (sub-ident enabled) and (destination equals the same subscriber): discard

    • otherwise: flood to all SAPs/SDPs outside this SHG

  • For ARP request received from the network:

    • lookup IP address in DHCP lease state table — if no match: discard

    • otherwise: respond with MAC address from the DHCP lease state table

Dynamic ARP table population

This section describes the 7450 ESS or 7750 SR acting as a Broadband Subscriber Aggregator (BSA) with Layer 3 forwarding toward the network.

In an IES service, the system’s ARP table can be populated dynamically using entries in the DHCP lease state table (in turn, populated from snooping DHCP ACK messages (see DHCP Snooping)), and from static hosts defined on the SAP. In the router ARP table these are indicated with state managed.

If both a static host is created with the same IP and MAC address as an existing managed entry, creation fails and a trap is generated.

If a DHCP Lease needs to be populated with the same IP and MAC address as an existing static host entry, creation fails and a trap is generated.

No static-arp creation is possible when combined with arp-populate.

Local proxy ARP

This section describes the 7450 ESS or 7750 SR acting as a Broadband Subscriber Aggregator (BSA) with Layer 3 forwarding toward the network.

Local proxy ARP allows the 7450 ESS or 7750 SR to respond to ARP requests received on an interface, for an IP address which is part of a subnet assigned to the interface. When the local proxy ARP feature is enabled, the switch responds to all ARP requests for IP addresses belonging to the subnet with the MAC address of the interface, and forwards all traffic between hosts in the subnet.

This feature is intended to be used in situations (such as DSL aggregation networks) when hosts belonging to the same subnet are prevented from directly communicating with each other over the subnet by the configuration of the switch (or DSLAM) to which they are connected.

Note:

When local-proxy-arp is enabled under a IES service, all ICMP redirects on the ports associated with the service are automatically blocked. This prevents users from learning each other's MAC address (from ICMP redirects).

The implementation of proxy ARP with support for local proxy ARP allows the router to respond to ARP requests in the subnet assigned to an IES or VPRN interface, therefore allowing multiple customers to share the same IP subnet.

Web portal redirect

This section describes the 7450 ESS or 7750 SR acting as a Broadband Subscriber Aggregator (BSA).

In a Triple Play network it may not be wanted (or feasible) to perform manual provisioning of new services and service changes. The ideal way of working is automatic provisioning, with the end-user supplying his details at a retailer, or (if physical connectivity is already present through an on-line customer portal).

The 7450 ESS and 7750 SR support a special ACL that automatically redirects subscribers to a predefined URL. This is done by sending a HTTP 302 (moved) message to the subscriber, regardless of the requested URL.

The message flow is as follows (see IP illustration of message flow in web portal redirect below):

  1. The subscriber gets an IP address using DHCP (if the customer is trying to use a static IP he is blocked by the anti-spoofing filter).

  2. The subscriber tries to connect to a website (TCP SYN, TCP ACK, HTTP GET).

  3. The 7450 ESS or 7750 SR intercepts the HTTP GET request and discards it.

  4. The 7450 ESS or 7750 SR then responds to the subscriber with a HTTP 302 message (service temporarily unavailable or moved), containing a new target URL (that of the portal) configured by the operator. This target URL can include the subscriber’s IP and MAC addresses as part of the portal’s URL string.

  5. The subscriber’s web browser closes the original TCP connection and opens a new connection to the web portal where the subscriber can sign up or change his/her service Profile.

  6. After approving the changes, the web portal updates the ACL (directly or through another system such as the Nokia 5750 SSC) to remove the redirection policy.

  7. The subscriber can now connect to the original site.

Figure 1. IP illustration of message flow in web portal redirect

The items in red text in IP illustration of message flow in web portal redirect are messages the 7450 ESS or 7750 SR sends (masquerading as the destination), regardless of the destination IP address or type of service.

The following displays information that can optionally be added as variables in the portal URL (http-redirect url):

  • $IP

    Customer’s IP address

  • $MAC –

    Customer’s MAC address

  • $URL

    Original requested URL

  • $SAP

    Customer’s SAP

  • $SUB

    Customer’s subscriber identification string

  • $CID

    The string that represents the circuit-id or interface-id of the subscriber host (hexadecimal format)

  • $RID

    The string that represents the remote-id of the subscriber host (hexadecimal format)

Note:

The subscriber’s IP and MAC address variables are populated from the anti-spoofing list, and therefore anti-spoofing must be enabled (see section Anti-spoofing filters).

Because most websites are accessed using the domain name, the 7450 ESS or 7750 SR needs to allow DNS queries, and an ACL entry to this effect should be included in the filter (see Configuring Web Portal Redirect).

Configuring Triple Play security with CLI

Common configuration tasks

Configuring anti-spoofing filters

Anti-spoofing filters are used to prevent malicious subscribers from sending IP packets with a forged IP or MAC address, and therefore mis-directing traffic. The anti-spoofing filter is populated from the DHCP lease state table, and DHCP snooping must be enabled on the SAP.

There are three types of filters (MAC, IP, and IP+MAC). One type is allowed per SAP.

The following displays an IES service interface configuration with anti-spoofing.

A:ALA-48>config>service>ies# info
----------------------------------------------
            interface "test123" create
                address 10.10.42.41/24
                local-proxy-arp
                proxy-arp
                    policy-statement "ProxyARP"
                exit
                sap 1/1/7:0 create
                    anti-spoof ip
                exit
                arp-populate
                dhcp
                    lease-populate 1
                    no shutdown
                exit
            exit
            no shutdown
----------------------------------------------
A:ALA-48>config>service>ies#

Configuring Triple Play security features

Configuring MAC pinning

The following example displays a partial BSA configuration with MAC pinning enabled on a SAP.

A:ALA-48>config>service# info
----------------------------------------------
vpls 800 customer 6001 create
    description "VPLS with residential split horizon for DSL"
    stp
        shutdown
    exit
    sap 2/1/4:100 split-horizon-group "DSL-group2" create
        description "SAP for RSHG"
               mac-pinning
    exit    
    no shutdown
----------------------------------------------
A:ALA-48>config>service#
Configuring MAC protection
Preventing access by residential subscribers using protected (gateway) MAC addresses

The first step is to create a list of MAC addresses to be protected. The second step is to prevent access using these source addresses inside an SHG or a SAP.

The following example displays a partial BSA configuration with some protected MAC addresses on any SAP created inside the SHG.

A:ALA-48>config>service# info
----------------------------------------------
vpls 800 customer 6001 create
    no shutdown
    split-horizon-group "mygroup" create
        restrict-protected-src
    exit
    description "VPLS with residential split horizon for DSL"
    mac-protect
        mac 00:00:17:FE:82:D8
        mac 93:33:00:00:BF:92
    exit
----------------------------------------------
A:ALA-48>config>service#
Restricting access by residential subscribers to a small list of upstream MAC addresses

The first step is to create a list of MAC addresses to be protected. The second step is to restrict access to these addresses only from an SHG or a SAP (if the MAC address of an upstream server is not known, it can be discovered using, for example, the CPE ping OAM tool).

The following example displays a partial BSA configuration with restricted access to some MAC addresses from a specified SAP (an unrestricted access from any other SAP within the VPLS).

A:ALA-48>config>service# info
----------------------------------------------
vpls 800 customer 6001 create
    no shutdown
    description "VPLS with restricted access on a SAP"
    mac-protect
        mac 00:00:17:FE:82:D8
        mac 93:33:00:00:BF:92
    exit
    sap 1/1/4:30 create
        restrict-unprotected-dst
    exit
----------------------------------------------
A:ALA-48>config>service#
Configuring a VPLS redirect policy

VPLS redirect policy example displays an IP filter entry configuration for VPLS redirect policy.

Figure 2. VPLS redirect policy example

Information about defining and applying IP and MAC filters is described in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

Creating the filter

The following displays a redirect filter entry:

A:ALA-A>config>filter# info
----------------------------------------------
    ip-filter 10 
        default-action forward
        entry 10
            match 
                dscp be
            exit
            action forward next-hop sap 1/1/1:100
            exit
        exit
    exit
    ip-filter 11 
        default-action forward
        entry 10
            match 
                dscp be
            exit
                dscp be
            exit
            action forward next-hop sap 1/1/2:100
        exit
    exit
---------------------------------------------
A:ALA-A>config>filter#
Applying the filter to a VPLS service

The following displays how the redirection filter configured above is assigned to the ingress SAP from the DSLAM, and the ingress SDP from the BSR:

A:ALA-A>config>service>vpls# info
----------------------------------------------
    vpls 10 customer 1 create
        description ‟vpls10”
            sap 1/2/3:100 create
                ingress ip filter 10
            exit
            sap 1/1/1:100 create
            exit
            sap 1/1/2:100 create
            exit
            mesh-sdp 100:10 create
                ingress ip filter 11
            exit
        exit
    exit
----------------------------------------------
A:ALA-A>config>service>vpls#

Configuring ARP handling

Configuring proxy ARP

The implementation of proxy ARP with support for local proxy ARP allows the 7450 ESS or 7750 SR to respond to ARP requests in the subnet assigned to an IES or VPRN interface.

Configuring this command allows multiple customers to share the same IP subnet.

The following example displays an IES proxy ARP configuration:

A:ALA-48>config>service>ies# info
----------------------------------------------
            interface "test123" create
                address 10.10.42.41/24
                local-proxy-arp
                proxy-arp-policy "ProxyARP"
                exit
            exit
            no shutdown
----------------------------------------------
A:ALA-48>config>service>ies#
Configuring local proxy ARP

When local proxy ARP is enabled on an IP interface, the 7450 ESS or 7750 SR responds to all ARP requests for IP addresses belonging to the subnet with its own MAC address, and forwards all traffic between hosts in that subnet. Local proxy ARP is disabled by default.

Note: When local-proxy-arp is enabled under a IES or VPRN service, all ICMP redirects on the ports associated with the service are automatically blocked. This prevents users from learning each other's MAC address (from ICMP redirects).

The following example displays a local proxy ARP IES configuration:

A:ALA-A>config>service>ies# info
----------------------------------------------
        interface "test" create
            shutdown
            address 10.10.36.2/24
            local-proxy-arp
        exit
----------------------------------------------
A:ALA-A>config>service>ies#
Configuring ARP reply agent in a VPLS service

When ARP reply agent is enabled, the 7450 ESS or 7750 SR responds to ARP requests from the network, with information from the DHCP lease state table.

In the upstream direction (toward the network), the ARP reply agent intercepts ARP requests on subscriber SAPs, and checks them against the DHCP lease state table. The purpose is to prevent a malicious subscriber spoofing ARP request or ARP reply messages and therefore populating the upstream router's ARP table with incorrect entries.

The following example displays a partial BSA configuration with ARP Reply Agent enabled on a SAP:

A:ALA-48>config>service# info
----------------------------------------------
...
    vpls 800 customer 6001 create
        description "VPLS with ARP Reply Agent active"
        sap 2/1/4:100 split-horizon-group "DSL-group2" create
    arp-reply-agent sub-ident
        exit    
        sap 3/1/4:200 split-horizon-group "DSL-group2" create
    arp-reply-agent sub-ident
        exit
        no shutdown
...
----------------------------------------------
A:ALA-48>config>service#
Configuring remote proxy ARP

The following example displays the IES configuration to enable remote proxy ARP:

A:ALA-49>config>service>ies# info
----------------------------------------------
            interface "test-1A" create
                address 10.10.26.3/24
                remote-proxy-arp
            exit
            no shutdown
----------------------------------------------
A:ALA-49>config>service>ies#
Configuring automatic ARP table population in an IES or VPRN interface

The following example displays the IES DHCP configuration to enable automatic population of the ARP table using snooped DHCP information about an IES or VPRN (VPRN is supported on the 7750 SR only) interface:

A:ALA-1>config>service>ies>if# info
----------------------------------------------
                arp-populate
                dhcp
                    description "snooping_only"
                    lease-populate 1
                    no shutdown
                exit
----------------------------------------------
A:ALA-1>config>service>ies>if#


A:ALA-1>config>service>vprn>if# info
----------------------------------------------
                dhcp
                    description "test"
                    lease-populate 1
                    no shutdown
                exit
----------------------------------------------
A:ALA-1>config>service>ies>if#
Configuring CPU protection

CPU Protection can be used to protect the SR OS in subscriber management scenarios. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for information about CPU Protection operation and configuration.

Configuring web portal redirect

The generic CLI structure for defining and applying IP and MAC filters is described in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

The following example displays an IP filter entry configuration for web-portal redirect:

A:ALA-A>config>filter# info
----------------------------------------------
    ip-filter 10 create
        description ‟filter to forward DNS and web traffic to my portal; redirect al
l other web traffic to the portal and drop everything else”
        default-action drop
        entry 10 create
            description ‟allows DNS traffic”
                match protocol 17 
                dst-port 53
            exit
            action forward 
        exit
        entry 20 create
            description ‟allows web traffic destined to portal (IP address 10.0.0.1)
”
            match protocol 6
                dst-port eq 80
                dst-ip 10.0.0.1
            exit
            action forward 
        exit
        entry 30
            description ‟redirects all web traffic to portal”
            match protocol 6
                dst-port eq 80
            exit
            action http-redirect http://www.myportal.com/defaultportal/
login.cgi?ip=$IP&mac=$MAC&orig_url=$URL&usb=$SUB
        exit
    exit
----------------------------------------------
A:ALA-A>config>filter#
  • Filter entry 10 in the example output allows the customer to access DNS to get the IP address of the original website they are trying to view.

  • Entry 20 allows HTTP packets destined for the captive portal itself to be forwarded.

    Note: The actual IP address (a.b.c.d) must be entered, not the DNS name (‟www.myportal.com”). The IP address can be easily resolved from the 7450 ESS or 7750 SR CLI using the ping command.
  • Entry 30 (which is the last option that does not drop the customer packets) checks for HTTP protocol and then starts the redirection process:

    • The 7450 ESS or 7750 SR intercepts the HTTP GET from the subscriber and respond with an HTTP 302 (temporarily moved) with the URL configured in the filter entry. This URL can contain some variables, notably the customer IP and MAC addresses to allow the portal to create an entry for the customer. The original requested URL is also included to redirect the client site back to the original requested site when the process is done.

    • The client then closes the connection with the original IP address and open a connection to the redirected server. Entry 20 allows this connection.

The following displays how the redirection filter configured above is assigned to an ingress SAP:

A:ALA-A>config>service>vpls# info
----------------------------------------------
    vpls 3 customer 6 create
        description "VPLS with web portal redirection filter applied"
        sap 2/1/5:0 create
            ingress
                filter ip 10
            exit
        exit
        no shutdown
    exit
----------------------------------------------
A:ALA-A>config>service>vpls#