Ticket #279 (assigned task)

Opened 3 years ago

Last modified 6 months ago

RTSP client polling

Reported by: hartman Assigned to: courmisch (accepted)
Priority: high Milestone: 1.0.x feature freeze
Component: Stream output Version: master
Severity: major Keywords:
Cc: Platform(s): all
Difficulty: medium Work status: Not started

Description

When clients of our RTSP server forcefully die, our server keeps sending information to them. This causes a DoS attack. http://forum.videolan.org/viewtopic.php?t=11035

Change History

07/30/05 01:13:16 changed by hartman

  • difficulty changed from unknown to medium.

See 14.37 of http://www.rtsp.org/2004/drafts/draft06/draft-ietf-mmusic-rfc2326bis-06.txt for RTCP see: http://www.ietf.org/rfc/rfc1889.txt

08/01/05 18:22:41 changed by courmisch

  • version changed from 0.8.2 to HEAD.

RFC2326bis (RTSP/1.1 draft) says you MUST NOT stop sending RTP data when a clients disconnect from the server. Clients are supposed to be able to do that then reconnect. So VLC's behavior is actually correct.

So, hmm, well, I'm pretty much against unilateraly stopping the stream when the client disconnects. I don't know if implementing RTCP would allow a clean solution to that (I doubt it). However, I would assume there has to be some kind of timeout and maybe VLC doesn't do that. Will check.

08/01/05 18:45:56 changed by courmisch

Well... after a more precise check, it turns out the correct behavior is indeed not to stop the RTP stream when the client hangs up the TCP session, but to implement a liveness timeout.

There are two ways for the client to show it is still alive :

  • send RTCP feedback,
  • send an empty OPTIONS or, better yet, SET_PARAMETER, request.

Given we don't support RTCP (#157), we can't check for this properly, so we just can't fix this bug (otherwise we'd timeout living clients which would be worst).

08/03/05 16:49:36 changed by courmisch

  • owner deleted.
  • milestone changed from 0.8.4 (feature freeze) to 0.8.5.

08/21/05 09:39:49 changed by zorglub

  • milestone changed from 0.8.5 to Features paradize.

08/30/05 13:10:57 changed by E-bola

  • severity changed from normal to critical.

I wouldnt say a DoS attack should have normal as severity...

09/24/05 17:32:08 changed by zorglub

  • severity changed from critical to major.

Please use severities with consideration

01/26/06 14:02:33 changed by tumu

  • priority changed from normal to high.

03/09/06 21:10:06 changed by tumu

  • milestone changed from Features paradize to 0.8.6 features freeze.

Some RTCP code was added recently so might as well bring this ticket to 0.8.6.

03/11/06 14:43:53 changed by zorglub

  • status changed from new to closed.
  • resolution set to duplicate.

This is part of #157

08/19/07 16:38:04 changed by courmisch

  • status changed from closed to reopened.
  • resolution deleted.

This is not part of RTCP support. What we need to do is timeout clients that haven't refreshed the session (through RTSP control connection) for a while. Clients are supposed to send dummy OPTIONS query with the appropriate Session-ID to keep a stream alive.

Failing to detect that, our RTSP server would indeed be a nice DoS proxy.

08/25/07 22:43:17 changed by courmisch

  • status changed from reopened to new.
  • owner set to courmisch.

08/25/07 22:43:30 changed by courmisch

  • status changed from new to assigned.

02/10/08 13:21:28 changed by courmisch

  • type changed from defect to task.

03/10/08 09:38:25 changed by jb

  • milestone changed from 0.9.0 features freeze to 0.9.1-features.