Triple Play security

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

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.

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.

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.

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.

This section describes the mechanisms and limitations of DoS protection related to subscriber management snooping functions. This feature is only supported on 7750 SR-Series and 7450 ESS-Series 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.

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.

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

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.

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.

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.

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#

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#