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

"Cullen Jennings (fluffy)" <> Thu, 05 December 2013 16:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DDC721AE0A7; Thu, 5 Dec 2013 08:56:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.502
X-Spam-Status: No, score=-109.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WewDLdODgau3; Thu, 5 Dec 2013 08:56:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DAA721AE09C; Thu, 5 Dec 2013 08:56:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2353; q=dns/txt; s=iport; t=1386262598; x=1387472198; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XjWpTUOTRV7O1kRq9MPZou8yQnCVWlMzAxO2XLxsttg=; b=Sps4b+SxYRRDa7GxuHyP7hhyqtEyu86tH5sDs9qagWTIi811Eiln4hVA tpXpLe/g8iguOr3XCeO3axcRdLQxz5uRBouCf8KJzZZF+a+zmfuV77jpU ecBAVt+FB6Q5kcTJRF/Y/0oSCx1Ag4n3iswBOufh8dYFOwxEcLoYwrlEE Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.93,834,1378857600"; d="scan'208";a="4595743"
Received: from ([]) by with ESMTP; 05 Dec 2013 16:56:38 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rB5GucAA000713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 16:56:38 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 10:56:38 -0600
From: "Cullen Jennings (fluffy)" <>
To: "" <>
Thread-Topic: [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
Thread-Index: AQHO8dr2KpmHjzBK6UeIp1AiReLDwQ==
Date: Thu, 5 Dec 2013 16:56:38 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " WG" <>
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-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Dec 2013 16:56:44 -0000

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. 

On Nov 22, 2013, at 3:07 PM, The IESG <> wrote:

> The IESG has received a request from the Audio/Video Transport Core
> Maintenance WG (avtcore) to consider the following document:
> - 'Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single
>   Media Security Solution'
>  <draft-ietf-avt-srtp-not-mandatory-14.txt> as Informational RFC
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> mailing lists by 2013-12-06. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> Abstract
>   This memo discusses the problem of securing real-time multimedia
>   sessions, and explains why the Real-time Transport Protocol (RTP),
>   and the associated RTP Control Protocol (RTCP), do not mandate a
>   single media security mechanism.  Guidelines for designers and
>   reviewers of future RTP extensions are provided, to ensure that
>   appropriate security mechanisms are mandated, and that any such
>   mechanisms are specified in a manner that conforms with the RTP
>   architecture.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> _______________________________________________
> Audio/Video Transport Core Maintenance