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).
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-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.
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.
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):
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).
The subscriber tries to connect to a website (TCP SYN, TCP ACK, HTTP GET).
The 7450 ESS or 7750 SR intercepts the HTTP GET request and discards it.
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.
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.
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.
The subscriber can now connect to the original site.
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)
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.
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.
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#