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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers