Developers WON'T fix severe DOS attack bug. Any workaounds?

[TVEng]

I am using VLC to stream video to BlackBerry devices on Verizon's 3G network. This works very well but there is a problem. Verizon called me a few days ago to ask why I was data-spamming their customers. Here is what happens.

BlackBerry client requests RTSP stream from a VLC server instance.
VLC starts sending video packets to client via UDP.
Client crashes, loses IP, powers off, battery dies, etc.....
VLC *never* stops sending UDP packets of video to client IP
Some other Verizon customer's phone gets our client's now unused IP
Verizon customer gets hammered by unwanted UDP packets 24/7
Verizon customer goes over data usage limits and gets hit with a huge bill
I get called by Verizon.

The developers seem to know this but refuse/decline to fix it. See here:
http://trac.videolan.org/vlc/ticket/279
hxxp://forum.videolan.org/viewtopic.php?f=4&t=11035

Are there any workarounds that might help here? Can VLC stream RTSP via TCP only?

[Rémi Denis-Courmont]

Congratulations, you've just (re)discovered that pay-per-packet is broken by design because anyone can spam the subscriber. At the very least, they should drop firewall bindings that is not refreshed by any outbound packet after a few minutes. Otherwise, that's really plain broken (or evil marketing depending on your PoV).

If you care so badly about this "severe DOS attack", you're welcome to write the missing code or pay someone to do so. I don't think anybody denies that this is a bug/limitation. But code does not get written by whining or publicly shaming open-source hobbyists.

And to answer your question, no there is no solution other than write the missing code, use a different protocol, or a competing piece of software.

[TVEng]

whining or publicly shaming open-source hobbyists

That was not my intent at all. I love VLC and use it constantly. I would be more than willing to write the missing code. Unfortunately, VLC is not written in Python and I am not up to coding in C++ with QT.

The reason I chose the word "won't" was due to message board posts arguing the merit of whether or not the RFC for RTSP is inherently flawed. I saw some VLC devs taking up a debate over whether to be purists and honor the RFC (knowing it was broken) or "fix" the issue.

I did NOT mean any disrespect. And Rémi, thanks for all your hard work!

Can you think of any way that ipfilter could watch the client's responses (or lack there of) and then DROP outgoing UDP packets to that IP as a workaround?

[Rémi Denis-Courmont]

The obvious solution that has been proposed several times involves discarding client that don't ping the server for a certain amount of time (as specified by the RTSP session timeout parameter). Unfortunately, the RTSP specification leaves much room for interpretation as to what refreshes the timer.

And as far as security is concerned, this is a lost fight. Even if VLC implemented the timeout, an evil third party could keep the session going by sending spoofed RTCP Receiver Reports every so often. I do not know any way to authenticate RTCP packets.