1 Apr
2008
1 Apr
'08
4:30 p.m.
Stefan Sayer wrote:
Andres wrote:
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.
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?
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers