Acme Packet 6300
 

PLA-Support>Sun Systems>CommsGBU>Session Delivery Network>SN-SND: Acme Service Provider
 

In this Document

Goal

Solution

References

Created from <SR 3-11769702261>

Applies to:

Goal

The environment consist of HA pair comprises of the Acme_6300 running SBC Version Acme Packet Net-Net 6300 SCZ7.2.x. In this example, the SBC is using sip-interface associated with the 'SIPConnect' realm. Upon any SIP messages that arrives to SBC using sip-interface associated with the 'SIPConnect' realm, SBC will forward the requests to the redirect servers based on the local policy routing. During the DoS attack, a spike in traffic from the unsolicited source to the 'SIPConnect' realm occurs. This caused:

1. The registration attempts from the IP Address of the unsolicted source were forwarded by SBC to the call servers based on response from re-direct servers. Such attempts were rejected with 403
2. Customers associated to the SIPConnect realms were primarily affected
3. Access SBC dropped the inbound SIP messages (requests and responses) from customers connected to the system which resulted in registrations and calls to fail
4. The session-agents corresponding to the re-direct servers were taken out-of-service quiet frequently (state transitioned from I to O to S to O)

Example of SBC settings:

sipd.log file has entries such as:

indicating the IP address from unsolicited source was going to untrusted but not to deny list

Why did the SBC drop the SIP messages from the trusted entities and how can this be countered ?

Solution

The trusted drops would have been caused by exceeding the trusted bandwidth limitations set in the customer configuration.

Each REGISTER request from the faulty endpoint generated two "trusted" responses (ie on the CoreTrusted_SIPConnect realm) - a 3xx redirect and a 403 forbidden - so you have a certain amount of amplification for each message that was received from this endpoint. If we assume that this endpoint was the only one generating untrusted traffic, this means it could generate REGISTER messages at up to 15% of the max signalling bandwidth (see media-manager/max-untrusted-signaling setting) - ie this would increase the amount of trusted traffic significantly.

In addition, if SROP is used, the REGISTER request for the misbehaving endpoint was challenged before being reject. This would mean that the endpoint would be temporarily promoted to trusted increasing the amount of trusted signalling being received by the SBC.

Changing the trust level to low is a sensible precaution as it would demote the misbehaving endpoint to the denied list blocking all traffic from it.
In addition, we would suggest that the max-untrusted-signaling and min-untrusted-signaling media-manager settings are checked. These are percentage values meaning that when they increased the max-signaling-bandwidth setting they also increase the amount of untrusted traffic that the SBC will accept. These settings should be re-asses in accordance to the new bandwidth setting.

Other example of recommendations:

References

This solution has no attachment