Page History

 

borderColor	green
bgColor	transparent
borderWidth	2

Noprint
Back to Table of Contents Back to SBC System Security

Additional sections:

Children Display
style h6

Panel

In this section:

Table of ContentsmaxLevel3

Traffic Filtering and Policing

The

Spacevars
0 series4

supports traffic filtering and policing mechanisms to block packets that may be harmful to the network. Packet policing is done at several different levels of granularity, with all appropriate levels of policing applied to each packet. This section describes

Spacevars
0 series4

policing and filtering mechanisms for providing packet level Denial Of Service (DoS) protection and access control.

IP Access Control Lists (ACLs) are filters and policers that deals only with packets associated with SIP message arriving at the SBC. It is not concerned with SIP message leaving the SBC. ACLs protect the SBC from attacks by preventing traffic from all other IP addresses except those specified on the "white list". However, only signaling and management IP traffic is subjected to IP ACL filtering. Media IP traffic (such as RTCP, SRTCP, SRTP and RTP) is not subjected to IP ACL filtering. For more information on IP ACLs, see Types of ACLs.

An attack is defined as an excessive packet discard rate (of various packet types), when the rate of incoming packets exceeds the Fill Rate. Fill Rate is measured in "packets per second" or "pps". The policing is done based on fill rate and token buckets. Fill rate determines the rate in which credits are applied to the bucket.  So a 20 pps Fill Rate means one credit every 50 millisecond. If you have a Bucket Size of 50 packets and Fill Rate of 20 pps, the policer can handle a burst of 50 packets but if the 51st packet arrives 49 millisecond later, that packet will be dropped. This is because the Fill Rate applies credit every 50 millisecond so a packet arriving before that will get dropped. The Bucket Size allows room for sudden bursts of traffic, whereas the Fill Rate indicates the expected steady state flow of the traffic.  For more information on Token Buckets and Fill Rates, please consult Token Bucket Policers.

Once recognized, a DoS attacks trigger alarms. Packet discard rate thresholds and duration are defined for recognizing the end of an attack which also triggers an alarm.

The policers monitor all packets.  Packet discard rates are measured against the threshold rate and duration levels configured in the Discard Rate Profile. An alarm is triggered when a a threshold discard rate (or higher) is maintained for a prescribed duration. That alarm is cleared when a lesser threshold is met and that discard rate (or lower) is maintained for a prescribed duration. These alarms are configured on a system-wide basis.

On SBC platforms, network interfaces may be configured with IP policers. Media policing is enabled/disabled on a system-wide basis and operates on a per-media flow basis. The policer configuration, status, and statistics are accessible through EMA or CLI. 

The

Spacevars
0 series4

supports hardware-based policing to ensure excessive network traffic (due to heavy load or an attack) does not disrupt the system, the internal network, or customers. These hardware-based policers filter packets at wire-rate which means the policers keep up with all the packets arriving on an interface to prevent an attack from overwhelming the protective measures using a significantly high attack rate. Each packet is evaluated and either forwarded or rejected.

Once a received packet is validated by the hardware, it is placed into either a media or non-media stream. SBC decides if a packet is a media packet, signaling packet, or a management packet.

Dynamic Blacklisting

Dynamic blacklisting is a feature that detects abnormal events from end points, and blocks traffic from those end points for a configured period of time. Dynamic blacklisting is designed to detect misbehaving end points rather than prevent malicious attacks, for which the system already has other mechanisms.

Dynamic Blacklist (DBL) events and the actions to take for each event are configurable using a set of DBL rules in a DBL profile. The DBL profile is then assigned to a SIP trunk group. Any packets entering the system from that trunk group is then compared against the rules configured in that DBL profile.

Policing Steps Summary

 A summary of the high level

Spacevars
0 series4

steps to filter and police policy for media, signaling, and control traffic packets is described below.

1. Initially, wire-rate policers are applied as soon as the SBC receives a packet at NIF (see Figure 1 for the flow).
   
   

   Note
   The term "wire-rate policer" represents the steps performed before registered/registering peer policing/aggregate policing.

   Caption
   0 Figure 1 SBC Packet Policing Flow

2. After wire-rate policers have completed, the packet is sent to one of the following application policers (system automatically distributes packet based on the registration status):
   1. Registered Peer Policing—Packet comes from registered peer. The policer parameter is taken from Registered Endpoint CAC Profile associated to SIP Trunk Group.
   2. Registering Peer Policing—Packet comes from peer now registering. The micro-flow policer policy is applied. The parameters associated with this are not configurable.
   3. Unknown Peer Policing—Packet comes from non-registered peer, and goes to operator configured ACL flow policer, and then to system configured ACL low policer
      
      
3. After individual policing completes, all SIP and H323 packets go to an aggregate policer which is applied on a per-zone basis. Within this policer, the packet is prioritized (from highest to lowest) as follows.
   1. Registered access peers
   2. "Whitelisted" – matches an operator-configured ACL rule
   3. Registering access peers
   4. "Dark gray" – matches a defaulted signaling port ACL rule

Note
Non-signaling packets are put into specific aggregate policers based on protocol type (management, overhead, ICMP, IKE, ARP, media).

 

Note
Media is policed at the rate implied by the codec selected during call setup. For the other protocols, a system-installed ACL is used.

Policing for Multiple Signaling Ports on Same IP Address

When an operator configures multiple SIP signaling ports on the same IP address in the same address context,

Spacevars
0 series4

creates multiple default system Access Control Lists (ACLs) for SIP signaling traffic including one for each SIP signaling port. Because the SIP signaling ports in this scenario use the same IP address and default system ACLs match only on Address Context, IP Interface Group, and destination IP Address, the default system ACLs use the same packet matching criteria. All SIP signaling packets destined to these SIP signaling ports match the first default system ACL created for these SIP signaling ports.

Note
The default system ACL for SIP signaling ports uses a wild-carded protocol, source IP, source port number, destination port number.

If you need to police packets sent to individual SIP signaling ports, configure 'user' IP ACLs for each SIP signaling port. In an IP ACL for access deployment, specify not only destination address (SIP signaling address), but also protocol (UDP/TCP) and destination port number (SIP signaling port's UDP/TCP port number). In a case where SIP port is used for a peering deployment, the peer's IP address (source IP) and port number (source port) are frequently known and can additionally be specified in the IP ACL.

The table below depicts IP ACLs and the default system ACL for two SIP signaling ports configured with the same IP address (10.10.10.20) with port numbers 5060 and 5070 for peering scenario where port number 5060 supports both SIP-UDP and SIP-TCP and port number 5070 supports SIP-UDP only. The two peers' addresses/ports are 20.20.20.20:5080 (Peer A) and 30.30.30.30:5090 (Peer B), respectively.

Configuration of the IP ACLs is accomplished using lower precedence values ("higher priority") for the IP ACLs and fully specified for the protocol, source-IP, and source-Port.

• UDP packets coming from the peer 20.20.20.20:5080/UDP to UDP port 5060 match "Peering UDP A' rule.
• TCP packets from the peer 20.20.20.20:*/TCP to TCP port 5060 match "Peering TCP Ingress A" rule, which is for peer-initiated inbound TCP connection to SBC's SIP signaling port.
• TCP packets from the peer 20.20.20.20:5080/TCP match "Peering TCP Egress A" rule, which is for outbound-initiated TCP connection with ephemeral port numbers on SBC.
• UDP packets coming from the peer 30.30.30.30:5090/UDP to UDP port 5070 will match "Peering UDP B" rule.

 

Caption
0 Table 1 Example of two SIP signaling ports configured with the same IP address
Scenario / Rule Source Source   Protocol Destination Destination Users ACL Precedence Remote IP Remote Port Local IP Local Port Peering UDP A 20.20.20.20 5080 UDP 10.10.10.20 5060 101 Peering TCP Ingress A 20.20.20.20 * TCP 10.10.10.20 5060 102 Peering TCP Egress A 20.20.20.20 5080 TCP 10.10.10.20 * 103               Peering UDP B 30.30.30.30 5090 UDP 10.10.10.20 5070 111               Default System ACL A * * * 10.10.10.20 * N/A               Default System ACL B * * * 10.10.10.20 * N/A