IETF Logo Mail Archive

Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC

Colin Perkins <csp@csperkins.org> Fri, 06 December 2013 11:40 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F251ADF54; Fri, 6 Dec 2013 03:40:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV_NiqvUEcAX; Fri, 6 Dec 2013 03:40:27 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7311ADF4E; Fri, 6 Dec 2013 03:40:27 -0800 (PST)
Received: from [130.209.247.112] (port=52111 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1Votlb-0003xB-NV; Fri, 06 Dec 2013 11:40:21 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <1286562B-6C43-4ADC-8999-C70CA356F587@cisco.com>
Date: Fri, 06 Dec 2013 11:40:18 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <89E376B0-5555-40D8-A59E-0286CABC856C@csperkins.org>
References: <20131122220752.31098.83432.idtracker@ietfa.amsl.com> <1286562B-6C43-4ADC-8999-C70CA356F587@cisco.com>
To: Cullen Jennings <fluffy@cisco.com>
X-Mailer: Apple Mail (2.1510)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: "ietf@ietf.org" <ietf@ietf.org>, "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 11:40:29 -0000

Cullen,

On 5 Dec 2013, at 16:56, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
> Given the hum in the IETF plenary at the last IETF, I no longer think this document represents IETF consensus. Given the hum in RTCWeb working group, I doubt this represents the consensus of the RAI area either. 
> 
> I think I would be tempted to resolve this by saying for each different scenario RTP is used in (SIP, RTSP, Mulitcast etc) exactly how it needs to be secured and for scenarios not listed such as new usages, what the requirements are. For something like SIP, having just one way to secure RTP is much better than having many ways. 


I'm confused about your objection, since this draft states that we need to do exactly as you propose. 

Colin



-- 
Colin Perkins
http://csperkins.org/

v2.23.0 | Report a Bug | By Email