[asterisk-dev] SIP Timers and "100 Trying" on a Re-INVITE. Resource leak.

[Kevin P. Fleming]

On 06/13/2012 07:41 AM, Steve Davies wrote:
> Hi,
>
>  From my Google searches, this is a much asked but little answered
> question that the SIP RFCs do not appear to handle. I've been using
> the Asterisk 1.8.11.0 code to determine how Asterisk behaves, so
> apologies if version 10 already answers this.
>
> In a "normal" INVITE, we have a global timeout that is specified by
> the Dial command's ring duration, such that it all else fails,
> app_dial or equivalent will stop the channel from existing beyond its
> natural lifespan. With a Re-INVITE, this is not the case, and I have a
> scenario where Asterisk leaks RTP ports:
>
> - Inbound call (any channel tech) to SIP endpoint A.
> - Original call on-hold by SIP A
> - SIP A calls SIP B, and direct-media call is set up.
> - SIP A 'REFER's the call to bridge the inbound call to SIP B.
> - As part of this, it Re-INVITEs the SIP A and SIP B audio back to Asterisk

By 'it' I believe you mean Asterisk, right?

> - SIP A has a bug that means it responds "100 Trying" to the
> Re-INVITE, but then nothing more.

Ugly.

> I completely appreciate that this is not Asterisk's problem, BUT it
> leaves a potential DoS where the original SIP A RTP ports are leaked,
> and over a period of time can prevent Asterisk and/or the host from
> working.
>
> My Thoughts:
>
> If we know we are a Re-INVITE, set a new destroy timer on the pvt
> after a 1xx or 18x response. I assume that we can identify a Re-INVITE
> as an invite that it in progress on a channel that is in state
> AST_STATE_UP ?

I'm not sure what you mean by 'we are a Re-INVITE' but that could just 
be a lack of common language, since you don't speak the same English I 
do :-)

You have found a legitimate issue; because the other UA (SIP A) sent a 
response within the interval allowed by Timer B, Asterisk will stop 
re-transmitting the INVITE request. More importantly, there is *no* 
RFC-specified timer that will later cause the INVITE transaction to 
enter the 'Terminated' state if SIP A never sends a final response.

This a somewhat convoluted, but legitimate, attack vector. If you setup 
a call with Asterisk and somehow convince *it* to send you a re-INVITE, 
then respond with 100 Trying and disappear, that dialog will never be 
terminated (except possibly via Session-Timer or RTP timeouts, but the 
fact that it is in a 'pending re-INVITE' states causes me to believe 
that even those won't get triggered).

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org