29 Mar
2008
29 Mar
'08
6:03 p.m.
Hi,
I have a question regarding the way rtpproxy handles 'address filling'.
After a session has been created, the rtpproxy pre-fills the caller and
callee's addresses and we see that in the rtpproxy output like:
pre-filling caller's address with 192.116.246.234:41000
pre-filling callee's address with 192.116.246.234:20000
Then when it sees the actual packets coming in from a different source
port, it updates the address and we see it in the log like:
callee's address filled in: 192.116.246.234:1024 (RTP)
The audio then flows fine both ways.
My question is, what would happen it the actual packets came in from a
different IP while the rtpproxy was waiting between the state of
'pre-filling' and 'address filled' states? Will the rtpproxy accept
such a change that includes a new IP? Will it ignore packets from a
different IP and continue the session normally? Or will it abort the
session completely?
Thanks,
Andres
http://www.telesip.net
30 Mar
30 Mar
12:41 a.m.
To answer my own question, I just set up a lab test to verify this.
After the session is up and the address has been 'pre-filled', if
rtpproxy receives a packet on the same UDP port as one of the call legs
but from a different IP, it changes the address to which it forwards 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.
I wanted to see if this was possible so I setup a new test with 32
concurrent calls on an rtpproxy server. The calls were setup and all
streams were being forwarded correctly. I then used 'nmap' to scan all
UDP ports used by rtpproxy. Initially nothing happened, but then I
tried it again with a regular data_length and it effectively destroyed
all sessions by pointing them to the nmap PC.
The rtpproxy console confirms the address change with 32 messages like
these:
callee's address filled in: 192.168.2.6:40318 (RTP) {this is the nmap PC}
caller's address filled in: 192.168.2.6:40318 (RTP) {this is the nmap PC}
What do you think? Is this too far fecthed to worry about?
Maxim, can you provide a fix that ignores IP Address changes and just
acts on Port changes or does something critical break here? I can't
think of a reason other than a bouncing DSL line that would require the
rtpproxy server to worry about an IP Address change or a complicated
NAT/Routing setup with multiple public IP Addresses.
Thanks,
Andres
Andres wrote:
Hi,
I have a question regarding the way rtpproxy handles 'address filling'.
After a session has been created, the rtpproxy pre-fills the caller and
callee's addresses and we see that in the rtpproxy output like:
pre-filling caller's address with 192.116.246.234:41000
pre-filling callee's address with 192.116.246.234:20000
Then when it sees the actual packets coming in from a different source
port, it updates the address and we see it in the log like:
callee's address filled in: 192.116.246.234:1024 (RTP)
The audio then flows fine both ways.
My question is, what would happen it the actual packets came in from a
different IP while the rtpproxy was waiting between the state of
'pre-filling' and 'address filled' states? Will the rtpproxy accept
such a change that includes a new IP? Will it ignore packets from a
different IP and continue the session normally? Or will it abort the
session completely?
Thanks,
Andres
http://www.telesip.net
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
9:21 a.m.
Andres wrote:
I can't
think of a reason other than a bouncing DSL line that would require the
rtpproxy server to worry about an IP Address change or a complicated
NAT/Routing setup with multiple public IP Addresses.
If you fork a call to multiple destinations and more than one starts
doing early media or alternatively, if you have early media from one
destination and final media from another, there will be a change in the
source address of media. You will end up with no media on the actual
call, if you don't accept the new addresses.
Regards,
Martin
1 Apr
1 Apr
9:08 p.m.
Hello,
I think this is an interesting question, but
Andres wrote:
To answer my own question, I just set up a lab test to
verify this.
After the session is up and the address has been 'pre-filled', if
rtpproxy receives a packet on the same UDP port as one of the call legs
but from a different IP, it changes the address to which it forwards 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?
Stefan
--
Stefan Sayer
VoIP Services
stefan.sayer(a)iptego.com
www.iptego.com
iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
9:47 p.m.
Stefan Sayer wrote:
Hello,
I think this is an interesting question, but
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.
Andres
http://www.neuroredes.com
To answer my own question, I just set up a lab
test to verify this.
After the session is up and the address has been 'pre-filled', if
rtpproxy receives a packet on the same UDP port as one of the call
legs but from a different IP, it changes the address to which it
forwards 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?
Stefan
10:06 p.m.
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
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)
Stefan
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?
Andres
http://www.neuroredes.com
--
Stefan Sayer
VoIP Services
stefan.sayer(a)iptego.com
www.iptego.com
iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
Stefan
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10: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
10:53 p.m.
Andres wrote:
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.
>
sorry, I was not precise:
> so would the more secure fix maybe be to always
allow a switch back to
> the original address?
... to the original address only?
so that a switch to an address away from the original address would be
possible exactly once, but switching back to original address always.
this would also work with your D-Link modems.
Stefan
--
Stefan Sayer
VoIP Services
stefan.sayer(a)iptego.com
www.iptego.com
iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany
Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann
11:33 p.m.
Stefan Sayer wrote:
Andres wrote:
... to the original address only?
so that a switch to an address away from the original address would be
possible exactly once, but switching back to original address always.
Sure, that sounds good and more secure too. Maybe Maxim can chime in
with his thoughts.
Andres
http://www.neuroredes.com
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.
>
>
sorry, I was not precise:
so would
the more secure fix maybe be to always allow a switch back
to the original address?
this would also work with your D-Link modems.
Stefan
2 Apr
2 Apr
5:37 a.m.
Stefan Sayer wrote:
But there is still forking. The way things work now is this: I detect
the caller and at least one of the recipients of the INVITE to be NATed
and activate RTP proxy. What happens is that RTP proxy returns an
address and a port which nathelper puts into SDP for all branches.
Now consider the case where three devices are registered. They all start
ringing. Two of them decide to not just say "180 Ringing" but to create
early media. Which one does RTP proxy allow media from? In the current
implementation, the UA that sends its media second wins. In the
suggested implementation, the UA that sends its media first wins long
term.
But: The third phone, which so far didn't do any media at all, is picked
up. The two other branches are CANCELed, the early dialog is terminated,
and the media streams end. The third phone wants to set up a media
stream for the actual real call -- and is ignored by RTP proxy because
it is considered an evil imposter.
Normally, you will not have this problem, because most UAs don't do
early media. But the moment you do something fancy, like forking the
call off to a PSTN number (eg., the user's cell phone) or playing a
custom ringback tone, you are skrewed.
The only solution I can think of is to make RTP proxy branch aware. You
could assign a separate port for each branch, but that is quite
wasteful and will most likely exaust the ports rather quickly.
I can't think of a way to correlate branches and media streams without
knowing IP address and port, though. Anyone have a clever idea?
Maybe TURN isn't such a bad idea after all.
> so would the more secure fix maybe be to
always allow a switch back to
> the original address?
... to the original address only?
so that a switch to an address away from the original address would be
possible exactly once, but switching back to original address always. this would also work with your D-Link modems.
Ah, D-Link. What joy.
Regards,
Martin
2:15 p.m.
>>>> Andres <andres(a)telesip.net>
wrote:
>> After the session is up and the address has
been 'pre-filled', if
>> rtpproxy receives a packet on the same UDP port as one of the call
>> legs but from a different IP, it changes the address to which it
>> forwards 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.
If this is concern for you, use option 'A' for commands.
Asymmetric mode means destination can't be changed, but source
with the same host, but another port, is accepted.
Default mode is designed for NAT traversal when external address
detector (e.g. STUN) is absent or misworking. Security risk is
other side of successful working under such conditions.
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.
Really there no such need, but we use variant when rtpproxy
relearns for each packet in first 3 seconds after update/lookup
command.
--
Valentin Nechayev
PortaOne Inc., Software Engineer
mailto:netch@portaone.com
5875
days inactive
5879
days old
10 comments
4 participants
participants (4)
-
Andres -
Martin Hoffmann -
Stefan Sayer -
Valentin Nechayev