<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.30.3">
</HEAD>
<BODY LINK="#0000ff">
This is my precise point. Improper use of HNT can manufacture registration floods where none would have existed if your timers aren't in tune with what your traffic looks like. <BR>
<BR>
There are preventative measures that can be taken to hold back reg-floods using a combination of acme deny list policies, acme sip-config options and softswitch reg throttling but the precise formula is really Dependant on you. <BR>
<BR>
On Wed, 2011-02-23 at 15:59 -0800, Ujjval Karihaloo wrote:
<BLOCKQUOTE TYPE=CITE>
    ACME DDOS BCP clearly says it has not been tested for REGISTRATION floods. Any SBC out there that can withstand a REG flood?<BR>
    <BR>
     <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    UK<BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
     <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
    <B>From:</B> anorexicpoodle [mailto:anorexicpoodle@gmail.com] <BR>
    <B>Sent:</B> Wednesday, February 23, 2011 4:40 PM<BR>
    <B>To:</B> Ujjval Karihaloo<BR>
    <B>Cc:</B> voiceops@voiceops.org<BR>
    <B>Subject:</B> Re: [VoiceOps] ACMEs SIP Dynamic HNT<BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
     <BR>
    <BR>
    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. <BR>
    <BR>
    Some gotchas: <BR>
    <BR>
    1: If you aren't careful about tuning your timers you can quickly overwhelm the CPU of the SBC with a large subscriber base. <BR>
    <BR>
    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. <BR>
    <BR>
    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<BR>
    <BR>
    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. <BR>
    <BR>
    <BR>
    -anorexicpoodle<BR>
    <BR>
    <BR>
    <BR>
    On Wed, 2011-02-23 at 15:12 -0800, Ujjval Karihaloo wrote: <BR>
    <BR>
    Hi Guys:<BR>
    <BR>
     <BR>
    <BR>
       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.<BR>
    <BR>
     <BR>
    <BR>
    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).<BR>
    <BR>
     <BR>
    <BR>
    Thx for your input<BR>
    <BR>
     <BR>
    <BR>
    UK<BR>
    <BR>
     <BR>
    <BR>
    <BR>
    <BR>
    <BLOCKQUOTE>
<PRE>
 
_______________________________________________
VoiceOps mailing list
<A HREF="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</A>
<A HREF="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</A>
</PRE>
    </BLOCKQUOTE>
    <BR>
     <BR>
    <BR>
    <BR>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>