IETF Logo Mail Archive

Re: [MMUSIC] Replay in RTSP?

worley@ariadne.com Wed, 10 January 2024 18:53 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE1AC14F683 for <mmusic@ietfa.amsl.com>; Wed, 10 Jan 2024 10:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.991
X-Spam-Level:
X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EZ9CjZBJUTT for <mmusic@ietfa.amsl.com>; Wed, 10 Jan 2024 10:53:42 -0800 (PST)
Received: from resqmta-c1p-024061.sys.comcast.net (resqmta-c1p-024061.sys.comcast.net [96.102.19.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC10C14F5E6 for <mmusic@ietf.org>; Wed, 10 Jan 2024 10:53:41 -0800 (PST)
Received: from resomta-c1p-023266.sys.comcast.net ([96.102.18.234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resqmta-c1p-024061.sys.comcast.net with ESMTP id Nbitr1ciTKm6bNdfwrqLXn; Wed, 10 Jan 2024 18:51:40 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1704912700; bh=el9ScNFxGPrIT8zZ+GQuSA+fCV/t92LED37pvZukSKc=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=k40HbpqKJvWkwlpKkcosbKF/953bBC1ZJF2VL7ToeMpbyFvxsQubpxjaLl4CKtVx8 JLauVlVXeHfUTBcbbmsV1Mdb/bYkjtREEuz9U/1cSTQlJw6e797NUm604ehqWr3WV6 SiGKHL98YMS8ZEAhzRW4ZL4cDGGye43FTRCZf1Memym0OyBuX28QaW27ceisXD2txH vbsy7t6zlqNjbufHak2/TM7YgYyf71mP5jR1eNmOm6PR2+bqEv6UPNfVKDpWUYaJEW aLZz3YSCkbIj8KghbJcFzVWu353kZafwJ/sRJ8MQ9+wmp5TLKssdc1r7KEjdpapwj4 ksxSuU8M/fH2Q==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::e1a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-c1p-023266.sys.comcast.net with ESMTPA id Ndfvr9Mmy8vzrNdfvrU7nt; Wed, 10 Jan 2024 18:51:40 +0000
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 40AIpc4D3200961 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 10 Jan 2024 13:51:38 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 40AIpcfj3200958; Wed, 10 Jan 2024 13:51:38 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Josip Bodružić <josip.bodruzic@outlook.com>
Cc: mmusic@ietf.org
In-Reply-To: <DU0PR10MB7051F99AE02A454EDE6743AB83692@DU0PR10MB7051.EURPRD10.PROD.OUTLOOK.COM> (josip.bodruzic@outlook.com)
Sender: worley@ariadne.com
Date: Wed, 10 Jan 2024 13:51:38 -0500
Message-ID: <87le8xxbr9.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/5E_eWv0KNQur0AiLyxNumNsWr7A>
Subject: Re: [MMUSIC] Replay in RTSP?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jan 2024 18:53:55 -0000

Josip Bodružić <josip.bodruzic@outlook.com> writes:
> I realized that, for example, YouTube Music's replay button doesn't
> work in the "replay" manner.  [...]  I'm curious so I started looking
> at RTSP's RFC. By searching for "replay" in the RFC I get one hit, and
> there you talk about a security issue, so called replay attacks on the
> media stream. So, my question is: is security the reason why you don't
> have a replay feature as a part of the protocol?

First, "RTSP's RFC" is RFC 2326, which doesn't mention "replay" at all.
By my count, there are 5 RFCs that mention RTSP in the title alone.  So
it would have helped if you specified the RFC number.

I believe you are referring to RFC 4567, "Key Management Extensions for
Session Description Protocol (SDP) and Real Time Streaming Protocol
(RTSP)", which does mention "replay":

   Making the (necessary) assumption that all involved key
   management protocols are secure, the second attack will be detected
   by replay protection mechanisms of the key management protocol(s).

In this case, "replay" means repetition of the authentication messages
needed to set up the media stream, rather than repetition of the media
stream itself.  So no, this security consideration has nothing to do
with the lack of a Replay feature in YouTube.

My belief is that the reason that RTSP does not have a "replay feature"
is that the general model of "media stream" does not have the concept
that the media is stored somewhere, and therefore there is no
pre-existing "beginning" return to and thus obtain again the stream
data that was previously obtained.  That is, it is the media stream
source that defines the concept of a beginning point of a persistent
blob of stored media.  (Or ending point, for that matter.)

Dale

v2.23.0 | Report a Bug | By Email