In this section:
The
Unable to show "metadata-from": No such page "_space_variables"
applies filtering and policing policy on different types of signaling/management packets as listed below:- packets from all unknown peers in a zone
- packets from registered peers
- packets from registering peers
- packets from whitelisted peers
Each of the above mentioned signaling/management packets are screened by the following subsystems before being forwarded to the appropriate application for further action.
When the wire-rate policers complete, the packets (media or non media) may get processed by application-level policers (or “software” policers) including the SIP trunk group policers described in Call Admission Controls. SIP trunk group policers limit call and registration rates but depend on sufficient
Unable to show "metadata-from": No such page "_space_variables"
hardware and software resources to maintain processing integrity. Wire-rate policers simply drop rejected packets, whereas application-level policers attempt to throttle the source using SIP failure response messages.To view or reset offenders list from EMA, see Policers - IP Policing Offenders, System - Ip Policing; or from CLI, see IP Policing - CLI.
The Network Processor logs discarded packets and keeps a summary of ten categories of “offenders lists”. The top 10 offenders in each category display in IP Policing “offenders list” statistics. For the
rogueMediaOffendersList and mediaOffenderListstatistics, a new entry is created when the destination IP address or destination UDP port is different than the existing entries. Some offenders lists include the column “Source Unique.” If the “Source Unique” field is “notUnique”, the packets from multiple source IP addresses or source UDP ports were discarded. If the source unique field is “unique,” the packets from a single source IP address/UDP port were discarded.For all other “offenders list” categories, a new entry is created when the source IP address is different than the existing entries.
Registered Peer Policing
Packets from a registered peer are policed by the Registered Peer Policers. Registered peer packet policing is applied peer by peer. However, the policing parameters are defined and applied on a per trunk group level. Registered Peer Policing applies to packets received from peers that are authorized by successfully registering with a SIP Registrar through the
Unable to show "metadata-from": No such page "_space_variables"
. This is comparable to the policing described previously except that the Registered Peer policers are instantiated automatically based on registration, rather than based on manual per-peer configuration. These policers are intended for use in access deployments where registration is used, and monitor:- “good” traffic from legitimately registered SIP endpoints,
- “attack” traffic from attackers that have successfully registered, or are spoofing the source of legitimately registered SIP endpoints.
For each registered end point, the system associates a flow policer. The flow policer applies to that registered end point. The flow policer parameters are based on the endpoint CAC profile associated with the SIP trunk group. If there is no associated endpoint CAC profile, then a fixed rate is used.
Registered Peer Policers use the “single token bucket” model. These policers are limited to one Bucket Size and one Fill Rate used for every Registered Peer Policer instance throughout the system.
Registering Peer Policing
When a SIP Register request is challenged by the application server, an interim micro-flow policer is created with fill rate of 0 packets per second and bucket size of 10 packets. As a result, the policer limits the number of packets from the end point to at most 10 packets. The policer remains in effect for a random interval with a range of 5-9 seconds.
Unknown Peer Policing
The
Unable to show "metadata-from": No such page "_space_variables"
installs an unknown peer policer for each SIP signaling port. This allows some traffic from SIP peers. When end point successfully registers with the Unable to show "metadata-from": No such page "_space_variables"
, a flow policer is installed to monitor the incoming signaling traffic from that end point. For non-registering peers, it is recommended to add an ACL entry.The
Unable to show "metadata-from": No such page "_space_variables"
also installs an unknown peer policer for each H.323 signaling port. This allows some H.323 traffic from unknown peers. However, it is recommended to add an ACL entry for every known H.323 peer.Aggregate Policing
Aggregate Policers are implemented at the hardware level to protect against Denial of Service (DoS) attacks. All arriving IP non-media packets that have passed the ACL or registered peer policers, are aggregated and policed using the Aggregate Policer.
Non-signaling non-media packets are collectively policed depending on the type of packet (ARP, ICMP, IKE etc). These policers are not configurable by the operator.
The following diagram details how aggregate policing is applied to incoming signaling packets in SBC.
Zone Aggregate Policing
The
Unable to show "metadata-from": No such page "_space_variables"
aggregates SIP and H.323 signaling packets for per-zone aggregate policing. Different variations of the zone aggregate policing (based on source) for signaling packets are given below:- SIP access peer policing per zone: Aggregate policing of registered or registering peers.
- SIP access Initial Register messages are policed per ACL rule and per Zone
- H.323 access peers are policed per ACL rule and per Zone
Media Policing
The
Unable to show "metadata-from": No such page "_space_variables"
applies filtering and policing policy to each media packet received on the network interface. Each media packet must be accepted by the media policers before proceeding to additional operations.Most media validating and policing are either not user configurable or generally do not require changing from the default setting. Individual Token Bucket policers for properly established calls are automatically configured based on the associated codec. Media packet validation (rogue media detection) associated with an unallocated port or bad destination address is always on and is not
user-configurable.
The only media packet validation provisioning to normally perform is to enable media source address filtering. This function is disabled by default (for SIP) but can be enabled by setting the Source Address Filtering state (SAF) parameter in the SIP trunk group object to “enabled”.
It is important to note that Source Address Filtering generally does not work in an environment where Network Address Translation (NAT) is used because SAF assumes that the
Unable to show "metadata-from": No such page "_space_variables"
sends RTP packets to a known IP address and only accepts received packets from that address, whereas with NAT the Unable to show "metadata-from": No such page "_space_variables"
depends on the IP address of an incoming packet to determine where to address the return RTP stream.Media policing is based solely on RTP packet length (MAC, IP, and UDP headers are ignored).
Rogue Media Detection
A "Rogue RTP Stream" is comprised of media packets not associated with any active call. These may be inadvertent, such as late arrival of packets associated with a recently terminated call, or malicious, such as a generalized Denial of Service attack, or an attempt to corrupt the media stream of a legitimate call.
The
Unable to show "metadata-from": No such page "_space_variables"
detects and mitigates the impact of Rogue RTP Streams. In particular, RTP Relay can be configured to perform the functions of a pinhole firewall, silently discarding all media packets not part of a properly originated call. It passes only those packets for which the {source address&port; destination address&port} tuple fully matches that signaled in a successful call attempt.The
Unable to show "metadata-from": No such page "_space_variables"
also rate-limits the amount of media traffic allowed to flow into the Unable to show "metadata-from": No such page "_space_variables"
on a per-call basis. The rate limit is set based on the bit rate of the negotiated codec as determined by call setup procedures. The media rate limit protects internal resources of the SBC and other trusted network resources from untrusted peers.
Overview
Content Tools