[VoiceOps] ACMEs SIP Dynamic HNT

[Victor Pascual Avila]

Please check Acme Packet's "Basic DDoS Configuration for SIP Access
Environments" (Jan 2011) and "SIP Access Configuration" (Apr 2011) BCPs.
They describe the SIP Registration Overload Protection (SROP) mechanism.

Cheers,
-Victor

On Thu, Feb 24, 2011 at 12:59 AM, Ujjval Karihaloo
<ujjval at simplesignal.com>wrote:

>  ACME DDOS BCP clearly says it has not been tested for REGISTRATION
> floods. Any SBC out there that can withstand a REG flood?
>
>
>
> UK
>
>
>
> *From:* anorexicpoodle [mailto:anorexicpoodle at gmail.com]
> *Sent:* Wednesday, February 23, 2011 4:40 PM
> *To:* Ujjval Karihaloo
> *Cc:* voiceops at voiceops.org
> *Subject:* Re: [VoiceOps] ACMEs SIP Dynamic HNT
>
>
>
> I use AHNT extensively and it works extremely well. It is critical to note
> that if the device doesnt respect the expires= parameter than almost no nat
> traversal on the SBC will work.
>
> Some gotchas:
>
> 1: If you aren't careful about tuning your timers you can quickly overwhelm
> the CPU of the SBC with a large subscriber base.
>
> 2: Understand your endpoint and network behavioral patterns. Because HNT(or
> AHNT) on any level creates a disparity between the public UA and the UA in
> the softswitch it is possible to inadvertently create registration storms
> with poor timer and cache settings. This will cripple and SBC faster than
> you could think. The more common scenario I have seen is endpoints are on a
> 45 second registration timer, and an equally short grace period. You
> experience some kind of BGP issue with a peer causing all your HNT endpoints
> via that BGP session to go dead for 180 seconds (bgp failure timer). This
> means their public UA is removed from the SD but their softswitch
> registration remains (if you aren't using authentication you could use
> forced unregistration but thats a whole different can of worms). When that
> BGP session is re-established those devices will come at you in a flood.
> Each of those registers MUST be challenged by the softswitch. If this flood
> is large enough it can edge out other traffic creating more retransmissions
> etc and overall getting quite ugly. There are protections in the SD for this
> but they are reactionary and don't apply well to this sort of traffic.
>
> 3: Watch your SD CPU usage like a hawk. On the access side this will be the
> single limiting factor for how far you can strech a pair of SD's
>
> 4: Early registration makes AHNT much less effective. IF you have devices
> that regularly send early registrations this will dramatically hinder the
> AHNT nat discovery algorithms ability to detect the right timer. Many
> devices attempting to be clever will re-register at 50% of the expires=
> value. This really hurts AHNT.
>
>
> -anorexicpoodle
>
>
>
> On Wed, 2011-02-23 at 15:12 -0800, Ujjval Karihaloo wrote:
>
> Hi Guys:
>
>
>
>    We have not used the ACMEs SIP Dynamic HNT feature, where the ACME sends
> OPTIONS msgs to individual endpoints on its Access side and adjusts their
> expires times as per individual Firewalls that they are behind.
>
>
>
> While it sounds cool, I was wondering if folks have noticed issues with
> using it given that some endpoints out there don’t even honor the Expires
> header from REGISTRARs and as the ACME determines the correct NAT interval
> automatically, it may leave some endpoints de-registers for small intervals
> (as per ACME ACLI guide).
>
>
>
> Thx for your input
>
>
>
> UK
>
>
>
>
>
> _______________________________________________
>
> VoiceOps mailing list
>
> VoiceOps at voiceops.org
>
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>


-- 
Victor Pascual Ávila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110426/f1783267/attachment.html>