[secdir] SecDir Review of draft-ietf-avtext-rams-scenarios-04

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 30 April 2012 10:56 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 72BE721F8496; Mon, 30 Apr 2012 03:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.527
X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rZ--6khN2u9M; Mon, 30 Apr 2012 03:56:00 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5D521F848A; Mon, 30 Apr 2012 03:56:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335783359; d=isode.com; s=selector; i=@isode.com; bh=vaoKXVGbgYhnsbNYWEZpJ8HM9eiAgZVDsvegGm7Anz4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=RW0dAOtrybxx6glRUCNxoGnFMQKvdIFN6m0FCU6eMJ+fhA12DKR1on13NLwR7s0wi1C6Fr UYLNGnMaPMhkerr2rVDArv7f6afQbkMc5sUldrSvS9vD5vqEubqER2Mr0YDgCES+9k2pbV I7jfc4usj7lmsIo7sFwbel7nczneeJQ=;
Received: from [] (shiny.isode.com []) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <T55vvgB=g2LT@rufus.isode.com>; Mon, 30 Apr 2012 11:55:59 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F9E6FDF.3080209@isode.com>
Date: Mon, 30 Apr 2012 11:56:31 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: draft-ietf-avtext-rams-scenarios.all@tools.ietf.org, secdir@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org
Subject: [secdir] SecDir Review of draft-ietf-avtext-rams-scenarios-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Apr 2012 10:56:01 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The Rapid Acquisition of Multicast RTP Sessions (RAMS) solution is a 
method based on RTP and RTP Control Protocol (RTCP) that enables an RTP 
receiver to rapidly acquire and start consuming the RTP multicast data. 
Upon a request from the RTP receiver, an auxiliary unicast RTP 
retransmission session is set up between a retransmission server and the 
RTP receiver, over which the reference information about the new 
multicast stream the RTP receiver is about to join is transmitted at an 
accelerated rate. This document provides example scenarios and discusses 
how the RAMS solution could be used when there are two or more multicast 
streams to be acquired from the same or different multicast RTP sessions.

The document says that it has no security considerations. While I would 
agree that it doesn't add new security considerations to the one defined 
in RFC 6285, I am a bit puzzled why it doesn't say exactly that. RFC 
6285 has very extensive Security Considerations.