[Serusers] rtpproxy address filling

[Andres]

Stefan Sayer wrote:

>
>
> Andres wrote:
>
>>>>
>>>> It immediately jumped into my mind that this could be a security 
>>>> vulnerability since a remote attacker could effectively bring down 
>>>> all sessions on an rtpproxy just by doing a UDP scan.
>>>
>>> ...wouldn't they switch back to the correct addresses when the next 
>>> RTP packet arrives, i.e. after 10/20/30 ms?
>>>
>> No it does not.  I tried it.  RTPProxy only switches addresses once.  
>> Although it is trivial to edit the source code and allow rtpproxy to 
>> always listen and adjust to IP Address changes during the entire call.
>
> so would the more secure fix maybe be to always allow a switch back to 
> the original address?
>  o streams with rtp from the original address would switch back the 
> connection address

yes, I like it this way.   RTPPRoxy is always ready to change the IP 
Address of the stream.

>  o streams with rtp from different address would be vulnerable only 
> for the very short period of call setup, before the first packet 
> arrived (which makes the switch to the correct address)

As it stands today, it is vulnerable for the entire duration of the 
call.  If for example 5 minutes into the call, you get a packet from a 
different IP Address, it switches the destination.  (and stops listening 
for changes)

It turns out that we started investigating the issue due to loads of 
trouble at an ISP using D-Link ADSL modems.  These modems are set to 
PPPoE and perform NAT.  The problem is that its NAT is buggy.  After 
call setup, every now and then it lets out a packet with the internal 
private IP Address of the SIP ATA as source, and naturally when the 
RTPProxy receives the packet it switches the media stream and it never 
switches it back when packets continue to flow in with the correct IP.

After the call was established, audio would fail as soon as this 
rtpproxy message appeared:
caller's address filled in: 10.1.1.2:20014 (RTP)

The Ethereal trace revealed we received a packet from the private IP 
Address instead of the public one.

Andres
http://www.neuroredes.com

>
> Stefan
>
>>
>> Andres
>> http://www.neuroredes.com
>>
>>> Stefan
>>>
>>>
>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
>