Summary:	ASTERISK-08700: Asterisk accepts RTP from random endpoints
Reporter:	Benny Amorsen (amorsen)	Labels:
Date Opened:	2007-01-31 08:38:25.000-0600	Date Closed:	2008-01-24 11:47:41.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Sometimes the audio from an unrelated call would enter the RTP stream, accompanied by a stream of:  == Forcing Marker bit, because SSRC has changed I finally had the chance to tcpdump when it happened. The basic setup is a central asterisk connected by SIP to two branch asterisks. A call from the central to branch2 has failed on the central asterisk but somehow stayed open on branch2, so branch2 kept sending audio which central naturally ignored. The audio is sent as RTP, and the RTP port on central happens to be 18796. Later another call comes along from central to branch1, and the RTP port chosen for this call on central happens to be 18796. branch1 starts sending RTP to that port, and asterisk happily accepts BOTH RTP streams. Obviously asterisk should reject the RTP stream from branch2. Failure to do so is a security breach. I have not tried to replicate this issue, it has happened several times but until now I have not had the chance to debug it. Replicating it properly would involve generating an RTP stream.
Comments:	By: Olle Johansson (oej) 2007-01-31 16:32:32.000-0600 I agree that this is a potential problem. There are two issues here: - Asterisk accepts RTP streams with unknown SSRC identifiers. Bad. - Asterisk accepts RTP streams from unknown IP addresses The latter is a feature we do rely on for musiconhold in the situation where we have a remote RTP bridge. So to fix the first one, we need to fix it so Asterisk sends re-invites for music on hold, which we have started working on. Secondary, we need to implement SSRC filters and potentially IP too. These need to be optional, since there seems to be devices and systems that depend on being able to do that. By: Joshua C. Colp (jcolp) 2007-02-13 19:39:55.000-0600 The first part (sending re-invites for music on hold) has been completed and is in 1.4/trunk. We can swiftly move on to the second part now. By: Olle Johansson (oej) 2007-05-15 15:18:21 file, let's put this on our agenda for next week. By: jmls (jmls) 2007-09-12 16:33:04 was this put on the agenda ? If so, what's the course of action ? By: Joshua C. Colp (jcolp) 2008-01-21 10:58:44.000-0600 There is now a branch, http://svn.digium.com/svn/asterisk/team/file/strictrtp, which will drop packets not coming from the source. Please give it a go. By: Digium Subversion (svnbot) 2008-01-24 11:47:31.000-0600 Repository: asterisk Revision: 100206 U   trunk/CHANGES U   trunk/configs/rtp.conf.sample U   trunk/main/rtp.c ------------------------------------------------------------------------ r100206 | file | 2008-01-24 11:47:29 -0600 (Thu, 24 Jan 2008) | 4 lines Merge in strictrtp branch. This adds a strictrtp option to rtp.conf which drops packets that do not come from the remote party. (closes issue ASTERISK-8700) Reported by: amorsen ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=100206