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

Robert Sparks <rjsparks@nostrum.com> Wed, 20 May 2015 20:39 UTC

Return-Path: <rjsparks@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 3E4421A90C2; Wed, 20 May 2015 13:39:23 -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 6fsrwGAkpV8Z; Wed, 20 May 2015 13:39:21 -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 8EA811A90C3; Wed, 20 May 2015 13:39:21 -0700 (PDT)
Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4KKdHS2051630 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 May 2015 15:39:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local
Message-ID: <555CF0F0.5000502@nostrum.com>
Date: Wed, 20 May 2015 15:39:12 -0500
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <5554F5D3.7080204@nostrum.com> <5559B2FA.20801@ericsson.com> <8469C57F-5864-4B9E-9A3B-428DDB4101FD@nostrum.com>
In-Reply-To: <8469C57F-5864-4B9E-9A3B-428DDB4101FD@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/tlHI8Kd9anJz28r4abj8k_p03FA>
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:39:23 -0000


On 5/20/15 3:25 PM, Ben Campbell wrote:
> 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.
I think Magnus was sketching out proposed new text for the document.
>
> 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