[asterisk-bugs] [Asterisk 0018121]: Early bind of UDPTL ports can create a DoS condition

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18121 
====================================================================== 
Reported By:                ebroad
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18121
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-10-12 10:11 CDT
Last Modified:              2010-10-12 13:36 CDT
====================================================================== 
Summary:                    Early bind of UDPTL ports can create a DoS condition
Description: 
The issue is that we bind udptl ports early on in the game, in sip_alloc(),
which can exhaust the port limit in udptl.conf quite quickly, when a flood
of invites from a (rogue) scanner with a udptl sdp payload is processed by
Asterisk. Even though the invite is ultimately challenged and/or rejected,
the port is bound, and is not released until the 32 second retry before
destroy window is up, and once all the ports are bound, service will be
denied to legitimate calls; bear in mind we don't do this with voice, video
and text ports.
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-10-12 13:36 lmadsen        Additional Information Updated                  
 
======================================================================