Re: [Gen-art] [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06

"Ben Campbell" <ben@nostrum.com> Wed, 20 May 2015 20:25 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315B01A9084; Wed, 20 May 2015 13:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 mSHaZjZbyJj9; Wed, 20 May 2015 13:25:47 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8B61B1A8BBD; Wed, 20 May 2015 13:25:47 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4KKPXPs050349 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 May 2015 15:25:43 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Robert Sparks <rjsparks@nostrum.com>
Date: Wed, 20 May 2015 15:25:33 -0500
Message-ID: <8469C57F-5864-4B9E-9A3B-428DDB4101FD@nostrum.com>
In-Reply-To: <5559B2FA.20801@ericsson.com>
References: <5554F5D3.7080204@nostrum.com> <5559B2FA.20801@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/FVeGpx0hKb9tNXS0YYMZDG7rMFg>
Cc: General Area Review Team <gen-art@ietf.org>, avtext@ietf.org, draft-ietf-avtext-rtp-grouping-taxonomy@ietf.org, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [Gen-art] [avtext] Genart LC review: draft-ietf-avtext-rtp-grouping-taxonomy-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 May 2015 20:25:49 -0000

Magnus and Robert: Is there an action implied here? I see that Magnus 
agreed that there was an oversight in regards to security, but it's not 
clear to me what action (if any) is planned.

Thanks!

Ben.

On 18 May 2015, at 4:38, Magnus Westerlund wrote:

> Robert Sparks skrev den 2015-05-14 21:21:
>
>> Major issues:
>>
>> I'm surprised that there is no mention of how SRTP fits into the
>> vocabulary this
>> document builds. Would it be a mistake for someone to think of SRTP 
>> as what
>> this document calls a transformation? Are there any consequences of
>> using SRTP
>> on one or more of the streams being associated that impact how you 
>> would
>> talk about
>> the association? (There are certainly consequences about which 
>> elements
>> can see
>> into the various streams).
>>
>
> Yes, encryption is clearly a transformation. And there are cases where 
> the order of the encryption and other transformations, like FEC, do 
> matter. Thus, I agree that it is an significant oversight to not 
> include security.
>
> So SRTP is an Securing / Protection (as it is not only Encryption) 
> transformation that operates on Source RTP Streams or Redundancy RTP 
> Streams to create Secured Source RTP Streams or Secured Redundancy RTP 
> Stream.
>
> If one looks on something like ISMAcrypt that operates on a special 
> form of packetized encoded streams, i.e. payload created, but not RTP 
> headers, we get into further distinctions that we so far haven't 
> needed to have.
>
> I don't know how well we must ensure that something like ISMAcrypt is 
> clearly defined, because then we do need to split the RTP 
> packetization transformation into two parts.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
> _______________________________________________
> avtext mailing list
> avtext@ietf.org
> https://www.ietf.org/mailman/listinfo/avtext