[asterisk-dev] the strictrtp feature is almost useless

[Kevin P. Fleming]

On 10/13/2010 09:20 AM, Kristijan Vrban wrote:
> Hello, following problem: Asterisk use RTP Port e.g from 14000-15000
> and all phones have nat=yes. Now there is a call to a phone,
> and asterisk use Port e.g. 14555, and the phone send it's rtp audio to
> 14555. Ok but the phone is buggy, and after hangup, the phone still
> send rtp
> to 14555 (and yes, in real live there are buggy phones that do this).
> No problem the port is closed, and the rtp to this port get dropped.
> 
> But after a while there is a new call and asterisk reuse the port
> 14555 *BOOM* asterisk use the the rtp stream from the buggy phone, and
> dropp the proper
> stream with "strictrtp=yes" because the wrong rtp comes first and if
> "strictrtp=no", it mix the wrong and right rtp stream.
> 
> has anyone ever thought about it? this issue can also be used by an
> attacker. the attacker just need to send an RTP flooding to the RTP
> range asterisk use,
> to block the whole pbx. I have tried this. It's a simple and working attack.
> 
> In 2007 the problem was described in #8952 and the the ticket was
> closed with the strictrtp feature. But the strictrtp does only do the
> half job.
> The issue i described is not handled.
> 
> The question the the dev list, can this issue fix at all? Because to
> fix it, there is need any unique identifier in the rtp
> packet itself. to match if this is the right or wrong rtp packet.

This is not an Asterisk problem, it's a problem with RTP itself, when
coupled with NAT devices and the desire for 'comedia' mode where the
receiver (not behind a NAT) discovers the address of the sender (behind
a NAT).

To my knowledge there isn't any piece of information included in the SDP
during session establishment that would be usable to identify incoming
RTP packets as belonging to the 'correct' sender or not. Of course, SRTP
would solve this, as the packets from the incorrect sender will fail to
decrypt and will be dropped... but that's a fairly heavyweight solution.

Any server that accepts RTP and cannot know conclusively what the source
IP/port of that stream are going to be (because the source might be
behind a NAT and the address/port can't be predicted) is subject to this
problem.

There is a solution out there though: ICE. ICE uses two-way connectivity
checks (with digital signatures) to determine the ports that will be
used for transferring media over RTP (or other protocols). This method
can't be spoofed, because of its two-way nature and the use of
pre-shared identifiers in the signaling used to do the connectivity
checks. However... using ICE to solve this problem will require that all
endpoints that are connecting to each other support ICE fully, and there
aren't many that do yet.

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