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
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
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<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
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. 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. On Wed, 2011-02-23 at 15:59 -0800, Ujjval Karihaloo 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
I believe you can configure the ACMEs to limit the qty of registrations send to a downstream registrar, which limits the impacts of most re-registration floods. It is also possible to have a 'cache-after-expires' extension to attempt to 'smooth' user-agents that skip a register or two. On 24/02/2011, at 10:29 AM, Ujjval Karihaloo 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<mailto: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<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
An HTML attachment was scrubbed... URL: <https://puck.nether.net/pipermail/voiceops/attachments/20110223/4df596d1/att...>
The Sansay SPX does a great job. Sent from my iPhone. On Feb 23, 2011, at 6:59 PM, 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
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
participants (6)
-
anorexicpoodle＠gmail.com -
cpena＠ststelecom.com -
PChilds＠internode.com.au -
ujjval＠simplesignal.com -
victor.pascual.avila＠gmail.com -
zavoid＠gmail.com