From nobody Sun Feb 1 12:24:01 2015 Return-Path: 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 1F7CB1A8A5F for ; Sun, 1 Feb 2015 12:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 MYr1QUyx2cCJ for ; Sun, 1 Feb 2015 12:23:57 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC801A8F48 for ; Sun, 1 Feb 2015 12:23:56 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so35420298wgh.6 for ; Sun, 01 Feb 2015 12:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=FXMdjIwtiBqtSLkysb+Skiu/Qj6GSKw1mS1kmHRkcN0=; b=D+bpvwBjbnm8S/AFPYMSXSEQtBIhki6UFrRhvvif/01t9F0yJq+hWc32IquNbVFIrN otn76pd5yw6oBNjkpYb405T7mRk6vxkrzqv0LCc7a+Bv503jNO5F4UGW3Pui8qlkINwj zu65Fr5WUAOitelynIk5/tIouRAk1K2hWPmlinbXIxwMsHx/7i8f19M4YA8VPccOvrVD pUcbokvZOTUPDfoi69jQce+q5AZ1yq680iL9gVxKyl3xFFgDtzxdClbDIvnAmlPEjN2D xIXJyu06EvK9SdUrYIePkCTmuVYYpSqxxjfzFhOrc/T4BC0flUc5NYqNDhu3yK7XZP9z fNDw== X-Received: by 10.180.7.199 with SMTP id l7mr17594339wia.66.1422822235606; Sun, 01 Feb 2015 12:23:55 -0800 (PST) Received: from RoniE (bzq-79-181-50-186.red.bezeqint.net. [79.181.50.186]) by mx.google.com with ESMTPSA id fo15sm16672350wic.19.2015.02.01.12.23.53 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 01 Feb 2015 12:23:54 -0800 (PST) From: "Roni Even" To: Date: Sun, 1 Feb 2015 22:23:49 +0200 Message-ID: <063901d03e5c$ff2088e0$fd619aa0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_063A_01D03E6D.C2A9CE10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA+XJAGkuWlck6RRD2hpPyKxGwTgA== Content-Language: en-us Archived-At: Subject: [AVTCORE] Second WGLC on draft-ietf-avtcore-rtp-topologies-update-05 X-BeenThere: avt@ietf.org 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: Sun, 01 Feb 2015 20:23:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_063A_01D03E6D.C2A9CE10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We had a WGLC on the 04 version in September 2014, The document was updated based on comments and the latest version is in https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-05 We would like to have a short second WGLC till February 15th. Please review and send comments. If there are no new comments we will send the document to publication Regards Roni Even AVTcore co-chair ------=_NextPart_000_063A_01D03E6D.C2A9CE10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We had a WGLC = on the 04 version in September 2014, The document was updated based on = comments and the latest version is in https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-upd= ate-05

 

We would like to have a short second WGLC till = February 15th.

Please = review and send comments.

If there = are no new comments we will send the document to = publication

Regards

Roni Even

AVTcore = co-chair

------=_NextPart_000_063A_01D03E6D.C2A9CE10-- From nobody Fri Feb 6 07:05:52 2015 Return-Path: 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 06FBA1A1B1B; Fri, 6 Feb 2015 07:05:45 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 h76LKavAsLCc; Fri, 6 Feb 2015 07:05:42 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02DB1A1B2B; Fri, 6 Feb 2015 07:05:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2056CBED3; Fri, 6 Feb 2015 15:06:11 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abSiJ0jNrPoT; Fri, 6 Feb 2015 15:06:09 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.24.69]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 21215BED1; Fri, 6 Feb 2015 15:06:09 +0000 (GMT) Message-ID: <54D4D840.4080808@cs.tcd.ie> Date: Fri, 06 Feb 2015 15:05:36 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Magnus Westerlund , David McGrew References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> In-Reply-To: <54CA135D.3020304@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , The IESG , IETF AVTCore WG Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Fri, 06 Feb 2015 15:05:45 -0000 Hi Magnus, I had hoped the WG would chime in but apparently they do not care much about this topic. I'd take that as indicating that it is ok to remove some of the options since nobody is yelling that they are all needed. After all - is there really a need to define 10 ways of using one algorithm (AES) to do pretty much exactly the same thing? I think 10 options is just damaging to interop even if done for the best of motives. S. On 29/01/15 11:02, Magnus Westerlund wrote: > Hi Stephen, All, > > (Adding the AVTCORE WG): WG there are feedback requested from you below! > > I am taking over as shepherd for this document and would like to make > some progress here. > > I would like to make some observations around the discuss. > https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ballot/#stephen-farrell > > First, that Stephen appear to grouping AES-GCM and AES-CCM into one > bucket. From my perspective they are defined as two different ciphers > for SRTP but within a single document. One can implement either of them > without any requirement on implementing the other from this document. > > Each of them have MTI requirements on configurations that MUST be > supported if one support that particular cipher. That is defined as > strongest for each key length. > >>From the draft: > > Section 13.1: > > Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM > and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication > tags), and it MAY support the four other variants shown in table 1. > > Section 13.2: > > Any implementation of AES-CCM SRTP/SRTCP MUST support both > AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet > AEAD authentication tags), and MAY support the other four variants. > > I would further also note that to make anything MTI for SRTP independent > on deployment and usage, then a document must Update the MTI definition > in RFC 3711, something that hasn't been done yet. So far it is up to the > umbrella specifications, like WebRTC etc as discussed in SRTP not > mandatory document (RFC 7202) to define what ciphers that MUST be > implemented. And if we are updating RFC 3711 the mandatory to implement > for any SRTP implementation will certainly be a question. > > > When it comes to the core of your discuss if these 4 (AES-GCM) + 6 > (AES-CCM) options must be defined. That is difficult question. One which > is difficult to answer within the context of the WG actually. As David > has raised in the private discussion so far there will be people that > will argue anything other than the longest tags and keys are acceptable, > others will note that using the 16 byte authentication tags do results > in the authentication data being more than the RTP payload (single audio > frame) for a number of the audio formats we have. Me personally I think > I would remove the 12 bytes tag-length from AES-CCM to reduce the number > of options. But two tag-lengths and two key-lengths do not appear > excessive. > > WG, the chairs and ADs appreciate feedback on your view here. > > > 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 > ---------------------------------------------------------------------- > From nobody Mon Feb 9 04:05:50 2015 Return-Path: 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 BF3E91A036D; Mon, 9 Feb 2015 04:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 yJ51hsADpBlL; Mon, 9 Feb 2015 04:05:46 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434391A0369; Mon, 9 Feb 2015 04:05:45 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-59-54d8a297044f Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F6.67.24955.792A8D45; Mon, 9 Feb 2015 13:05:43 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Mon, 9 Feb 2015 13:05:43 +0100 Message-ID: <54D8A297.9090505@ericsson.com> Date: Mon, 9 Feb 2015 13:05:43 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Farrell , David McGrew References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> In-Reply-To: <54D4D840.4080808@cs.tcd.ie> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvje70RTdCDKb9UrZ42bOS3WLlt+us FmuPJFrM+DOR2WLCqdesFldX/WG3mL73GrsDu8eU3xtZPdZ2X2XzWLLkJ5NH/66XrB5fLn9m C2CN4rJJSc3JLEst0rdL4Mq4+3gGU0GvQ8WHG5OYGhibjboYOTkkBEwkFn9qZ4OwxSQu3FsP ZHNxCAkcYZTY0tHEDOEsY5RY8KMfrIpXQFti8s2TrF2MHBwsAioS/44ngoTZBCwkbv5oBCsR FQiWWPz8KStEuaDEyZlPWEBsEYEgicWNbWA1zAKdTBJ7+tNBbGGBOIlZLzexQ+xazyzR0roK rJlTQFPi7OODTCC7mIHs9bv0IXrlJZq3zmYGsYWAzmlo6mCdwCg4C8m6WQgds5B0LGBkXsUo WpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGPoHt/xW3cF4+Y3jIUYBDkYlHt4NSjdChFgTy4or cw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAqPVv/YHck5dnrbtluMXv oqbm1ncztcP1TFguppWH/Cq45PFz/ZsaLsUV/Al9b+4eWvjJXVx493mzlPy9Zox7lysXlYls +TydrUHjxly9vHkZtrciOfcd5Dv29W7ilYd8IgGNMqG63xcHqflcK7nDVrfavIIjTivicOHR Ayx3trvG8MiJb/zUrsRSnJFoqMVcVJwIAKEWs/JeAgAA Archived-At: Cc: "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , The IESG , IETF AVTCore WG Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Mon, 09 Feb 2015 12:05:49 -0000 Hi Stephen, (as individual) I also wished the WG was more active. I like to ask you about your characterization of this as being 10 ways of using the same algorithm. To my understanding what we have are really two different algorithm usages, the AES-GCM and the AES-CCM. They appear to have potentially significant differences in how they work. Thus having potentially different vulnerabilities. Thus, if we are going to have a discussion about how to trim the permutational tree for this, I think it is important that we consider this as being a selection in three dimensions, namely algorithm, key-length and authentication tag length. When it comes to the algorithms, this will be the second and third use of AES in SRTP, as we already have four operation points using longer than 128 bit-keys for SRTP where AES Counter mode is combined with HMAC. >From Section 5 of RFC 6188. +-------------------------+-----------+ | Crypto Suite Name | Reference | +-------------------------+-----------+ | AES_192_CM_HMAC_SHA1_80 | [RFC6188] | | AES_192_CM_HMAC_SHA1_32 | [RFC6188] | | AES_256_CM_HMAC_SHA1_80 | [RFC6188] | | AES_256_CM_HMAC_SHA1_32 | [RFC6188] | +-------------------------+-----------+ Thus lets start with the differences between AES-GCM and AES-CCM. I can't argue around there differences. But, I do like to note that I personally are fine with treating them as two separate entities. Neither are mandatory to implement in an SRTP implementation. We have today only one MTI encryption algorithm namely AES-CM with 128 keys and 80-bit SHA-1 HMAC. This document change none of that, and the consideration for SRTP not mandatory (RFC 7202) applies here. These algorithm will have to be mandated by other specifications until that point that someone see a need to update the MTI in RFC 3711. Thus, the document provides two choices, where you can select to use only one of them. And if you select either they have their MTI configuration, thus ensuring that any implementation have at least one common configuration per algorithm. Thus lets look at the configurations on a per algorithm basis: AES-GCM: AEAD_AES_128_GCM = {TBD, TBD } AEAD_AES_256_GCM = {TBD, TBD } AEAD_AES_128_GCM_12 = {TBD, TBD } AEAD_AES_256_GCM_12 = {TBD, TBD } This is four alternatives, with either 128 or 256 bit keys and the choice between 12 and 16 bytes authentication tag. AES-CCM AEAD_AES_128_CCM = {TBD, TBD } AEAD_AES_256_CCM = {TBD, TBD } AEAD_AES_128_CCM_8 = {TBD, TBD } AEAD_AES_256_CCM_8 = {TBD, TBD } AEAD_AES_128_CCM_12 = {TBD, TBD } AEAD_AES_256_CCM_12 = {TBD, TBD } AES-CCM has the choices between the 128 and 256 bit keys with authentication tags with a length of 8, 12 or 16 bytes. >From my perspective, I don't see many obvious candidates to remove. I think the AES-CCM 12 bytes tags could go. You either care about tag-length and then that is so important that you accept the weakness of the 8 byte ones, or you can use 16 bytes to get the stronger protection. The half-way point seems a bit unnecessary. This is based on that there are cases where people either care about the authentication overhead or they don't thus, having a weaker shorter and a long strong one appears reasonably motivated, as long as the short isn't so weak that it will be highly susceptible to forging. Thus, I think the main question remaining if one tries to reduce this further, is 128 bit keys to short in today's world for actual standardization? I don't know the answer, nor have an opinion on it. Cheers Magnus Westerlund On 2015-02-06 16:05, Stephen Farrell wrote: > > Hi Magnus, > > I had hoped the WG would chime in but apparently they do not > care much about this topic. > > I'd take that as indicating that it is ok to remove some of > the options since nobody is yelling that they are all needed. > > After all - is there really a need to define 10 ways of using > one algorithm (AES) to do pretty much exactly the same thing? > > I think 10 options is just damaging to interop even if done for > the best of motives. > > S. > > On 29/01/15 11:02, Magnus Westerlund wrote: >> Hi Stephen, All, >> >> (Adding the AVTCORE WG): WG there are feedback requested from you below! >> >> I am taking over as shepherd for this document and would like to make >> some progress here. >> >> I would like to make some observations around the discuss. >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ballot/#stephen-farrell >> >> First, that Stephen appear to grouping AES-GCM and AES-CCM into one >> bucket. From my perspective they are defined as two different ciphers >> for SRTP but within a single document. One can implement either of them >> without any requirement on implementing the other from this document. >> >> Each of them have MTI requirements on configurations that MUST be >> supported if one support that particular cipher. That is defined as >> strongest for each key length. >> >> >From the draft: >> >> Section 13.1: >> >> Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM >> and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication >> tags), and it MAY support the four other variants shown in table 1. >> >> Section 13.2: >> >> Any implementation of AES-CCM SRTP/SRTCP MUST support both >> AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet >> AEAD authentication tags), and MAY support the other four variants. >> >> I would further also note that to make anything MTI for SRTP independent >> on deployment and usage, then a document must Update the MTI definition >> in RFC 3711, something that hasn't been done yet. So far it is up to the >> umbrella specifications, like WebRTC etc as discussed in SRTP not >> mandatory document (RFC 7202) to define what ciphers that MUST be >> implemented. And if we are updating RFC 3711 the mandatory to implement >> for any SRTP implementation will certainly be a question. >> >> >> When it comes to the core of your discuss if these 4 (AES-GCM) + 6 >> (AES-CCM) options must be defined. That is difficult question. One which >> is difficult to answer within the context of the WG actually. As David >> has raised in the private discussion so far there will be people that >> will argue anything other than the longest tags and keys are acceptable, >> others will note that using the 16 byte authentication tags do results >> in the authentication data being more than the RTP payload (single audio >> frame) for a number of the audio formats we have. Me personally I think >> I would remove the 12 bytes tag-length from AES-CCM to reduce the number >> of options. But two tag-lengths and two key-lengths do not appear >> excessive. >> >> WG, the chairs and ADs appreciate feedback on your view here. >> >> >> 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 >> ---------------------------------------------------------------------- >> > > -- 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 ---------------------------------------------------------------------- From nobody Mon Feb 9 06:48:38 2015 Return-Path: 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 A3F431A046D for ; Mon, 9 Feb 2015 06:40:10 -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 8qf8mnewAJlf for ; Mon, 9 Feb 2015 06:40:08 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976F01A044D for ; Mon, 9 Feb 2015 06:40:08 -0800 (PST) Received: from [130.209.247.112] (port=58200 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YKpVO-0005ea-68; Mon, 09 Feb 2015 14:40:07 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <063901d03e5c$ff2088e0$fd619aa0$@gmail.com> Date: Mon, 9 Feb 2015 14:39:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7D03393D-7F95-4395-A514-85CD374CB545@csperkins.org> References: <063901d03e5c$ff2088e0$fd619aa0$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avt@ietf.org Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-rtp-topologies-update-05 X-BeenThere: avt@ietf.org 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: Mon, 09 Feb 2015 14:40:11 -0000 Hi Roni, On 1 Feb 2015, at 20:23, Roni Even wrote: > We had a WGLC on the 04 version in September 2014, The document was = updated based on comments and the latest version is in = https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-05 > =20 > We would like to have a short second WGLC till February 15th. > Please review and send comments. > If there are no new comments we will send the document to publication I reviewed the diff, which looks okay to me. --=20 Colin Perkins https://csperkins.org/ From nobody Mon Feb 9 13:54:27 2015 Return-Path: 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 521D91A1A51 for ; Mon, 9 Feb 2015 07:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.764 X-Spam-Level: *** X-Spam-Status: No, score=3.764 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FRT_STOCK1=3.988, FRT_STOCK2=3.988, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 LfFry5jXIfYy for ; Mon, 9 Feb 2015 07:56:19 -0800 (PST) Received: from smtpsalv.upv.es (smtpsal1.cc.upv.es [158.42.249.61]) (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 F05061A1A27 for ; Mon, 9 Feb 2015 07:56:18 -0800 (PST) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by smtpsalv.upv.es (8.14.4/8.14.4) with ESMTP id t19FuGRh001201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Feb 2015 16:56:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=upv.es; s=default; t=1423497376; bh=jxXsPiKl8GsLCKYMKQAIA9eWJ8l2L+90ttSVMzrcWgs=; h=Date:From:To:Subject; b=bLfm8N0POHzPe+wUf8RC8G7vmIi7u4j9h64VMGimqzrUzNDnR5hGOPRKbFkaUqsDx lM5rYXpqTXJJ7+CI5MdeEfNogY6hAcVXfp+egRTRT/89O7bc0u6le2ukY2k668WI8L VFoBLr1HSbpYcW6jRFp1ojUjW8qiIRVkTMDtvJKiBfSsKwYHA2iWN6McJulw/54nEF yC1u7QpBeqrGf+inatEQ9sGyGM1x0G8lXNiz+ZQfNkjRghAhpvTHri2lgnFyxDouEF 33/qtB416G6CY3nrwD6rw3TWLB7A7/c72zvgoBg9rXlL/pqD1/bGh14/bbbQPVGpnl kj36x2MRr2GDw== Received: from smtp.upv.es (smtpv.cc.upv.es [158.42.249.16]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id t19FuGM5016116 for ; Mon, 9 Feb 2015 16:56:16 +0100 Received: from localhost (wm1.cc.upv.es [158.42.249.56]) by smtp.upv.es (8.14.4/8.13.6) with ESMTP id t19FuFPj005999 for ; Mon, 9 Feb 2015 16:56:15 +0100 Received: from gnd2g71-201.wi-fi.upv.es (gnd2g71-201.wi-fi.upv.es [158.42.71.201]) by webmail.upv.es (Horde Framework) with HTTP; Mon, 09 Feb 2015 16:56:15 +0100 Message-ID: <20150209165615.14986fhp4iz1ozvj@webmail.upv.es> Date: Mon, 09 Feb 2015 16:56:15 +0100 From: Mario Montagud Climent To: "avt@ietf.org" MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_u9cojz5ce9z" Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) Archived-At: X-Mailman-Approved-At: Mon, 09 Feb 2015 13:30:41 -0800 Subject: [AVTCORE] Fwd: New Version Notification for draft-montagud-avtcore-eed-rtcp-idms-00.txt X-BeenThere: avt@ietf.org 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: Mon, 09 Feb 2015 15:56:24 -0000 This message is in MIME format. --=_u9cojz5ce9z Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit Dear AVTCORE WG members, We have just submitted a new ID proposing new RTCP reporting rules and messages for Inter-Destination Media Synchronization (IDMS), which, in conjunction, we call "Early-Event Driven (EED) RTCP Feedback for IDMS". The rationale of such document is to allow a more strategic and efficient usage of the RTCP channel for IDMS, based on the proposed RTCP extensions in [RFC4585] and in [RFC6051]. The use of EED RTCP Feedback for IDMS is backward compatible with [RFC7272], while it adheres to the RTCP traffic bounds specified in [RFC3550]. In particular, the following key benefits are provided by the proposed EED RTCP Feedback for IDMS: i) earlier correction of out-of-sync situations; ii) higher granularity for synchronizing the presentation of dynamically triggered media-related events (e.g., to ensure that important pieces of media content are simultaneously presented in all the users); iii) ability of dynamically requesting (re-)IDMS setting instructions (e.g., in case of RTCP packet loss); iv) dynamic and rapid accommodation of latecomers in on-going sessions; and v) reduction of channel-change (i.e., zapping) delays. Additionally, this ID also discusses various situations in which the reporting of Reduced-Size RTCP packets [RFC3556] can be applicable and beneficial for IDMS. We have also included some definitions from [RFC3550], [RFC4585] and [RFC6051] for a better understanding of this document. We will deeply appreciate your feedback on this document and a discussion for its consideration as a WG item. Cheers, Mario Montagud PS: A preliminary evalution of such IDMS extensions can be found in "Montagud, M., Boronat, F., Stokking, H., Early Event-Driven (EED) RTCP Feedback for Rapid IDMS, The 21st ACM International Conference on Multimedia (ACM MM 2013), Barcelona (Spain), October 2013". If you are interested in reading this paper, but do not have access, please send me an e-mail. ----- Mensaje reenviado de internet-drafts@ietf.org ----- Fecha: Mon, 09 Feb 2015 07:42:44 -0800 De: internet-drafts@ietf.org Asunto: New Version Notification for draft-montagud-avtcore-eed-rtcp-idms-00.txt Para: Mario Montagud , Fernando Boronat , Hans Stokking A new version of I-D, draft-montagud-avtcore-eed-rtcp-idms-00.txt has been successfully submitted by Mario Montagud and posted to the IETF repository. Name: draft-montagud-avtcore-eed-rtcp-idms Revision: 00 Title: Early Event-Driven (EED) RTCP Feedback for Rapid IDMS Document date: 2015-02-09 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-montagud-avtcore-eed-rtcp-idms-00.txt Status: https://datatracker.ietf.org/doc/draft-montagud-avtcore-eed-rtcp-idms/ Htmlized: http://tools.ietf.org/html/draft-montagud-avtcore-eed-rtcp-idms-00 Abstract: RFC 7272 defines two RTCP messages to enable Inter-Destination Media Synchronization (IDMS). However, if such RTCP messages are exchanged using the Regular RTCP reporting rules specified in RFC 3550, unacceptable delays can be originated when exchanging the synchronization information conveyed into RTCP packets. Accordingly, this document proposes Early Event-Driven (EED) RTCP reporting rules and messages to enable higher interactivity, dynamism, flexibility and accuracy when using RTP/RTCP for IDMS. Such IDMS extensions are targeted at providing faster reaction on dynamic situations, such as out-of-sync situations and channel change delays, as well as a finer granularity for synchronizing media-related events, while still adhering to the RTCP bandwidth bounds specified in RFC 3550. Besides, a new RTP/AVPF transport layer feedback message is proposed to allow the request of re-IDMS setting instructions (e.g., in case of RTCP packet loss) as well as rapid accommodation of latecomers in on-going sessions. Finally, this document also discusses various situations in which the reporting of Reduced-Size RTCP packets (RFC 3556) can be applicable and beneficial for IDMS. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ----- Terminar mensaje reenviado ----- --=_u9cojz5ce9z Content-Type: message/rfc822; name="Mensaje reenviado: New Version Notification for draft-montagud-avtcore-eed-rtcp-idms-00.txt"; name*0="Mensaje reenviado: New Version Notification for draft-montagud-avtcore-"; name*1="eed-rtcp-idms-00.txt" Return-Path: Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by acentauri.cc.upv.es (Cyrus v2.3.16-Invoca-RPM-2.3.16-4) with LMTPA; Mon, 09 Feb 2015 16:43:06 +0100 X-Sieve: CMU Sieve 2.3 Received: from mx.upv.es (albali.cc.upv.es [158.42.250.156]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id t19Fh6ZL007044 for ; Mon, 9 Feb 2015 16:43:06 +0100 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mx.upv.es (8.14.3/8.14.3) with ESMTP id t19FgwsF016948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Feb 2015 16:43:05 +0100 Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531B81A1A1B; Mon, 9 Feb 2015 07:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com 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 mke5upXn6hio; Mon, 9 Feb 2015 07:42:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7EE1A1A74; Mon, 9 Feb 2015 07:42:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Mario Montagud" , "Fernando Boronat" , "Hans Stokking" , "Hans Stokking" , "Mario Montagud" , "Fernando Boronat" Subject: New Version Notification for draft-montagud-avtcore-eed-rtcp-idms-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209154244.23340.52788.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 07:42:44 -0800 A new version of I-D, draft-montagud-avtcore-eed-rtcp-idms-00.txt has been successfully submitted by Mario Montagud and posted to the IETF repository. Name: draft-montagud-avtcore-eed-rtcp-idms Revision: 00 Title: Early Event-Driven (EED) RTCP Feedback for Rapid IDMS Document date: 2015-02-09 Group: Individual Submission Pages: 25 URL: http://www.ietf.org/internet-drafts/draft-montagud-avtcore-eed-rtcp-idms-00.txt Status: https://datatracker.ietf.org/doc/draft-montagud-avtcore-eed-rtcp-idms/ Htmlized: http://tools.ietf.org/html/draft-montagud-avtcore-eed-rtcp-idms-00 Abstract: RFC 7272 defines two RTCP messages to enable Inter-Destination Media Synchronization (IDMS). However, if such RTCP messages are exchanged using the Regular RTCP reporting rules specified in RFC 3550, unacceptable delays can be originated when exchanging the synchronization information conveyed into RTCP packets. Accordingly, this document proposes Early Event-Driven (EED) RTCP reporting rules and messages to enable higher interactivity, dynamism, flexibility and accuracy when using RTP/RTCP for IDMS. Such IDMS extensions are targeted at providing faster reaction on dynamic situations, such as out-of-sync situations and channel change delays, as well as a finer granularity for synchronizing media-related events, while still adhering to the RTCP bandwidth bounds specified in RFC 3550. Besides, a new RTP/AVPF transport layer feedback message is proposed to allow the request of re-IDMS setting instructions (e.g., in case of RTCP packet loss) as well as rapid accommodation of latecomers in on-going sessions. Finally, this document also discusses various situations in which the reporting of Reduced-Size RTCP packets (RFC 3556) can be applicable and beneficial for IDMS. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --=_u9cojz5ce9z-- From nobody Mon Feb 9 15:21:29 2015 Return-Path: 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 04EE11A8A63; Mon, 9 Feb 2015 14:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 0vjzGioWRsFB; Mon, 9 Feb 2015 14:58:43 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBFB11A8940; Mon, 9 Feb 2015 14:58:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 78988BEE9; Mon, 9 Feb 2015 22:59:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmaYsylY-sKC; Mon, 9 Feb 2015 22:59:11 +0000 (GMT) Received: from [172.16.29.43] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 191E3BE51; Mon, 9 Feb 2015 22:59:08 +0000 (GMT) Message-ID: <54D93B9A.9090409@cs.tcd.ie> Date: Mon, 09 Feb 2015 22:58:34 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Magnus Westerlund , David McGrew References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> In-Reply-To: <54D8A297.9090505@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , The IESG , IETF AVTCore WG Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Mon, 09 Feb 2015 22:58:46 -0000 Hi Magnus, On 09/02/15 12:05, Magnus Westerlund wrote: > Hi Stephen, > > (as individual) > I also wished the WG was more active. Yep, hard to evaluate consensus with so few commenting. Thanks for the good analysis below, I'll respond here as I think that's better done in reverse order almost. - aes-128 in any flavour is good enough, there's IMO no pressing need for aes-256 here - gcm vs. ccm: those are functionally equivalent as far as this application is concerned I think - the only reason to have both is if one has to deal with systems that only support one and not the other; ccm is all that is available on some very constrained devices for essentially historical reasons and again I don't see why that is an issue here (it could be, but I don't recall anyone saying that it is - apologies if I've forgotten) - I tend to agree with you about the 192 label If I were correct in the above then all that'd be really needed is AEAD_AES_128_GCM = {TBD, TBD } AEAD_AES_128_GCM_12 = {TBD, TBD } I'd argue that 2 options vs. 10 options may lead to overall better security and interop. as there will be many systems and libraries with less code and hence fewer bugs. (It's credible to argue that code size reduction might outweigh adding aes-256 in a case where you don't worry about ciphertext being secure for decades.) If we continue to have so few folks engaging on this maybe the best way to handle it would be to talk about it on an IESG informal telechat if we can get you and David (and Russ) all on the call? (Or over a beer in Dallas I guess as that's also getting close and there a bunch of IESG calls coming up that are devotes to BoFs and the Dallas schedule.) Cheers, S. > > I like to ask you about your characterization of this as being 10 ways > of using the same algorithm. To my understanding what we have are really > two different algorithm usages, the AES-GCM and the AES-CCM. > They appear to have potentially significant differences in how they > work. Thus having potentially different vulnerabilities. Thus, if we are > going to have a discussion about how to trim the permutational tree for > this, I think it is important that we consider this as being a selection > in three dimensions, namely algorithm, key-length and authentication tag > length. > > When it comes to the algorithms, this will be the second and third use > of AES in SRTP, as we already have four operation points using longer > than 128 bit-keys for SRTP where AES Counter mode is combined with HMAC. > > From Section 5 of RFC 6188. > > +-------------------------+-----------+ > | Crypto Suite Name | Reference | > +-------------------------+-----------+ > | AES_192_CM_HMAC_SHA1_80 | [RFC6188] | > | AES_192_CM_HMAC_SHA1_32 | [RFC6188] | > | AES_256_CM_HMAC_SHA1_80 | [RFC6188] | > | AES_256_CM_HMAC_SHA1_32 | [RFC6188] | > +-------------------------+-----------+ > > Thus lets start with the differences between AES-GCM and AES-CCM. I > can't argue around there differences. But, I do like to note that I > personally are fine with treating them as two separate entities. Neither > are mandatory to implement in an SRTP implementation. We have today only > one MTI encryption algorithm namely AES-CM with 128 keys and 80-bit > SHA-1 HMAC. This document change none of that, and the consideration for > SRTP not mandatory (RFC 7202) applies here. These algorithm will have to > be mandated by other specifications until that point that someone see a > need to update the MTI in RFC 3711. > > Thus, the document provides two choices, where you can select to use > only one of them. And if you select either they have their MTI > configuration, thus ensuring that any implementation have at least one > common configuration per algorithm. > > Thus lets look at the configurations on a per algorithm basis: > > AES-GCM: > > AEAD_AES_128_GCM = {TBD, TBD } > AEAD_AES_256_GCM = {TBD, TBD } > AEAD_AES_128_GCM_12 = {TBD, TBD } > AEAD_AES_256_GCM_12 = {TBD, TBD } > > > This is four alternatives, with either 128 or 256 bit keys and the > choice between 12 and 16 bytes authentication tag. > > AES-CCM > AEAD_AES_128_CCM = {TBD, TBD } > AEAD_AES_256_CCM = {TBD, TBD } > AEAD_AES_128_CCM_8 = {TBD, TBD } > AEAD_AES_256_CCM_8 = {TBD, TBD } > AEAD_AES_128_CCM_12 = {TBD, TBD } > AEAD_AES_256_CCM_12 = {TBD, TBD } > > AES-CCM has the choices between the 128 and 256 bit keys with > authentication tags with a length of 8, 12 or 16 bytes. > > From my perspective, I don't see many obvious candidates to remove. I > think the AES-CCM 12 bytes tags could go. You either care about > tag-length and then that is so important that you accept the weakness of > the 8 byte ones, or you can use 16 bytes to get the stronger protection. > The half-way point seems a bit unnecessary. This is based on that there > are cases where people either care about the authentication overhead or > they don't thus, having a weaker shorter and a long strong one appears > reasonably motivated, as long as the short isn't so weak that it will be > highly susceptible to forging. > > Thus, I think the main question remaining if one tries to reduce this > further, is 128 bit keys to short in today's world for actual > standardization? > > I don't know the answer, nor have an opinion on it. > > Cheers > > Magnus Westerlund > > > On 2015-02-06 16:05, Stephen Farrell wrote: >> >> Hi Magnus, >> >> I had hoped the WG would chime in but apparently they do not >> care much about this topic. >> >> I'd take that as indicating that it is ok to remove some of >> the options since nobody is yelling that they are all needed. >> >> After all - is there really a need to define 10 ways of using >> one algorithm (AES) to do pretty much exactly the same thing? >> >> I think 10 options is just damaging to interop even if done for >> the best of motives. >> >> S. >> >> On 29/01/15 11:02, Magnus Westerlund wrote: >>> Hi Stephen, All, >>> >>> (Adding the AVTCORE WG): WG there are feedback requested from you below! >>> >>> I am taking over as shepherd for this document and would like to make >>> some progress here. >>> >>> I would like to make some observations around the discuss. >>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm/ballot/#stephen-farrell >>> >>> First, that Stephen appear to grouping AES-GCM and AES-CCM into one >>> bucket. From my perspective they are defined as two different ciphers >>> for SRTP but within a single document. One can implement either of them >>> without any requirement on implementing the other from this document. >>> >>> Each of them have MTI requirements on configurations that MUST be >>> supported if one support that particular cipher. That is defined as >>> strongest for each key length. >>> >>> >From the draft: >>> >>> Section 13.1: >>> >>> Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM >>> and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication >>> tags), and it MAY support the four other variants shown in table 1. >>> >>> Section 13.2: >>> >>> Any implementation of AES-CCM SRTP/SRTCP MUST support both >>> AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet >>> AEAD authentication tags), and MAY support the other four variants. >>> >>> I would further also note that to make anything MTI for SRTP independent >>> on deployment and usage, then a document must Update the MTI definition >>> in RFC 3711, something that hasn't been done yet. So far it is up to the >>> umbrella specifications, like WebRTC etc as discussed in SRTP not >>> mandatory document (RFC 7202) to define what ciphers that MUST be >>> implemented. And if we are updating RFC 3711 the mandatory to implement >>> for any SRTP implementation will certainly be a question. >>> >>> >>> When it comes to the core of your discuss if these 4 (AES-GCM) + 6 >>> (AES-CCM) options must be defined. That is difficult question. One which >>> is difficult to answer within the context of the WG actually. As David >>> has raised in the private discussion so far there will be people that >>> will argue anything other than the longest tags and keys are acceptable, >>> others will note that using the 16 byte authentication tags do results >>> in the authentication data being more than the RTP payload (single audio >>> frame) for a number of the audio formats we have. Me personally I think >>> I would remove the 12 bytes tag-length from AES-CCM to reduce the number >>> of options. But two tag-lengths and two key-lengths do not appear >>> excessive. >>> >>> WG, the chairs and ADs appreciate feedback on your view here. >>> >>> >>> 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 >>> ---------------------------------------------------------------------- >>> >> >> > > From nobody Mon Feb 9 15:49:20 2015 Return-Path: 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 4DBE91A1A1B for ; Mon, 9 Feb 2015 07:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 wnyNmHTyMctz for ; Mon, 9 Feb 2015 07:39:41 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739F71A1A03 for ; Mon, 9 Feb 2015 07:39:39 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-2c-54d8d4b9ac66 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FE.9F.04231.9B4D8D45; Mon, 9 Feb 2015 16:39:38 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.210.2; Mon, 9 Feb 2015 16:39:37 +0100 Message-ID: <54D8D4A7.3080809@ericsson.com> Date: Mon, 9 Feb 2015 16:39:19 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Roni Even , References: <063901d03e5c$ff2088e0$fd619aa0$@gmail.com> In-Reply-To: <063901d03e5c$ff2088e0$fd619aa0$@gmail.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUyM+Jvje6uKzdCDOb9FLR42bOS3eJvO7MD k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfFvXxdjwV+uil+XLrE0MN7h6GLk5JAQMJF4 fnQZG4QtJnHh3nogm4tDSOAIo0Tvwj2MEM4yRok3O64zgVTxCmhL/J/dCmazCKhIXJo7hR3E ZhOwkLj5oxFskqhAsMTi509ZIeoFJU7OfMICYosImEmsO/8KzBYWCJQ42vkPrFdIwFzi9K7v jCA2J9Cctn/vwHqZBQwkjiyaA2XLSzRvnc0MUa8t0dDUwTqBUWAWkhWzkLTMQtKygJF5FaNo cWpxcW66kbFealFmcnFxfp5eXmrJJkZgWB7c8lt3B+Pq146HGAU4GJV4eDco3QgRYk0sK67M PcQozcGiJM5rZ3woREggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj6RwtZvtTB057G3iHbfwo 4D/h7Cz+DdWWEnVbsr30Dn7qTj3oz54v1CypIa4gPL99Jceab31fw1J9/qVl79uxjG3uL80V YitnH3MPi32RqtjMLrOooubU7bA/9yyzIwysc7Ne7lVTm5m3kY3p0wU11edhr8PX9O5meJ5r 0HqCNVbbSuCbiYQSS3FGoqEWc1FxIgAuyZC4LAIAAA== Archived-At: Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-rtp-topologies-update-05 X-BeenThere: avt@ietf.org 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: Mon, 09 Feb 2015 15:39:43 -0000 Hi, I have reviewed the whole document with a fresh mind, and found no issues beyond the needed to update the usage of "End Point" to "Endpoint" to align with the updated Taxonomy. Cheers Magnus Westerlund (As Author) On 2015-02-01 21:23, Roni Even wrote: > Hi, > > We had a WGLC on the 04 version in September 2014, The document was > updated based on comments and the latest version is in > https://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-05 > > > > We would like to have a short second WGLC till February 15^th . > > Please review and send comments. > > If there are no new comments we will send the document to publication > > Regards > > Roni Even > > AVTcore co-chair > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- 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 ---------------------------------------------------------------------- From nobody Mon Feb 9 15:51:20 2015 Return-Path: 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 7EDF51A8A8A; Mon, 9 Feb 2015 15:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 wfWwxKiYBKt3; Mon, 9 Feb 2015 15:39:00 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A4F1A6EE8; Mon, 9 Feb 2015 15:38:59 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id va2so28567129obc.1; Mon, 09 Feb 2015 15:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e4vxyFc9+ev3io35MAbOqWpbfaZBHgOvMorfBQ2/Smk=; b=OYMIc4AhpvxdxDKlV0j05+3j9uZOfO7Kdv8ZYJGGYKZXBETaMip4xhLwI2+MNVxvtk g1JS059yDkA/ti82gT8TD7uPlLfCHw/AFkdqFfBY1O8eG6YyE/YK1TaOclu03JZ/4eoe Iicl0mAs2QG7tvzsH1Xzg55wFcV3lHIp9i2wnMWiiD6dBEpYb0BqpXVBKz8ArppxmMo7 CmkX+UR13u5Q1uLhx4+ZVt3zkZY0M/I9f1cdr6u0vdGMaOD7GuP6kS/12vkbo9+omBQS lIgUiGvOZArF7lHBBVizUPo1irnIwAEIHvgv3CWKFlWl4/5EGiv9YodT7s5C1PZTlolA FlpQ== MIME-Version: 1.0 X-Received: by 10.60.92.5 with SMTP id ci5mr13450781oeb.26.1423525138830; Mon, 09 Feb 2015 15:38:58 -0800 (PST) Received: by 10.202.225.135 with HTTP; Mon, 9 Feb 2015 15:38:58 -0800 (PST) In-Reply-To: <54D93B9A.9090409@cs.tcd.ie> References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> Date: Tue, 10 Feb 2015 10:38:58 +1100 Message-ID: From: Martin Thomson To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Magnus Westerlund , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , David McGrew , IETF AVTCore WG , "avtcore-chairs@tools.ietf.org" , The IESG Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Mon, 09 Feb 2015 23:39:01 -0000 On 10 February 2015 at 09:58, Stephen Farrell wrote: > > AEAD_AES_128_GCM = {TBD, TBD } > AEAD_AES_128_GCM_12 = {TBD, TBD } FWIW, I agree with Stephen here. Other than knowing of its existence, I haven't been following this work at all. But I really don't want SRTP cipher suite proliferation. I'm personally uninterested in a suite with an abbreviated tag, given that it's a mere 4 octets of savings. I know that this was a big deal in the past, but that gave us the _24 (bits) variants. In this case, either save bits by being more aggressive, or drop the _12 (bytes) variant. If you keep it, please be consistent and call it _96. From nobody Tue Feb 10 05:49:05 2015 Return-Path: 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 614871A0271; Tue, 10 Feb 2015 05:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 PyijC4mLIrhy; Tue, 10 Feb 2015 05:48:59 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECC61A026E; Tue, 10 Feb 2015 05:48:56 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-a4-54da0c466001 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B6.C8.04231.64C0AD45; Tue, 10 Feb 2015 14:48:54 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.210.2; Tue, 10 Feb 2015 14:48:54 +0100 Message-ID: <54DA0C45.2030609@ericsson.com> Date: Tue, 10 Feb 2015 14:48:53 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Farrell , David McGrew References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> In-Reply-To: <54D93B9A.9090409@cs.tcd.ie> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvja4bz60Qg39d6hYve1ayW6z8dp3V Yu2RRIsZfyYyW0w49ZrV4uqqP+wW0/deY3dg95jyeyOrx9ruq2weS5b8ZPLo3/WS1ePL5c9s AaxRXDYpqTmZZalF+nYJXBmXH09nLJgvX7HgxS/GBsbv4l2MnBwSAiYSU5ofMELYYhIX7q1n 62Lk4hASOMIoMe3LHlYIZzmjxJ/FO1lAqngFtCV+XVwM1sEioCrRvn8fG4jNJmAhcfNHI5gt KhAssfj5U1aIekGJkzOfgPWKCARJLG5sA6thFuhkktjTnw5iCwvEScx6uYkdYtkbZok7N96B FXEKaEpMnQGyjAOoQVNi/S59iF55ieats5lBbCGgexqaOlgnMArOQrJuFkLHLCQdCxiZVzGK FqcWF+emGxnrpRZlJhcX5+fp5aWWbGIEBv/BLb91dzCufu14iFGAg1GJh9eg5GaIEGtiWXFl 7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYXa+el40KzVWLFlX4ZRfO Vp95Z4uK1busT2uDO/RXa+2bUlChvlcwfdXuiW7Cy9JFLssa5T3Mv5KSktDSpDB128y2adnm X/i/Zs4NU9666sTbbw9ftB3R4j3+P0Uh3i+wc0XFv0cHo/qfuES0c6+asDOuR++Kn2D/z+o5 lt3hqqHzC9myb3spsRRnJBpqMRcVJwIApU7Co18CAAA= Archived-At: Cc: "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , The IESG , IETF AVTCore WG Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Tue, 10 Feb 2015 13:49:01 -0000 Hi, I would definitely want the authors to step in now and provide their reasoning for why these options have been included. On 2015-02-09 23:58, Stephen Farrell wrote: > > Hi Magnus, > > On 09/02/15 12:05, Magnus Westerlund wrote: >> Hi Stephen, >> >> (as individual) >> I also wished the WG was more active. > > Yep, hard to evaluate consensus with so few commenting. > > Thanks for the good analysis below, I'll respond here as I think > that's better done in reverse order almost. > > - aes-128 in any flavour is good enough, there's IMO no pressing > need for aes-256 here Despite that we have a definition for AES-256 for SRTP already and personally I find it a bit difficult to throw away work for something we are likely to going to need in the future. > - gcm vs. ccm: those are functionally equivalent as far as this > application is concerned I think - the only reason to have both > is if one has to deal with systems that only support one and not > the other; ccm is all that is available on some very constrained > devices for essentially historical reasons and again I don't see > why that is an issue here (it could be, but I don't recall anyone > saying that it is - apologies if I've forgotten) Well, if I understand the security analysis then apparently CCM is less sensitive to a weak authentication, and could use the 64 bit authentication tag, while GCM needs a stronger one. Thus, from that perspective, if we at all are going to have a shorter authentication tag then 128 bits, then why not use the 64 bit CCM then as that is significant saving, rather than only four bytes for the GCM. > - I tend to agree with you about the 192 label > > If I were correct in the above then all that'd be really needed is > > AEAD_AES_128_GCM = {TBD, TBD } > AEAD_AES_128_GCM_12 = {TBD, TBD } > > I'd argue that 2 options vs. 10 options may lead to overall > better security and interop. as there will be many systems and > libraries with less code and hence fewer bugs. (It's credible > to argue that code size reduction might outweigh adding aes-256 > in a case where you don't worry about ciphertext being secure > for decades.) I understand the desire to avoid proliferation here. I might not see the 256 bit keys in the same way. Make it clear that they are optional and that anyone supporting AES-GCM MUST support 128-bit keys. But based on the above reasoning if we are doing only AES-GCM then I rather see: AEAD_AES_128_GCM = {TBD, TBD } AEAD_AES_256_GCM = {TBD, TBD } If we based on my above argumentation think we should provide a short tag version then I think the set to define would become: AEAD_AES_128_CCM = {TBD, TBD } AEAD_AES_256_CCM = {TBD, TBD } AEAD_AES_128_CCM_64 = {TBD, TBD } AEAD_AES_256_CCM_64 = {TBD, TBD } Using Martin's suggestion for being consistent in bits vs bytes. > > If we continue to have so few folks engaging on this maybe the > best way to handle it would be to talk about it on an IESG > informal telechat if we can get you and David (and Russ) all > on the call? (Or over a beer in Dallas I guess as that's also > getting close and there a bunch of IESG calls coming up that > are devotes to BoFs and the Dallas schedule.) > Yes, unless we get more opinions now, I think the way forward is to go that road so that we can conclude. 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 ---------------------------------------------------------------------- From nobody Tue Feb 10 12:21:40 2015 Return-Path: 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 681AB1A6FF7 for ; Tue, 10 Feb 2015 12:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 1CbJgwkfvte1 for ; Tue, 10 Feb 2015 12:21:25 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28E81A7018 for ; Tue, 10 Feb 2015 12:21:03 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2C2FC20F7F for ; Tue, 10 Feb 2015 15:21:03 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 10 Feb 2015 15:21:03 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=toUIrXAgsLaPlvBTWkAig26Zz2U=; b=cAFxF1odrVGFNZwIWWvU6 QHr5mmG1DvtAXS274yKOYtJ84soYTMAFJbq89A/6fbvRz++1piUs2DSxpOa1wgNn JhDiqpLEhObnol+hPLl7++BA5SmFOUr/3Y9uYzKuOWDROk4rrP766QXNCQ5FKvz4 zQdViVIcDEKAXOC169AlMQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=toUIrXAgsLaPlvBTWkAig26 Zz2U=; b=oAOc/apEs1f4yhaeE3StFxhlew8EwvSGACeFyXNA9hQH8Mz2HUq7ohI gPCQZMuraJf8kgh8zIFGxIJZxYMPnwU6VRSMh6fFYprmE5HplaO/bPM//naUPrXw uXLSwYXj0nfHTgFOuf3TmjoHuJuFps/gjnCvpa1fNv5C8ASVQ9ho= X-Sasl-enc: i4bD0Kb18B2VsNeZJVeUyw4QznXlYqmekbzGyjRwiXOf 1423599662 Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id DD1F2C00297; Tue, 10 Feb 2015 15:21:00 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alissa Cooper In-Reply-To: <54DA0C45.2030609@ericsson.com> Date: Tue, 10 Feb 2015 12:21:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <214AB7CA-19B4-4CB6-B60A-A31478FB00DD@cooperw.in> References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , David McGrew , IETF AVTCore WG , "avtcore-chairs@tools.ietf.org" , IESG , Stephen Farrell Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Tue, 10 Feb 2015 20:21:28 -0000 For scheduling purposes I put this on the agenda for the next informal = (Feb 26 at 16:30 UTC) and have reached out to the authors separately to = see if they are available. If it gets resolved before then we can remove = it from the agenda. Alissa On Feb 10, 2015, at 5:48 AM, Magnus Westerlund = wrote: > Hi, >=20 > I would definitely want the authors to step in now and provide their > reasoning for why these options have been included. >=20 >=20 >=20 > On 2015-02-09 23:58, Stephen Farrell wrote: >>=20 >> Hi Magnus, >>=20 >> On 09/02/15 12:05, Magnus Westerlund wrote: >>> Hi Stephen, >>>=20 >>> (as individual) >>> I also wished the WG was more active. >>=20 >> Yep, hard to evaluate consensus with so few commenting. >>=20 >> Thanks for the good analysis below, I'll respond here as I think >> that's better done in reverse order almost. >>=20 >> - aes-128 in any flavour is good enough, there's IMO no pressing >> need for aes-256 here >=20 > Despite that we have a definition for AES-256 for SRTP already and > personally I find it a bit difficult to throw away work for something = we > are likely to going to need in the future. >=20 >> - gcm vs. ccm: those are functionally equivalent as far as this >> application is concerned I think - the only reason to have both >> is if one has to deal with systems that only support one and not >> the other; ccm is all that is available on some very constrained >> devices for essentially historical reasons and again I don't see >> why that is an issue here (it could be, but I don't recall anyone >> saying that it is - apologies if I've forgotten) >=20 > Well, if I understand the security analysis then apparently CCM is = less > sensitive to a weak authentication, and could use the 64 bit > authentication tag, while GCM needs a stronger one. Thus, from that > perspective, if we at all are going to have a shorter authentication = tag > then 128 bits, then why not use the 64 bit CCM then as that is > significant saving, rather than only four bytes for the GCM. >=20 >> - I tend to agree with you about the 192 label >>=20 >> If I were correct in the above then all that'd be really needed is >>=20 >> AEAD_AES_128_GCM =3D {TBD, TBD } >> AEAD_AES_128_GCM_12 =3D {TBD, TBD } >>=20 >> I'd argue that 2 options vs. 10 options may lead to overall >> better security and interop. as there will be many systems and >> libraries with less code and hence fewer bugs. (It's credible >> to argue that code size reduction might outweigh adding aes-256 >> in a case where you don't worry about ciphertext being secure >> for decades.) >=20 > I understand the desire to avoid proliferation here. I might not see = the > 256 bit keys in the same way. Make it clear that they are optional and > that anyone supporting AES-GCM MUST support 128-bit keys. But based on > the above reasoning if we are doing only AES-GCM then I rather see: >=20 > AEAD_AES_128_GCM =3D {TBD, TBD } > AEAD_AES_256_GCM =3D {TBD, TBD } >=20 > If we based on my above argumentation think we should provide a short > tag version then I think the set to define would become: >=20 > AEAD_AES_128_CCM =3D {TBD, TBD } > AEAD_AES_256_CCM =3D {TBD, TBD } > AEAD_AES_128_CCM_64 =3D {TBD, TBD } > AEAD_AES_256_CCM_64 =3D {TBD, TBD } >=20 > Using Martin's suggestion for being consistent in bits vs bytes. >=20 >>=20 >> If we continue to have so few folks engaging on this maybe the >> best way to handle it would be to talk about it on an IESG >> informal telechat if we can get you and David (and Russ) all >> on the call? (Or over a beer in Dallas I guess as that's also >> getting close and there a bunch of IESG calls coming up that >> are devotes to BoFs and the Dallas schedule.) >>=20 >=20 > Yes, unless we get more opinions now, I think the way forward is to go > that road so that we can conclude. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 From nobody Wed Feb 11 05:35:49 2015 Return-Path: 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 2D0981A88AD; Wed, 11 Feb 2015 05:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 ST4vAzMo3y_b; Wed, 11 Feb 2015 05:35:44 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88FC1A8899; Wed, 11 Feb 2015 05:35:42 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-04-54db5aac5465 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.AE.04484.CAA5BD45; Wed, 11 Feb 2015 14:35:40 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.21]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0210.002; Wed, 11 Feb 2015 14:35:40 +0100 From: John Mattsson To: Alissa Cooper Thread-Topic: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) Thread-Index: AQHQQh5oJgFl6m3W+E63IOWS9grYL5zoLHSAgAC2aACAAPjAgIAAbZCAgAEhFAA= Date: Wed, 11 Feb 2015 13:35:39 +0000 Message-ID: References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> <214AB7CA-19B4-4CB6-B60A-A31478FB00DD@cooperw.in> In-Reply-To: <214AB7CA-19B4-4CB6-B60A-A31478FB00DD@cooperw.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_F318B21421B24CD0A511DAB6C05DACD6ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM+Jvje6aqNshBnteallMP/OX0eJlz0p2 i5XfrrNarD2SaDHjz0Rmi6ur/rBbTN97jd2B3WPK742sHl+evGTyWNt9lc1jyZKfTB5fLn9m C2CN4rJJSc3JLEst0rdL4MpouHKJqWDyLuaK3l0dzA2Mf/8xdTFycEgImEi8nuTRxcgJZIpJ XLi3nq2LkYtDSOAIo8TjzR8YIZzFjBJr7rxhAqliEzCQmLungQ3EFhFQlbh67AdYB7PACyaJ 42uXMYIkhAUyJH72v2WFKMqUOPp2PpTtJ3H1+VJmEJsFqHnrtd/sIFfwCthL7OxjhVh2hUVi ypTtYHM4Bewkvq1dALaMEei876fWgB3BLCAucevJfCaIswUkluw5zwxhi0q8fPyPFeIzRYnl /XIQ5ckSfydtAzuBV0BQ4uTMJywTGEVnIZk0C0nZLCRlEHEDiffn5jND2NoSyxa+hrL1JTZ+ OcsIYVtLrGtvY0VWs4CRYxWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYGQf3PLbYAfjy+eO hxgFOBiVeHg3HL0VIsSaWFZcmXuIUZqDRUmc1874UIiQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGxlrbqtiEjhc+Su4Kd/XDprZbf2nM3Sn0aNvUO7M/x3uzaqQn/F+SHjs1RM9CJt1xmSd3 6e15P3sXiqz6teH589qHIZW5GnfXdPbXb71++NHp196mS213n1l3bPUuk0gPh9cXp7ZKVlTr veb7d0I45PrSLSLn2J8/VoltT+vPmca2cLoOc8KGf0osxRmJhlrMRcWJAF6eUWvNAgAA Archived-At: Cc: Magnus Westerlund , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , David McGrew , IETF AVTCore WG , "avtcore-chairs@tools.ietf.org" , IESG , Stephen Farrell Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Wed, 11 Feb 2015 13:35:48 -0000 --_000_F318B21421B24CD0A511DAB6C05DACD6ericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable My view is that we should standardize GCM and CCM as well as both 128-bit a= nd 256-bit keys, but not necessarily all combinations. Having the option of= 64-bit tags also makes a lot of sense. 10 protection profiles are a bit mu= ch. If I were to choose a bare minimum set of needed protection profiles, = my choice would be: AEAD_AES_128_CCM_64 AEAD_AES_128_GCM_96 AEAD_AES_256_GCM Regarding 256-bit keys, there are such requirements for national security. = I definitely think we should have a 256-bit option (and currently there are= no such protection profile). I think users of 256-bit keys would like 128-= bit tags and GCM. Regarding CCM, it is currently used mostly in constrained devices where it = is a better fit that GCM. CCM_64 is currently the default TLS cipher suite = for COAP. I think we should have an SRTP option for these devices and then = CCM_64 makes sense. Regarding tag lengths, I don=92t see the practical security need for long t= ag lengths, long authentication tags is less important in SRTP than in TLS = or IPsec. Even 64-bit tags offer very good protection as an attacker would = need to send 2^64 randomly forged messages before a single one (with a rand= om plaintext) would be validated. Receiving 2^64 packages is far more serio= us then accepting 20 ms of random noise. I think 96-bit authentication tags= make sense for most users of AES_128_GCM. (BTW, SRTP has only 4 registered protection profiles. TLS has 327 registere= d cipher suites! Why is IESG suddenly reacting when SRTP is getting some we= ll-needed AEAD algorithms? ;) John On 10 Feb 2015, at 21:21, Alissa Cooper > wrote: For scheduling purposes I put this on the agenda for the next informal (Feb= 26 at 16:30 UTC) and have reached out to the authors separately to see if = they are available. If it gets resolved before then we can remove it from t= he agenda. Alissa On Feb 10, 2015, at 5:48 AM, Magnus Westerlund > wrote: Hi, I would definitely want the authors to step in now and provide their reasoning for why these options have been included. On 2015-02-09 23:58, Stephen Farrell wrote: Hi Magnus, On 09/02/15 12:05, Magnus Westerlund wrote: Hi Stephen, (as individual) I also wished the WG was more active. Yep, hard to evaluate consensus with so few commenting. Thanks for the good analysis below, I'll respond here as I think that's better done in reverse order almost. - aes-128 in any flavour is good enough, there's IMO no pressing need for aes-256 here Despite that we have a definition for AES-256 for SRTP already and personally I find it a bit difficult to throw away work for something we are likely to going to need in the future. - gcm vs. ccm: those are functionally equivalent as far as this application is concerned I think - the only reason to have both is if one has to deal with systems that only support one and not the other; ccm is all that is available on some very constrained devices for essentially historical reasons and again I don't see why that is an issue here (it could be, but I don't recall anyone saying that it is - apologies if I've forgotten) Well, if I understand the security analysis then apparently CCM is less sensitive to a weak authentication, and could use the 64 bit authentication tag, while GCM needs a stronger one. Thus, from that perspective, if we at all are going to have a shorter authentication tag then 128 bits, then why not use the 64 bit CCM then as that is significant saving, rather than only four bytes for the GCM. - I tend to agree with you about the 192 label If I were correct in the above then all that'd be really needed is AEAD_AES_128_GCM =3D {TBD, TBD } AEAD_AES_128_GCM_12 =3D {TBD, TBD } I'd argue that 2 options vs. 10 options may lead to overall better security and interop. as there will be many systems and libraries with less code and hence fewer bugs. (It's credible to argue that code size reduction might outweigh adding aes-256 in a case where you don't worry about ciphertext being secure for decades.) I understand the desire to avoid proliferation here. I might not see the 256 bit keys in the same way. Make it clear that they are optional and that anyone supporting AES-GCM MUST support 128-bit keys. But based on the above reasoning if we are doing only AES-GCM then I rather see: AEAD_AES_128_GCM =3D {TBD, TBD } AEAD_AES_256_GCM =3D {TBD, TBD } If we based on my above argumentation think we should provide a short tag version then I think the set to define would become: AEAD_AES_128_CCM =3D {TBD, TBD } AEAD_AES_256_CCM =3D {TBD, TBD } AEAD_AES_128_CCM_64 =3D {TBD, TBD } AEAD_AES_256_CCM_64 =3D {TBD, TBD } Using Martin's suggestion for being consistent in bits vs bytes. If we continue to have so few folks engaging on this maybe the best way to handle it would be to talk about it on an IESG informal telechat if we can get you and David (and Russ) all on the call? (Or over a beer in Dallas I guess as that's also getting close and there a bunch of IESG calls coming up that are devotes to BoFs and the Dallas schedule.) Yes, unless we get more opinions now, I think the way forward is to go that road so that we can conclude. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt --_000_F318B21421B24CD0A511DAB6C05DACD6ericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <24884A4320528B40A9AA92E3B2BC1043@ericsson.com> Content-Transfer-Encoding: quoted-printable

My view is that we should standardize GCM and CCM as= well as both 128-bit and 256-bit keys, but not necessarily all combination= s. Having the option of 64-bit tags also makes a lot of sense. 10 protectio= n profiles are a bit much.  If I were to choose a bare minimum set of needed protection profiles, my choice woul= d be:

=  AEAD_AES_128_CCM_64

=  AEAD_AES_128_GCM_96

=  AEAD_AES_256_GCM

Regarding 256-bit keys, there are such requirements = for national security. I definitely think we should have a 256-bit option (= and currently there are no such protection profile). I think users of 256-b= it keys would like 128-bit tags and GCM.

Regarding CCM, it is currently used mostly in constr= ained devices where it is a better fit that GCM. CCM_64 is currently the de= fault TLS cipher suite for COAP. I think we should have an SRTP option for = these devices and then CCM_64 makes sense.

Regarding tag lengths, I don=92t see the practical s= ecurity need for long tag lengths, long authentication tags is less importa= nt in SRTP than in TLS or IPsec. Even 64-bit tags offer very good protectio= n as an attacker would need to send 2^64 randomly forged messages before a single one (with a random plaintext= ) would be validated. Receiving 2^64 packages is far more serious then acce= pting 20 ms of random noise. I think 96-bit authentication tags make sense = for most users of AES_128_GCM.

(BTW, SRTP has only 4 registered protection profiles= . TLS has 327 registered cipher suites! Why is IESG suddenly reacting when = SRTP is getting some well-needed AEAD algorithms? ;)

John


On 10 Feb 2015, at 21:21, Alissa Cooper <alissa@cooperw.in> wrote:

For scheduling purposes I put this on the agenda for the ne= xt informal (Feb 26 at 16:30 UTC) and have reached out to the authors separ= ately to see if they are available. If it gets resolved before then we can = remove it from the agenda.

Alissa

On Feb 10, 2015, at 5:48 AM, Magnus Westerlund <magnus.westerlund@ericsson.com>= wrote:

Hi,

I would definitely want the authors to step in now and provide their
reasoning for why these options have been included.



On 2015-02-09 23:58, Stephen Farrell wrote:

Hi Magnus,

On 09/02/15 12:05, Magnus Westerlund wrote:
Hi Stephen,

(as individual)
I also wished the WG was more active.

Yep, hard to evaluate consensus with so few commenting.

Thanks for the good analysis below, I'll respond here as I think
that's better done in reverse order almost.

- aes-128 in any flavour is good enough, there's IMO no pressing
need for aes-256 here

Despite that we have a definition for AES-256 for SRTP already and
personally I find it a bit difficult to throw away work for something we are likely to going to need in the future.

- gcm vs. ccm: those are functionally = equivalent as far as this
application is concerned I think - the only reason to have both
is if one has to deal with systems that only support one and not
the other; ccm is all that is available on some very constrained
devices for essentially historical reasons and again I don't see
why that is an issue here (it could be, but I don't recall anyone
saying that it is - apologies if I've forgotten)

Well, if I understand the security analysis then apparently CCM is less
sensitive to a weak authentication, and could use the 64 bit
authentication tag, while GCM needs a stronger one. Thus, from that
perspective, if we at all are going to have a shorter authentication tag then 128 bits, then why not use the 64 bit CCM then as that is
significant saving, rather than only four bytes for the GCM.

- I tend to agree with you about the 1= 92 label

If I were correct in the above then all that'd be really needed is

        AEAD_AES_128_GCM  &nbs= p; =3D {TBD, TBD }
        AEAD_AES_128_GCM_12 =3D {TB= D, TBD }

I'd argue that 2 options vs. 10 options may lead to overall
better security and interop. as there will be many systems and
libraries with less code and hence fewer bugs. (It's credible
to argue that code size reduction might outweigh adding aes-256
in a case where you don't worry about ciphertext being secure
for decades.)

I understand the desire to avoid proliferation here. I might not see the 256 bit keys in the same way. Make it clear that they are optional and
that anyone supporting AES-GCM MUST support 128-bit keys. But based on
the above reasoning if we are doing only AES-GCM then I rather see:

          AEAD_AES_128_GC= M    =3D {TBD, TBD }
          AEAD_AES_256_GC= M    =3D {TBD, TBD }

If we based on my above argumentation think we should provide a short
tag version then I think the set to define would become:

       AEAD_AES_128_CCM   &nbs= p;=3D {TBD, TBD }
       AEAD_AES_256_CCM   &nbs= p;=3D {TBD, TBD }
       AEAD_AES_128_CCM_64 =3D {TBD, TBD= }
       AEAD_AES_256_CCM_64 =3D {TBD, TBD= }

Using Martin's suggestion for being consistent in bits vs bytes.


If we continue to have so few folks engaging on this maybe the
best way to handle it would be to talk about it on an IESG
informal telechat if we can get you and David (and Russ) all
on the call? (Or over a beer in Dallas I guess as that's also
getting close and there a bunch of IESG calls coming up that
are devotes to BoFs and the Dallas schedule.)


Yes, unless we get more opinions now, I think the way forward is to go
that road so that we can conclude.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB           &nb= sp;     | Phone  +46 10 7148287
F=E4r=F6gatan 6           = ;      | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

--_000_F318B21421B24CD0A511DAB6C05DACD6ericssoncom_-- From nobody Sun Feb 15 06:09:28 2015 Return-Path: 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 9C05E1A1BC6; Sun, 15 Feb 2015 06:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 rRUP_jNbpg4O; Sun, 15 Feb 2015 06:09:18 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71ADE1A1BCE; Sun, 15 Feb 2015 06:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21270; q=dns/txt; s=iport; t=1424009358; x=1425218958; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=BGH+8M9PtAYSD6LwL3stx1+U+pJ0tiOTQxhFsO4sbak=; b=ZLFZTvKC3r5csyzuRRwvBgv5TLdkPp1mM+pT1EH06hRMNBvsda/3VAcO X42ewZgjCIkJj56OHHwoWmWRQEuFWfBVGGfDOw1Zc9mZNLgNptjznohs8 YCCHbTd6wAZ8f+MToeuoctpzDiFiMEh336fzQhEIHEk3SPuUUimhb7Ms+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscFAG6n4FStJA2K/2dsb2JhbABbgkNDgSyEBsQlAoEOQwEBAQEBAXyEDAEBAQMBDG0FCQILGCcHGysRBhOIJQjPAAEBAQEBAQEBAQEBAQEBAQEBAQEBARcEigp+hG0HgxaBFAWFWoRggxKHVoNNgRiDDY5oIoF/HxSBWiAxgkMBAQE X-IronPort-AV: E=Sophos;i="5.09,581,1418083200"; d="scan'208,217";a="396290862" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP; 15 Feb 2015 14:09:16 +0000 Received: from rtp-mcgrew-8916.cisco.com (rtp-mcgrew-8916.cisco.com [10.117.10.231]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1FE9Dv4025439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 15 Feb 2015 14:09:14 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_326575E8-3C14-4E7D-8DC3-C5055A9DBFB4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David McGrew In-Reply-To: <54DA0C45.2030609@ericsson.com> Date: Sun, 15 Feb 2015 09:09:17 -0500 Message-Id: References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , IETF AVTCore WG , "avtcore-chairs@tools.ietf.org" , The IESG , Stephen Farrell Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Sun, 15 Feb 2015 14:09:25 -0000 --Apple-Mail=_326575E8-3C14-4E7D-8DC3-C5055A9DBFB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Magnus, On Feb 10, 2015, at 8:48 AM, Magnus Westerlund = wrote: > Hi, >=20 > I would definitely want the authors to step in now and provide their > reasoning for why these options have been included. >=20 >=20 because it has been conventional practice for crypto standards to = provide a variety of security levels and a diversity of crypto = mechanisms. Certainly this has been the case historically, and eight = of the ten ciphersuites have been in the draft ever since October 27, = 2008, when draft-mcgrew-srtp-aes-gcm-01 was first submitted. There was = not any feedback that eight or ten was excessive until Stephen raised = his Discuss issue. =20 My opinion is: it would be best to preserve the existing specification = and implementation work, and retain all ten crypto suite definitions. = But if we want to make SRTP-AEAD be the first instance in which the IETF = will prioritize simplicity over variety and diversity, I=92m good with = that, because I certainly see the value of simplicity; then my = recommendation would be to eliminate the four 12-octet authentication = versions. That would leave just six crypto suites, with two different = modes of operation, two different key sizes, and two different tag = lengths (but not all tag lengths for all modes), like this: srtp-crypto-suite-ext =3D "AEAD_AES_128_GCM" / "AEAD_AES_256_GCM" / "AEAD_AES_128_CCM" / "AEAD_AES_256_CCM" / "AEAD_AES_128_CCM_8" / "AEAD_AES_256_CCM_8" / Please see more inline. >=20 > On 2015-02-09 23:58, Stephen Farrell wrote: >>=20 >> Hi Magnus, >>=20 >> On 09/02/15 12:05, Magnus Westerlund wrote: >>> Hi Stephen, >>>=20 >>> (as individual) >>> I also wished the WG was more active. >>=20 >> Yep, hard to evaluate consensus with so few commenting. >>=20 >> Thanks for the good analysis below, I'll respond here as I think >> that's better done in reverse order almost. >>=20 >> - aes-128 in any flavour is good enough, there's IMO no pressing >> need for aes-256 here >=20 > Despite that we have a definition for AES-256 for SRTP already and > personally I find it a bit difficult to throw away work for something = we > are likely to going to need in the future. Agreed. >=20 >> - gcm vs. ccm: those are functionally equivalent as far as this >> application is concerned I think - the only reason to have both >> is if one has to deal with systems that only support one and not >> the other; ccm is all that is available on some very constrained >> devices for essentially historical reasons and again I don't see >> why that is an issue here (it could be, but I don't recall anyone >> saying that it is - apologies if I've forgotten) Some other considerations: - CCM performs well on platforms that have AES acceleration, and it may = outperform GCM on those systems, if they don=92t have a good way to do = the multiply-and-accumulate for GCM - including both CCM and GCM allows for diversity of crypto mechanism = and implementation. =20 >=20 > Well, if I understand the security analysis then apparently CCM is = less > sensitive to a weak authentication, and could use the 64 bit > authentication tag, while GCM needs a stronger one. Thus, from that > perspective, if we at all are going to have a shorter authentication = tag > then 128 bits, then why not use the 64 bit CCM then as that is > significant saving, rather than only four bytes for the GCM. Exactly. CCM has more robust authentication at shorter tag sizes. = Many people (including John Mattson on this thread) point out that GCM = with 64-bit tags provides adequate security in realistic scenarios. = However, it is desirable to include CCM regardless, because CCM is = quantifiably better (I believe it has the strongest authentication of = any real world AEAD mode, actually) and because of the possibility that = 1) someone in the future will come up with an actual SRTP scenario in = which 64-bit authentication for GCM is inadequate, or 2) someone will = come up with a contrived scenario in which GCM authentication looks = inadequate. #2 may be more likely than #1, but in any case, we should = produce a standard that is future proof against either scenario. I hope that this makes sense. I regret that I do not have a lot of = time to devote to these issues at present; my main contributions to this = draft are several years old at this point. best, David >=20 >> - I tend to agree with you about the 192 label >>=20 >> If I were correct in the above then all that'd be really needed is >>=20 >> AEAD_AES_128_GCM =3D {TBD, TBD } >> AEAD_AES_128_GCM_12 =3D {TBD, TBD } >>=20 >> I'd argue that 2 options vs. 10 options may lead to overall >> better security and interop. as there will be many systems and >> libraries with less code and hence fewer bugs. (It's credible >> to argue that code size reduction might outweigh adding aes-256 >> in a case where you don't worry about ciphertext being secure >> for decades.) >=20 > I understand the desire to avoid proliferation here. I might not see = the > 256 bit keys in the same way. Make it clear that they are optional and > that anyone supporting AES-GCM MUST support 128-bit keys. But based on > the above reasoning if we are doing only AES-GCM then I rather see: >=20 > AEAD_AES_128_GCM =3D {TBD, TBD } > AEAD_AES_256_GCM =3D {TBD, TBD } >=20 > If we based on my above argumentation think we should provide a short > tag version then I think the set to define would become: >=20 > AEAD_AES_128_CCM =3D {TBD, TBD } > AEAD_AES_256_CCM =3D {TBD, TBD } > AEAD_AES_128_CCM_64 =3D {TBD, TBD } > AEAD_AES_256_CCM_64 =3D {TBD, TBD } >=20 > Using Martin's suggestion for being consistent in bits vs bytes. >=20 >>=20 >> If we continue to have so few folks engaging on this maybe the >> best way to handle it would be to talk about it on an IESG >> informal telechat if we can get you and David (and Russ) all >> on the call? (Or over a beer in Dallas I guess as that's also >> getting close and there a bunch of IESG calls coming up that >> are devotes to BoFs and the Dallas schedule.) >>=20 >=20 > Yes, unless we get more opinions now, I think the way forward is to go > that road so that we can conclude. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- David McGrew, PhD Cisco Fellow Office of the CTO, Security Business Group, Cisco Systems --Apple-Mail=_326575E8-3C14-4E7D-8DC3-C5055A9DBFB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Magnus,

On Feb 10, 2015, at 8:48 AM, Magnus = Westerlund <magnus.westerlund@ericsson.= com> wrote:

Hi,

I would definitely want the = authors to step in now and provide their
reasoning for why these = options have been = included.



because it = has been conventional practice for crypto standards to provide a variety = of security levels and a diversity of crypto mechanisms.   = Certainly this has been the case historically, and eight of the ten = ciphersuites have been in the draft ever since October 27, 2008, = when draft-mcgrew-srtp-aes-gcm-01 was first submitted.  There = was not any feedback that eight or ten was excessive until Stephen = raised his Discuss issue.  

My opinion is: = it would be best to preserve the existing specification and = implementation work, and retain all ten crypto suite definitions.   = But if we want to make SRTP-AEAD be the first instance in which the IETF = will  prioritize simplicity over variety and diversity, I=92m good = with that, because I certainly see the value of simplicity; then my = recommendation would be to eliminate the four 12-octet authentication = versions.  That would leave just six crypto suites, with two = different modes of operation, two different key sizes, and two different = tag lengths (but not all tag lengths for all modes), like = this:

      = srtp-crypto-suite-ext =3D "AEAD_AES_128_GCM"   =  /
              =                 = "AEAD_AES_256_GCM"    /
        =                     =   "AEAD_AES_128_CCM"    /
      =                     =     "AEAD_AES_256_CCM"    /
    =                     =       "AEAD_AES_128_CCM_8"  /
  =                     =         "AEAD_AES_256_CCM_8" =  /

Please see more = inline.


On 2015-02-09 23:58, Stephen = Farrell wrote:

Hi Magnus,

On = 09/02/15 12:05, Magnus Westerlund wrote:
Hi = Stephen,

(as individual)
I also wished the WG was more = active.

Yep, hard to evaluate consensus with so few = commenting.

Thanks for the good analysis below, I'll respond here = as I think
that's better done in reverse order almost.

- = aes-128 in any flavour is good enough, there's IMO no = pressing
 need for aes-256 here

Despite that = we have a definition for AES-256 for SRTP already and
personally I = find it a bit difficult to throw away work for something we
are = likely to going to need in the = future.

Agreed.


- = gcm vs. ccm: those are functionally equivalent as far as = this
 application is concerned I think - the only reason to have = both
 is if one has to deal with systems that only support one = and not
 the other; ccm is all that is available on some very = constrained
 devices for essentially historical reasons and = again I don't see
 why that is an issue here (it could be, but I = don't recall anyone
 saying that it is - apologies if I've = forgotten)

Some = other considerations:

- CCM performs well on = platforms that have AES acceleration, and it may outperform GCM on those = systems, if they don=92t have a good way to do the = multiply-and-accumulate for GCM

- including = both CCM and GCM allows for diversity of crypto mechanism and = implementation.  


Well, if I understand the security = analysis then apparently CCM is less
sensitive to a weak = authentication, and could use the 64 bit
authentication tag, while = GCM needs a stronger one. Thus, from that
perspective, if we at all = are going to have a shorter authentication tag
then 128 bits, then = why not use the 64 bit CCM then as that is
significant saving, rather = than only four bytes for the = GCM.

Exactly.   CCM has = more robust authentication at shorter tag sizes.   Many people = (including John Mattson on this thread) point out that GCM with 64-bit = tags provides adequate security in realistic scenarios.   However, = it is desirable to include CCM regardless, because CCM is quantifiably = better (I believe it has the strongest authentication of any real world = AEAD mode, actually) and because of the possibility that 1) someone in = the future will come up with an actual SRTP scenario in which 64-bit = authentication for GCM is inadequate, or 2) someone will come up with a = contrived scenario in which GCM authentication looks inadequate.   = #2 may be more likely than #1, but in any case, we should produce a = standard that is future proof against either = scenario.

I hope that this makes sense.   = I regret that I do not have a lot of time to devote to these issues at = present; my main contributions to this draft are several years old at = this = point.

best,

David
=

- I tend to agree with you about the = 192 label

If I were = correct in the above then all that'd be really needed = is

         AEAD_AES_1= 28_GCM    =3D {TBD, TBD = }
         AEAD_AES_128_GC= M_12 =3D {TBD, TBD }

I'd argue that 2 options vs. 10 options may = lead to overall
better security and interop. as there will be many = systems and
libraries with less code and hence fewer bugs. (It's = credible
to argue that code size reduction might outweigh adding = aes-256
in a case where you don't worry about ciphertext being = secure
for decades.)

I understand the desire to = avoid proliferation here. I might not see the
256 bit keys in the = same way. Make it clear that they are optional and
that anyone = supporting AES-GCM MUST support 128-bit keys. But based on
the above = reasoning if we are doing only AES-GCM then I rather = see:

          &n= bsp;AEAD_AES_128_GCM    =3D {TBD, TBD = }
           AEA= D_AES_256_GCM    =3D {TBD, TBD }

If we based on my = above argumentation think we should provide a short
tag version then = I think the set to define would = become:

        AEAD_AES_12= 8_CCM    =3D {TBD, TBD = }
        AEAD_AES_256_CCM =    =3D {TBD, TBD = }
        AEAD_AES_128_CCM_64 = =3D {TBD, TBD = }
        AEAD_AES_256_CCM_64 = =3D {TBD, TBD }

Using Martin's suggestion for being consistent in = bits vs bytes.


If we continue to = have so few folks engaging on this maybe the
best way to handle it = would be to talk about it on an IESG
informal telechat if we can get = you and David (and Russ) all
on the call? (Or over a beer in Dallas I = guess as that's also
getting close and there a bunch of IESG calls = coming up that
are devotes to BoFs and the Dallas = schedule.)


Yes, unless we get more opinions now, = I think the way forward is to go
that road so that we can = conclude.


Cheers

Magnus = Westerlund

--------------------------------------------------------= --------------
Services, Media and Network features, Ericsson = Research = EAB/TXM
---------------------------------------------------------------= -------
Ericsson AB =             &n= bsp;   | Phone  +46 10 7148287
F=E4r=F6gatan 6 =             &n= bsp;   | Mobile +46 73 0949079
SE-164 80 Stockholm, = Sweden | mailto: magnus.westerlund@ericsson.= com
---------------------------------------------------------------= -------


David = McGrew, PhD
Cisco Fellow
Office of the CTO, Security Business Group, = Cisco Systems





= --Apple-Mail=_326575E8-3C14-4E7D-8DC3-C5055A9DBFB4-- From nobody Mon Feb 16 00:13:39 2015 Return-Path: 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 7C2BF1A876A for ; Mon, 16 Feb 2015 00:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 RXzh4T6Xbo5D for ; Mon, 16 Feb 2015 00:13:31 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3409D1A876B for ; Mon, 16 Feb 2015 00:13:31 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-15-54e1a6a8c749 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 65.61.04231.8A6A1E45; Mon, 16 Feb 2015 09:13:29 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.210.2; Mon, 16 Feb 2015 09:13:28 +0100 Message-ID: <54E1A696.8020500@ericsson.com> Date: Mon, 16 Feb 2015 09:13:10 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Dale R. Worley" References: <87sietgfoe.fsf@hobgoblin.ariadne.com> In-Reply-To: <87sietgfoe.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje7KZQ9DDM7fZrSYfuYvo8XLnpXs FsdPNDFbvDxR5sDiMXn/V2aPL09eMnnsnHWX3WPJkp9MASxRXDYpqTmZZalF+nYJXBnP7/ey FUzirNjRvZGtgXErexcjJ4eEgInE6rdnGSFsMYkL99azdTFycQgJHGGUOH61gQnCWc4ocaBx IxtIFa+AtsSOg2+ZQWwWAVWJk3NWgnWzCVhI3PzRCFYjKhAssfj5U1aIekGJkzOfsHQxcnCI CGhKdCzIATGZBZwlzrwEu0FYwFFiyZkZYBOFBIwknrV3M4HYnALGEs1vTrKA2MwCBhJHFs1h hbDlJZq3zoaq15ZoaOpgncAoOAvJsllIWmYhaVnAyLyKUbQ4tbg4N93IWC+1KDO5uDg/Ty8v tWQTIzCkD275rbuDcfVrx0OMAhyMSjy8H1QehgixJpYVV+YeYpTmYFES57UzPhQiJJCeWJKa nZpakFoUX1Sak1p8iJGJg1OqgTGFXY9F+9TUKBk9lVv/7/w0YL21jV/85eJ+v08nfj64oXHV K0NMfN3nSvV/zowfJnwoXh0j0b5w7484jYcBlVclF4QVslTt+dRjXXBzDdOetcp1PAtYOn6/ 75t52rR25fQC9hThzCdfJVY8atU3LknM91IWzw7UO6Wh7fKOZffkQPePqdkXGpVYijMSDbWY i4oTAVPYuzZKAgAA Archived-At: Cc: juliusfriedman@gmail.com, avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC2435 (4094) X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:13:33 -0000 On 2015-01-30 03:34, Dale R. Worley wrote: > Magnus Westerlund writes: >> I need your input on this Errata. Should it be held for document update >> or Rejected? > > It's difficult to say because it's not clear (at least to me) what the > erratum is intended to do. I would need to see a more detailed > explanation of the error the erratum is intended to correct. > Hi, There has been some off-line discussion with Julius around RFC2435 where it becomes clear that he really like to have capabilities in the payload format that the current specification does not support. Therefore the decision is to reject this Errata. 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 ---------------------------------------------------------------------- From nobody Mon Feb 16 00:18:23 2015 Return-Path: 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 8800B1A1A67 for ; Mon, 16 Feb 2015 00:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 OAGYxSX_wq-k for ; Mon, 16 Feb 2015 00:18:19 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C49E1A875A for ; Mon, 16 Feb 2015 00:18:18 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-a0-54e1a7c8e8ab Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E7.54.04076.8C7A1E45; Mon, 16 Feb 2015 09:18:16 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Mon, 16 Feb 2015 09:18:15 +0100 Message-ID: <54E1A7C6.9070002@ericsson.com> Date: Mon, 16 Feb 2015 09:18:14 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julius Friedman , "Dale R. Worley" References: <54CA2EF3.2000108@ericsson.com> <87vbjpgfxl.fsf@hobgoblin.ariadne.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUyM+Jvje6J5Q9DDN5sF7GYfuYvo8XLnpXs FsdPNDFbvDxR5sDiMXn/V2aPL09eMnnsnHWX3WPJkp9MASxRXDYpqTmZZalF+nYJXBkTlj5n LDhlV/Frzj2WBsa5ml2MnBwSAiYS10+/ZIawxSQu3FvP1sXIxSEkcIRR4vTRB1DOckaJt9P3 M4FU8QpoS6z80c0KYrMIqErc/HiABcRmE7CQuPmjkQ3EFhUIllj8/CkrRL2gxMmZT8BqRATC JX4fOsYOYjMLqEvsWrIXzBYWcJRYMPMTM8Sy6YwSK59+A3I4ODgFAiVW7XMAMZkFNCXW79KH aJWXaN46G+xoIaBzGpo6WCcwCs5Csm0WQscsJB0LGJlXMYoWpxYX56YbGemlFmUmFxfn5+nl pZZsYgSG9MEtv612MB587niIUYCDUYmH94PKwxAh1sSy4srcQ4zSHCxK4rx2xodChATSE0tS s1NTC1KL4otKc1KLDzEycXBKNTC2K8zRu3E/z6xR+H30s/3H9bOuhelmHTxyU+hfcN3UzjPP dRV1xVRvXIk5/uO//ewDbLaXtN5FJUoJJiU0La57+EC16OTBjW73N55ziQ2USRT8xxw+Q3sx 12JNiyQ1/5k7RM6/fLPD7NIc3nVLN3ZPyNX7eaehhvWZruDhdxmr/td6bHO/vI5NiaU4I9FQ i7moOBEARsduzEoCAAA= Archived-At: Cc: avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC2435 (4095) X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:18:21 -0000 WG, My decision is to recommend to the AD that this is Rejected based on that the code change attempts to address handling images that the payload format can't support as currently specified. Instead a new update RTP payload specification that has extended functionality are needed to address this issue. Cheers Magnus Westerlund On 2015-01-30 03:35, Julius Friedman wrote: > Magnus has my input, I will also include it here in case I was > supposed to. > > Here is my input and explanation for 4095. > > The implementation I have is similar to the annex code I changed and > uses the number of components corresponding to those from the jpeg SOS > marker. > > The functionality was already hardcoded for two tables and the case of 1 > table all the data probably belongs to only the luma table but the table > class decided that. > > The function definition could be changed to give an array of each > components but I believe the maximum number of components is 4 anyway > and because its a 4 bit value i ignored it. > > This goes back to being compatible and why I opted to change the annex > the way I did. > > Cases of 0 and 1 table are now handled. > > Cases of 2 tables were previously handled (although if they use > different sizes tables without precision the given code will also fail > although im not sure this is typically seen as a table usually has > either 64 or 128 octets and the same number for each other table > generated. ) > > Cases of 3 also now handled. (With th above notion in mind about all > tables being the same length or requiring precision) > > Cases of 4 tables should also be handled in my opinion if they are not ; > but you can't have a value 4 there... > > I believe the code used the three tables to determine if there were any > more remaining but I may have omitted that code from the erratum. > > In short it may be beneficial to change the function definition to give > those components and their lengths; if that decision is made the result > will be easier to follow but I also defer there for your opinion. > > There is also a problem using the given standard table on progressive > encoded images. > > I have answered another question related to this here which may make > more sense. > > http://stackoverflow.com/questions/25662584/how-to-convert-a-jpeg-444-ycbcr-to-422-ycbcr/25676532#25676532 > > My code is which is working with this method is @ > http://net7mma.codeplex.com/SourceControl/latest#RtspServer/MediaTypes/RFC2435Media.cs > > The project also has a number of jpeg images to test on which fail in > the annex code, two of which are argb and cmyk. > > The latter two would require some custom sdp and the header or other > informat to be given explicitly there and it should be noted that I am > not arguing for those formats, just the ones allowed by the baseline > specification which includes progressive. > > I do however feel that any updates to the document should allow for any > jpeg, onvif does this differently and it may work looking at how they do > it to ensure compatible implementations are possible. > > http://www.onvif.org/specs/stream/ONVIF-Streaming-Spec-v210.pdf > > Thanks, > Julius > > Magnus Westerlund > writes: >> I would like to have your feedback on this errata. >> >> It appears to me that the code is hard coded for three components. That >> should be pretty evident for anyone reading the comments. >> >> So from that perspective Julius is correct that the code was not taking >> single component images into account. However, it is difficult to >> determine the intention here. > > The code change in the erratum is: > > --- says 2015-01-29 21:21:01.578501194 -0500 > +++ should-say 2015-01-29 21:20:32.139678733 -0500 > @@ -1,4 +1,4 @@ > -Section Appendix B says: > +It should say: > > int MakeHeaders(u_char *p, int type, int w, int h, u_char *lqt, > u_char *cqt, u_short dri) > @@ -12,7 +12,7 @@ > *p++ = 0xd8; /* SOI */ > > p = MakeQuantHeader(p, lqt, 0); > - p = MakeQuantHeader(p, cqt, 1); > + if(cqt != NULL) p = MakeQuantHeader(p, cqt, 1); > > if (dri != 0) > p = MakeDRIHeader(p, dri); > @@ -27,7 +27,7 @@ > *p++ = w >> 8; /* width msb */ > *p++ = w; /* wudth lsb */ > *p++ = 3; /* number of components */ > - *p++ = 0; /* comp 0 */ > + *p++ = 1; /* comp 1 */ > if (type == 0) > *p++ = 0x21; /* hsamp = 2, vsamp = 1 */ > else > @@ -47,6 +47,8 @@ > sizeof(lum_ac_codelens), > lum_ac_symbols, > sizeof(lum_ac_symbols), 0, 1); > + if(cqt != NULL) > + { > p = MakeHuffmanHeader(p, chm_dc_codelens, > sizeof(chm_dc_codelens), > chm_dc_symbols, > @@ -55,6 +57,7 @@ > sizeof(chm_ac_codelens), > chm_ac_symbols, > sizeof(chm_ac_symbols), 1, 1); > + } > > > > @@ -67,14 +70,14 @@ > *p++ = 0xff; > *p++ = 0xda; /* SOS */ > *p++ = 0; /* length msb */ > - *p++ = 12; /* length lsb */ > - *p++ = 3; /* 3 components */ > + *p++ = cqt != NULL ? 0x12 : 0x0b;/* length lsb */ > + *p++ = cqt != NULL ? 0x03 : 0x01;/* 3 components */ > *p++ = 0; /* comp 0 */ > *p++ = 0; /* huffman table 0 */ > - *p++ = 1; /* comp 1 */ > - *p++ = 0x11; /* huffman table 1 */ > - *p++ = 2; /* comp 2 */ > - *p++ = 0x11; /* huffman table 1 */ > + *p++ = 0x01; /* comp 1 */ > + *p++ = cqt != NULL ? 0x11 : 0x00;/* huffman table 1 */ > + if(cqt != NULL) *p++ = 2;/* comp 2 */ > + *p++ = cqt != NULL ? 0x11 : 0x00;/* huffman table 1 */ > *p++ = 0; /* first DCT coeff */ > *p++ = 63; /* last DCT coeff */ > *p++ = 0; /* sucessive approx. */ > > I don't understand the code, but it appears that the "should-say" code is > intended to work as the "says" code works when cqt is not NULL. > > However, this change is always operative: > > - *p++ = 0; /* comp 0 */ > + *p++ = 1; /* comp 1 */ > > And this change is peculiar, in that the first character assigned to p > changes from 12 to a choice between 18 (0x12) and 11 (0xB). I wonder if > 0x12 is intended to be 12? > > - *p++ = 12; /* length lsb */ > - *p++ = 3; /* 3 components */ > + *p++ = cqt != NULL ? 0x12 : 0x0b;/* length lsb */ > + *p++ = cqt != NULL ? 0x03 : 0x01;/* 3 components */ > > Dale -- 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 ---------------------------------------------------------------------- From nobody Mon Feb 16 00:19:53 2015 Return-Path: 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 882A71A876A for ; Mon, 16 Feb 2015 00:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 qz6tK3g_l8Yp for ; Mon, 16 Feb 2015 00:19:50 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2BF01A876B for ; Mon, 16 Feb 2015 00:19:49 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-4b-54e1a823065c Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0D.A2.04231.328A1E45; Mon, 16 Feb 2015 09:19:48 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.210.2; Mon, 16 Feb 2015 09:19:47 +0100 Message-ID: <54E1A823.2070906@ericsson.com> Date: Mon, 16 Feb 2015 09:19:47 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Frederick, Ron" References: <20140904164839.0F554180450@rfc-editor.org> <54C9048F.1000509@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+Jvja7KiochBmcnMlq87FnJbrH7Xyuz A5PHyxc3WT2WLPnJFMAUxWWTkpqTWZZapG+XwJXxflIbc8FcrYor7ywbGOcqdjFycEgImEhM 2JHVxcgJZIpJXLi3nq2LkYtDSOAIo8S8h3tZIZzljBLff/azgFTxCmhLTJnwgB3EZhFQldh7 aRojiM0mYCFx80cjG4gtKhAssfj5U1aIekGJkzOfgPWKCBhKHHm+ghVkMbOAosSkdkmQsLCA o8Si+2uZIXZ1M0p0v1oHNodTwEFi2ZXpYL3MAgYSRxbNYYWw5SWat85mBrGFgO5paOpgncAo OAvJullIWmYhaVnAyLyKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzBYD275rbuDcfVrx0OM AhyMSjy8H1QehgixJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gZFTaMndLzUFv2+fmuR5V6RwudJ67dS3EtGL+Sex/0ufqymx+uD5Peb5ma4y54ONw+5wzahW njdNmWHloo6/AuxXgudF/Z712mJF4KPZSxSi4/apXPqe9nLnRnbR8s6HJ7KiL87pKfAV7OeX CylblVpilsRc+8K+n/ey3v7Pdlfq7/E0rzkcrqHEUpyRaKjFXFScCADWtY+GNwIAAA== Archived-At: Cc: "avt@ietf.org" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC2435 (4097) X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:19:52 -0000 WG, My decision is to recommend Rejected to the AD. Cheers Magnus Westerlund On 2015-01-28 21:38, Frederick, Ron wrote: > I agree with this. Here are some other issues: > > - The “Original text” is actually wrong here. Both the width and height > in the original text have a maximum of 2040 pixels. I’m guessing that > the intent was to update this to 65535 for both width & height in the > corrected text, but that would have been wrong as well. If I understand > the proposal, the maximum supported value here would become 255*256, or > 65280 pixels. > > - I don’t understand how the receiving system is supposed to know > whether the divisor is 8 or 256. Perhaps the text in the “Notes” was > intended to somehow deal with this, but what’s proposed there doesn’t > make sense to me. I also don’t see how this could be done in a manner > which is backward compatible with existing clients. > > - Using a larger divisor also has another problem. It would be > impossible to represent image widths or heights greater than 2040 pixels > that were not a multiple of 8. While we already have an issue with not > being able to represent non-multiples of 8 in the current spec, that was > done with the expectation that the JPEG block size would generally > constrain images to 8x8, 16x8, or 16x16 size blocks, so that was not a > strong requirement. Requiring larger sizes to always be a multiple of > 256 seems like it would be much more problematic, and I think we need a > better solution for that. > > On Jan 28, 2015, at 7:47 AM, Magnus Westerlund > > > wrote: >> >> WG, >> >> My proposal is that this Errata is "Rejected" based on that its section >> of change does not contain any change. And the notes part proposed >> changed is a redefinition of a field, i.e. something that would require >> a replacement RFC to change. >> >> Please provide any comments by the 12th of February. >> >> Cheers >> >> Magnus Westerlund >> WG chair >> >> >> On 2014-09-04 18:48, RFC Errata System wrote: >>> The following errata report has been submitted for RFC2435, >>> "RTP Payload Format for JPEG-compressed Video". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=2435&eid=4097 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Julius Richard Friedman >>> >>> Section: 3.1.5 >>> >>> Original Text >>> ------------- >>> 3.1.5. Width: 8 bits >>> >>> This field encodes the width of the image in 8-pixel multiples (e.g., >>> a width of 40 denotes an image 320 pixels wide). The maximum width >>> is 2040 pixels. >>> >>> 3.1.6. Height: 8 bits >>> >>> This field encodes the height of the image in 8-pixel multiples >>> (e.g., a height of 30 denotes an image 240 pixels tall). When >>> encoding interlaced video, this is the height of a video field, since >>> fields are individually JPEG encoded. The maximum height is 65535 >>> pixels. >>> >>> Corrected Text >>> -------------- >>> 3.1.5. Width: 8 bits >>> >>> This field encodes the width of the image in 8-pixel multiples (e.g., >>> a width of 40 denotes an image 320 pixels wide). The maximum width >>> is 2040 pixels. >>> >>> 3.1.6. Height: 8 bits >>> >>> This field encodes the height of the image in 8-pixel multiples >>> (e.g., a height of 30 denotes an image 240 pixels tall). When >>> encoding interlaced video, this is the height of a video field, since >>> fields are individually JPEG encoded. The maximum height is 65535 >>> pixels. >>> >>> Notes >>> ----- >>> Use a divisor of 256 to determine the height, where 8 / 256 = 32. >>> >>> Ensure FragmentOffset does not exceed 2^24, if it does then use 2^24 >>> - value) >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC2435 (no draft string recorded) >>> -------------------------------------- >>> Title : RTP Payload Format for JPEG-compressed Video >>> Publication Date : October 1998 >>> Author(s) : L. Berc, W. Fenner, R. Frederick, S. McCanne, >>> P. Stewart >>> Category : PROPOSED STANDARD >>> Source : Audio/Video Transport >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG > -- > Ron Frederick > ronf@bluecoat.com > > > -- 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 ---------------------------------------------------------------------- From nobody Mon Feb 16 00:20:43 2015 Return-Path: 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 5439D1A876A for ; Mon, 16 Feb 2015 00:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 ezu6x5pTJgpR for ; Mon, 16 Feb 2015 00:20:38 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70791A1A67 for ; Mon, 16 Feb 2015 00:20:37 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-02-54e1a853e126 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A9.B4.04076.358A1E45; Mon, 16 Feb 2015 09:20:36 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.210.2; Mon, 16 Feb 2015 09:20:35 +0100 Message-ID: <54E1A853.8040405@ericsson.com> Date: Mon, 16 Feb 2015 09:20:35 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: References: <20140904152601.9343018001B@rfc-editor.org> <54CA305A.1040402@ericsson.com> In-Reply-To: <54CA305A.1040402@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+JvjW7IiochBpOeclq87FnJbnH8RBOz A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx/U03U8F0xYqnf9cwNzDOl+hi5OSQEDCR 2Dj/DhOELSZx4d56ti5GLg4hgSOMEucbV4ElhASWM0ocXKMCYvMKaEvseTuLEcRmEVCVeHbj PhuIzSZgIXHzRyOYLSoQLLH4+VNWiHpBiZMzn7CA2CICchK/HkH0MgsISZye8w2sRljAUeLG gwlQu8IlTh/+CGZzCuhINN27zwxRbyBxZNEcVghbXqJ562xmiHptiYamDtYJjIKzkKybhaRl FpKWBYzMqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECw/Xglt9WOxgPPnc8xCjAwajEw/tB 5WGIEGtiWXFl7iFGaQ4WJXFeO+NDIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY5fxfLP++ WPjC4cYL90Q2P1v1aFdt7N2FlgcWiRvxzP3mH99Waiqlerjop77v7xI5GaPTXGmas/Xqj7F9 1rlwf53pvkc5ldL9QU1F5ov7Jv8XMxfqyL3/eG5/Vn/tlqk9wZ0ZG+QuezevlVuu6u99O+ET Z2v0qdRtV7U/RfIs/yN83yl1SV2WEktxRqKhFnNRcSIADpLAKTgCAAA= Archived-At: Cc: avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC2435 (4096) X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:20:40 -0000 WG, My decision is to recommend REJECTED to the AD for this Errata. Cheers Magnus Westerlund On 2015-01-29 14:06, Magnus Westerlund wrote: > Julius, > > I would appreciate some clarification on the Errata. Is this an attempt > to raise a discussion around an improvement here, or something else? > > Because without clarification this Errata will be rejected as makes no > correction. > > /Magnus Westerlund > > > On 2014-09-04 17:26, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC2435, >> "RTP Payload Format for JPEG-compressed Video". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=2435&eid=4096 >> >> -------------------------------------- >> Type: Technical >> Reported by: Julius Richard Friedman >> >> Section: Discussion >> >> Original Text >> ------------- >> types component samp. fact. samp. fact. table number >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | 1 (Y) | 2 | 1 | 0 | >> | 0, 64 | 2 (U) | 1 | 1 | 1 | >> | | 3 (V) | 1 | 1 | 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | 1 (Y) | 2 | 2 | 0 | >> | 1, 65 | 2 (U) | 1 | 1 | 1 | >> | | 3 (V) | 1 | 1 | 1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Corrected Text >> -------------- >> TO BE DETERMINED >> >> Notes >> ----- >> types component samp. fact. samp. fact. table number >> FROM StartOf Frame (0xFFC0) >> >> Read Nf - Number of image components in frame >> >> if(Nf > 1) >> >> Read Each Component >> >> 0 1 2 3 4 5 6 7 >> +-+-+-+-+-+-+-+-+ >> | H | V | >> +-+-+-+-+-+-+-+-+ >> >> H: Horizontal sampling factor – Specifies the relationship between the component horizontal dimension >> and maximum image dimension X (see Jpeg Spec A.1.1); also specifies the number of horizontal data units of component >> Ci in each MCU, when more than one component is encoded in a scan. >> Vi: Vertical sampling factor – Specifies the relationship between the component vertical dimension and >> maximum image dimension Y (see Jpeg Spec A.1.1); also specifies the number of vertical data units of component Ci in >> each MCU, when more than one component is encoded in a scan. >> Tqi: Implied from the position in parsing >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC2435 (no draft string recorded) >> -------------------------------------- >> Title : RTP Payload Format for JPEG-compressed Video >> Publication Date : October 1998 >> Author(s) : L. Berc, W. Fenner, R. Frederick, S. McCanne, P. Stewart >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > -- 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 ---------------------------------------------------------------------- From nobody Mon Feb 16 00:22:11 2015 Return-Path: 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 7163F1A875A for ; Mon, 16 Feb 2015 00:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 fptIYNKhcTxE for ; Mon, 16 Feb 2015 00:22:08 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B690C1A1A67 for ; Mon, 16 Feb 2015 00:22:07 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-9b-54e1a8adb56e Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5F.F4.04076.DA8A1E45; Mon, 16 Feb 2015 09:22:06 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Mon, 16 Feb 2015 09:22:05 +0100 Message-ID: <54E1A8AD.7080302@ericsson.com> Date: Mon, 16 Feb 2015 09:22:05 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: References: <20141204014737.6282D181CD3@rfc-editor.org> <54C9039E.1080105@ericsson.com> In-Reply-To: <54C9039E.1080105@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvje66FQ9DDGa+YrWYfuYvo8XLnpXs FsdPNDE7MHt8efKSyWPnrLvsHkuW/GQKYI7isklJzcksSy3St0vgyjgz6yJLwU25inOnJ7A0 MLZIdDFyckgImEj0TJ/FBmGLSVy4tx7I5uIQEjjCKDH9yx4mCGc5o8Slj7fYQap4BbQl3s/5 wQxiswioSjzvuQHWzSZgIXHzRyOYLSoQLLH4+VNWiHpBiZMzn7CA2CIC4hIrG7eA2cwCehI7 7zeBzRQWcJRYvPQlI4gtJBAuMeFVP9gcTgEdibnT77BC1BtIHFk0B8qWl2jeOpsZol5boqGp g3UCo+AsJOtmIWmZhaRlASPzKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAID645bfVDsaD zx0PMQpwMCrx8H5QeRgixJpYVlyZe4hRmoNFSZzXzvhQiJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGOQJtSbqKl7oPGH3/lWPqWbjK2nPF44TO04knY+fwa0r99nm+Kbrhm+IFk8TgzZmv TKt8FS+tV9x6Tezwmu98hz7lH865aVFs8tIpQWy7m95uppQNfLkqTPbte6aWv7jM+2b72WWd 2vkqqvUnTQsmr3BiUu2vVE5WvibzQyM869+95P/nH75WYinOSDTUYi4qTgQARPzXyUMCAAA= Archived-At: Cc: juliusfriedman@gmail.com, avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3550 (4192) X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:22:10 -0000 WG, My decision is to recommend the AD to Reject this Errata. Cheers Magnus Westerlund On 2015-01-28 16:43, Magnus Westerlund wrote: > WG, > > There has been quite some discussion. There appear to be substantial > support for putting this Errata into the "Rejected" state. > > Any additional feedback, please provided it by the 12th of February. > > Cheers > > Magnus > > On 2014-12-04 02:47, RFC Errata System wrote: >> The following errata report has been submitted for RFC3550, >> "RTP: A Transport Protocol for Real-Time Applications". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3550&eid=4192 >> >> -------------------------------------- >> Type: Technical >> Reported by: Julius Friedman >> >> Section: 6.4.1 >> >> Original Text >> ------------- >> sender's octet count: 32 bits >> The total number of payload octets (i.e., not including header or >> padding) transmitted in RTP data packets by the sender since >> starting transmission up until the time this SR packet was >> generated. The count SHOULD be reset if the sender changes its >> SSRC identifier. This field can be used to estimate the average >> payload data rate. >> >> Corrected Text >> -------------- >> sender's octet count: 32 bits >> The total number of payload octets >> transmitted in RTP data packets by the sender since >> starting transmission up until the time this SR packet was >> generated. The count SHOULD be reset if the sender changes its >> SSRC identifier. This field can be used to estimate the average >> payload data rate. >> >> Notes >> ----- >> Where as payload octets is defined as the total number of data octets contained in a Rtp Packet minus the 12 Header octets for Rtp Packets. >> >> Padding octets as well as octets which occur in the contributing source list should also be included as they may differ on a per packet basis and would make the total calculation invalid. >> >> During TCP communication any application layer header should NOT be included in the total bytes count when including the header length. >> >> Any Rtcp packet counters should include the total length of the packet (header, padding and any other data). >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3550 (draft-ietf-avt-rtp-new-12) >> -------------------------------------- >> Title : RTP: A Transport Protocol for Real-Time Applications >> Publication Date : July 2003 >> Author(s) : H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson >> Category : DRAFT STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > > -- 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 ---------------------------------------------------------------------- From nobody Mon Feb 16 00:24:08 2015 Return-Path: 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 43B631A876F for ; Mon, 16 Feb 2015 00:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 w61Bbj35iswQ for ; Mon, 16 Feb 2015 00:24:03 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DE81A1A67 for ; Mon, 16 Feb 2015 00:24:02 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-2f-54e1a9201de5 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C4.21.04484.029A1E45; Mon, 16 Feb 2015 09:24:00 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.210.2; Mon, 16 Feb 2015 09:24:00 +0100 Message-ID: <54E1A91F.5030908@ericsson.com> Date: Mon, 16 Feb 2015 09:23:59 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: , , References: <20131111125230.63AF875E015@rfc-editor.org> <54C902B9.2000308@ericsson.com> In-Reply-To: <54C902B9.2000308@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvja7CyochBj932Fhcu9fPbvGyZyW7 xeU71xkt7szYwe7A4rFkyU8mj71bsjyOzT/H6HFuo3EASxSXTUpqTmZZapG+XQJXxurO36wF v0UrDl9qYm5gXC/YxcjJISFgInH5308WCFtM4sK99WxdjFwcQgJHGCUuzZwE5SxnlDjxcQ4r SBWvgLbEso4tQB0cHCwCqhK3L5aBhNkELCRu/mhkA7FFBYIlFj9/ClUuKHFy5hOwchEBb4lF 67RAwswCQhKn53wDKxEWcJT4su0tWKuQQLjEjxMvGUFsTgEdia6zh9kh6g0kjiyCuIBZQF6i eetsZoh6bYmGpg7WCYyCs5Bsm4WkZRaSlgWMzKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYx AgP64JbfBjsYXz53PMQowMGoxMP7QeVhiBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGOf3cAo/+dG0r8nLytFN5OFU+X/ijy9oB7/Yt8G/ddXWw58XXWq8 nbfM17Kk5wIPX7rfXa2Vhawb5CWfX9+Rd60/O+XXW5ZgdsGzE346P7pp2HSjk6VmmZtxl7D4 g5P1Sx2/pygZbZydni2nrrThX8+mC8aerUULitMe3H3y6u2SXtfvNZlnfJRYijMSDbWYi4oT AYSjUBRJAgAA Archived-At: Cc: avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3611 (3795) X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:24:06 -0000 WG, My decision is to recommend VERIFIED for this Errata. Cheers Magnus Westerlund On 2015-01-28 16:39, Magnus Westerlund wrote: > WG, > > Based on the discussion in the MMUSIC WG I draw the conclusion that this > Errata shall be Verified. > > Any comments on this, please provide them by the 12th of February. > > Cheers > > Magnus > > > On 2013-11-11 13:52, RFC Errata System wrote: >> The following errata report has been submitted for RFC3611, >> "RTP Control Protocol Extended Reports (RTCP XR)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3611&eid=3795 >> >> -------------------------------------- >> Type: Technical >> Reported by: Stephen James >> >> Section: 5.1 >> >> Original Text >> ------------- >> rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF >> >> Corrected Text >> -------------- >> rtcp-xr-attrib = "a=" "rtcp-xr" [ ":" xr-format *(SP xr-format)] CRLF >> >> Notes >> ----- >> The ABNF for the attribute is causing some interoperability issues. >> The text as written shows that the colon is required while the parameters are optional. >> This leaves the format: "a=rtcp-xr:" the required format. Vendors are using "a=rtcp-xr" which strictly violates the ABNF above. Moving the ':' into the optional part seems correct. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3611 (draft-ietf-avt-rtcp-report-extns-06) >> -------------------------------------- >> Title : RTP Control Protocol Extended Reports (RTCP XR) >> Publication Date : November 2003 >> Author(s) : T. Friedman, Ed., R. Caceres, Ed., A. Clark, Ed. >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> > > -- 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 ---------------------------------------------------------------------- From nobody Mon Feb 16 00:34:58 2015 Return-Path: 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 25F801A0222 for ; Mon, 16 Feb 2015 00:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 9zVxQa0R6Jna for ; Mon, 16 Feb 2015 00:34:55 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A320A1A00C5 for ; Mon, 16 Feb 2015 00:34:54 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-55-54e1abac34d3 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 57.83.04484.CABA1E45; Mon, 16 Feb 2015 09:34:52 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.210.2; Mon, 16 Feb 2015 09:34:52 +0100 Message-ID: <54E1AB9C.4000201@ericsson.com> Date: Mon, 16 Feb 2015 09:34:36 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: , , Alissa Cooper References: <20140422230255.290D61801A5@rfc-editor.org> <54C90022.2030307@ericsson.com> In-Reply-To: <54C90022.2030307@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvje6a1Q9DDB6+tbGYfuYvo8XLnpXs Fiten2O3uLrqD7sDi8eU3xtZPb48ecnksWTJTyaPyY/bmANYorhsUlJzMstSi/TtErgyrt3+ xVYwQ6ri0LULbA2Mb0S6GDk5JARMJPa+f8AGYYtJXLi3Hsjm4hASOMIocejEb3YIZzmjxJwv rcwgVbwC2hKb781nArFZBFQlNk3bCGazCVhI3PzRCDZJVCBYYvHzp6wQ9YISJ2c+YQGxRQQ8 Jaaub2cEsZkFhCROz/kGVMPBISzgKPFuhyJIWEggXOLP4a1grZwCOhLX12+GKjeQOLJoDiuE LS/RvHU2M0S9tkRDUwfrBEbBWUi2zULSMgtJywJG5lWMosWpxUm56UZGeqlFmcnFxfl5enmp JZsYgWF9cMtvgx2ML587HmIU4GBU4uH9oPIwRIg1say4MvcQozQHi5I4r53xoRAhgfTEktTs 1NSC1KL4otKc1OJDjEwcnFINjJP9zk7R/Hmu0pPtftp/hqwDemGSE1L2OVkvyTtSd/aDvdTT Ewvm590xltY9P5np/0S2rH0WtVOXsrRcyJDoi5hrJVKnytJzvLhnUXbwMg3+v4nlQmb7/r1l FgyR0Dw7sdCV8fhqbeMJTD2TRHnk9WtD3Vd+u7/2mZGr3sqn03bOW8NcvdSkXomlOCPRUIu5 qDgRABEv11xMAgAA Archived-At: Cc: avt@ietf.org Subject: Re: [AVTCORE] [Technical Errata Reported] RFC5764 (3971) X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:34:57 -0000 WG, I hereby decided that the WG's recommendation for this Errata is that it is VERIFIED. Cheers Magnus Westerlund On 2015-01-28 16:28, Magnus Westerlund wrote: > WG, EKR and David > > Without having any deep knowledge of TLS, this errata appears to be > correct and minor potential source of confusion. Thus, I would propose > that we put this on into "Verified" status. I would appreciate if EKR > could confirm this as being valid. > > WG, please provide feedback by the 12th of February. > > Cheers > > Magnus Westerlund > > > On 2014-04-23 01:02, RFC Errata System wrote: >> The following errata report has been submitted for RFC5764, >> "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=5764&eid=3971 >> >> -------------------------------------- >> Type: Technical >> Reported by: Martin Thomson >> >> Section: 4.1.3 >> >> Original Text >> ------------- >> If the client detects a nonzero-length MKI in the server's response >> that is different than the one the client offered, then the client >> MUST abort the handshake and SHOULD send an invalid_parameter alert. >> >> Corrected Text >> -------------- >> If the client detects a nonzero-length MKI in the server's response >> that is different than the one the client offered, then the client >> MUST abort the handshake and SHOULD send an illegal_parameter alert. >> >> Notes >> ----- >> invalid_parameter isn't defined anywhere; this probably means illegal_parameter(47), which is defined in RFC 5246. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5764 (draft-ietf-avt-dtls-srtp-07) >> -------------------------------------- >> Title : Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) >> Publication Date : May 2010 >> Author(s) : D. McGrew, E. Rescorla >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > > -- 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 ---------------------------------------------------------------------- From nobody Mon Feb 16 00:38:50 2015 Return-Path: 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 8A7B61A875C for ; Mon, 16 Feb 2015 00:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 xRBoc6m28Uy9 for ; Mon, 16 Feb 2015 00:38:46 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3D91A00C5 for ; Mon, 16 Feb 2015 00:38:45 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-63-54e1ac93381d Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.34.04484.39CA1E45; Mon, 16 Feb 2015 09:38:43 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.210.2; Mon, 16 Feb 2015 09:38:43 +0100 Message-ID: <54E1AC92.6030607@ericsson.com> Date: Mon, 16 Feb 2015 09:38:42 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Martin Thomson References: <7594FB04B1934943A5C02806D1A2204B1D2E53A6@ESESSMB209.ericsson.se> <536356B3.8010000@ericsson.com> <53673293.7030700@ericsson.com> <54CA2764.9040103@ericsson.com> <54CA27C3.2070708@ericsson.com> In-Reply-To: <54CA27C3.2070708@ericsson.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvje7kNQ9DDLoWqlq87FnJbnHtzD9G ByaPnbPusnssWfKTKYApissmJTUnsyy1SN8ugSvj/bHXzAXNihXb52xmamC8K9XFyMEhIWAi 8eAtexcjJ5ApJnHh3no2EFtI4AijxOQpRl2MXED2ckaJ5yv7WUASvALaEtcf9jGB9LIIqEq8 OVIJEmYTsJC4+aMRrFdUIFhi8fOnrBDlghInZz4BaxUR0JVYdPYBO0grs4CixKR2SZCwsIC1 xPT1X9khVl1nkri27RnYHE4BHYnnx/ZB1WtKrN+lDxJmFpCXaN46mxniTG2JhqYO1gmMgrOQ bJuF0DELSccCRuZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIFhenDLb4MdjC+fOx5iFOBg VOLh/aDyMESINbGsuDL3EKM0B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxq PR8Onfy/XP1ou+THb6fsD7wIv5qx0PRpwsm/H3csKrs0OeXsMt5cs7711rKhk18EqbXEz5NY Ef4pycGiOr22KeJTwOebVoX7HAyzLsxYt+Dk6Zs+OnM6dXY3GR0Mk2y6+7zCIO/1IknT+L7P Jcefxvs3ub9qOvDQd+XihUXpq1Z633iprvtZiaU4I9FQi7moOBEAbuu0cjQCAAA= Archived-At: Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Errata on RFC 5764 : Errata ID: 3913 X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:38:48 -0000 WG, I decided that the WG recommendation for this Errata is HELD FOR DOCUMENT UPDATE. The reason is that there is ongoing work both in AVTCORE (https://datatracker.ietf.org/doc/draft-petithuguenin-avtcore-rfc5764-mux-fixes/) and in TRAM WG (With TURN IANA rules) in regards to this Errata. Cheers Magnus Westerlund On 2015-01-29 13:29, Magnus Westerlund wrote: > Sorry, for confusing you. > > I already sent another email on this. Lets go with the previous emails > Held for Document Update. > > /Magnus > > On 2015-01-29 13:28, Magnus Westerlund wrote: >> WG, >> >> Based on this discussion it appears that the conclusion was to Reject >> this errata. We have ongoing document work that will address this issue, >> so approving it would be to get ahead of that work. Secondly, held for >> document update appears possible, but also unnecessary now that the work >> actually is happening. >> >> So this will be requested to be rejected by the AD, unless someone >> speaks up before the 13th of February. >> >> Cheers >> >> Magnus >> WG chair >> >> On 2014-05-05 08:41, Magnus Westerlund wrote: >>> On 2014-05-02 19:10, Martin Thomson wrote: >>>> On 2 May 2014 01:26, Magnus Westerlund wrote: >>>>> 1. To any in the WG: Do you really think there is an issue of >>>>> restricting STUN to 128 methods per class per existing RFC? >>>> >>>> This is an alternative to what I proposed, which would leave 5764 >>>> alone. You need to make some allowance for this though: >>>> http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml#stun-parameters-2 >>>> (Note the range 0x800-0xFFF, which is currently unused) >>> >>> >>> Yes, and from my personal position, I think it is fine to leave RFC 5764 >>> alone here. The 128 methods per class should be sufficient. >>> >>> But I do agree that we should work to ensure that these limitations are >>> reflected in STUN's IANA section. >>> >>>> >>>>> 2. To Martin: What made you think there was an error in RFC 5764? >>>> >>>> This: >>>> >>>>> Formally this is a value overlap between what STUN could potentially use >>>>> (0-63) and what DTLS can potentially use 20-63. >>>> >>>> I don't think that it's quite fair to say that it's a fault of STUN. >>>> STUN was there first, so arguably the fault lies with RFC 5764. >>> >>> Agreed, but it was a decision that was discussed in the community when >>> it happened. >>> >>>> >>>> As I said, it's a minor issue. There doesn't seem to be any need for >>>> the overlap, so it's probably safe to retroactively change the rules >>>> for STUN method registrations. >>>> >>> >>> I also think so. And, I think the minimal work needed here is to address >>> STUN's IANA rules within the TRAM WG, not also change values in RFC >>> 5764. Therefore I would like to reject this Errata. >>> >>> I will give everyone two weeks to think this over and object against my >>> proposal to reject the errata. >>> >>> 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 >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>> >> >> > > -- 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 ---------------------------------------------------------------------- From nobody Mon Feb 16 00:42:53 2015 Return-Path: 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 D35211A1A8B for ; Mon, 16 Feb 2015 00:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 ZkjhNbvVTVsi for ; Mon, 16 Feb 2015 00:42:48 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBDA1A00C5 for ; Mon, 16 Feb 2015 00:42:47 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-13-54e1ad85ec70 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7F.79.04076.58DA1E45; Mon, 16 Feb 2015 09:42:46 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.210.2; Mon, 16 Feb 2015 09:42:45 +0100 Message-ID: <54E1AD84.80805@ericsson.com> Date: Mon, 16 Feb 2015 09:42:44 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Alissa Cooper , Ben Campbell , Richard Barnes Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+JvjW7b2ochBitbmCymn/nLaPGyZyW7 xfzO0+wWU/tsHVg8vjx5yeSxZMlPJo/JG2exeMza+YQlgCWKyyYlNSezLLVI3y6BK2Ptu072 gja+iisHu5gaGPu4uxg5OSQETCRmf/rPDGGLSVy4t56ti5GLQ0jgCKPEs+alrCAJIYHljBIv j6l2MXJw8ApoStxuMQMJswioSpz7vQysl03AQuLmj0Y2EFtUIFhi8fOnYK28AoISJ2c+YQFp FRFIkXg0nREkzCygJDF36WuwVmEBQ4m/N/tZQUqYgaav36UPUSIv0bx1NjPEAdoSDU0drBMY +WchGToLoWMWko4FjMyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQKD8+CW31Y7GA8+dzzE KMDBqMTD+0HlYYgQa2JZcWXuIUZpDhYlcV4740MhQgLpiSWp2ampBalF8UWlOanFhxiZODil GhgN53fbLFB+NsW6n/dY89bfdccvrbAQ3vX2Y27TS6lO7e4y1iPcb53a32+tEFg2qySZZd2m G1Kb645l3NJ+soBjw4na2QleF0/uZ2icpMh4eJL4Ymn7EmnVG0afDp4Ilgr9uZRlU+z0WboF 8stkg0Uq8m33zwyWV1vjNedCCPuO6TFXVI5+n/tEiaU4I9FQi7moOBEAZO5fkC8CAAA= Archived-At: Cc: IETF AVTCore WG Subject: [AVTCORE] Summary of AVTCORE WG's Errata decisions X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:42:51 -0000 ADs, Here is a current summary of the Erratas that are in reported state for the AVT WG (AVTCORE has no reported Errata), including the WG's decisions on how handle them. RFC2435 (4094) Appendix A Technical avt (rai) Julius Richard Friedman 2014-09-04 WG decided that Errata 4094 is REJECTED. RFC2435 (4095) Appendix B Technical avt (rai) Julius Richard Friedman 2014-09-04 WG decided that Errata 4095 is REJECTED. RFC2435 (4096) Discussion Technical avt (rai) Julius Richard Friedman 2014-09-04 WG decided that Errata 4096 is REJECTED. RFC2435 (4097) 3.1.5 Technical avt (rai) Julius Richard Friedman 2014-09-04 WG decided that Errata 4097 is REJECTED. RFC3550 (4192) 6.4.1 Technical avt (rai) Julius Friedman 2014-12-03 WG decided that Errata 4192 is REJECTED. RFC3611 (3795) 5.1 Technical avt (rai) Stephen James 2013-11-11 WG decided that Errata 3795 is VERIFIED. RFC5764 (3913) 5.1.2 Technical avt (rai) Martin Thomson 2014-03-06 WG decided that Errata 3913 is Held for Document Update. RFC5764 (3971) 4.1.3 Technical avt (rai) Martin Thomson 2014-04-22 WG decided that Errata 3971 is VERIFIED. I hope the ADs concur with the WG assessment and can enter the Erratas into the appropriate state. 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 ---------------------------------------------------------------------- From nobody Mon Feb 16 00:51:58 2015 Return-Path: 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 D9F381A8775 for ; Mon, 16 Feb 2015 00:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 DeVACyEsLAYW for ; Mon, 16 Feb 2015 00:51:52 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A7F1A8777 for ; Mon, 16 Feb 2015 00:51:52 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id kx10so33781264pab.13 for ; Mon, 16 Feb 2015 00:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CSvZpCZWzmXOa2ASyUhlYZiYLNLuVD2+j8uzV17QYbs=; b=RwSwWtxEDYLafvCHhosauqOYWyc5LbRyMf0lez50S+FkaGYtPh7x1mF2TqGsPl8Nwv KREMAskbKsNhpp4QHpWL601lc3eXNsyY3kriJT1IkoxZbyB19LZkhGABkzjTS/ElfJhz foXz4/qelR2Ym/S1tg8NIal4SSP2mOg8P80McB+BxStK4hPjPwsv8byit2RhOBBvsrDu Y/vYwTaABzpJPO/lZe6fef3HHJjV+lmHkJBf2H/eNCd0X1YowfHUjUL28/TMlsfOwoow 3VJ6/9omdKeotKccHQO7+6BnL/TJb0ivq/XDNJ4nacBgQ1LmfctH/hrxuxblNtWUcS/I cssA== MIME-Version: 1.0 X-Received: by 10.70.128.15 with SMTP id nk15mr37386416pdb.121.1424076710921; Mon, 16 Feb 2015 00:51:50 -0800 (PST) Received: by 10.70.117.99 with HTTP; Mon, 16 Feb 2015 00:51:50 -0800 (PST) In-Reply-To: <54E1A696.8020500@ericsson.com> References: <87sietgfoe.fsf@hobgoblin.ariadne.com> <54E1A696.8020500@ericsson.com> Date: Mon, 16 Feb 2015 03:51:50 -0500 Message-ID: From: Julius Friedman To: Magnus Westerlund , "Frederick, Ron" , "Dale R. Worley" , alissa@cooperw.in, avt@ietf.org Content-Type: multipart/alternative; boundary=001a11c3d33c7cc9eb050f30b28a Archived-At: Subject: Re: [AVTCORE] [Technical Errata Reported] RFC2435 (4094) X-BeenThere: avt@ietf.org 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: Mon, 16 Feb 2015 08:51:56 -0000 --001a11c3d33c7cc9eb050f30b28a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you. And please, as per my final emails with Mr. Frederick, please do also see if there is a way to indicate somehow that progressive images would need to utilize a dynamic profile, the same for images which use components which are non incremental or do not start at 0. In short, the standard doesn't explicitly tell people that if you want to do things like that you must use a dynamic profile. Part of these desires I have came from the upset that the standard didn't specify a standard way to use dynamic profiles, therefore even if I did utilize a dynamic one the receiver would need to know how to handle the format and kind of defeats the purpose of having a standard in the first place. If RFC2435 had been implemented as a dynamic profile of RFC2035 then it possibly would have been easier to work around. RFC2435 also specifically states progressive DCT would be supported in the profile but unfortunately it cannot be supported unless a dynamic profile is used or the DCT used is compatible with the interlaced DCT (coefficient wise) making it a interlaced image anyway. I suppose even though the Quantization tables are not in the correct order that is because the RFC was only showing the tables, it would be up to someone to put them into the ZigZag order as per the JPEG spec. None the less, sorry for any confusion and I do appreciate your time. Thanks! On Mon, Feb 16, 2015 at 3:13 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > On 2015-01-30 03:34, Dale R. Worley wrote: > > Magnus Westerlund writes: > >> I need your input on this Errata. Should it be held for document updat= e > >> or Rejected? > > > > It's difficult to say because it's not clear (at least to me) what the > > erratum is intended to do. I would need to see a more detailed > > explanation of the error the erratum is intended to correct. > > > > Hi, > > There has been some off-line discussion with Julius around RFC2435 where > it becomes clear that he really like to have capabilities in the payload > format that the current specification does not support. > > Therefore the decision is to reject this Errata. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --001a11c3d33c7cc9eb050f30b28a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you.

And please, as per my final = emails with Mr. Frederick, please do also see if there is a way to indicate= somehow that progressive images would need to utilize a dynamic profile, t= he same for images which use components which are non incremental or do not= start at 0.

In short, the standard doesn'= ;t explicitly tell people that if you want to do things like that you must = use a dynamic profile.

Part of these desires I hav= e came from the upset that the standard didn't specify a standard way t= o use dynamic profiles, therefore even if I did utilize a dynamic one the r= eceiver would need to know how to handle the format and kind of defeats the= purpose of having a standard in the first place.

= If RFC2435 had been implemented as a dynamic profile of RFC2035 then it pos= sibly would have been easier to work around.

RFC24= 35 also specifically states progressive DCT would be supported in the profi= le but unfortunately it cannot be supported unless a dynamic profile is use= d or the DCT used is compatible with the interlaced DCT (coefficient wise) = making it a interlaced image anyway.

I suppose eve= n though the Quantization tables are not in the correct order that is becau= se the RFC was only showing the tables, it would be up to someone to put th= em into the ZigZag order as per the JPEG spec.

Non= e the less, sorry for any confusion and I do appreciate your time.

Thanks!


On Mon, Feb 16,= 2015 at 3:13 AM, Magnus Westerlund <magnus.westerlund@ericss= on.com> wrote:
On= 2015-01-30 03:34, Dale R. Worley wrote:
> Magnus Westerlund <magnus.westerlund@ericsson.com> writes:
>> I need your input on this Errata. Should it be held for document u= pdate
>> or Rejected?
>
> It's difficult to say because it's not clear (at least to me) = what the
> erratum is intended to do.=C2=A0 I would need to see a more detailed > explanation of the error the erratum is intended to correct.
>

Hi,

There has been some off-line discussion with Julius around RFC2435 where it becomes clear that he really like to have capabilities in the payload format that the current specification does not support.

Therefore the decision is to reject this Errata.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--001a11c3d33c7cc9eb050f30b28a-- From nobody Tue Feb 17 03:04:49 2015 Return-Path: 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 6DE0A1A879B; Tue, 17 Feb 2015 03:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=no 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 1oUjuUEKMV3t; Tue, 17 Feb 2015 03:04:41 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02E81A874E; Tue, 17 Feb 2015 03:04:40 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-80-54e320469f74 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F8.25.24955.64023E45; Tue, 17 Feb 2015 12:04:38 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Tue, 17 Feb 2015 12:04:38 +0100 Message-ID: <54E3202F.4050802@ericsson.com> Date: Tue, 17 Feb 2015 12:04:15 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprELMWRmVeSWpSXmKPExsUyM+Jvja6bwuMQg1kv9Sxe9qxkt5i6/DGL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgytp5bxFpwR6Ti78tG5gbGV/xdjJwcEgImEs2vb7FD 2GISF+6tZ+ti5OIQEjjCKPF203YmCGc5o8SXv1cYQap4BbQlJr1ZyQRiswioSnxr3QZmswlY SNz80cgGYgsJ6Ep09t8Hi4sKBEssfv6UFaJXUOLkzCcsILaIgLpE6+Y+sDizgJLE3KWvmbsY OTiEgeb3XHUHMZkFNCXW79KHqJCXaN46mxliurZEQ1MH6wRGgVlIhs5C6JiFpGMBI/MqRtHi 1OKk3HQjY73Uoszk4uL8PL281JJNjMBAPLjlt+oOxstvHA8xCnAwKvHwblj3KESINbGsuDL3 EKM0B4uSOK+d8aEQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYw6FRK1BsufH3B2tLB90VjZ LzWhw/jGW1OL3PjjcvcZ3l6PNPh1f83GVQHnrz6uzFVUeiI6X5Dl+ot9Uz/UT2LMMKzLdw/I vFr4anatZn3ngZm19R9ehHc7nFG+uXylJkuf9MIJAnsemGRKXl6rmp+ueVp2ceis7Kpw22tv jDlM5pt8mnQz6pESS3FGoqEWc1FxIgB9p7IUJQIAAA== Archived-At: Cc: IETF AVTCore WG Subject: [AVTCORE] RTP Retransmission, FID and BUNDLE X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "mmusic \(E-mail\)" List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 11:04:47 -0000 MMUSIC, (CC AVTCORE but please reply to MMUSIC only) In draft-ietf-avtcore-multi-media-rtp-session-06 we have the following open issue in Section 7.1: Open Issue: When using SDP to signal retransmission for one RTP session with multiple media types and one RTP session for the retransmission data will cause a situation where one will have multiple m= lines grouped using FID and the ones belonging to respective RTP session being grouped using BUNDLE. This usage might contradict both the FID semantics [RFC5888] and an assumption in the RTP retransmission specification [RFC4588]. What I understand the concern relates to the correct usage of FID to avoid breaking the semantics of FID when declaring an RTP session that would contain one audio, one video source bundled but a separate RTP session for the retransmission of both these media sources. Lets exemplify with what I believe is the only possible offer for this in regards to FID usage. SDP Offer (3) v=0 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com s= c=IN IP4 atlanta.example.com t=0 0 a=group:BUNDLE foo bar a=group:FID foo zoo a=group:FID bar zoo m=audio 10000 RTP/AVP 0 b=AS:200 a=mid:foo a=rtpmap:0 PCMU/8000 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid m=video 10000 RTP/AVP 31 b=AS:1000 a=mid:bar a=rtpmap:31 H261/90000 a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid m=application 40000 RTP/AVPF 99 100 a=rtpmap:99 rtx/90000 a=fmtp:99 apt=0;rtx-time=3000 a=rtpmap:100 rtx/90000 a=fmtp:199 apt=31;rtx-time=3000 a=mid:zoo I think the important aspect here is that one MUST use one FID line per m= line one groups with the retransmission session to avoid the FID MUST NOT have the same address that Roni brought up back in December. Have I missed any limitation or does the above example appear reasonable. If it does then we can write a small informational description about this into the multiple media types document. 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 ---------------------------------------------------------------------- From nobody Tue Feb 17 07:45:51 2015 Return-Path: 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 182FE1A8A51; Tue, 17 Feb 2015 07:45:50 -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 yUpPFjZOVE-n; Tue, 17 Feb 2015 07:45:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8261A1EE9; Tue, 17 Feb 2015 07:45:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217154548.10340.47552.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 07:45:48 -0800 Archived-At: Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-optimisation-05.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 15:45:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. Title : Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback Authors : Jonathan Lennox Magnus Westerlund Qin Wu Colin Perkins Filename : draft-ietf-avtcore-rtp-multi-stream-optimisation-05.txt Pages : 17 Date : 2015-02-17 Abstract: RTP allows multiple media streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optimisation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-optimisation-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-multi-stream-optimisation-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 17 07:52:48 2015 Return-Path: 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 6B2691A8A58 for ; Tue, 17 Feb 2015 07:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 SB8AtiSnxtjg for ; Tue, 17 Feb 2015 07:52:42 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C0B1A8A98 for ; Tue, 17 Feb 2015 07:52:41 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-76-54e363c7b62c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 27.19.04076.7C363E45; Tue, 17 Feb 2015 16:52:39 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.210.2; Tue, 17 Feb 2015 16:52:38 +0100 Message-ID: <54E363C6.8060108@ericsson.com> Date: Tue, 17 Feb 2015 16:52:38 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: References: <20150217154548.10340.47552.idtracker@ietfa.amsl.com> In-Reply-To: <20150217154548.10340.47552.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Rvd48uMQg7W7RCxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtd1w4LD4hXNzzIaGOcJdTFyckgImEhcXXSWGcIWk7hwbz0b iC0kcIRRovF5RhcjF5C9nFHi1tP3TCAJXgFtiUMnJoIVsQioSpzsWsoKYrMJWEjc/NEIFhcV CJZY/PwpK0S9oMTJmU9YQGwRASGJ6f0TwOYIC0RJfDvxkAlimaPEvZYnYL2cAk4Sqxa/AjuI WcBA4siiOawQtrxE89bZzBD12hINTR2sExgFZiFZMQtJyywkLQsYmVcxihanFhfnphsZ6aUW ZSYXF+fn6eWllmxiBIbfwS2/rXYwHnzueIhRgINRiYd3w7pHIUKsiWXFlbmHGKU5WJTEee2M D4UICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYEyrdWt4+ELqp+P7Ky+/KAVZGxh4zf2poKB1 6vrS1ZMFNzCInCw8p3aQf7lYMWfSFddDDPP5hKz7NFmKsq+9kD+q9TZkAnPdw1CdJ7ddmDze 6pzoUV8kYi/dmTb92qW6mTdvHd08S3va3Giudc80gld3vM94KHSo7mDndJWi33c+G8RzfOFb ZK/EUpyRaKjFXFScCAC1gMOgIAIAAA== Archived-At: Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-optimisation-05.txt X-BeenThere: avt@ietf.org 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: Tue, 17 Feb 2015 15:52:48 -0000 WG, This is a minor update of the draft. The changes can easily be seen in the diff. The major change is around the SDP signalling text in Section 3.6. Please review the draft. We authors think this is now very stable and needs author external eyes to determine if we have missed anything. Cheers Magnus On 2015-02-17 16:45, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Sending Multiple Media Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback > Authors : Jonathan Lennox > Magnus Westerlund > Qin Wu > Colin Perkins > Filename : draft-ietf-avtcore-rtp-multi-stream-optimisation-05.txt > Pages : 17 > Date : 2015-02-17 > > Abstract: > RTP allows multiple media streams to be sent in a single session, but > requires each Synchronisation Source (SSRC) to send RTCP reception > quality reports for every other SSRC visible in the session. This > causes the number of RTCP reception reports to grow with the number > of SSRCs, rather than the number of endpoints. In many cases most of > these RTCP reception reports are unnecessary, since all SSRCs of an > endpoint are co-located and see the same reception quality. This > memo defines a Reporting Group extension to RTCP to reduce the > reporting overhead in such scenarios. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream-optimisation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-optimisation-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-multi-stream-optimisation-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- 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 ---------------------------------------------------------------------- From nobody Tue Feb 17 12:43:22 2015 Return-Path: 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 B94A91A0097 for ; Tue, 17 Feb 2015 12:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 y2BrlRm08ywG for ; Tue, 17 Feb 2015 12:43:18 -0800 (PST) Received: from plsvl-mailgw-01.bluecoat.com (spf.bluecoat.com [199.91.133.11]) by ietfa.amsl.com (Postfix) with ESMTP id E98801A87C5 for ; Tue, 17 Feb 2015 12:42:14 -0800 (PST) Received: from pwsvl-exchts-06.internal.cacheflow.com (esxdev03.bluecoat.com [10.2.2.166]) by plsvl-mailgw-01.bluecoat.com (Postfix) with ESMTP id 749BE81A6D1; Tue, 17 Feb 2015 12:42:14 -0800 (PST) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by pwsvl-exchts-06.internal.cacheflow.com ([fe80::8554:761:8def:a2e1%12]) with mapi id 14.03.0123.003; Tue, 17 Feb 2015 12:42:14 -0800 From: "Frederick, Ron" To: Julius Friedman Thread-Topic: [AVTCORE] [Technical Errata Reported] RFC2435 (4094) Thread-Index: AQHQPDU53kDg45vfj0Gx4JNI3XxmLZzzjn8AgAAKzQCAAljPAA== Date: Tue, 17 Feb 2015 20:42:12 +0000 Message-ID: <893707E3-6213-405F-A245-604603FBA0F5@bluecoat.com> References: <87sietgfoe.fsf@hobgoblin.ariadne.com> <54E1A696.8020500@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="utf-8" Content-ID: <07D0404E13285D41A61F1AA5D6AC6A29@bluecoat.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "avt@ietf.org" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC2435 (4094) X-BeenThere: avt@ietf.org 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: Tue, 17 Feb 2015 20:43:20 -0000 SGkgSnVsaXVzLA0KDQpPbiBGZWIgMTYsIDIwMTUsIGF0IDEyOjUxIEFNLCBKdWxpdXMgRnJpZWRt YW4gPGp1bGl1c2ZyaWVkbWFuQGdtYWlsLmNvbT4gd3JvdGU6DQo+IEFuZCBwbGVhc2UsIGFzIHBl ciBteSBmaW5hbCBlbWFpbHMgd2l0aCBNci4gRnJlZGVyaWNrLCBwbGVhc2UgZG8gYWxzbyBzZWUg aWYgdGhlcmUgaXMgYSB3YXkgdG8gaW5kaWNhdGUgc29tZWhvdyB0aGF0IHByb2dyZXNzaXZlIGlt YWdlcyB3b3VsZCBuZWVkIHRvIHV0aWxpemUgYSBkeW5hbWljIHByb2ZpbGUsIHRoZSBzYW1lIGZv ciBpbWFnZXMgd2hpY2ggdXNlIGNvbXBvbmVudHMgd2hpY2ggYXJlIG5vbiBpbmNyZW1lbnRhbCBv ciBkbyBub3Qgc3RhcnQgYXQgMC4NCj4gDQo+IEluIHNob3J0LCB0aGUgc3RhbmRhcmQgZG9lc24n dCBleHBsaWNpdGx5IHRlbGwgcGVvcGxlIHRoYXQgaWYgeW91IHdhbnQgdG8gZG8gdGhpbmdzIGxp a2UgdGhhdCB5b3UgbXVzdCB1c2UgYSBkeW5hbWljIHByb2ZpbGUuDQoNCkRvIHlvdSBoYXZlIGEg c3VnZ2VzdGlvbiBmb3IgaG93IHRoZSB3b3JkaW5nIGNhbiBiZSBpbXByb3ZlZCBvbiB0aGlzIHBv aW50PyBUaGlzIGlzIGFjdHVhbGx5IHNwZWxsZWQgb3V0IGluIHRoZSBjdXJyZW50IFJGQ3MuIEZv ciBpbnN0YW5jZSwgaW4gUkZDIDI0MzUgc2VjdGlvbiAyLCB0aGVyZSBpcyB0aGUgZm9sbG93aW5n IHRleHQ6DQoNCiAgIFRvIG1heGltaXplIGludGVyb3BlcmFiaWxpdHkgYW1vbmcgaGFyZHdhcmUt YmFzZWQgY29kZWNzLCB3ZSBhc3N1bWUNCiAgIHRoZSBzZXF1ZW50aWFsIERDVCBvcGVyYXRpbmcg bW9kZSBbMSxBbm5leCBGXSBhbmQgcmVzdHJpY3QgdGhlIHNldCBvZg0KICAgcHJlZGVmaW5lZCBS VFAvSlBFRyAidHlwZSBjb2RlcyIgKGRlZmluZWQgYmVsb3cpIHRvIHNpbmdsZS1zY2FuLA0KICAg aW50ZXJsZWF2ZWQgaW1hZ2VzLiAgV2hpbGUgdGhpcyBpcyBtb3JlIHJlc3RyaWN0aXZlIHRoYW4g ZXZlbg0KICAgYmFzZWxpbmUgSlBFRywgbWFueSBoYXJkd2FyZSBpbXBsZW1lbnRhdGlvbiBmYWxs IHNob3J0IG9mIHRoZQ0KICAgYmFzZWxpbmUgc3BlY2lmaWNhdGlvbiAoZS5nLiwgbW9zdCBoYXJk d2FyZSBjYW5ub3QgZGVjb2RlIG5vbi0NCiAgIGludGVybGVhdmVkIHNjYW5zKS4NCg0KSW4gc2Vj dGlvbiA0LjEgaXQgdGhlbiBnb2VzIG9uIHRvIHNheToNCg0KICAgT2YgdGhlIGZpcnN0IGdyb3Vw IG9mIGZpeGVkIG1hcHBpbmdzLCB0eXBlcyAwIGFuZCAxIGFyZSBjdXJyZW50bHkNCiAgIGRlZmlu ZWQsIGFsb25nIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgdHlwZXMgNjQgYW5kIDY1IHRoYXQgaW5k aWNhdGUNCiAgIHRoZSBwcmVzZW5jZSBvZiByZXN0YXJ0IG1hcmtlcnMuICBUaGV5IGNvcnJlc3Bv bmQgdG8gYW4gYWJicmV2aWF0ZWQNCiAgIHRhYmxlLXNwZWNpZmljYXRpb24gaW5kaWNhdGluZyB0 aGUgIkJhc2VsaW5lIERDVCBzZXF1ZW50aWFsIiBtb2RlLA0KICAgOC1iaXQgc2FtcGxlcywgc3F1 YXJlIHBpeGVscywgdGhyZWUgY29tcG9uZW50cyBpbiB0aGUgWVVWIGNvbG9yDQogICBzcGFjZSwg c3RhbmRhcmQgSHVmZm1hbiB0YWJsZXMgYXMgZGVmaW5lZCBpbiBbMSwgQW5uZXggSy4zXSwgYW5k IGENCiAgIHNpbmdsZSBpbnRlcmxlYXZlZCBzY2FuIHdpdGggYSBzY2FuIGNvbXBvbmVudCBzZWxl Y3RvciBpbmRpY2F0aW5nDQogICBjb21wb25lbnRzIDEsIDIsIGFuZCAzIGluIHRoYXQgb3JkZXIu ICBUaGUgWSwgVSwgYW5kIFYgY29sb3IgcGxhbmVzDQogICBjb3JyZXNwb25kIHRvIGNvbXBvbmVu dCBudW1iZXJzIDEsIDIsIGFuZCAzLCByZXNwZWN0aXZlbHkuICBDb21wb25lbnQNCiAgIDEgKGku ZS4sIHRoZSBsdW1pbmFuY2UgcGxhbmUpIHVzZXMgSHVmZm1hbiB0YWJsZSBudW1iZXIgMCBhbmQN CiAgIHF1YW50aXphdGlvbiB0YWJsZSBudW1iZXIgMCAoZGVmaW5lZCBiZWxvdykgYW5kIGNvbXBv bmVudHMgMiBhbmQgMw0KICAgKGkuZS4sIHRoZSBjaHJvbWluYW5jZSBwbGFuZXMpIHVzZSBIdWZm bWFuIHRhYmxlIG51bWJlciAxIGFuZA0KICAgcXVhbnRpemF0aW9uIHRhYmxlIG51bWJlciAxIChk ZWZpbmVkIGJlbG93KS4NCg0KVGhpcyBzcGVjaWZpY2FsbHkgc3RhdGVzIHRoYXQgb25seSB0aGUg YmFzZWxpbmUgRENUIHNlcXVlbnRpYWwgbW9kZSBpcyBzdXBwb3J0ZWQgKHJ1bGluZyBvdXQgcHJv Z3Jlc3NpdmUgRENUIG1vZGUgd2hlbiB1c2luZyB0aGVzZSBwcmVkZWZpbmVkIHR5cGVzKSBhbmQg YWxzbyBzcGVjaWZpZXMgdGhlIGV4YWN0IHNldCBvZiBjb21wb25lbnRzLCB0aGVpciBudW1iZXJp bmcsIGFuZCB0aGUgbWFwcGluZyBmcm9tIHRoZW0gdG8gdGhlIGNvcnJlc3BvbmRpbmcgcXVhbnRp emF0aW9uIGFuZCBIdWZmbWFuIHRhYmxlcy4NCg0KPiBQYXJ0IG9mIHRoZXNlIGRlc2lyZXMgSSBo YXZlIGNhbWUgZnJvbSB0aGUgdXBzZXQgdGhhdCB0aGUgc3RhbmRhcmQgZGlkbid0IHNwZWNpZnkg YSBzdGFuZGFyZCB3YXkgdG8gdXNlIGR5bmFtaWMgcHJvZmlsZXMsIHRoZXJlZm9yZSBldmVuIGlm IEkgZGlkIHV0aWxpemUgYSBkeW5hbWljIG9uZSB0aGUgcmVjZWl2ZXIgd291bGQgbmVlZCB0byBr bm93IGhvdyB0byBoYW5kbGUgdGhlIGZvcm1hdCBhbmQga2luZCBvZiBkZWZlYXRzIHRoZSBwdXJw b3NlIG9mIGhhdmluZyBhIHN0YW5kYXJkIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KVGhpcyBpcyB0 aGUgcmVzcG9uc2liaWxpdHkgb2YgYSBzZXNzaW9uIHNldHVwIHByb3RvY29sLCBhcyBjb3ZlcmVk IGluIHRoZSBsYXN0IHNlbnRlbmNlIG9mIHNlY3Rpb24gMy4xLjM6DQoNCiAgIFRoZSB0eXBlIGZp ZWxkIHNwZWNpZmllcyB0aGUgaW5mb3JtYXRpb24gdGhhdCB3b3VsZCBvdGhlcndpc2UgYmUNCiAg IHByZXNlbnQgaW4gYSBKUEVHIGFiYnJldmlhdGVkIHRhYmxlLXNwZWNpZmljYXRpb24gYXMgd2Vs bCBhcyB0aGUNCiAgIGFkZGl0aW9uYWwgSkZJRi1zdHlsZSBwYXJhbWV0ZXJzIG5vdCBkZWZpbmVk IGJ5IEpQRUcuICBUeXBlcyAwLTYzIGFyZQ0KICAgcmVzZXJ2ZWQgYXMgZml4ZWQsIHdlbGwta25v d24gbWFwcGluZ3MgdG8gYmUgZGVmaW5lZCBieSB0aGlzIGRvY3VtZW50DQogICBhbmQgZnV0dXJl IHJldmlzaW9ucyBvZiB0aGlzIGRvY3VtZW50LiAgVHlwZXMgNjQtMTI3IGFyZSB0aGUgc2FtZSBh cw0KICAgdHlwZXMgMC02MywgZXhjZXB0IHRoYXQgcmVzdGFydCBtYXJrZXJzIGFyZSBwcmVzZW50 IGluIHRoZSBKUEVHIGRhdGENCiAgIGFuZCBhIFJlc3RhcnQgTWFya2VyIGhlYWRlciBhcHBlYXJz IGltbWVkaWF0ZWx5IGZvbGxvd2luZyB0aGUgbWFpbg0KICAgSlBFRyBoZWFkZXIuICBUeXBlcyAx MjgtMjU1IGFyZSBmcmVlIHRvIGJlIGR5bmFtaWNhbGx5IGRlZmluZWQgYnkgYQ0KICAgc2Vzc2lv biBzZXR1cCBwcm90b2NvbCAod2hpY2ggaXMgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50KS4NCg0KPiBSRkMyNDM1IGFsc28gc3BlY2lmaWNhbGx5IHN0YXRlcyBwcm9ncmVzc2l2ZSBE Q1Qgd291bGQgYmUgc3VwcG9ydGVkIGluIHRoZSBwcm9maWxlIGJ1dCB1bmZvcnR1bmF0ZWx5IGl0 IGNhbm5vdCBiZSBzdXBwb3J0ZWQgdW5sZXNzIGEgZHluYW1pYyBwcm9maWxlIGlzIHVzZWQgb3Ig dGhlIERDVCB1c2VkIGlzIGNvbXBhdGlibGUgd2l0aCB0aGUgaW50ZXJsYWNlZCBEQ1QgKGNvZWZm aWNpZW50IHdpc2UpIG1ha2luZyBpdCBhIGludGVybGFjZWQgaW1hZ2UgYW55d2F5Lg0KDQpXZSBk aXNjdXNzZWQgdGhpcyBpbiBvdXIgZWFybGllciBlLW1haWwgZXhjaGFuZ2UuIFRoZSByZWZlcmVu Y2VzIGluIFJGQyAyNDM1IGFyZSB0byB0aGUgcHJlLWRlZmluZWQgdHlwZXMgc3VwcG9ydCDigJxw cm9ncmVzc2l2ZWx5IHNjYW5uZWTigJ0gaW1hZ2UgZGF0YSwgd2hpY2ggaXMgZGlmZmVyZW50IGZy b20gc3VwcG9ydCBmb3IgcHJvZ3Jlc3NpdmUgRENUIG1vZGUuIEJvdGggcHJvZ3Jlc3NpdmUgYW5k IGludGVybGFjZWQgaW1hZ2VzIGFyZSBzdXBwb3J0ZWQsIGJ1dCB0aGUgY29ycmVzcG9uZGluZyBm cmFtZXMgb3IgaW50ZXJsYWNlZCBmaWVsZHMgYXJlIGVuY29kZWQgaW5kZXBlbmRlbnRseSwgZWFj aCBhcyBhbiBlbnRyb3B5LWNvZGVkIHNlZ21lbnQgY29udGFpbmluZyBhIHNpbmdsZSBKUEVHIHNj YW4gdXNpbmcgYSBzdWJzZXQgb2YgdGhlIGJhc2VsaW5lIHNlcXVlbnRpYWwgRENUIG1vZGUuDQoN Cj4gSSBzdXBwb3NlIGV2ZW4gdGhvdWdoIHRoZSBRdWFudGl6YXRpb24gdGFibGVzIGFyZSBub3Qg aW4gdGhlIGNvcnJlY3Qgb3JkZXIgdGhhdCBpcyBiZWNhdXNlIHRoZSBSRkMgd2FzIG9ubHkgc2hv d2luZyB0aGUgdGFibGVzLCBpdCB3b3VsZCBiZSB1cCB0byBzb21lb25lIHRvIHB1dCB0aGVtIGlu dG8gdGhlIFppZ1phZyBvcmRlciBhcyBwZXIgdGhlIEpQRUcgc3BlYy4NCg0KSSB0b29rIGEgY2xv c2VyIGxvb2sgYXQgdGhlIHNhbXBsZSBjb2RlIGhlcmUsIGFuZCB0aGUgU2VuZEZyYW1lKCkgZnVu Y3Rpb24gdGhhdCByZWZlcnMgdG8gdGhlc2UgcXVhbnRpemF0aW9uIHRhYmxlcyBpcyBzaG93aW5n IGFuIGV4YW1wbGUgb2YgaG93IHRvIGZvcm1hdCB0aGUgUlRQIGhlYWRlciBkYXRhIGluIHRoZSBj YXNlIHdoZXJlIGEgZHluYW1pYyBRIHZhbHVlIGlzIHVzZWQgdGhhdCByZXF1aXJlcyB0aGF0IHRo ZSB0YWJsZXMgYmUgdHJhbnNtaXR0ZWQgZXhwbGljaXRseS4gSW4gUlRQLCB0aGUgcXVhbnRpemF0 aW9uIHRhYmxlIGRhdGEgaXMgTk9UIHNlbnQgaW4gemlnLXphZyBvcmRlciwgc28gSSBiZWxpZXZl IHRoZSBzYW1wbGUgY29kZSBoZXJlIGlzIGNvcnJlY3QuIElmIHlvdSBoYXZlIGEgY3VzdG9tIHF1 YW50aXphdGlvbiB0YWJsZSBjb21pbmcgZnJvbSBhbm90aGVyIHNvdXJjZSB3aGljaCBpcyBhbHJl YWR5IGluIHppZy16YWcgb3JkZXIsIHRoaXMgd291bGQgbmVlZCB0byBiZSB1bi1kb25lIGJlZm9y ZSBpdCBpcyBlbmNvZGVkIGluIHRoZSBSVFAgSlBFRyBwYWNrZXQgYXMgaW4tYmFuZCBkYXRhLg0K LS0gDQpSb24gRnJlZGVyaWNrDQpyb25mQGJsdWVjb2F0LmNvbQ0KDQoNCg0K From nobody Tue Feb 17 14:37:07 2015 Return-Path: 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 6DFEC1A87E4 for ; Tue, 17 Feb 2015 14:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 8lrVy6kaS2UW for ; Tue, 17 Feb 2015 14:37:06 -0800 (PST) Received: from plsvl-mailgw-02.bluecoat.com (plsvl-mailgw-02.bluecoat.com [199.91.133.12]) by ietfa.amsl.com (Postfix) with ESMTP id EE7461A1AB5 for ; Tue, 17 Feb 2015 14:37:05 -0800 (PST) Received: from pwsvl-exchts-04.internal.cacheflow.com (esxprd03.bluecoat.com [10.2.2.162]) by plsvl-mailgw-02.bluecoat.com (Postfix) with ESMTP id A032920127; Tue, 17 Feb 2015 14:37:05 -0800 (PST) Received: from pwsvl-excmbx-05.internal.cacheflow.com ([fe80::f848:d461:9aa9:59a8]) by pwsvl-exchts-04.internal.cacheflow.com ([fe80::9403:6f39:feac:adb1%12]) with mapi id 14.03.0123.003; Tue, 17 Feb 2015 14:37:05 -0800 From: "Frederick, Ron" To: Julius Friedman Thread-Topic: [AVTCORE] [Technical Errata Reported] RFC2435 (4094) Thread-Index: AQHQPDU53kDg45vfj0Gx4JNI3XxmLZzzjn8AgAAKzQCAAljPAIAAIBaA Date: Tue, 17 Feb 2015 22:37:03 +0000 Message-ID: References: <87sietgfoe.fsf@hobgoblin.ariadne.com> <54E1A696.8020500@ericsson.com> <893707E3-6213-405F-A245-604603FBA0F5@bluecoat.com> In-Reply-To: <893707E3-6213-405F-A245-604603FBA0F5@bluecoat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.2.2.106] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "avt@ietf.org" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC2435 (4094) X-BeenThere: avt@ietf.org 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: Tue, 17 Feb 2015 22:37:07 -0000 Sorry - a correction to the final point below in my previous reply: On Feb 17, 2015, at 12:42 PM, Frederick, Ron w= rote: >> I suppose even though the Quantization tables are not in the correct ord= er that is because the RFC was only showing the tables, it would be up to s= omeone to put them into the ZigZag order as per the JPEG spec. >=20 > I took a closer look at the sample code here, and the SendFrame() functio= n that refers to these quantization tables is showing an example of how to = format the RTP header data in the case where a dynamic Q value is used that= requires that the tables be transmitted explicitly. In RTP, the quantizati= on table data is NOT sent in zig-zag order, so I believe the sample code he= re is correct. If you have a custom quantization table coming from another = source which is already in zig-zag order, this would need to be un-done bef= ore it is encoded in the RTP JPEG packet as in-band data. I was wrong about this. Section 3.1.8 does specify zig-zag order for these = coefficients. So, while the code in Appendix A is not wrong by itself, the = reference in Appendix B that suggests that the lqt & cqt parameters passed = into it can be created using MakeTables() is not correct with its tables be= ing in non zig-zag order and no re-ordering being applied before these tabl= es are copied into the SOI segment. Having MakeTables() in Appendix A produce a table which is already in zig-z= ag order is probably the simplest fix. --=20 Ron Frederick ronf@bluecoat.com From nobody Thu Feb 19 00:06:15 2015 Return-Path: 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 4915C1A88D4 for ; Thu, 19 Feb 2015 00:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 X4QlkEPycTlf for ; Thu, 19 Feb 2015 00:06:12 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D4AA1A88D2 for ; Thu, 19 Feb 2015 00:06:12 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-c5-54e59971fcb5 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 20.CB.24955.17995E45; Thu, 19 Feb 2015 09:06:09 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.210.2; Thu, 19 Feb 2015 09:06:09 +0100 Message-ID: <54E59970.6040804@ericsson.com> Date: Thu, 19 Feb 2015 09:06:08 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Colin Perkins , , IETF AVTCore WG Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGfG3Rrdw5tMQg9O3rC1e9qxkt1j+8gSj xYwTHA7MHmeXTWXymHb/PpvHkiU/mQKYo7hsUlJzMstSi/TtErgypqy9zFrQwVfxfMZqxgbG +dxdjJwcEgImEkc/v2SGsMUkLtxbz9bFyMUhJHCEUWLqoV8sEM5yRokVt84xdjFycPAKaEv8 nZQGYrIIqEpMPpoP0ssmYCFx80cjG4gtKhAssfj5U1YQm1dAUOLkzCcsILaIQJzEhkmbwOLC Ak4Se6d8ZwexmQUMJI4smsMKYctLNG+dDXaPENCmhqYO1gmMfLOQjJqFpGUWkpYFjMyrGEWL U4uTctONjPVSizKTi4vz8/TyUks2MQLD7uCW36o7GC+/cTzEKMDBqMTD+6HzaYgQa2JZcWXu IUZpDhYlcV4740MhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgrZza/4eTK/hVn9+N04n1T yazedftP/1pxIvV9Fd/uma1997Urejav1vE67XHD86TDlE3HG44422o8/ny1vvNX5Vabg2Ya XmLlV1d5yois7mv+5nzEMP1WYOKX88n/jx3jaFGOYmjLKKpVMVU+9Sr7mHDsBn3PwP2H46W3 2q59dtHS4cedTx+VWIozEg21mIuKEwF0Hx6ZHAIAAA== Archived-At: Subject: [AVTCORE] My comments on draft-ietf-avtcore-rtp-circuit-breakers-08 X-BeenThere: avt@ietf.org 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, 19 Feb 2015 08:06:14 -0000 Hi, I have just reviewed the latest version of circuit breakers and have the following feedback. I think the document has improved since I last reviewed it (-05) but I think the following issue is not yet addressed from my previous review. > 7) Section 5: > > As there is a difference between CB #1 and #3 and #2 that has to do > with that the first (#1 and #3) uses incoming RTCP reports and that #2 > uses the CB implementers estimate of what the regular reporting > interval is. Thus, I wonder if there needs to exist include a > reflection over t_rr_int as well as the RTCP SSRC timeout calculation > that we recommend to use 5 seconds as fixed minimal value in those > calculations (if 5 sec larger than t_rr_int). I will see if I can propose some text to address this. I also think there is need for scaling the number of reporting intervals it takes to trigger the circuit breakers when using AVPF or reduced minimum. Especially for AVPF there will be a lot of false triggering due to relatively short time intervals that the circuit breakers will sample over. I would really like to have proposals for all open issues in the draft prior to the upcoming meetings deadline. I really like to be able to have this go to WG last call soon after the Dallas meeting. 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 ---------------------------------------------------------------------- From nobody Thu Feb 19 02:16:19 2015 Return-Path: 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 7027B1A8A6B for ; Thu, 19 Feb 2015 02:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7, TVD_FROM_1=0.999, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 HVOLYINJJYjk for ; Thu, 19 Feb 2015 02:16:17 -0800 (PST) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) (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 DC17E1A8A4F for ; Thu, 19 Feb 2015 02:16:17 -0800 (PST) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.9/8.14.9) with ESMTP id t1JAG5YC046096; Thu, 19 Feb 2015 02:16:06 -0800 (PST) (envelope-from finlayson@live555.com) Content-Type: multipart/alternative; boundary="Apple-Mail=_D291B11D-AD21-4D3A-80B0-783DD940CBEE" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ross Finlayson In-Reply-To: <54E1AD84.80805@ericsson.com> Date: Thu, 19 Feb 2015 23:16:05 +1300 Message-Id: References: <54E1AD84.80805@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: avt@ietf.org Subject: Re: [AVTCORE] Summary of AVTCORE WG's Errata decisions X-BeenThere: avt@ietf.org 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, 19 Feb 2015 10:16:19 -0000 --Apple-Mail=_D291B11D-AD21-4D3A-80B0-783DD940CBEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 16, 2015, at 9:42 PM, Magnus Westerlund = > = wrote: >=20 > ADs, >=20 > Here is a current summary of the Erratas that are in reported state = for > the AVT WG (AVTCORE has no reported Errata) FYI, last August I reported a minor bug (email copied below) in RFC 3711 = (SRTP). IMHO, this should be added to the RFC 3711 errata at some = point... > Begin forwarded message: >=20 > From: Ross Finlayson > > Subject: Minor bug in RFC 3711 (SRTP), FYI > Date: August 10, 2014 at 5:57:22 PM GMT+12 > Cc: avt@ietf.org > To: mbaugher@cisco.com , = elisabetta.carrara@ericsson.com = , mcgrew@cisco.com = , mats.naslund@ericsson.com = , karl.norrman@ericsson.com = >=20 > In section 3.4 ("Secure RTCP"), there is a bug in "Figure 2. An = example of the format of a Secure RTCP packet..." >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ > |V=3D2|P| RC | PT=3DSR or RR | length = | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = | >=20 > The boundary between the "PT=3DSR or RR" and the "length" fields is = wrong: The boundary is shown as being between bits 16 and 17; it should = be between bits 15 and 16. I.e., the "PT=3DSR or RR" field should be 8 = bits long, not 9. >=20 > This is just a minor bug, because the equivalent diagram in RFC 3550 = (the normative reference for RTCP) is correct. Nonetheless, this bug = should probably be added to the errata for RFC 3711 >=20 > Ross Finlayson > Live Networks, Inc. > http://www.live555.com/ --Apple-Mail=_D291B11D-AD21-4D3A-80B0-783DD940CBEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 16, 2015, at 9:42 PM, = Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:

ADs,
Here is a current summary of the Erratas that are in = reported state for
the AVT WG (AVTCORE has no reported = Errata)

FYI, last = August I reported a minor bug (email copied below) in RFC 3711 (SRTP). =  IMHO, this should be added to the RFC 3711 errata at some = point...



Begin forwarded = message:

From: Ross Finlayson <finlayson@live555.com>
Subject: Minor bug in RFC 3711 (SRTP), = FYI
Date: August 10, 2014 at 5:57:22 PM GMT+12
Cc: avt@ietf.org
To: mbaugher@cisco.com, elisabetta.carrara@ericsson.com, mcgrew@cisco.com, mats.naslund@ericsson.com, karl.norrman@ericsson.com

In section 3.4 ("Secure RTCP"), there is a bug in = "Figure 2. An example of the format of a Secure RTCP packet..."

  =     0                 =   1                   = 2                   = 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= ;+
     |V=3D2|P|    RC =   |   PT=3DSR or RR   |         =     length          | |
    =  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |

The = boundary between the "PT=3DSR or RR" and the "length" fields is wrong: = The boundary is shown as being between bits 16 and 17; it should be = between bits 15 and 16.  I.e., the "PT=3DSR or RR" field should be = 8 bits long, not 9.

This is just a minor bug, because the equivalent diagram in = RFC 3550 (the normative reference for RTCP) is correct. =  Nonetheless, this bug should probably be added to the errata for = RFC 3711

Ross Finlayson
Live = Networks, Inc.
http://www.live555.com/


= --Apple-Mail=_D291B11D-AD21-4D3A-80B0-783DD940CBEE-- From nobody Thu Feb 19 07:03:53 2015 Return-Path: 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 73D1D1A906E for ; Thu, 19 Feb 2015 07:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 G8x0xZI6ceYA for ; Thu, 19 Feb 2015 07:03:45 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7311A8901 for ; Thu, 19 Feb 2015 07:02:43 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-ec-54e5fb100def Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D0.8A.24955.01BF5E45; Thu, 19 Feb 2015 16:02:41 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.210.2; Thu, 19 Feb 2015 16:02:40 +0100 Message-ID: <54E5FB10.2030209@ericsson.com> Date: Thu, 19 Feb 2015 16:02:40 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: IETF AVTCore WG , "Paul E. Jones" , , "David Benham (dbenham)" Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvja7g76chBofWcVi87FnJbnHm1zwm i1Un/rFanL+wgcmBxWPK742sHkuW/GTyaNh3lD2AOYrLJiU1J7MstUjfLoErY++et+wFzUoV cy+0sTUwXpTuYuTkkBAwkfjRupUdwhaTuHBvPVsXIxeHkMARRol3s7axQjjLGSX+/n3NBFLF K6AtsWv+E1YQm0VAVWJdzxEWEJtNwELi5o9GNhBbVCBYYvHzp6wQ9YISJ2c+YQEZJCIwgVHi dednsISwQKDEm5XbgFZzcDALaEqs36UPEmYWkJdo3jqbGcQWAtrV0NTBOoGRbxaSUbMQOmYh 6VjAyLyKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzAID275rbqD8fIbx0OMAhyMSjy8Hzqf hgixJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgXHqnCW/OTzf JflN6Apz8w9wmeXHxHzpXHUET+/tjykPZzdfFz9Usm/zZ6bilAsTVNdsOaH4SPHA+R1niqUO 67YbqzCfUK+O8skKXP+q6cYySS6r67klkvUH/wSvqj7PvGLx0+9RPkkXnMJz4vxyRCx4HV7N e10Sd6P5tg3TpZOs3x4um/AnI16JpTgj0VCLuag4EQBakZyEIwIAAA== Archived-At: Subject: [AVTCORE] Design choice comments on draft-jones-avtcore-private-media-framework-00 X-BeenThere: avt@ietf.org 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, 19 Feb 2015 15:03:51 -0000 Hi, (As individual) I have just reviewed the draft and are supportive of work in this field. However, I have some really high level comments in regards to the design choices. 1. Supported RTP topologies I think you will need to discuss a bit more which RTP topologies that the framework should support. The current draft supports only basic transport translators (Relay) to my understanding, because of it preventing rewriting of RTP sequence number as well as the SSRC. Thus, all RTP streams sent to the server must be forwarded to all other participants. I believe the intention of the document is to support at least Selective Forwarding Middlebox (SFM). However, to support such a topology and be able to suspend delivery of some media streams, then RTP sequence number rewriting becomes a requirement to keep the media streams compliant with current RTP specification. Also people who have been building conferencing middleboxes also uses other topologies, for example the RTP mixer in also used to build switching mixers. Where an SSRC can represent a role rather than a original sender. I think there is need to have some discussion of which RTP topologies this type of solution intends to support so that one can determine which RTP field behaviours that is to be expected and need to be dealt with. I would appreciate your view of what you see as needed to be supported. 2. Additional privacy concerns in RTP/RTCP. The proposed framework protects the RTP payloads and their media content from the middle. However, the document fails to discuss if privacy protection is needed either for the RTP header extensions themselves or if any RTCP packets or their content is privacy sensitive. The RTP header extensions that are defined in IETF, as well as the two 3GPP has registered appears to be privacy sensitive in any way. However, the big picture issue is that RTP header extensions do not require to be standardized. The registration requires only an Expert Review, and they are trivial to use for proprietary extension. So we have no idea what might be showing up here. I could easily believe that someone would for example include a geolocation attached to a video stream to capture where for example a airborne drone where when capturing the video. Suddenly you have data that is privacy sensitive and may require end to end protection. In RTCP you already today have some parts that are privacy sensitive. For example all the SDES items with the exception of CNAME (if generated correctly) can contain privacy sensitive data. Also the APP RTCP packet type might contain data that needs to be protected end to end. Thus I think you need to consider if there are need for additional protection mechanisms to realize the goals of this framework. To me it appears that this are reasonably straightforward SRTP extensions that could solve these issues if they are considered necessary to resolve. Even if the initial solution doesn't provide a fully specified solution, I think it is important to ensure that the framework do support a solution to specified at a later stage. 3. What must be in the trusted zone? Looking at the description it looks like the solution is missing one important part in the trusted zone. That is the list of identities or secret that enables an invited / allowed participant to participate in a particular conference. That functionality is key component of the security solution. How else is the KMF going to be able to determine which asserted identities that are allowed to get the EKT, thus being able to get access to the media. I understand the need for having solution agility when it comes to identity solutions, however the functionality and the requirement on it I think needs to be described in this type of framework. 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 ---------------------------------------------------------------------- From nobody Thu Feb 19 08:01:56 2015 Return-Path: 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 B51341A19F8; Thu, 19 Feb 2015 08:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 HQbdDeQJT8Ts; Thu, 19 Feb 2015 08:01:45 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628CF1A90C8; Thu, 19 Feb 2015 08:01:44 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-90-54e608e6b73b Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.32.24955.6E806E45; Thu, 19 Feb 2015 17:01:42 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.53) with Microsoft SMTP Server id 14.3.210.2; Thu, 19 Feb 2015 17:01:41 +0100 Message-ID: <54E608E5.1070102@ericsson.com> Date: Thu, 19 Feb 2015 17:01:41 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David McGrew References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+Jvje4zjmchBmsvSFq87FnJbrHy23VW i7VHEi1m/JnIbDHh1GtWi6ur/rBbTN97jd2B3WPK742sHmu7r7J5LFnyk8mjf9dLVo8vlz+z BbBGcdmkpOZklqUW6dslcGV8XL+IrWAjf8XWLxOYGhi3cncxcnJICJhIrLj4lxnCFpO4cG89 G4gtJHCEUWJxj2sXIxeQvZxR4vXlWUwgCV4BbYljD7azgNgsAqoSKx8tBrPZBCwkbv5oBGsW FQiWWPz8KStEvaDEyZlPwGpEBJQltr6bzgQylFlgB5PEs0cTwYYKC8RJzHq5iR1i814Wif0H IkBsTgFbiYPTDoJdxyxgIHFk0RxWCFteonnrbGaIem2JhqYO1gmMgrOQ7JuFpGUWkpYFjMyr GEWLU4uTctONjPVSizKTi4vz8/TyUks2MQLD/+CW36o7GC+/cTzEKMDBqMTD+6HzaYgQa2JZ cWXuIUZpDhYlcV4740MhQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjl5nm887/qvu7Ym4ZH +7m3qTn03WqcbfVlixfHakEOER2Pi7/s2QJM2Hu1FI87bWmxmmpzel6RWJ12xYKd/dfWemkp PGN6dfhaGVNTYrvv0yCvJQGzIsujwzwflzFYr/63pkLtEI9a94nGaSY7fm6+Gaa6wbXyBNur 7nPP46y3uR7k+b8kzFSJpTgj0VCLuag4EQDCfTSFYAIAAA== Archived-At: Cc: "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , IETF AVTCore WG , "avtcore-chairs@tools.ietf.org" , The IESG , Stephen Farrell Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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, 19 Feb 2015 16:01:50 -0000 On 2015-02-15 15:09, David McGrew wrote: > > My opinion is: it would be best to preserve the existing specification > and implementation work, and retain all ten crypto suite definitions. > But if we want to make SRTP-AEAD be the first instance in which the IETF > will prioritize simplicity over variety and diversity, I’m good with > that, because I certainly see the value of simplicity; then my > recommendation would be to eliminate the four 12-octet authentication > versions. That would leave just six crypto suites, with two different > modes of operation, two different key sizes, and two different tag > lengths (but not all tag lengths for all modes), like this: > > srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / > "AEAD_AES_256_GCM" / > "AEAD_AES_128_CCM" / > "AEAD_AES_256_CCM" / > "AEAD_AES_128_CCM_8" / > "AEAD_AES_256_CCM_8" / > Stephen, WG Having looked at the feedback provided in this discussion so far, I think the above set of 6 are a reasonable selection without unduly limiting functionality, but removing the four least necessary profiles. My proposal is that if no one is disagreeing with this in the next week (Prior to Feb 26 at 16:30 UTC) we use it. If someone disagrees we hold a discussion at the informal IESG telechat on how to proceed. 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 ---------------------------------------------------------------------- From nobody Thu Feb 19 08:04:28 2015 Return-Path: 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 321CA1A912B for ; Thu, 19 Feb 2015 08:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 3K9gFG8UYGUW for ; Thu, 19 Feb 2015 08:04:23 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20301A90EE for ; Thu, 19 Feb 2015 08:04:22 -0800 (PST) Received: from [156.106.247.97] ([156.106.247.97]) (authenticated bits=0) by dublin.packetizer.com (8.14.9/8.14.9) with ESMTP id t1JG48Lg023135 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2015 11:04:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1424361850; bh=nQjp1iFgcopR60Nj8i7FrurNRrwkOuwnWk5RCwm2XOA=; h=From:To:Subject:Date:In-Reply-To:Reply-To; b=VQOzFwnrbgVj5UZ9w/7WcV5fhVysTe3+qKMRTIQX7OIDfJy/qmdWDLCSbSneafmWa 58K/qFxVcMGFlIp00DO3H7Y4uq3h5aEBgnJswb+S84WXFIz8QKY1ZWek6tmhWW/JZo HbRxC1Bo1a0y/xopLkHYQRyOFFlMBYjOvNGj0MNA= From: "Paul E. Jones" To: "Magnus Westerlund" , "IETF AVTCore WG" , nermeen@cisco.com, "David Benham (dbenham)" Date: Thu, 19 Feb 2015 16:04:09 +0000 Message-Id: In-Reply-To: <54E5FB10.2030209@ericsson.com> User-Agent: eM_Client/6.0.21372.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [AVTCORE] Design choice comments on draft-jones-avtcore-private-media-framework-00 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 16:04:26 -0000 Magnus, >Hi, >(As individual) > >I have just reviewed the draft and are supportive of work in this=20 >field. >However, I have some really high level comments in regards to the=20 >design >choices. > >1. Supported RTP topologies > >I think you will need to discuss a bit more which RTP topologies that >the framework should support. The current draft supports only basic >transport translators (Relay) to my understanding, because of it >preventing rewriting of RTP sequence number as well as the SSRC. Thus, >all RTP streams sent to the server must be forwarded to all other >participants. > >I believe the intention of the document is to support at least=20 >Selective >Forwarding Middlebox (SFM). However, to support such a topology and be >able to suspend delivery of some media streams, then RTP sequence=20 >number >rewriting becomes a requirement to keep the media streams compliant=20 >with >current RTP specification. > >Also people who have been building conferencing middleboxes also uses >other topologies, for example the RTP mixer in also used to build >switching mixers. Where an SSRC can represent a role rather than a >original sender. > >I think there is need to have some discussion of which RTP topologies >this type of solution intends to support so that one can determine=20 >which >RTP field behaviours that is to be expected and need to be dealt with. > >I would appreciate your view of what you see as needed to be supported. I agree that we will need to elaborate a bit more on that, but it's not=20 clear to me if any of the existing topologies that are defined match=20 exactly. The desire to prevent changes to the RTP headers means that=20 something else is needed in order to properly forward media (e.g., a=20 header extension) and account for packet loss, handle congestion issues,= =20 etc. We've been more focused on what we want to accomplish than trying to fit= =20 the solution into a specific topology. I think we can get there, but we= =20 need more discussion as a group. > 2. Additional privacy concerns in RTP/RTCP. > >The proposed framework protects the RTP payloads and their media=20 >content >from the middle. However, the document fails to discuss if privacy >protection is needed either for the RTP header extensions themselves or >if any RTCP packets or their content is privacy sensitive. > >The RTP header extensions that are defined in IETF, as well as the two >3GPP has registered appears to be privacy sensitive in any way.=20 >However, >the big picture issue is that RTP header extensions do not require to=20 >be >standardized. The registration requires only an Expert Review, and they >are trivial to use for proprietary extension. So we have no idea what >might be showing up here. I could easily believe that someone would for >example include a geolocation attached to a video stream to capture >where for example a airborne drone where when capturing the video. >Suddenly you have data that is privacy sensitive and may require end to >end protection. > >In RTCP you already today have some parts that are privacy sensitive. >For example all the SDES items with the exception of CNAME (if=20 >generated >correctly) can contain privacy sensitive data. Also the APP RTCP packet >type might contain data that needs to be protected end to end. > >Thus I think you need to consider if there are need for additional >protection mechanisms to realize the goals of this framework. To me it >appears that this are reasonably straightforward SRTP extensions that >could solve these issues if they are considered necessary to resolve. >Even if the initial solution doesn't provide a fully specified=20 >solution, >I think it is important to ensure that the framework do support a >solution to specified at a later stage. The intention was the RTP header extensions and RTCP could optionally be= =20 encrypted using the SRTP keys exchanged as they are today. This would=20 be done hop-by-hop. This does not provide for end-to-end privacy, of=20 course. That fits with the goals we've stated in the requirements=20 document. We're not trying to hide the fact that two people=20 communicated, for example, but we do not want to disclose what is being=20 communicated. If there is truly a need to encrypt end-to-end such that middle boxes=20 cannot gain access to some RTP header extensions or some RTCP data=20 fields, I would assert we need to define a way to allow some header=20 extensions and some RTCP header fields to be visible hop-by-hop. We do=20 want to enable middleboxes to be able to collect and use RTCP=20 statistics, for example. We also want to allow them to have access to=20 any header extension that help facilitate packet forwarding and=20 processing. > >3. What must be in the trusted zone? > >Looking at the description it looks like the solution is missing one >important part in the trusted zone. That is the list of identities or >secret that enables an invited / allowed participant to participate in=20 >a >particular conference. That functionality is key component of the >security solution. How else is the KMF going to be able to determine >which asserted identities that are allowed to get the EKT, thus being >able to get access to the media. > >I understand the need for having solution agility when it comes to >identity solutions, however the functionality and the requirement on it >I think needs to be described in this type of framework. This framework is only focused on the media aspects. The approach we're= =20 taking here is that there is some kind of exchange that happens between=20 the endpoint and the KMF or some other trusted entity that exists in the= =20 signaling plane. It is through this signaling that a determination is=20 made as to what endpoint can have access to the keys for a particular=20 conference. We expect that fingerprint for the endpoint certificate=20 would be exchanged with the KMF and vice versa. When the DTLS connection is made to the switching conference server,=20 that would be tunneled (via a protocol we've defined but not published)=20 from the switching conference server to the KMF. Effectively, the=20 endpoint and KMF establish a DTLS connection. The KMF would recognize=20 the user as belonging to a particular conference and provide the SRTP=20 keys (using DTLS-SRTP procedures) and the EKT key (via the EKT=20 procedures). One thing I would like to add to the EKT draft is some=20 piece of data that indicates what the conference identifier is. I would= =20 like the endpoint to convey that information as part of the EKT=20 exchange, but no such field exists today. I would also like the=20 conference server to convey the conference identifier for comparison. So, the framework is clearly not complete even on the media side. There= =20 are some editor's notes and perhaps additional items (like the field for= =20 the conference identifier). However, I would prefer to keep the=20 signaling that happens before this point separate. The reason is that I= =20 can imagine that a number of different mechanisms might exists. For a=20 WebRTC client, for example, the signaling might be entirely proprietary.= =20 For SIP devices, we then also have to worry with securing the signaling= =20 exchanges That's important, but I think that can be done in parallel=20 and independently of this media-focused draft. Paul > > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > From nobody Thu Feb 19 14:15:08 2015 Return-Path: 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 371C41A036F for ; Thu, 19 Feb 2015 14:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 xs5vc67qC2Vt for ; Thu, 19 Feb 2015 14:15:05 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9591A001A for ; Thu, 19 Feb 2015 14:15:05 -0800 (PST) Received: by pdjy10 with SMTP id y10so2886780pdj.6 for ; Thu, 19 Feb 2015 14:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jJh0QuCD1bcFazmH8oCfBvxtgHfHv2q+/hCei0u8D7s=; b=Ezp+RnSLwayzwvT79Uf+4amK1PPCYV6FdqTG/3/z/IW+3qcWYxsfZuIMd8Nxeou/xf brWsi9uEZfpvclrWFupr1f2aR4HfSTi/VhWLRof0j364F9GW4PHdwJTuTx6mOoWdqVUv 5hfab8xgcd8KlGcQ+pRjULumfqFnBlHke9DdasZfa27AFzOou7zMDjJc/VLFPjl1CzyI 0C7WPlUVD9RiCHjLD4JN+N74EtS1iV0ShABctPWJ/xkEps+msBLz5Hem5L0NJ66nJu9B ZV7E28I2aP6M7hDVI6Ijwmlx59FSh00N15Qt3DIkvE+dPYiLgMv0Vblm+qx3QvMP3Pm4 oN1g== MIME-Version: 1.0 X-Received: by 10.66.182.199 with SMTP id eg7mr3727718pac.57.1424384104333; Thu, 19 Feb 2015 14:15:04 -0800 (PST) Received: by 10.70.117.99 with HTTP; Thu, 19 Feb 2015 14:15:04 -0800 (PST) Received: by 10.70.117.99 with HTTP; Thu, 19 Feb 2015 14:15:04 -0800 (PST) Date: Thu, 19 Feb 2015 17:15:04 -0500 Message-ID: From: Julius Friedman To: Magnus Westerlund , Ron Frederick , avt@ietf.org Content-Type: multipart/alternative; boundary=047d7bd6c70a900721050f7844d1 Archived-At: Subject: [AVTCORE] On my erratum X-BeenThere: avt@ietf.org 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, 19 Feb 2015 22:15:07 -0000 --047d7bd6c70a900721050f7844d1 Content-Type: text/plain; charset=UTF-8 I had sent in an email with the subject "on the following erratum". That email was all but ignored by the IETF until recently. I am preparing a response but I think its faux paus that the erratum was voted against without first getting that input. With that being stated I am preparing a response. Please be patient so that I can include all relevant gripes and details. I have the response prepared and I am proof reading it, please allow me an additional day or two to respond and I will have the email out by the Friday February 20 2015 before 5 PM EST. Thanks. --047d7bd6c70a900721050f7844d1 Content-Type: text/html; charset=UTF-8

I had sent in an email with the subject "on the following erratum".

That email was all but ignored by the IETF until recently.

I am preparing a response but I think its faux paus that the erratum was voted against without first getting that input.

With that being stated I am preparing a response.

Please be patient so that I can include all relevant gripes and details.

I have the response prepared and I am proof reading it, please allow me an additional day or two to respond and I will have the email out by the Friday February 20 2015 before 5 PM EST.

Thanks.

--047d7bd6c70a900721050f7844d1-- From nobody Fri Feb 20 00:36:56 2015 Return-Path: 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 965D71A7D80 for ; Fri, 20 Feb 2015 00:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 MqW4aoswHw97 for ; Fri, 20 Feb 2015 00:36:53 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951491A711A for ; Fri, 20 Feb 2015 00:36:52 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-c2-54e6f22286b9 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AD.FE.04231.222F6E45; Fri, 20 Feb 2015 09:36:50 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.210.2; Fri, 20 Feb 2015 09:36:50 +0100 Message-ID: <54E6F222.4030908@ericsson.com> Date: Fri, 20 Feb 2015 09:36:50 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julius Friedman , Ron Frederick , References: In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrILMWRmVeSWpSXmKPExsUyM+Jvja7Sp2chBh8b9C1e9qxktzh+oonZ Yve/VmYHZo+XL26yeuycdZfdY8mSn0wBzFFcNimpOZllqUX6dglcGYffH2Ep2MNbsWz1b7YG xutcXYycHBICJhKHN11nhbDFJC7cW8/WxcjFISRwhFFiz5Ib7BDOckaJa3v/soBU8QpoS9zt mMkGYrMIqEpMPz6PEcRmE7CQuPmjESwuKhAssfj5U1aIekGJkzOfgPWKCORIPL6zg6mLkYND WEBKoulPLUhYSCBA4tzqvewgNqdAoMSFyVeYQUqYBTQl1u/SBwkzC8hLNG+dzQxRri3R0NTB OoFRYBaSBbMQOmYh6VjAyLyKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzBMD275rbuDcfVr x0OMAhyMSjy8BoufhQixJpYVV+YeYpTmYFES57UzPhQiJJCeWJKanZpakFoUX1Sak1p8iJGJ g1OqgbFhL3fm4zYeZpvN8ddtFS6nT0i4WxQje+r6h5uTI1/Xt86pfhzIfG32qu4FDtUb/qko misc1XOZpJnSdfuDlJKgrH3Cn9dr9ogc/v7PdJVXx8bTfUm+H+XP1rd/El1aJi3E5pDkE3m9 cCkLl9tvHuX6J2snx0WsPCxx4rcDtzFbbJ7HIqHvfkosxRmJhlrMRcWJAMQVhE40AgAA Archived-At: Subject: Re: [AVTCORE] On my erratum X-BeenThere: avt@ietf.org 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: Fri, 20 Feb 2015 08:36:54 -0000 Julius, Rather than trying to edit the errata that you have submitted, lets discuss the issue you have on the mailing list. If we arrive that the issue is suitable for an errata, then lets formulate it and run an consensus call on it prior to submitting it to the RFC-editor. Also, please do not bunch issues together, especially not on issues that concerns different documents. Instead send separate emails with subjects stating what it concerns so that one can keep things separate and more follow any resulting discussion. Cheers Magnus On 2015-02-19 23:15, Julius Friedman wrote: > I had sent in an email with the subject "on the following erratum". > > That email was all but ignored by the IETF until recently. > > I am preparing a response but I think its faux paus that the erratum was > voted against without first getting that input. > > With that being stated I am preparing a response. > > Please be patient so that I can include all relevant gripes and details. > > I have the response prepared and I am proof reading it, please allow me > an additional day or two to respond and I will have the email out by the > Friday February 20 2015 before 5 PM EST. > > Thanks. > -- 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 ---------------------------------------------------------------------- From nobody Fri Feb 20 00:42:46 2015 Return-Path: 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 9B4E51A8032 for ; Fri, 20 Feb 2015 00:42:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 Ye_Uq9OYz2dx for ; Fri, 20 Feb 2015 00:42:43 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497BC1A8029 for ; Fri, 20 Feb 2015 00:42:43 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-aa-54e6f381d099 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 40.65.04484.183F6E45; Fri, 20 Feb 2015 09:42:41 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.210.2; Fri, 20 Feb 2015 09:42:40 +0100 Message-ID: <54E6F380.3070208@ericsson.com> Date: Fri, 20 Feb 2015 09:42:40 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ross Finlayson References: <54E1AD84.80805@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+JvjW7j52chBn/nCVm87FnJbjG18T+r A5PHkiU/mTxWL/nDGsAUxWWTkpqTWZZapG+XwJVx9fgG1oJOsYrZax6zNTBOEOxi5OSQEDCR eL5tBjuELSZx4d56ti5GLg4hgSOMEl8mrWSFcJYzSjyYspsVpIpXQFuiZ8NqJhCbRUBV4vjf 32DdbAIWEjd/NLKB2KICwRKLnz+FqheUODnzCUsXIweHiICWxNVJNSBhZgEhidNzvoGVCAvY SyyYsxrMFhKIkZh9/D4zSDknUHzFRgmIcgOJI4vmsELY8hLNW2czQ5RrSzQ0dbBOYBSchWTZ LCQts5C0LGBkXsUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGKwHt/w22MH48rnjIUYBDkYl Hl6Dxc9ChFgTy4orcw8xSnOwKInz2hkfChESSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuPVv 32tt12zDMHOdBUI6R2JOTzqkdZ99U6fdi8BrW2Nn73iy/oR+8WT7HTrPgs3ZkwPmbzTPU5tx +7v90Qctl5W38Xxln+3LtoYpWuES2/M5eyJ9hZ86Gh+1Oxfs0yEmb7ybbR5/rsP09VOk0o/b 1eZEnmS4Hfdr9ccHbXsTTRN/CO9QZj9zQImlOCPRUIu5qDgRAByx8+Q3AgAA Archived-At: Cc: avt@ietf.org Subject: Re: [AVTCORE] Summary of AVTCORE WG's Errata decisions X-BeenThere: avt@ietf.org 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: Fri, 20 Feb 2015 08:42:45 -0000 Ross, Yes, I think this is appropriate for an editorial errata. Can you please write this up in an email form based on the Errata template: The old text: New text: Notes: Cheers Magnus On 2015-02-19 11:16, Ross Finlayson wrote: > >> On Feb 16, 2015, at 9:42 PM, Magnus Westerlund >> > > wrote: >> >> ADs, >> >> Here is a current summary of the Erratas that are in reported state for >> the AVT WG (AVTCORE has no reported Errata) > > FYI, last August I reported a minor bug (email copied below) in RFC 3711 > (SRTP). IMHO, this should be added to the RFC 3711 errata at some point... > > > >> Begin forwarded message: >> >> *From: *Ross Finlayson > > >> *Subject: **Minor bug in RFC 3711 (SRTP), FYI* >> *Date: *August 10, 2014 at 5:57:22 PM GMT+12 >> *Cc: *avt@ietf.org >> *To: *mbaugher@cisco.com , >> elisabetta.carrara@ericsson.com >> , mcgrew@cisco.com >> , mats.naslund@ericsson.com >> , karl.norrman@ericsson.com >> >> >> In section 3.4 ("Secure RTCP"), there is a bug in "Figure 2. An >> example of the format of a Secure RTCP packet..." >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ >> |V=2|P| RC | PT=SR or RR | length | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> >> The boundary between the "PT=SR or RR" and the "length" fields is >> wrong: The boundary is shown as being between bits 16 and 17; it >> should be between bits 15 and 16. I.e., the "PT=SR or RR" field >> should be 8 bits long, not 9. >> >> This is just a minor bug, because the equivalent diagram in RFC 3550 >> (the normative reference for RTCP) is correct. Nonetheless, this bug >> should probably be added to the errata for RFC 3711 >> >> Ross Finlayson >> Live Networks, Inc. >> http://www.live555.com/ >> > -- 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 ---------------------------------------------------------------------- From nobody Fri Feb 20 01:07:18 2015 Return-Path: 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 262B71A8718 for ; Fri, 20 Feb 2015 01:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 s58K2fBOK3Zk for ; Fri, 20 Feb 2015 01:07:14 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2660C1A8714 for ; Fri, 20 Feb 2015 01:07:13 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-9a-54e6f940937c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3A.E4.04231.049F6E45; Fri, 20 Feb 2015 10:07:12 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.210.2; Fri, 20 Feb 2015 10:07:11 +0100 Message-ID: <54E6F93F.9010307@ericsson.com> Date: Fri, 20 Feb 2015 10:07:11 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Paul E. Jones" , IETF AVTCore WG , , "David Benham (dbenham)" References: In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvja7Dz2chBvN3yFu87FnJbnHm1zwm i1Un/rFanL+wgcmBxWPK742sHkuW/GTyaNh3lD2AOYrLJiU1J7MstUjfLoErY9qt7awFm0Mr ts0OamA869LFyMkhIWAicf/7E1YIW0ziwr31bCC2kMARRolnq3y7GLmA7OWMEq0HuthBErwC 2hIzp54Bs1kEVCVWrjjJBGKzCVhI3PzRCNYsKhAssfj5U1aIekGJkzOfsIAMEhGYwCjxddUU RpCEsECoROPSnUDNHEAbbCVenywCCXMK2Ens3XqAHSTMLKApsX6XPkiYWUBeonnrbGaI27Ql Gpo6WCcwCsxCsmEWQscsJB0LGJlXMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgSG68Etv3V3 MK5+7XiIUYCDUYmH12DxsxAh1sSy4srcQ4zSHCxK4rx2xodChATSE0tSs1NTC1KL4otKc1KL DzEycXBKNTByyuz8+OJ4l6/mzTq5B4Llrb6pwYqTNjo0ml3fkeWZliZ7XmqO5jSp9fuLKq7d zgl6cii/7u/Bicdm/FX1tti7TiUkaQ2/slpghMwa98K1ekvk7dgOhssV7J0wRamuO5hL6dzS 05oPoiYttDxzPS/lAbuGieCfgw43N6w489BOZkmczVG+mfFKLMUZiYZazEXFiQBp0Ux0OAIA AA== Archived-At: Subject: Re: [AVTCORE] Design choice comments on draft-jones-avtcore-private-media-framework-00 X-BeenThere: avt@ietf.org 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: Fri, 20 Feb 2015 09:07:18 -0000 Hi, Please see inline. On 2015-02-19 17:04, Paul E. Jones wrote: > Magnus, > >> Hi, >> (As individual) >> >> I have just reviewed the draft and are supportive of work in this field. >> However, I have some really high level comments in regards to the design >> choices. >> >> 1. Supported RTP topologies >> >> I think you will need to discuss a bit more which RTP topologies that >> the framework should support. The current draft supports only basic >> transport translators (Relay) to my understanding, because of it >> preventing rewriting of RTP sequence number as well as the SSRC. Thus, >> all RTP streams sent to the server must be forwarded to all other >> participants. >> >> I believe the intention of the document is to support at least Selective >> Forwarding Middlebox (SFM). However, to support such a topology and be >> able to suspend delivery of some media streams, then RTP sequence number >> rewriting becomes a requirement to keep the media streams compliant with >> current RTP specification. >> >> Also people who have been building conferencing middleboxes also uses >> other topologies, for example the RTP mixer in also used to build >> switching mixers. Where an SSRC can represent a role rather than a >> original sender. >> >> I think there is need to have some discussion of which RTP topologies >> this type of solution intends to support so that one can determine which >> RTP field behaviours that is to be expected and need to be dealt with. >> >> I would appreciate your view of what you see as needed to be supported. > > I agree that we will need to elaborate a bit more on that, but it's not > clear to me if any of the existing topologies that are defined match > exactly. The desire to prevent changes to the RTP headers means that > something else is needed in order to properly forward media (e.g., a > header extension) and account for packet loss, handle congestion issues, > etc. Lets discuss this more, but I like to state my personal position here. I much rather see the security solution take the current RTP into account, rather than forcing us to redefine RTP and make changes to how existing and working mechanisms function. In this case I am especially concerned your disregard to ensure that the RTP sequence numbers will be sent without sender side gaps in the sequence. This as it impacts the existing packet loss detection and reporting mechanisms. > > We've been more focused on what we want to accomplish than trying to fit > the solution into a specific topology. I think we can get there, but we > need more discussion as a group. I think that is fine, but you appear to have jumped to conclusions and suggested technical solutions that consider the security goals but not the RTP implications. Thus, I would suggest that you focus on making clear the high level security requirements and then factor in the existing RTP and its impact on possible solutions. > > > >> 2. Additional privacy concerns in RTP/RTCP. >> >> The proposed framework protects the RTP payloads and their media content >> from the middle. However, the document fails to discuss if privacy >> protection is needed either for the RTP header extensions themselves or >> if any RTCP packets or their content is privacy sensitive. >> >> The RTP header extensions that are defined in IETF, as well as the two >> 3GPP has registered appears to be privacy sensitive in any way. However, >> the big picture issue is that RTP header extensions do not require to be >> standardized. The registration requires only an Expert Review, and they >> are trivial to use for proprietary extension. So we have no idea what >> might be showing up here. I could easily believe that someone would for >> example include a geolocation attached to a video stream to capture >> where for example a airborne drone where when capturing the video. >> Suddenly you have data that is privacy sensitive and may require end to >> end protection. >> >> In RTCP you already today have some parts that are privacy sensitive. >> For example all the SDES items with the exception of CNAME (if generated >> correctly) can contain privacy sensitive data. Also the APP RTCP packet >> type might contain data that needs to be protected end to end. >> >> Thus I think you need to consider if there are need for additional >> protection mechanisms to realize the goals of this framework. To me it >> appears that this are reasonably straightforward SRTP extensions that >> could solve these issues if they are considered necessary to resolve. >> Even if the initial solution doesn't provide a fully specified solution, >> I think it is important to ensure that the framework do support a >> solution to specified at a later stage. > > The intention was the RTP header extensions and RTCP could optionally be > encrypted using the SRTP keys exchanged as they are today. This would > be done hop-by-hop. This does not provide for end-to-end privacy, of > course. That fits with the goals we've stated in the requirements > document. We're not trying to hide the fact that two people > communicated, for example, but we do not want to disclose what is being > communicated. > > If there is truly a need to encrypt end-to-end such that middle boxes > cannot gain access to some RTP header extensions or some RTCP data > fields, I would assert we need to define a way to allow some header > extensions and some RTCP header fields to be visible hop-by-hop. We do > want to enable middleboxes to be able to collect and use RTCP > statistics, for example. We also want to allow them to have access to > any header extension that help facilitate packet forwarding and processing. I fully agree that there MUST be possibility to have both RTP header extensions as well as many type of RTCP packets to be only protected hop by hop. The core of my comment is rather that the solution appear to need to take into account the likely need for end-to-end protection of other RTP/RTCP fields and actively discuss in its security considerations the privacy risk from some existing RTP/RTCP protocol elements, specifically the RTCP SDES items. > > >> >> 3. What must be in the trusted zone? >> >> Looking at the description it looks like the solution is missing one >> important part in the trusted zone. That is the list of identities or >> secret that enables an invited / allowed participant to participate in a >> particular conference. That functionality is key component of the >> security solution. How else is the KMF going to be able to determine >> which asserted identities that are allowed to get the EKT, thus being >> able to get access to the media. >> >> I understand the need for having solution agility when it comes to >> identity solutions, however the functionality and the requirement on it >> I think needs to be described in this type of framework. > > This framework is only focused on the media aspects. The approach we're > taking here is that there is some kind of exchange that happens between > the endpoint and the KMF or some other trusted entity that exists in the > signaling plane. It is through this signaling that a determination is > made as to what endpoint can have access to the keys for a particular > conference. We expect that fingerprint for the endpoint certificate > would be exchanged with the KMF and vice versa. I think that is not sufficient as it can not ensure the security goals of providing confidentiality. Without explicitly discussing the fact that there is a set of trusted participants and the need for a mechanism to verify that a endpoint is representing that such a participant the solution is flawed. I fully understand that there is need to enable multiple technical solutions for verifying that identity, however if the intention is to provide a framework for solving this issue, the requirement on parts that are outside of this WGs main expertise, namely RTP must still be discussed. > > When the DTLS connection is made to the switching conference server, > that would be tunneled (via a protocol we've defined but not published) > from the switching conference server to the KMF. Effectively, the > endpoint and KMF establish a DTLS connection. The KMF would recognize > the user as belonging to a particular conference and provide the SRTP > keys (using DTLS-SRTP procedures) and the EKT key (via the EKT > procedures). One thing I would like to add to the EKT draft is some > piece of data that indicates what the conference identifier is. I would > like the endpoint to convey that information as part of the EKT > exchange, but no such field exists today. I would also like the > conference server to convey the conference identifier for comparison. I do wonder about this part of the solution. Why the structure you have selected? Another potential solution is clearly to run two different DTLS-SRTP handshakes, one directly between endpoint and KMT, the other between the endpoint and server. Once more I think you jumped into solution without motivating why you think the proposed solution is the appropriate. > > So, the framework is clearly not complete even on the media side. There > are some editor's notes and perhaps additional items (like the field for > the conference identifier). However, I would prefer to keep the > signaling that happens before this point separate. The reason is that I > can imagine that a number of different mechanisms might exists. For a > WebRTC client, for example, the signaling might be entirely proprietary. > For SIP devices, we then also have to worry with securing the signaling > exchanges That's important, but I think that can be done in parallel > and independently of this media-focused draft. Fully agree about the need for different signalling mechanism. However, to me it appears there need to be one or a small set of solution or at least hooks for how the KMT can verify the endpoint's right to be in particular session. I hope that you can take this discussion into account and improve your framework document to clearer on what you see as the minimal necessary functions in a solution. And when having established that can go into a discussion of proposed solutions to realize that. 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 ---------------------------------------------------------------------- From nobody Fri Feb 20 08:50:49 2015 Return-Path: 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 6A6EF1A0366 for ; Fri, 20 Feb 2015 08:50:48 -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 QlnE9kX5rbqK for ; Fri, 20 Feb 2015 08:50:45 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734141A1A96 for ; Fri, 20 Feb 2015 08:50:44 -0800 (PST) Received: from [130.209.247.112] (port=64951 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YOqmk-0003yQ-TQ; Fri, 20 Feb 2015 16:50:40 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Colin Perkins In-Reply-To: <54E59970.6040804@ericsson.com> Date: Fri, 20 Feb 2015 16:50:32 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E59970.6040804@ericsson.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.1878.6) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: varun@comnet.tkk.fi, IETF AVTCore WG Subject: Re: [AVTCORE] My comments on draft-ietf-avtcore-rtp-circuit-breakers-08 X-BeenThere: avt@ietf.org 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: Fri, 20 Feb 2015 16:50:48 -0000 Hi, On 19 Feb 2015, at 08:06, Magnus Westerlund = wrote: > Hi, >=20 > I have just reviewed the latest version of circuit breakers and have = the > following feedback. >=20 > I think the document has improved since I last reviewed it (-05) but I > think the following issue is not yet addressed from my previous = review. >=20 >> 7) Section 5: >>=20 >> As there is a difference between CB #1 and #3 and #2 that has to do >> with that the first (#1 and #3) uses incoming RTCP reports and that = #2 >> uses the CB implementers estimate of what the regular reporting >> interval is. Thus, I wonder if there needs to exist include a >> reflection over t_rr_int as well as the RTCP SSRC timeout calculation >> that we recommend to use 5 seconds as fixed minimal value in those >> calculations (if 5 sec larger than t_rr_int). >=20 > I will see if I can propose some text to address this. I=92m not sure how T_tt_interval affects the performance, so suggestions = would be welcomed. > I also think there is need for scaling the number of reporting = intervals > it takes to trigger the circuit breakers when using AVPF or reduced > minimum. Especially for AVPF there will be a lot of false triggering = due > to relatively short time intervals that the circuit breakers will = sample > over. I think it=92s clear we should scale the number of reporting intervals = needed to trigger the circuit breaker inversely with the duration of the = reporting interval, so it takes a roughly constant amount of time to = trigger. We need to write this up and simulate it=92s performance.=20 Do you see RTP/AVPF impacting this differently to the impact of using = the reduced minimum interval? (Or is this the T_rr_interval issue?) > I would really like to have proposals for all open issues in the draft > prior to the upcoming meetings deadline. I really like to be able to > have this go to WG last call soon after the Dallas meeting. Sure, agree. --=20 Colin Perkins https://csperkins.org/ From nobody Fri Feb 20 12:49:58 2015 Return-Path: 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 3C9481A87B0 for ; Fri, 20 Feb 2015 12:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 XPpcemR3i_5O for ; Fri, 20 Feb 2015 12:49:50 -0800 (PST) Received: from BLU004-OMC3S12.hotmail.com (blu004-omc3s12.hotmail.com [65.55.116.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E4911A879F for ; Fri, 20 Feb 2015 12:49:50 -0800 (PST) Received: from BLU181-W18 ([65.55.116.72]) by BLU004-OMC3S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 20 Feb 2015 12:49:49 -0800 X-TMN: [StU57jYClUle919AfKtRXZGW7WO9Wuut] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_5973caba-cd32-421c-8066-e48645d19e70_" From: Bernard Aboba To: Magnus Westerlund , IETF AVTCore WG Date: Fri, 20 Feb 2015 12:49:48 -0800 Importance: Normal In-Reply-To: <54E6F93F.9010307@ericsson.com> References: , <54E6F93F.9010307@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Feb 2015 20:49:49.0418 (UTC) FILETIME=[C48E1CA0:01D04D4E] Archived-At: Subject: Re: [AVTCORE] Design choice comments on draft-jones-avtcore-private-media-framework-00 X-BeenThere: avt@ietf.org 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: Fri, 20 Feb 2015 20:49:55 -0000 --_5973caba-cd32-421c-8066-e48645d19e70_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Magnus said:=20 > Lets discuss this more=2C but I like to state my personal position here. = I > much rather see the security solution take the current RTP into account= =2C > rather than forcing us to redefine RTP and make changes to how existing > and working mechanisms function. In this case I am especially concerned > your disregard to ensure that the RTP sequence numbers will be sent > without sender side gaps in the sequence. This as it impacts the > existing packet loss detection and reporting mechanisms. [BA] I agree with Magnus here. Re-defining RTP is a last resort=2C and ev= ery possible effort should be made to avoid it.=20 =20 AFAIK=2C SSRC re-writing is very common in SFUs today=2C even in simulcast-= only implementations. =20 Sequence number rewriting is a requirement in all SFUs that support SRST tr= ansport for SVC (e.g. VP8=2C VP9=2C H.264/SVC=2C H.265 and H.265/SVC).=20 =20 In general=2C it seems possible to avoid these issues by taking the approac= h advocated in draft-cheng-srtp-cloud: providing additional fields within = the encrypted payload=2C rather than assuming that the SFU passes the SSRC = and sequence number fields unmodified. =20 =20 The disadvantage of this approach is a potential decrease in the maximum pa= yload size=2C but presumably the encoder can take this into account. =20 =20 =20 =20 = --_5973caba-cd32-421c-8066-e48645d19e70_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Magnus said:

>=3B Lets= discuss this more=2C but I like to state my personal position here. I
&= gt=3B much rather see the security solution take the current RTP into accou= nt=2C
>=3B rather than forcing us to redefine RTP and make changes to = how existing
>=3B and working mechanisms function. In this case I am e= specially concerned
>=3B your disregard to ensure that the RTP sequenc= e numbers will be sent
>=3B without sender side gaps in the sequence. = This as it impacts the
>=3B existing packet loss detection and reporti= ng mechanisms.

[BA] I agree with Magnus here. =3B =3B Re-def= ining RTP is a last resort=2C and every possible effort should be made to a= void it.
 =3B
AFAIK=2C SSRC re-writing is very common in SFUs to= day=2C even in simulcast-only implementations. =3B =3B
Sequence = number rewriting is a requirement in all SFUs that support SRST transport f= or SVC (e.g. VP8=2C VP9=2C H.264/SVC=2C H.265 and H.265/SVC).
 =3B<= BR>In general=2C it seems possible to avoid these issues by taking =3Bt= he approach advocated in draft-cheng-srtp-cloud: =3B providing addition= al fields within the encrypted payload=2C rather than assuming that the SFU= passes the SSRC and sequence number fields unmodified. =3B
 = =3B
The disadvantage of this approach is a potential decrease in the max= imum payload size=2C but presumably the encoder can take this into account.=  =3B
 =3B
 =3B
 =3B
= --_5973caba-cd32-421c-8066-e48645d19e70_-- From nobody Fri Feb 20 14:03:29 2015 Return-Path: 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 AFDDD1A019B for ; Fri, 20 Feb 2015 14:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 CrAplEzPqTAe for ; Fri, 20 Feb 2015 14:03:27 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108AC1A0194 for ; Fri, 20 Feb 2015 14:03:26 -0800 (PST) Received: by padfb1 with SMTP id fb1so11112553pad.8 for ; Fri, 20 Feb 2015 14:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=f1K7FibP+8Z6kT2vlJgcIL560K8btAuSp6BfkG3CquY=; b=qI5SvvvaZQ/vyHD9s0EIxwjDhOOe62aK7H4exVTkUsjX5r9Q6L14MhCqUjO7h8GdSq 2kGbav1QQ5URILBO3QfS8NvpvuTRqBm8c44LihJpo5Z2jNds/PZSSIygl6CXuF5x53Qh tjDzH2nRFd+X+RByn7aeUCFDp9+D7yRI78IOhmh45IfSapb1JhpwD/ffB9xcBhSqAtaM AonMAr3O9n3DdhGObLkalXuDs6qkW9gsGBTvHGeGniEOrOZuY5O2BPqP3djPYNYizv/l 7Gd6DBCmfjp954oYA6byaHahqk4GRntRyqNkKW1xpmUgKuCPO4X3RkJNUfBWDdYNdtvg Xf6A== MIME-Version: 1.0 X-Received: by 10.68.204.39 with SMTP id kv7mr20189319pbc.49.1424469806208; Fri, 20 Feb 2015 14:03:26 -0800 (PST) Received: by 10.70.117.99 with HTTP; Fri, 20 Feb 2015 14:03:26 -0800 (PST) Date: Fri, 20 Feb 2015 17:03:26 -0500 Message-ID: From: Julius Friedman To: avt@ietf.org Content-Type: multipart/alternative; boundary=e89a8f234a31cade9d050f8c38a5 Archived-At: Subject: [AVTCORE] On my recently submitted errata X-BeenThere: avt@ietf.org 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: Fri, 20 Feb 2015 22:03:28 -0000 --e89a8f234a31cade9d050f8c38a5 Content-Type: text/plain; charset=UTF-8 I have sent he preliminary copy of what I hope will allow for the updates I suggest as improvements to the various standards in question however I did not send such document to the list in public as of yet. I move to make no excuses for my delay however there is a lot of subject material both to reference and disambiguate and as a result Magnus and Ron have a copy of the document and I will address the list in public as appropriate in due course, I appreciate your patience in this matter. I am sure you will be updated as appropriate. Sincerely, Julius Friedman --e89a8f234a31cade9d050f8c38a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have sent he preliminary copy of what I hope will allow = for the updates I suggest as improvements to the various standards in quest= ion however I did not send such document to the list in public as of yet.
I move to make no excuses for my delay however there is a= lot of subject material both to reference and disambiguate and as a result= Magnus and Ron have a copy of the document and I will address the list in = public as appropriate in due course, I appreciate your patience in this mat= ter.

I am sure you will be updated as appropriate.=

Sincerely,
Julius Friedman
--e89a8f234a31cade9d050f8c38a5-- From nobody Mon Feb 23 04:16:19 2015 Return-Path: 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 1DB301A1A73; Mon, 23 Feb 2015 04:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, 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 FWorUWRlQWG3; Mon, 23 Feb 2015 04:16:13 -0800 (PST) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id B806E1A1A72; Mon, 23 Feb 2015 04:16:12 -0800 (PST) X-TM-IMSS-Message-ID: <2c469c850002d0e0@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov (msht-gh1-uea01.corp.nsa.gov [10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 2c469c850002d0e0 ; Mon, 23 Feb 2015 07:16:30 -0500 Received: from MSMR-GH1-UEA01.corp.nsa.gov (10.215.225.4) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.2.347.0; Mon, 23 Feb 2015 07:16:05 -0500 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA01.corp.nsa.gov ([10.215.225.4]) with mapi id 14.02.0347.000; Mon, 23 Feb 2015 07:16:04 -0500 From: "Igoe, Kevin M." To: 'Magnus Westerlund' , 'David McGrew' Thread-Topic: Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) Thread-Index: AQHP83PgqVzDocYf9UC217fNF4hOKZxHcuyQgABb2YCAAAOhAIAAE5YAgAAOCQCAAAKygIAACCmAgI/US4CADNZ3AIAEhLyAgAC2aACAAPjAgIAH4VyAgAZouoCABa+doA== Date: Mon, 23 Feb 2015 12:16:03 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CABC7E6949@MSMR-GH1-UEA03.corp.nsa.gov> References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> <54E608E5.1070102@ericsson.com> In-Reply-To: <54E608E5.1070102@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.224.46] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "'avtcore-chairs@tools.ietf.org'" , "'draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org'" , 'The IESG' , 'IETF AVTCore WG' , 'Stephen Farrell' Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Mon, 23 Feb 2015 12:16:16 -0000 I am content with that. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, February 19, 2015 11:02 AM > To: David McGrew > Cc: Stephen Farrell; avtcore-chairs@tools.ietf.org; draft-ietf-avtcore-sr= tp-aes-gcm@tools.ietf.org; The IESG; Igoe, Kevin M.; IETF > AVTCore WG > Subject: Re: Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm= -14: (with DISCUSS) >=20 > On 2015-02-15 15:09, David McGrew wrote: > > > > My opinion is: it would be best to preserve the existing specification > > and implementation work, and retain all ten crypto suite definitions. > > But if we want to make SRTP-AEAD be the first instance in which the > > IETF will prioritize simplicity over variety and diversity, I'm good > > with that, because I certainly see the value of simplicity; then my > > recommendation would be to eliminate the four 12-octet authentication > > versions. That would leave just six crypto suites, with two different > > modes of operation, two different key sizes, and two different tag > > lengths (but not all tag lengths for all modes), like this: > > > > srtp-crypto-suite-ext =3D "AEAD_AES_128_GCM" / > > "AEAD_AES_256_GCM" / > > "AEAD_AES_128_CCM" / > > "AEAD_AES_256_CCM" / > > "AEAD_AES_128_CCM_8" / > > "AEAD_AES_256_CCM_8" / > > >=20 > Stephen, WG >=20 > Having looked at the feedback provided in this discussion so far, I think= the above set of 6 are a reasonable selection without unduly > limiting functionality, but removing the four least necessary profiles. >=20 > My proposal is that if no one is disagreeing with this in the next week (= Prior to Feb 26 at 16:30 UTC) we use it. If someone disagrees we > hold a discussion at the informal IESG telechat on how to proceed. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- From nobody Mon Feb 23 05:34:02 2015 Return-Path: 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 A3C6E1A1B6F for ; Mon, 23 Feb 2015 05:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 duydm6qQLpDj for ; Mon, 23 Feb 2015 05:33:58 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C2E1A1B20 for ; Mon, 23 Feb 2015 05:33:50 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-66-54eb2c3c518c Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 90.EA.04076.C3C2BE45; Mon, 23 Feb 2015 14:33:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.214]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0210.002; Mon, 23 Feb 2015 14:33:47 +0100 From: Christer Holmberg To: "avt@ietf.org" Thread-Topic: WGLC: draft-ietf-straw-b2bua-rtcp-03.txt Thread-Index: AdBPa6G93iYYLgF6Tt2JeXOX3wxijQAATThQ Date: Mon, 23 Feb 2015 13:33:46 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D714D50@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D713C28@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D713C28@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D714D50ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvja6NzusQgzu3hSxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt2NH1gLzphXTHn0kK2BcaZhFyMnh4SAiUT/4olsELaYxIV7 64FsLg4hgSOMEod/vWeBcJYwSuxvmgbkcHCwCVhIdP/TBmkQEVCUaL32mREkLCxgKvG2MwQi bCYxb34vO4RtJPF38nUwm0VAVWLK5W5WEJtXwFfi8ubLYHEhIHvirJUsIDangJ/Eos0vwO5h BLrn+6k1TCA2s4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VghbSaJxyRNWiPp8icOb1jFC7BKU ODnzCcsERpFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxaXJyb bmSkl1qUmVxcnJ+nl5dasokRGEEHt/y22sF48LnjIUYBDkYlHt4N01+FCLEmlhVX5h5ilOZg URLntTM+FCIkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcfX7Xeum/v0m88RzW/qEmEsmp/cb hum+Snjo/ZY3aN3OA8rBpi1XFgjXdDvFThG5VXkk87j3nmWP84+KKP46qN78L/LmRnnHI1Yy S8ONvOwkM7jc1m0/EHarWd34ACNP8q3/AgU2EgrJy65Pt0xj1cmbZlqRUXyi1qM+VsvbZ/GO xCU7X825o8RSnJFoqMVcVJwIALW0lxyBAgAA Archived-At: Subject: [AVTCORE] FW: WGLC: draft-ietf-straw-b2bua-rtcp-03.txt X-BeenThere: avt@ietf.org 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: Mon, 23 Feb 2015 13:34:00 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D714D50ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, The STRAW WG has announced WGLC for the following draft: draft-ietf-straw-b2bua-rtcp-03.txt Some of the discussions on the draft have been about RTP terminology, and t= he relationship to AVTCORE. For that reason, the STRAW WG chairs think it would be very good if some fr= om the AVT community would be able to perform a WGLC review of the draft. Please post any review comments on the STRAW list. Thanks! Christer & Victor STRAW chairs From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 23 February 2015 15:23 To: straw@ietf.org Cc: draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org Subject: [straw] WGLC: draft-ietf-straw-b2bua-rtcp-03.txt (As co-chair) Hi, This is a working group last call announcement for draft-ietf-straw-b2bua-r= tcp-03.txt. The working group last call will run for 2,5 weeks, until Friday 13th (hope= fully it won't end in horror :). Please provide your comments on the STRAW list. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D714D50ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,=

 

The STRAW WG has annou= nced WGLC for the following draft:

 

draft-ietf-straw-b2bua= -rtcp-03.txt

 

Some of the discussion= s on the draft have been about RTP terminology, and the relationship to AVT= CORE.

 

For that reason, the S= TRAW WG chairs think it would be very good if some from the AVT community w= ould be able to perform a WGLC review of the draft.

 

Please post any review= comments on the STRAW list.

 

Thanks!

 

Christer & Victor<= o:p>

STRAW chairs

 

 

From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 23 February 2015 15:23
To: straw@ietf.org
Cc: draft-ietf-straw-b2bua-rtcp.all@tools.ietf.org
Subject: [straw] WGLC: draft-ietf-straw-b2bua-rtcp-03.txt=

 

(As co-chair)

 

Hi,

 

This is a working group last call announcement for d= raft-ietf-straw-b2bua-rtcp-03.txt.

 

The working group last call will run for 2,5 week= s, until Friday 13th (hopefully it won’t end in horror :).=

 

Please provide your comments on the STRAW list.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D714D50ESESSMB209erics_-- From nobody Mon Feb 23 06:43:51 2015 Return-Path: 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 9A9F01A1B00 for ; Mon, 23 Feb 2015 06:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 cyRqKUKw-Nn5 for ; Mon, 23 Feb 2015 06:43:48 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41291A1AD0 for ; Mon, 23 Feb 2015 06:43:47 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id bs8so17567024wib.4 for ; Mon, 23 Feb 2015 06:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=25Tgfo5Fd0tEb3RURmF6Ut0eD73O/ldnIoTp2ls09CU=; b=La4pNCy+K/a7MRIhFKfmW24BZJYBrQQ/7AyQjuri/hTLFHfZMr5Y7PuVgg0sWi+RpN 9qISXjYKeFS7r8bBhG3hjR+QuN1bSyYG9y7sF1mPTcIg2JEXGgeabE42djc/pMaaXeKY JOsZGvou57FEFOESINDP8z2RDbLRVYCw/0qQ6lOcDNu6T6Ffq3OIlPPedxk7bf7MU8Jb ZkCFdGg4GbHUt/lqatihgfMTcvN20qFgb+rz2kzOiGE446iJRAheSufGE9yHPPk7AGaH QPTMdueTWSjqJK2hHhskNLjB+FxYbL/tPN22KPfWH8dyjxV4Gi7/KIeaBK7jysxeEPWI rD2w== X-Received: by 10.194.186.200 with SMTP id fm8mr23062810wjc.138.1424702626536; Mon, 23 Feb 2015 06:43:46 -0800 (PST) Received: from RoniE (bzq-79-177-192-183.red.bezeqint.net. [79.177.192.183]) by mx.google.com with ESMTPSA id n1sm16172266wib.11.2015.02.23.06.43.45 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Feb 2015 06:43:45 -0800 (PST) From: "Roni Even" To: Date: Mon, 23 Feb 2015 16:43:43 +0200 Message-ID: <02eb01d04f77$2047e6f0$60d7b4d0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EC_01D04F87.E3D15330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBPdxzMF6BMTQNsT3+3vpeXXBY9Xg== Content-Language: en-us Archived-At: Subject: [AVTCORE] call for AVTcore agenda requests X-BeenThere: avt@ietf.org 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: Mon, 23 Feb 2015 14:43:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02EC_01D04F87.E3D15330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The preliminary agenda of IETF-92 was published. The AVTCORE WG meeting is scheduled as follows: Tuesday, March 24, 2015 1300-15000 Afternoon Session I Venetian RAI avtcore Audio/Video Transport Core Maintenance WG Note that this scheduling is subject to change. Please send the chairs your requests for agenda items. Thanks and Regards, Roni Even AVTCORE co-chair ------=_NextPart_000_02EC_01D04F87.E3D15330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The = preliminary agenda of IETF-92 was published. The AVTCORE WG meeting is = scheduled as follows:

 

Tuesday, = March 24, 2015

1300-15000  = Afternoon Session I

Venetian     =             RAI =             = avtcore     =             &= nbsp;       Audio/Video Transport Core = Maintenance WG

 

 

Note that = this scheduling is subject to change.

 

Please send = the chairs your requests for agenda items.

 

Thanks and = Regards,

 

Roni Even

AVTCORE = co-chair

 

------=_NextPart_000_02EC_01D04F87.E3D15330-- From nobody Mon Feb 23 08:13:22 2015 Return-Path: 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 B88A31A1B96 for ; Mon, 23 Feb 2015 08:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 TzpbBGayqH2o for ; Mon, 23 Feb 2015 08:13:19 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9154A1A1B81 for ; Mon, 23 Feb 2015 08:13:16 -0800 (PST) X-AuditID: c1b4fb30-f79626d000003cf6-48-54eb519a2867 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CB.9C.15606.A915BE45; Mon, 23 Feb 2015 17:13:14 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.210.2; Mon, 23 Feb 2015 17:13:13 +0100 Message-ID: <54EB5198.2070803@ericsson.com> Date: Mon, 23 Feb 2015 17:13:12 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Colin Perkins References: <54E59970.6040804@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyM+Jvje6swNchBj2PTCxe9qxkt1j+8gSj xYwTHA7MHmeXTWXymHb/PpvHkiU/mQKYo7hsUlJzMstSi/TtErgyJjxYylhwVafi5oFZjA2M N5S7GDk5JARMJK59XM0OYYtJXLi3nq2LkYtDSOAIo0R391pWCGc5o8S+GY+ZQKp4BbQl3j0/ CdbBIqAq8WbBWzCbTcBC4uaPRjYQW1QgWGLx86esEPWCEidnPmEBsUWA6ncc/8fYxcjBwSxg KTH1qx5IWFjATWLb1r9g5UICCRItG7qZQWxOAUeJb1c/gcWZBQwkjiyaA2XLSzRvnc0MUa8t 0dDUwTqBUXAWkm2zkLTMQtKygJF5FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgAB/c8ttg B+PL546HGAU4GJV4eDdMfxUixJpYVlyZe4hRmoNFSZzXzvhQiJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQbGhIQ1qssVMyMrKjcsuyPe7hbIdDtm+WrzN/b2D/7dNdim35Ym6z7XaslHrzaF 327mDZIPV59a/UFPUWp36rXVuXxrTENk9ZRXbGC+L1N/3Hr7qvO2GsZxU59p+SQEb31S9HFG 2p2df/9OMz7by6t0dHHu/dtrnVrbgo3vbVx/qjg+4kFzbuwdJZbijERDLeai4kQAgHva7kEC AAA= Archived-At: Cc: varun@comnet.tkk.fi, IETF AVTCore WG Subject: Re: [AVTCORE] My comments on draft-ietf-avtcore-rtp-circuit-breakers-08 X-BeenThere: avt@ietf.org 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: Mon, 23 Feb 2015 16:13:21 -0000 On 2015-02-20 17:50, Colin Perkins wrote: > Hi, > > On 19 Feb 2015, at 08:06, Magnus Westerlund wrote: > >> Hi, >> >> I have just reviewed the latest version of circuit breakers and have the >> following feedback. >> >> I think the document has improved since I last reviewed it (-05) but I >> think the following issue is not yet addressed from my previous review. >> >>> 7) Section 5: >>> >>> As there is a difference between CB #1 and #3 and #2 that has to do >>> with that the first (#1 and #3) uses incoming RTCP reports and that #2 >>> uses the CB implementers estimate of what the regular reporting >>> interval is. Thus, I wonder if there needs to exist include a >>> reflection over t_rr_int as well as the RTCP SSRC timeout calculation >>> that we recommend to use 5 seconds as fixed minimal value in those >>> calculations (if 5 sec larger than t_rr_int). >> >> I will see if I can propose some text to address this. > > I’m not sure how T_tt_interval affects the performance, so > suggestions would be welcomed. So the impact that T_rr_int has on the AVPF implementation is to limiting the regular reporting (without any feedback) to no more often than a randomized [0.5,1.5] of T_rr_int per reporting interval. As the CB are based on the regular reporting, the choice of T_rr_int will affect the CB behaviour. Thus we have a potential issue with CB#2 and RTCP timeout. This breaker must clearly take T_rr_int into account as that affect the RTCP regular transmission interval. Thus, a media sender can't use its basic Td calculation to determine how many reporting intervals that passed, i.e this text from section 4.2: When calculating the timeout, the deterministic RTCP reporting interval, Td, without the randomization factor, and with a fixed minimum interval Tmin=5 seconds) SHOULD be used. The rationale for this choice of timeout is as described in Section 6.2 of RFC 3550 [RFC3550]. But, this could only be affected if T_rr_int is larger than 2,25 seconds. This is an approximation of where T_rr_int will result in any potential longer reporting intervals than what Tmin = 5 does. This approximation is based on the issue discussed in Section 6.1.1 of https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream/ However, that case is a worst case and in fact Section 6.1.3 do recommends a T_rr_int value of 4 for compatibility with AVP as that balances the timeout issues in both directions if the AVPF does not follow https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream/ This value of T_rr_int will increase the chance of being timed out following the above calculation slightly, and primarily in the case when the bandwidth and participant numbers results in a Td close to T_rr_int. Thus, I think one possible resolution is simply to forbid using T_rr_int larger than 4 seconds in combination with circuit breakers. > >> I also think there is need for scaling the number of reporting intervals >> it takes to trigger the circuit breakers when using AVPF or reduced >> minimum. Especially for AVPF there will be a lot of false triggering due >> to relatively short time intervals that the circuit breakers will sample >> over. > > I think it’s clear we should scale the number of reporting intervals needed to trigger the circuit breaker inversely with the duration of the reporting interval, so it takes a roughly constant amount of time to trigger. We need to write this up and simulate it’s performance. > > Do you see RTP/AVPF impacting this differently to the impact of > using the reduced minimum interval? (Or is this the T_rr_interval issue?) T_rr_int will affect the number of reporting intervals one can expect (statistically) during a certain time period within a given RTP session. I think the scaling will resolve this potential concern as long as T_rr_int is smaller than 4 seconds. I would note that there is one difficulty for the scaling. If one has bandwidth to have Td value of 0.1 seconds and a T_rr_int of 3 seconds, then the number of actually sent regular reports will depend on how much feedback one needed to send. Especially in combination with Reduced size RTCP. Because if reduced size RTP is used for all early packets, then the regular RTCP packets are the ones being counted towards the CB. And RFC 4585 in Section 4.5.3 contains this implementation specific behaviour when one has FB to send and comes upon a transmission point with a T_rr_int != 0. 2b) If t_rr_last + T_rr_current_interval > tn and RTCP FB messages have been stored and are awaiting transmission, an RTCP packet MUST be scheduled for transmission at tn. This RTCP packet MAY be a minimal or a Regular RTCP packet (at the discretion of the implementer), and the compound RTCP packet MUST include the stored RTCP FB message(s). t_rr_last MUST remain unchanged. Thus, the number of RTCP packets that contains RR or SR can and will likely vary over a time interval even if the other parameters affecting report interval is fixed. 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 ---------------------------------------------------------------------- From nobody Mon Feb 23 15:16:44 2015 Return-Path: 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 A9CCA1A1A62; Mon, 23 Feb 2015 15:16:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 eUuE2Ofq52KX; Mon, 23 Feb 2015 15:16:41 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C147C1A1A45; Mon, 23 Feb 2015 15:16:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4065; q=dns/txt; s=iport; t=1424733400; x=1425943000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7oKSRzk4xNcnC65Qx//foYge+coLDLPO3XkQEnhEtvQ=; b=dBT1I4pnsJxyteF1lpzOWOQvd5cyiSATp9HwytT7gB7OIWDFxc0xA/4Z YpftaTk7qZL4UZmjNnRAaEe8+rAXbmkx6/HPcBB/pwtVFKFMRA9JJ/bvP +rUzRTlkl7W0dvEGM6JX/fKP3azI+zkxOokRpc3Sa1SBEhcbfJ6CFVb+9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApBQDOs+tU/5BdJa1bgwZSWgTDCwqFcAKBJEMBAQEBAQF8hBABAQQBAQEJbQ4CAgEIGCcHGwwLFBECBAENBYgvDdMsAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwQEiw+EbgeEKwWFYoQ6hTaJQ5MzIoIygTxvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,634,1418083200"; d="scan'208";a="398501850" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-6.cisco.com with ESMTP; 23 Feb 2015 23:16:40 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1NNGeuc004409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Feb 2015 23:16:40 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 23 Feb 2015 17:16:39 -0600 From: "Mo Zanaty (mzanaty)" To: Magnus Westerlund , "David McGrew (mcgrew)" , John Mattsson Thread-Topic: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) Thread-Index: AQHQT77GzgiGf2lZgk+Ajujhv6SsqA== Date: Mon, 23 Feb 2015 23:16:39 +0000 Message-ID: References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> <54E608E5.1070102@ericsson.com> In-Reply-To: <54E608E5.1070102@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.150.30.107] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Stephen Farrell , "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , IETF AVTCore WG , The IESG Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Mon, 23 Feb 2015 23:16:42 -0000 I am fine with keeping only these 6 suites by eliminating 96 bit auth tags. However, I do wonder if any SRTP application will ever use CCM with full length tags or 256 bit keys, rather than using GCM. If not, another 3 suites can be eliminated, leaving only 3 suites: AEAD_AES_256_GCM AEAD_AES_128_GCM AEAD_AES_128_CCM_8/64 I also agree with John that 64 bit auth tags are sufficient for SRTP even using GCM. The NIST recommendation is key rotation after roughly 2^40 packets of 1.5 KB, which is many years for a 100 Mbps SRTP stream! And this is to protect against an attack where the receiver/victim notifies the sender/attacker of every auth failure, which is not possible in SRTP since no such feedback exists. And as John mentioned, the DOS of so many forged packets and auth failure messages would be a much worse consequence than compromising the auth tag. So I would also be fine with only 64 bit auth tags for both GCM and CCM. AEAD_AES_256_GCM_8/64 AEAD_AES_128_GCM_8/64 AEAD_AES_128_CCM_8/64 If we go this final route, I suggest updating section 14.2 with a table for 1.5 KB packets (not just 64 KB), and more concrete guidance on what the security ramifications are. In particular, that these (many) forgeries can only inject random data since the decryption key is unknown. That is, they inject a chosen cipher text but a random plain text after decryption since the decryption key is unknown and not compromised by this auth key attack. The security ramifications of this auth key attack are minor in my opinion, especially relative to the major denial-of-service caused by so many forgeries and auth failure feedback. I would not be fine with anything less than this. One GCM is not sufficient, we need both 128 and 256 bit keys. GCM is not sufficient, we also need CCM (128_8/64). Mo On 2/19/15, 11:01 AM, Magnus Westerlund wrote: On 2015-02-15 15:09, David McGrew wrote: >=20 > My opinion is: it would be best to preserve the existing specification > and implementation work, and retain all ten crypto suite definitions. > But if we want to make SRTP-AEAD be the first instance in which the IETF > will prioritize simplicity over variety and diversity, I=B9m good with > that, because I certainly see the value of simplicity; then my > recommendation would be to eliminate the four 12-octet authentication > versions. That would leave just six crypto suites, with two different > modes of operation, two different key sizes, and two different tag > lengths (but not all tag lengths for all modes), like this: >=20 > srtp-crypto-suite-ext =3D "AEAD_AES_128_GCM" / > "AEAD_AES_256_GCM" / > "AEAD_AES_128_CCM" / > "AEAD_AES_256_CCM" / > "AEAD_AES_128_CCM_8" / > "AEAD_AES_256_CCM_8" / >=20 Stephen, WG Having looked at the feedback provided in this discussion so far, I think the above set of 6 are a reasonable selection without unduly limiting functionality, but removing the four least necessary profiles. My proposal is that if no one is disagreeing with this in the next week (Prior to Feb 26 at 16:30 UTC) we use it. If someone disagrees we hold a discussion at the informal IESG telechat on how to proceed. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From nobody Tue Feb 24 04:06:57 2015 Return-Path: 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 310271A1A00; Tue, 24 Feb 2015 04:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yA0zPQMl4T1O; Tue, 24 Feb 2015 04:06:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6071A19F2; Tue, 24 Feb 2015 04:06:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 715D1BED8; Tue, 24 Feb 2015 12:06:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5ERmPLi_qld; Tue, 24 Feb 2015 12:06:50 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.27.159]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 40184BED4; Tue, 24 Feb 2015 12:06:50 +0000 (GMT) Message-ID: <54EC6956.8090009@cs.tcd.ie> Date: Tue, 24 Feb 2015 12:06:46 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Magnus Westerlund , David McGrew References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> <54E608E5.1070102@ericsson.com> In-Reply-To: <54E608E5.1070102@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , IETF AVTCore WG , The IESG Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Tue, 24 Feb 2015 12:06:55 -0000 We seem to have opinions all over the map on this one. Sorry for making life difficult;-) I guess we'll be discussing it on the informal telechat this Thursday though, so just picking some set then would seem like the best approach. (I'll still briefly argue for the minimal set, but I accept we should just pick something then and be done with this.) S. On 19/02/15 16:01, Magnus Westerlund wrote: > On 2015-02-15 15:09, David McGrew wrote: >> >> My opinion is: it would be best to preserve the existing specification >> and implementation work, and retain all ten crypto suite definitions. >> But if we want to make SRTP-AEAD be the first instance in which the IETF >> will prioritize simplicity over variety and diversity, I’m good with >> that, because I certainly see the value of simplicity; then my >> recommendation would be to eliminate the four 12-octet authentication >> versions. That would leave just six crypto suites, with two different >> modes of operation, two different key sizes, and two different tag >> lengths (but not all tag lengths for all modes), like this: >> >> srtp-crypto-suite-ext = "AEAD_AES_128_GCM" / >> "AEAD_AES_256_GCM" / >> "AEAD_AES_128_CCM" / >> "AEAD_AES_256_CCM" / >> "AEAD_AES_128_CCM_8" / >> "AEAD_AES_256_CCM_8" / >> > > Stephen, WG > > Having looked at the feedback provided in this discussion so far, I > think the above set of 6 are a reasonable selection without unduly > limiting functionality, but removing the four least necessary profiles. > > My proposal is that if no one is disagreeing with this in the next week > (Prior to Feb 26 at 16:30 UTC) we use it. If someone disagrees we hold a > discussion at the informal IESG telechat on how to proceed. > > 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 > ---------------------------------------------------------------------- > From nobody Tue Feb 24 10:07:36 2015 Return-Path: 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 A84671A1BCE; Tue, 24 Feb 2015 10:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 z55j55-njRE5; Tue, 24 Feb 2015 10:07:29 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0EE1A1B9E; Tue, 24 Feb 2015 10:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5808; q=dns/txt; s=iport; t=1424801249; x=1426010849; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eIsBQ7GPQqhsx6o2+LZqbx0tEgHb8yV907sZx+75Fmo=; b=TgI2/+8QgZoj4a8wa2qTqiOuluB+a48FzmIlRmUOvYsrkB5BF6te1ZKo 1e0SudXe8ctRR2rF5PPhtdnNiM0nQrY6r7rowqx3s1hKpL2prjUVYBMxx 32BnuHp/mE5LfMBBAR/h9OPxaolwvyiQcBD1gGJE9UaBOx/N1sCVPeDpZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CEBQBzvexU/4sNJK1bgwZSWgTDEgqFcAKBKkMBAQEBAQF8hBABAQQBAQEJbQ4CAgEIGCcHGwwLFBECBAENBYgvDdRuAQEBAQEBAQEBAQEBAQEBAQEBAQEYBIsPhBdXB4QrBYVkiXKDYIVlgVORZCKCMoE8bwGBAkF/AQEB X-IronPort-AV: E=Sophos;i="5.09,640,1418083200"; d="scan'208";a="398813367" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-4.cisco.com with ESMTP; 24 Feb 2015 18:07:12 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1OI7Cle004870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Feb 2015 18:07:12 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Tue, 24 Feb 2015 12:07:12 -0600 From: "Mo Zanaty (mzanaty)" To: Magnus Westerlund , "David McGrew (mcgrew)" , John Mattsson Thread-Topic: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) Thread-Index: AQHQUFy1yzfApg2NckKwE5Q/GdQjxA== Date: Tue, 24 Feb 2015 18:07:11 +0000 Message-ID: References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> <54E608E5.1070102@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [64.100.32.216] Content-Type: text/plain; charset="windows-1254" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: The IESG , "avtcore-chairs@tools.ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , IETF AVTCore WG , Stephen Farrell Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Tue, 24 Feb 2015 18:07:34 -0000 I would like to point out the strongest argument for the sufficiency of 64 bit auth tags, taken directly from the SRTP RFC. http://tools.ietf.org/html/rfc3711#section-9.2 ...when 2^48 SRTP packets or 2^31 SRTCP packets have been secured with the same key (whichever occurs before), the key management MUST be called to provide new master key(s)=85 Note: in most typical applications (assuming at least one RTCP packet for every 128,000 RTP packets), it will be the SRTCP index that first reaches the upper limit, although the time until this occurs is very long: even at 200 SRTCP packets/sec, the 2^31 index space of SRTCP is enough to secure approximately 4 months of communication. This should make it clear that any potential weakness in GCM auth that reduces the effective strength of 64 bit auth tags by 7-12 bits (for 2-64 KB packets) is moot due to the SRTCP 31 bit limit and SRTP 48 bit limit. An attacker would hit rekey criteria before achieving 0.1% chance of a single successfully forged packet (of chosen cipher text but random plain text since decryption keys are not compromised). DOS criteria would likely be hit much sooner at such extreme numbers of packets. Furthermore, this reduced effective strength of auth tags only applies against attacks which are anyway impossible in SRTP due to no auth failure feedback. So 64 bit auth tags should be sufficient for SRTP applications. (As long as the auth transform has no truncation issues.) Mo On 2/23/15, 6:16 PM, Mo Zanaty (mzanaty) wrote: I am fine with keeping only these 6 suites by eliminating 96 bit auth tags. However, I do wonder if any SRTP application will ever use CCM with full length tags or 256 bit keys, rather than using GCM. If not, another 3 suites can be eliminated, leaving only 3 suites: AEAD_AES_256_GCM AEAD_AES_128_GCM AEAD_AES_128_CCM_8/64 I also agree with John that 64 bit auth tags are sufficient for SRTP even using GCM. The NIST recommendation is key rotation after roughly 2^40 packets of 1.5 KB, which is many years for a 100 Mbps SRTP stream! And this is to protect against an attack where the receiver/victim notifies the sender/attacker of every auth failure, which is not possible in SRTP since no such feedback exists. And as John mentioned, the DOS of so many forged packets and auth failure messages would be a much worse consequence than compromising the auth tag. So I would also be fine with only 64 bit auth tags for both GCM and CCM. AEAD_AES_256_GCM_8/64 AEAD_AES_128_GCM_8/64 AEAD_AES_128_CCM_8/64 If we go this final route, I suggest updating section 14.2 with a table for 1.5 KB packets (not just 64 KB), and more concrete guidance on what the security ramifications are. In particular, that these (many) forgeries can only inject random data since the decryption key is unknown. That is, they inject a chosen cipher text but a random plain text after decryption since the decryption key is unknown and not compromised by this auth key attack. The security ramifications of this auth key attack are minor in my opinion, especially relative to the major denial-of-service caused by so many forgeries and auth failure feedback. I would not be fine with anything less than this. One GCM is not sufficient, we need both 128 and 256 bit keys. GCM is not sufficient, we also need CCM (128_8/64). Mo On 2/19/15, 11:01 AM, Magnus Westerlund wrote: On 2015-02-15 15:09, David McGrew wrote: >=20 > My opinion is: it would be best to preserve the existing specification > and implementation work, and retain all ten crypto suite definitions. > But if we want to make SRTP-AEAD be the first instance in which the IETF > will prioritize simplicity over variety and diversity, I=B9m good with > that, because I certainly see the value of simplicity; then my > recommendation would be to eliminate the four 12-octet authentication > versions. That would leave just six crypto suites, with two different > modes of operation, two different key sizes, and two different tag > lengths (but not all tag lengths for all modes), like this: >=20 > srtp-crypto-suite-ext =3D "AEAD_AES_128_GCM" / > "AEAD_AES_256_GCM" / > "AEAD_AES_128_CCM" / > "AEAD_AES_256_CCM" / > "AEAD_AES_128_CCM_8" / > "AEAD_AES_256_CCM_8" / >=20 Stephen, WG Having looked at the feedback provided in this discussion so far, I think the above set of 6 are a reasonable selection without unduly limiting functionality, but removing the four least necessary profiles. My proposal is that if no one is disagreeing with this in the next week (Prior to Feb 26 at 16:30 UTC) we use it. If someone disagrees we hold a discussion at the informal IESG telechat on how to proceed. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From nobody Wed Feb 25 00:48:56 2015 Return-Path: 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 F0AC81A702F; Wed, 25 Feb 2015 00:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 5yUQvElJfM5z; Wed, 25 Feb 2015 00:48:52 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8B751A7026; Wed, 25 Feb 2015 00:48:50 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-41-54ed8c705226 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6F.94.24955.07C8DE45; Wed, 25 Feb 2015 09:48:48 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.112]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0210.002; Wed, 25 Feb 2015 09:48:48 +0100 From: John Mattsson To: Stephen Farrell , Magnus Westerlund , "Mo Zanaty (mzanaty)" Thread-Topic: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) Thread-Index: AQHQQh5oJgFl6m3W+E63IOWS9grYL5zoLHSAgAC2aACAAPjAgIAH4VuAgAZou4CABsLbgIABO96AgAD2VAA= Date: Wed, 25 Feb 2015 08:48:47 +0000 Message-ID: <28669AE0-DF31-4910-BD97-5B319BFD1398@ericsson.com> References: <20141029122825.18943.78129.idtracker@ietfa.amsl.com> <3C4AAD4B5304AB44A6BA85173B4675CABC709A18@MSMR-GH1-UEA03.corp.nsa.gov> <545151F9.9050502@cs.tcd.ie> <54516572.8020601@cs.tcd.ie> <5451737B.6060504@cs.tcd.ie> <2D4BE3ED-840A-444C-9D18-09BC3D937D64@cisco.com> <54CA135D.3020304@ericsson.com> <54D4D840.4080808@cs.tcd.ie> <54D8A297.9090505@ericsson.com> <54D93B9A.9090409@cs.tcd.ie> <54DA0C45.2030609@ericsson.com> <54E608E5.1070102@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_28669AE0DF314910BD975B319BFD1398ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM+JvjW5Bz9sQg72fjS1e9qxkt1j57Tqr xdojiRYz/kxktri66g+7xYsHc5gspu+9xu7A7jHl90ZWj7XdV9k8liz5yeTx5fJntgCWKC6b lNSczLLUIn27BK6MQ0desRZsPc1YcWDLfZYGxqZjjF2MnBwSAiYS/77vYYKwxSQu3FvP1sXI xSEkcIRR4tD8DnYIZwmjxPVXz1lAqtgEDCTm7mkAqxIRmMAo8f/vFWYQh1lgCpPEmZVdzCBV wgIZEj/737KC2CICmRJH386HspMknu78AraPRUBV4sbGF2BxXgF7iU8dq1gg1u1llZh/+gc7 SIJTQF9i7+PtYDYj0IHfT60Ba2YWEJe49WQ+1OECEkv2nGeGsEUlXj7+xwphK0pcnb4cqj5Z 4tXv2cwQywQlTs58wjKBUXQWklGzkJTNQlI2i5EDKK4psX6XPkSJosSU7ofsELaGROucuVC2 tcS2AyeYkdUsYORYxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREY1Qe3/FbdwXj5jeMhRgEO RiUe3gLFNyFCrIllxZW5hxilOViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCU mK7/LPfri+9shm97Xi3n0Uy6VO+Xf678WcRped27+04JSP8TdnwbJFba6G9ju7JSS+q8zBXO T98muH+YzvNR7eqFG959tw3OOX9P2uZxdSqX0YmHHZdWd9521rLlPLHK/LFSt4eg8FH/S8aP 1YunH+76s0hKVYM9RF323hfPGb45edYZD38rsRRnJBpqMRcVJwIA7cW2I8sCAAA= Archived-At: Cc: "avtcore-chairs@tools.ietf.org" , "David McGrew \(mcgrew\)" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" , IETF AVTCore WG , The IESG Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS) X-BeenThere: avt@ietf.org 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: Wed, 25 Feb 2015 08:48:55 -0000 --_000_28669AE0DF314910BD975B319BFD1398ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBmaW5lIHdpdGgga2VlcGluZyBvbmx5IHRoZSA2IHN1aXRlcyBzdWdnZXN0ZWQgYnkgRGF2 aWQuDQoNCk9uIDIwMTUtMDItMjQgTW8gWmFuYXR5IHdyb3RlOg0KPiBJIGFsc28gYWdyZWUgd2l0 aCBKb2huIHRoYXQgNjQgYml0IGF1dGggdGFncyBhcmUgc3VmZmljaWVudCBmb3IgU1JUUCBldmVu IHVzaW5nIEdDTS4NCg0KVGhlIHJlYXNvbiBHQ01fNjQgd2FzIHJlbW92ZWQgd2FzIGJlY2F1c2Ug SSBwb2ludGVkIG91dCB0aGF0IHRoZSBkcmFmdCBzaG91bGQgZm9sbG93IHRoZSBOSVNUIHJlcXVp cmVtZW50cyBpbiBTUCA4MDAtMzhELCBBcHBlbmRpeCBDLiBLZXZpbiBhbmQgRGF2aWQgY2hvc2Ug dG8gcmVtb3ZlIEdDTV82NCBpbnN0ZWFkLg0KDQpDaGVlcnMsDQpKb2huDQoNCk9uIDI0IEZlYiAy MDE1LCBhdCAxOTowNywgTW8gWmFuYXR5IChtemFuYXR5KSA8bXphbmF0eUBjaXNjby5jb208bWFp bHRvOm16YW5hdHlAY2lzY28uY29tPj4gd3JvdGU6DQoNCkkgd291bGQgbGlrZSB0byBwb2ludCBv dXQgdGhlIHN0cm9uZ2VzdCBhcmd1bWVudCBmb3IgdGhlIHN1ZmZpY2llbmN5IG9mIDY0DQpiaXQg YXV0aCB0YWdzLCB0YWtlbiBkaXJlY3RseSBmcm9tIHRoZSBTUlRQIFJGQy4NCg0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjMzcxMSNzZWN0aW9uLTkuMg0KDQogIC4uLndoZW4gMl40OCBT UlRQIHBhY2tldHMgb3IgMl4zMSBTUlRDUCBwYWNrZXRzIGhhdmUgYmVlbiBzZWN1cmVkDQogIHdp dGggdGhlIHNhbWUga2V5ICh3aGljaGV2ZXIgb2NjdXJzIGJlZm9yZSksIHRoZSBrZXkgbWFuYWdl bWVudCBNVVNUDQogIGJlIGNhbGxlZCB0byBwcm92aWRlIG5ldyBtYXN0ZXIga2V5KHMp4oCmDQoN CiAgTm90ZTogaW4gbW9zdCB0eXBpY2FsIGFwcGxpY2F0aW9ucyAoYXNzdW1pbmcgYXQgbGVhc3Qg b25lIFJUQ1AgcGFja2V0DQogIGZvciBldmVyeSAxMjgsMDAwIFJUUCBwYWNrZXRzKSwgaXQgd2ls bCBiZSB0aGUgU1JUQ1AgaW5kZXggdGhhdCBmaXJzdA0KICByZWFjaGVzIHRoZSB1cHBlciBsaW1p dCwgYWx0aG91Z2ggdGhlIHRpbWUgdW50aWwgdGhpcyBvY2N1cnMgaXMgdmVyeQ0KICBsb25nOiBl dmVuIGF0IDIwMCBTUlRDUCBwYWNrZXRzL3NlYywgdGhlIDJeMzEgaW5kZXggc3BhY2Ugb2YgU1JU Q1AgaXMNCiAgZW5vdWdoIHRvIHNlY3VyZSBhcHByb3hpbWF0ZWx5IDQgbW9udGhzIG9mIGNvbW11 bmljYXRpb24uDQoNCg0KVGhpcyBzaG91bGQgbWFrZSBpdCBjbGVhciB0aGF0IGFueSBwb3RlbnRp YWwgd2Vha25lc3MgaW4gR0NNIGF1dGggdGhhdA0KcmVkdWNlcyB0aGUgZWZmZWN0aXZlIHN0cmVu Z3RoIG9mIDY0IGJpdCBhdXRoIHRhZ3MgYnkgNy0xMiBiaXRzIChmb3IgMi02NA0KS0IgcGFja2V0 cykgaXMgbW9vdCBkdWUgdG8gdGhlIFNSVENQIDMxIGJpdCBsaW1pdCBhbmQgU1JUUCA0OCBiaXQg bGltaXQuDQpBbiBhdHRhY2tlciB3b3VsZCBoaXQgcmVrZXkgY3JpdGVyaWEgYmVmb3JlIGFjaGll dmluZyAwLjElIGNoYW5jZSBvZiBhDQpzaW5nbGUgc3VjY2Vzc2Z1bGx5IGZvcmdlZCBwYWNrZXQg KG9mIGNob3NlbiBjaXBoZXIgdGV4dCBidXQgcmFuZG9tIHBsYWluDQp0ZXh0IHNpbmNlIGRlY3J5 cHRpb24ga2V5cyBhcmUgbm90IGNvbXByb21pc2VkKS4gRE9TIGNyaXRlcmlhIHdvdWxkIGxpa2Vs eQ0KYmUgaGl0IG11Y2ggc29vbmVyIGF0IHN1Y2ggZXh0cmVtZSBudW1iZXJzIG9mIHBhY2tldHMu IEZ1cnRoZXJtb3JlLCB0aGlzDQpyZWR1Y2VkIGVmZmVjdGl2ZSBzdHJlbmd0aCBvZiBhdXRoIHRh Z3Mgb25seSBhcHBsaWVzIGFnYWluc3QgYXR0YWNrcyB3aGljaA0KYXJlIGFueXdheSBpbXBvc3Np YmxlIGluIFNSVFAgZHVlIHRvIG5vIGF1dGggZmFpbHVyZSBmZWVkYmFjay4NCg0KU28gNjQgYml0 IGF1dGggdGFncyBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgU1JUUCBhcHBsaWNhdGlvbnMuDQoo QXMgbG9uZyBhcyB0aGUgYXV0aCB0cmFuc2Zvcm0gaGFzIG5vIHRydW5jYXRpb24gaXNzdWVzLikN Cg0KTW8NCg0KDQpPbiAyLzIzLzE1LCA2OjE2IFBNLCBNbyBaYW5hdHkgKG16YW5hdHkpIDxtemFu YXR5QGNpc2NvLmNvbT4gd3JvdGU6DQoNCkkgYW0gZmluZSB3aXRoIGtlZXBpbmcgb25seSB0aGVz ZSA2IHN1aXRlcyBieSBlbGltaW5hdGluZyA5NiBiaXQgYXV0aCB0YWdzLg0KDQpIb3dldmVyLCBJ IGRvIHdvbmRlciBpZiBhbnkgU1JUUCBhcHBsaWNhdGlvbiB3aWxsIGV2ZXIgdXNlIENDTSB3aXRo IGZ1bGwNCmxlbmd0aCB0YWdzIG9yIDI1NiBiaXQga2V5cywgcmF0aGVyIHRoYW4gdXNpbmcgR0NN LiBJZiBub3QsIGFub3RoZXIgMw0Kc3VpdGVzIGNhbiBiZSBlbGltaW5hdGVkLCBsZWF2aW5nIG9u bHkgMyBzdWl0ZXM6DQoNCkFFQURfQUVTXzI1Nl9HQ00NCkFFQURfQUVTXzEyOF9HQ00NCkFFQURf QUVTXzEyOF9DQ01fOC82NA0KDQpJIGFsc28gYWdyZWUgd2l0aCBKb2huIHRoYXQgNjQgYml0IGF1 dGggdGFncyBhcmUgc3VmZmljaWVudCBmb3IgU1JUUCBldmVuDQp1c2luZyBHQ00uIFRoZSBOSVNU IHJlY29tbWVuZGF0aW9uIGlzIGtleSByb3RhdGlvbiBhZnRlciByb3VnaGx5IDJeNDANCnBhY2tl dHMgb2YgMS41IEtCLCB3aGljaCBpcyBtYW55IHllYXJzIGZvciBhIDEwMCBNYnBzIFNSVFAgc3Ry ZWFtISBBbmQNCnRoaXMgaXMgdG8gcHJvdGVjdCBhZ2FpbnN0IGFuIGF0dGFjayB3aGVyZSB0aGUg cmVjZWl2ZXIvdmljdGltIG5vdGlmaWVzDQp0aGUgc2VuZGVyL2F0dGFja2VyIG9mIGV2ZXJ5IGF1 dGggZmFpbHVyZSwgd2hpY2ggaXMgbm90IHBvc3NpYmxlIGluIFNSVFANCnNpbmNlIG5vIHN1Y2gg ZmVlZGJhY2sgZXhpc3RzLiBBbmQgYXMgSm9obiBtZW50aW9uZWQsIHRoZSBET1Mgb2Ygc28gbWFu eQ0KZm9yZ2VkIHBhY2tldHMgYW5kIGF1dGggZmFpbHVyZSBtZXNzYWdlcyB3b3VsZCBiZSBhIG11 Y2ggd29yc2UgY29uc2VxdWVuY2UNCnRoYW4gY29tcHJvbWlzaW5nIHRoZSBhdXRoIHRhZy4NCg0K U28gSSB3b3VsZCBhbHNvIGJlIGZpbmUgd2l0aCBvbmx5IDY0IGJpdCBhdXRoIHRhZ3MgZm9yIGJv dGggR0NNIGFuZCBDQ00uDQoNCkFFQURfQUVTXzI1Nl9HQ01fOC82NA0KQUVBRF9BRVNfMTI4X0dD TV84LzY0DQpBRUFEX0FFU18xMjhfQ0NNXzgvNjQNCg0KSWYgd2UgZ28gdGhpcyBmaW5hbCByb3V0 ZSwgSSBzdWdnZXN0IHVwZGF0aW5nIHNlY3Rpb24gMTQuMiB3aXRoIGEgdGFibGUNCmZvciAxLjUg S0IgcGFja2V0cyAobm90IGp1c3QgNjQgS0IpLCBhbmQgbW9yZSBjb25jcmV0ZSBndWlkYW5jZSBv biB3aGF0DQp0aGUgc2VjdXJpdHkgcmFtaWZpY2F0aW9ucyBhcmUuIEluIHBhcnRpY3VsYXIsIHRo YXQgdGhlc2UgKG1hbnkpIGZvcmdlcmllcw0KY2FuIG9ubHkgaW5qZWN0IHJhbmRvbSBkYXRhIHNp bmNlIHRoZSBkZWNyeXB0aW9uIGtleSBpcyB1bmtub3duLiBUaGF0IGlzLA0KdGhleSBpbmplY3Qg YSBjaG9zZW4gY2lwaGVyIHRleHQgYnV0IGEgcmFuZG9tIHBsYWluIHRleHQgYWZ0ZXIgZGVjcnlw dGlvbg0Kc2luY2UgdGhlIGRlY3J5cHRpb24ga2V5IGlzIHVua25vd24gYW5kIG5vdCBjb21wcm9t aXNlZCBieSB0aGlzIGF1dGgga2V5DQphdHRhY2suIFRoZSBzZWN1cml0eSByYW1pZmljYXRpb25z IG9mIHRoaXMgYXV0aCBrZXkgYXR0YWNrIGFyZSBtaW5vciBpbiBteQ0Kb3BpbmlvbiwgZXNwZWNp YWxseSByZWxhdGl2ZSB0byB0aGUgbWFqb3IgZGVuaWFsLW9mLXNlcnZpY2UgY2F1c2VkIGJ5IHNv DQptYW55IGZvcmdlcmllcyBhbmQgYXV0aCBmYWlsdXJlIGZlZWRiYWNrLg0KDQpJIHdvdWxkIG5v dCBiZSBmaW5lIHdpdGggYW55dGhpbmcgbGVzcyB0aGFuIHRoaXMuIE9uZSBHQ00gaXMgbm90DQpz dWZmaWNpZW50LCB3ZSBuZWVkIGJvdGggMTI4IGFuZCAyNTYgYml0IGtleXMuIEdDTSBpcyBub3Qg c3VmZmljaWVudCwgd2UNCmFsc28gbmVlZCBDQ00gKDEyOF84LzY0KS4NCg0KTW8NCg0KDQoNCk9u IDIvMTkvMTUsIDExOjAxIEFNLCBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVzLndlc3Rlcmx1bmRA ZXJpY3Nzb24uY29tPg0Kd3JvdGU6DQoNCk9uIDIwMTUtMDItMTUgMTU6MDksIERhdmlkIE1jR3Jl dyB3cm90ZToNCg0KTXkgb3BpbmlvbiBpczogaXQgd291bGQgYmUgYmVzdCB0byBwcmVzZXJ2ZSB0 aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbg0KYW5kIGltcGxlbWVudGF0aW9uIHdvcmssIGFuZCBy ZXRhaW4gYWxsIHRlbiBjcnlwdG8gc3VpdGUgZGVmaW5pdGlvbnMuDQpCdXQgaWYgd2Ugd2FudCB0 byBtYWtlIFNSVFAtQUVBRCBiZSB0aGUgZmlyc3QgaW5zdGFuY2UgaW4gd2hpY2ggdGhlIElFVEYN CndpbGwgIHByaW9yaXRpemUgc2ltcGxpY2l0eSBvdmVyIHZhcmlldHkgYW5kIGRpdmVyc2l0eSwg ScK5bSBnb29kIHdpdGgNCnRoYXQsIGJlY2F1c2UgSSBjZXJ0YWlubHkgc2VlIHRoZSB2YWx1ZSBv ZiBzaW1wbGljaXR5OyB0aGVuIG15DQpyZWNvbW1lbmRhdGlvbiB3b3VsZCBiZSB0byBlbGltaW5h dGUgdGhlIGZvdXIgMTItb2N0ZXQgYXV0aGVudGljYXRpb24NCnZlcnNpb25zLiAgVGhhdCB3b3Vs ZCBsZWF2ZSBqdXN0IHNpeCBjcnlwdG8gc3VpdGVzLCB3aXRoIHR3byBkaWZmZXJlbnQNCm1vZGVz IG9mIG9wZXJhdGlvbiwgdHdvIGRpZmZlcmVudCBrZXkgc2l6ZXMsIGFuZCB0d28gZGlmZmVyZW50 IHRhZw0KbGVuZ3RocyAoYnV0IG5vdCBhbGwgdGFnIGxlbmd0aHMgZm9yIGFsbCBtb2RlcyksIGxp a2UgdGhpczoNCg0KICAgICBzcnRwLWNyeXB0by1zdWl0ZS1leHQgPSAiQUVBRF9BRVNfMTI4X0dD TSIgICAgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiQUVBRF9BRVNfMjU2X0dDTSIg ICAgLw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiQUVBRF9BRVNfMTI4X0NDTSIgICAg Lw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiQUVBRF9BRVNfMjU2X0NDTSIgICAgLw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiQUVBRF9BRVNfMTI4X0NDTV84IiAgLw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAiQUVBRF9BRVNfMjU2X0NDTV84IiAgLw0KDQoNClN0 ZXBoZW4sIFdHDQoNCkhhdmluZyBsb29rZWQgYXQgdGhlIGZlZWRiYWNrIHByb3ZpZGVkIGluIHRo aXMgZGlzY3Vzc2lvbiBzbyBmYXIsIEkNCnRoaW5rIHRoZSBhYm92ZSBzZXQgb2YgNiBhcmUgYSBy ZWFzb25hYmxlIHNlbGVjdGlvbiB3aXRob3V0IHVuZHVseQ0KbGltaXRpbmcgZnVuY3Rpb25hbGl0 eSwgYnV0IHJlbW92aW5nIHRoZSBmb3VyIGxlYXN0IG5lY2Vzc2FyeSBwcm9maWxlcy4NCg0KTXkg cHJvcG9zYWwgaXMgdGhhdCBpZiBubyBvbmUgaXMgZGlzYWdyZWVpbmcgd2l0aCB0aGlzIGluIHRo ZSBuZXh0IHdlZWsNCihQcmlvciB0byBGZWIgMjYgYXQgMTY6MzAgVVRDKSB3ZSB1c2UgaXQuIElm IHNvbWVvbmUgZGlzYWdyZWVzIHdlIGhvbGQgYQ0KZGlzY3Vzc2lvbiBhdCB0aGUgaW5mb3JtYWwg SUVTRyB0ZWxlY2hhdCBvbiBob3cgdG8gcHJvY2VlZC4NCg0KQ2hlZXJzDQoNCk1hZ251cyBXZXN0 ZXJsdW5kDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClNlcnZpY2VzLCBNZWRpYSBhbmQgTmV0d29yayBmZWF0 dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24g QUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpGw6Ryw7ZnYXRhbiA2 ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KU0UtMTY0IDgwIFN0b2Nr aG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRpby9WaWRlbyBUcmFu c3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KDQoNCg== --_000_28669AE0DF314910BD975B319BFD1398ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0584050DE44C2148BCDF227C0E738C03@ericsson.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBhcHBsZS1jb250ZW50LWVk aXRlZD0idHJ1ZSIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJvcnBoYW5zOiBhdXRvOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd2lkb3dzOiBhdXRvOyIgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgb3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdpZG93czogYXV0bzsgbWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyIgY2xhc3M9IiI+DQo8Zm9udCBmYWNlPSJBcmlhbCwgc2Fucy1z ZXJpZiIgY2xhc3M9IiI+SSBhbSBmaW5lIHdpdGgga2VlcGluZyBvbmx5IHRoZSA2IHN1aXRlcyBz dWdnZXN0ZWQgYnkgRGF2aWQuPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB3aWRvd3M6IGF1dG87IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHdpZG93czogYXV0bzsgbWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyIgY2xh c3M9IiI+DQpPbiAyMDE1LTAyLTI0IE1vIFphbmF0eSB3cm90ZTo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd2lkb3dzOiBhdXRvOyBtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IiBjbGFzcz0iIj4NCiZndDsgSSBhbHNvIGFncmVlIHdpdGggSm9obiB0aGF0IDY0 IGJpdCBhdXRoIHRhZ3MgYXJlIHN1ZmZpY2llbnQgZm9yIFNSVFAgZXZlbiZuYnNwO3VzaW5nIEdD TS4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd2lkb3dzOiBh dXRvOyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ib3JwaGFuczogYXV0bzsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHdpZG93czogYXV0bzsgbWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyIgY2xhc3M9IiI+DQo8Zm9udCBmYWNlPSJBcmlhbCwgc2Fucy1z ZXJpZiIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB0OyIgY2xhc3M9IiI+VGhl IHJlYXNvbiBHQ01fNjQgd2FzIHJlbW92ZWQgd2FzIGJlY2F1c2UgSSBwb2ludGVkIG91dCB0aGF0 IHRoZSBkcmFmdCBzaG91bGQgZm9sbG93IHRoZSBOSVNUIHJlcXVpcmVtZW50cyBpbiBTUCA4MDAt MzhELCBBcHBlbmRpeCBDLiZuYnNwOzwvc3Bhbj5LZXZpbiBhbmQgRGF2aWQgY2hvc2UgdG8gcmVt b3ZlJm5ic3A7PC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj5HQ01fNjQNCiBpbnN0ZWFkLjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3aWRv d3M6IGF1dG87IG1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB3aWRvd3M6IGF1dG87IG1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPkNoZWVycyw8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgd2lkb3dzOiBh dXRvOyBtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Kb2huPC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gMjQgRmViIDIwMTUsIGF0IDE5OjA3 LCBNbyBaYW5hdHkgKG16YW5hdHkpICZsdDs8YSBocmVmPSJtYWlsdG86bXphbmF0eUBjaXNjby5j b20iIGNsYXNzPSIiPm16YW5hdHlAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj5JIHdvdWxk IGxpa2UgdG8gcG9pbnQgb3V0IHRoZSBzdHJvbmdlc3QgYXJndW1lbnQgZm9yIHRoZSBzdWZmaWNp ZW5jeSBvZiA2NDxiciBjbGFzcz0iIj4NCmJpdCBhdXRoIHRhZ3MsIHRha2VuIGRpcmVjdGx5IGZy b20gdGhlIFNSVFAgUkZDLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM3MTEjc2VjdGlvbi05LjIiIGNsYXNzPSIiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM3MTEjc2VjdGlvbi05LjI8L2E+PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Li4ud2hlbiAyXjQ4IFNSVFAgcGFja2V0 cyBvciAyXjMxIFNSVENQIHBhY2tldHMgaGF2ZSBiZWVuIHNlY3VyZWQ8YnIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDt3aXRoIHRoZSBzYW1lIGtleSAod2hpY2hldmVyIG9jY3VycyBiZWZvcmUpLCB0 aGUga2V5IG1hbmFnZW1lbnQgTVVTVDxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO2JlIGNhbGxl ZCB0byBwcm92aWRlIG5ldyBtYXN0ZXIga2V5KHMp4oCmPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Tm90ZTogaW4gbW9zdCB0eXBpY2FsIGFwcGxpY2F0aW9ucyAoYXNz dW1pbmcgYXQgbGVhc3Qgb25lIFJUQ1AgcGFja2V0PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 Zm9yIGV2ZXJ5IDEyOCwwMDAgUlRQIHBhY2tldHMpLCBpdCB3aWxsIGJlIHRoZSBTUlRDUCBpbmRl eCB0aGF0IGZpcnN0PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7cmVhY2hlcyB0aGUgdXBwZXIg bGltaXQsIGFsdGhvdWdoIHRoZSB0aW1lIHVudGlsIHRoaXMgb2NjdXJzIGlzIHZlcnk8YnIgY2xh c3M9IiI+DQombmJzcDsmbmJzcDtsb25nOiBldmVuIGF0IDIwMCBTUlRDUCBwYWNrZXRzL3NlYywg dGhlIDJeMzEgaW5kZXggc3BhY2Ugb2YgU1JUQ1AgaXM8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDtlbm91Z2ggdG8gc2VjdXJlIGFwcHJveGltYXRlbHkgNCBtb250aHMgb2YgY29tbXVuaWNhdGlv bi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGlzIHNob3Vs ZCBtYWtlIGl0IGNsZWFyIHRoYXQgYW55IHBvdGVudGlhbCB3ZWFrbmVzcyBpbiBHQ00gYXV0aCB0 aGF0PGJyIGNsYXNzPSIiPg0KcmVkdWNlcyB0aGUgZWZmZWN0aXZlIHN0cmVuZ3RoIG9mIDY0IGJp dCBhdXRoIHRhZ3MgYnkgNy0xMiBiaXRzIChmb3IgMi02NDxiciBjbGFzcz0iIj4NCktCIHBhY2tl dHMpIGlzIG1vb3QgZHVlIHRvIHRoZSBTUlRDUCAzMSBiaXQgbGltaXQgYW5kIFNSVFAgNDggYml0 IGxpbWl0LjxiciBjbGFzcz0iIj4NCkFuIGF0dGFja2VyIHdvdWxkIGhpdCByZWtleSBjcml0ZXJp YSBiZWZvcmUgYWNoaWV2aW5nIDAuMSUgY2hhbmNlIG9mIGE8YnIgY2xhc3M9IiI+DQpzaW5nbGUg c3VjY2Vzc2Z1bGx5IGZvcmdlZCBwYWNrZXQgKG9mIGNob3NlbiBjaXBoZXIgdGV4dCBidXQgcmFu ZG9tIHBsYWluPGJyIGNsYXNzPSIiPg0KdGV4dCBzaW5jZSBkZWNyeXB0aW9uIGtleXMgYXJlIG5v dCBjb21wcm9taXNlZCkuIERPUyBjcml0ZXJpYSB3b3VsZCBsaWtlbHk8YnIgY2xhc3M9IiI+DQpi ZSBoaXQgbXVjaCBzb29uZXIgYXQgc3VjaCBleHRyZW1lIG51bWJlcnMgb2YgcGFja2V0cy4gRnVy dGhlcm1vcmUsIHRoaXM8YnIgY2xhc3M9IiI+DQpyZWR1Y2VkIGVmZmVjdGl2ZSBzdHJlbmd0aCBv ZiBhdXRoIHRhZ3Mgb25seSBhcHBsaWVzIGFnYWluc3QgYXR0YWNrcyB3aGljaDxiciBjbGFzcz0i Ij4NCmFyZSBhbnl3YXkgaW1wb3NzaWJsZSBpbiBTUlRQIGR1ZSB0byBubyBhdXRoIGZhaWx1cmUg ZmVlZGJhY2suPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU28gNjQgYml0IGF1dGggdGFn cyBzaG91bGQgYmUgc3VmZmljaWVudCBmb3IgU1JUUCBhcHBsaWNhdGlvbnMuPGJyIGNsYXNzPSIi Pg0KKEFzIGxvbmcgYXMgdGhlIGF1dGggdHJhbnNmb3JtIGhhcyBubyB0cnVuY2F0aW9uIGlzc3Vl cy4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTW88YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiAyLzIzLzE1LCA2OjE2IFBNLCBNbyBaYW5hdHkgKG16 YW5hdHkpICZsdDttemFuYXR5QGNpc2NvLmNvbSZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KSSBhbSBmaW5lIHdpdGgga2VlcGluZyBvbmx5IHRoZXNlIDYgc3VpdGVzIGJ5 IGVsaW1pbmF0aW5nIDk2IGJpdCBhdXRoIHRhZ3MuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSG93ZXZlciwgSSBkbyB3b25kZXIgaWYgYW55IFNSVFAgYXBwbGljYXRpb24gd2lsbCBldmVy IHVzZSBDQ00gd2l0aCBmdWxsPGJyIGNsYXNzPSIiPg0KbGVuZ3RoIHRhZ3Mgb3IgMjU2IGJpdCBr ZXlzLCByYXRoZXIgdGhhbiB1c2luZyBHQ00uIElmIG5vdCwgYW5vdGhlciAzPGJyIGNsYXNzPSIi Pg0Kc3VpdGVzIGNhbiBiZSBlbGltaW5hdGVkLCBsZWF2aW5nIG9ubHkgMyBzdWl0ZXM6PGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQUVBRF9BRVNfMjU2X0dDTTxiciBjbGFzcz0iIj4NCkFF QURfQUVTXzEyOF9HQ008YnIgY2xhc3M9IiI+DQpBRUFEX0FFU18xMjhfQ0NNXzgvNjQ8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGFsc28gYWdyZWUgd2l0aCBKb2huIHRoYXQgNjQgYml0 IGF1dGggdGFncyBhcmUgc3VmZmljaWVudCBmb3IgU1JUUCBldmVuPGJyIGNsYXNzPSIiPg0KdXNp bmcgR0NNLiBUaGUgTklTVCByZWNvbW1lbmRhdGlvbiBpcyBrZXkgcm90YXRpb24gYWZ0ZXIgcm91 Z2hseSAyXjQwPGJyIGNsYXNzPSIiPg0KcGFja2V0cyBvZiAxLjUgS0IsIHdoaWNoIGlzIG1hbnkg eWVhcnMgZm9yIGEgMTAwIE1icHMgU1JUUCBzdHJlYW0hIEFuZDxiciBjbGFzcz0iIj4NCnRoaXMg aXMgdG8gcHJvdGVjdCBhZ2FpbnN0IGFuIGF0dGFjayB3aGVyZSB0aGUgcmVjZWl2ZXIvdmljdGlt IG5vdGlmaWVzPGJyIGNsYXNzPSIiPg0KdGhlIHNlbmRlci9hdHRhY2tlciBvZiBldmVyeSBhdXRo IGZhaWx1cmUsIHdoaWNoIGlzIG5vdCBwb3NzaWJsZSBpbiBTUlRQPGJyIGNsYXNzPSIiPg0Kc2lu Y2Ugbm8gc3VjaCBmZWVkYmFjayBleGlzdHMuIEFuZCBhcyBKb2huIG1lbnRpb25lZCwgdGhlIERP UyBvZiBzbyBtYW55PGJyIGNsYXNzPSIiPg0KZm9yZ2VkIHBhY2tldHMgYW5kIGF1dGggZmFpbHVy ZSBtZXNzYWdlcyB3b3VsZCBiZSBhIG11Y2ggd29yc2UgY29uc2VxdWVuY2U8YnIgY2xhc3M9IiI+ DQp0aGFuIGNvbXByb21pc2luZyB0aGUgYXV0aCB0YWcuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KU28gSSB3b3VsZCBhbHNvIGJlIGZpbmUgd2l0aCBvbmx5IDY0IGJpdCBhdXRoIHRhZ3Mg Zm9yIGJvdGggR0NNIGFuZCBDQ00uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQUVBRF9B RVNfMjU2X0dDTV84LzY0PGJyIGNsYXNzPSIiPg0KQUVBRF9BRVNfMTI4X0dDTV84LzY0PGJyIGNs YXNzPSIiPg0KQUVBRF9BRVNfMTI4X0NDTV84LzY0PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSWYgd2UgZ28gdGhpcyBmaW5hbCByb3V0ZSwgSSBzdWdnZXN0IHVwZGF0aW5nIHNlY3Rpb24g MTQuMiB3aXRoIGEgdGFibGU8YnIgY2xhc3M9IiI+DQpmb3IgMS41IEtCIHBhY2tldHMgKG5vdCBq dXN0IDY0IEtCKSwgYW5kIG1vcmUgY29uY3JldGUgZ3VpZGFuY2Ugb24gd2hhdDxiciBjbGFzcz0i Ij4NCnRoZSBzZWN1cml0eSByYW1pZmljYXRpb25zIGFyZS4gSW4gcGFydGljdWxhciwgdGhhdCB0 aGVzZSAobWFueSkgZm9yZ2VyaWVzPGJyIGNsYXNzPSIiPg0KY2FuIG9ubHkgaW5qZWN0IHJhbmRv bSBkYXRhIHNpbmNlIHRoZSBkZWNyeXB0aW9uIGtleSBpcyB1bmtub3duLiBUaGF0IGlzLDxiciBj bGFzcz0iIj4NCnRoZXkgaW5qZWN0IGEgY2hvc2VuIGNpcGhlciB0ZXh0IGJ1dCBhIHJhbmRvbSBw bGFpbiB0ZXh0IGFmdGVyIGRlY3J5cHRpb248YnIgY2xhc3M9IiI+DQpzaW5jZSB0aGUgZGVjcnlw dGlvbiBrZXkgaXMgdW5rbm93biBhbmQgbm90IGNvbXByb21pc2VkIGJ5IHRoaXMgYXV0aCBrZXk8 YnIgY2xhc3M9IiI+DQphdHRhY2suIFRoZSBzZWN1cml0eSByYW1pZmljYXRpb25zIG9mIHRoaXMg YXV0aCBrZXkgYXR0YWNrIGFyZSBtaW5vciBpbiBteTxiciBjbGFzcz0iIj4NCm9waW5pb24sIGVz cGVjaWFsbHkgcmVsYXRpdmUgdG8gdGhlIG1ham9yIGRlbmlhbC1vZi1zZXJ2aWNlIGNhdXNlZCBi eSBzbzxiciBjbGFzcz0iIj4NCm1hbnkgZm9yZ2VyaWVzIGFuZCBhdXRoIGZhaWx1cmUgZmVlZGJh Y2suPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSB3b3VsZCBub3QgYmUgZmluZSB3aXRo IGFueXRoaW5nIGxlc3MgdGhhbiB0aGlzLiBPbmUgR0NNIGlzIG5vdDxiciBjbGFzcz0iIj4NCnN1 ZmZpY2llbnQsIHdlIG5lZWQgYm90aCAxMjggYW5kIDI1NiBiaXQga2V5cy4gR0NNIGlzIG5vdCBz dWZmaWNpZW50LCB3ZTxiciBjbGFzcz0iIj4NCmFsc28gbmVlZCBDQ00gKDEyOF84LzY0KS48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpNbzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDIvMTkvMTUsIDExOjAxIEFNLCBNYWdu dXMgV2VzdGVybHVuZCAmbHQ7bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tJmd0OzxiciBj bGFzcz0iIj4NCndyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDIwMTUtMDIt MTUgMTU6MDksIERhdmlkIE1jR3JldyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQpNeSBvcGluaW9uIGlzOiBpdCB3b3Vs ZCBiZSBiZXN0IHRvIHByZXNlcnZlIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9uPGJyIGNsYXNz PSIiPg0KYW5kIGltcGxlbWVudGF0aW9uIHdvcmssIGFuZCByZXRhaW4gYWxsIHRlbiBjcnlwdG8g c3VpdGUgZGVmaW5pdGlvbnMuPGJyIGNsYXNzPSIiPg0KQnV0IGlmIHdlIHdhbnQgdG8gbWFrZSBT UlRQLUFFQUQgYmUgdGhlIGZpcnN0IGluc3RhbmNlIGluIHdoaWNoIHRoZSBJRVRGPGJyIGNsYXNz PSIiPg0Kd2lsbCAmbmJzcDtwcmlvcml0aXplIHNpbXBsaWNpdHkgb3ZlciB2YXJpZXR5IGFuZCBk aXZlcnNpdHksIEnCuW0gZ29vZCB3aXRoPGJyIGNsYXNzPSIiPg0KdGhhdCwgYmVjYXVzZSBJIGNl cnRhaW5seSBzZWUgdGhlIHZhbHVlIG9mIHNpbXBsaWNpdHk7IHRoZW4gbXk8YnIgY2xhc3M9IiI+ DQpyZWNvbW1lbmRhdGlvbiB3b3VsZCBiZSB0byBlbGltaW5hdGUgdGhlIGZvdXIgMTItb2N0ZXQg YXV0aGVudGljYXRpb248YnIgY2xhc3M9IiI+DQp2ZXJzaW9ucy4gJm5ic3A7VGhhdCB3b3VsZCBs ZWF2ZSBqdXN0IHNpeCBjcnlwdG8gc3VpdGVzLCB3aXRoIHR3byBkaWZmZXJlbnQ8YnIgY2xhc3M9 IiI+DQptb2RlcyBvZiBvcGVyYXRpb24sIHR3byBkaWZmZXJlbnQga2V5IHNpemVzLCBhbmQgdHdv IGRpZmZlcmVudCB0YWc8YnIgY2xhc3M9IiI+DQpsZW5ndGhzIChidXQgbm90IGFsbCB0YWcgbGVu Z3RocyBmb3IgYWxsIG1vZGVzKSwgbGlrZSB0aGlzOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NydHAtY3J5cHRvLXN1aXRlLWV4dCA9 ICZxdW90O0FFQURfQUVTXzEyOF9HQ00mcXVvdDsgJm5ic3A7Jm5ic3A7Jm5ic3A7LzxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZxdW90O0FFQURfQUVTXzI1Nl9HQ00mcXVvdDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 LzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O0FFQURfQUVTXzEyOF9DQ00mcXVvdDsgJm5ic3A7Jm5i c3A7Jm5ic3A7LzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O0FFQURfQUVTXzI1Nl9DQ00mcXVvdDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7LzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90O0FFQURfQUVTXzEyOF9D Q01fOCZxdW90OyAmbmJzcDsvPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7QUVBRF9BRVNfMjU2X0ND TV84JnF1b3Q7ICZuYnNwOy88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVv dGU+DQo8YnIgY2xhc3M9IiI+DQpTdGVwaGVuLCBXRzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkhhdmluZyBsb29rZWQgYXQgdGhlIGZlZWRiYWNrIHByb3ZpZGVkIGluIHRoaXMgZGlzY3Vz c2lvbiBzbyBmYXIsIEk8YnIgY2xhc3M9IiI+DQp0aGluayB0aGUgYWJvdmUgc2V0IG9mIDYgYXJl IGEgcmVhc29uYWJsZSBzZWxlY3Rpb24gd2l0aG91dCB1bmR1bHk8YnIgY2xhc3M9IiI+DQpsaW1p dGluZyBmdW5jdGlvbmFsaXR5LCBidXQgcmVtb3ZpbmcgdGhlIGZvdXIgbGVhc3QgbmVjZXNzYXJ5 IHByb2ZpbGVzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk15IHByb3Bvc2FsIGlzIHRo YXQgaWYgbm8gb25lIGlzIGRpc2FncmVlaW5nIHdpdGggdGhpcyBpbiB0aGUgbmV4dCB3ZWVrPGJy IGNsYXNzPSIiPg0KKFByaW9yIHRvIEZlYiAyNiBhdCAxNjozMCBVVEMpIHdlIHVzZSBpdC4gSWYg c29tZW9uZSBkaXNhZ3JlZXMgd2UgaG9sZCBhPGJyIGNsYXNzPSIiPg0KZGlzY3Vzc2lvbiBhdCB0 aGUgaW5mb3JtYWwgSUVTRyB0ZWxlY2hhdCBvbiBob3cgdG8gcHJvY2VlZC48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpDaGVlcnM8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpNYWdu dXMgV2VzdGVybHVuZDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnIgY2xhc3M9IiI+DQpTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNz c29uIFJlc2VhcmNoIEVBQi9UWE08YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNz PSIiPg0KRXJpY3Nzb24gQUIgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fCBQaG9uZSAmbmJzcDsmIzQzOzQ2IDEwIDcxNDgyODc8YnIgY2xhc3M9IiI+DQpGw6Ryw7ZnYXRh biA2ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgTW9iaWxlICYjNDM7 NDYgNzMgMDk0OTA3OTxiciBjbGFzcz0iIj4NClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8 IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPGJyIGNsYXNzPSIiPg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KQXVkaW8vVmlkZW8g VHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2U8YnIgY2xhc3M9IiI+DQphdnRAaWV0Zi5vcmc8YnIg Y2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUg TWFpbnRlbmFuY2U8YnIgY2xhc3M9IiI+DQphdnRAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_28669AE0DF314910BD975B319BFD1398ericssoncom_-- From nobody Fri Feb 27 12:08:33 2015 Return-Path: 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 CD4361A0067 for ; Fri, 27 Feb 2015 12:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ChpmFDwI83Ai for ; Fri, 27 Feb 2015 12:08:30 -0800 (PST) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 10CC61A0053 for ; Fri, 27 Feb 2015 12:08:29 -0800 (PST) X-TM-IMSS-Message-ID: <4290682200074bb5@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov (msht-gh1-uea01.corp.nsa.gov [10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 4290682200074bb5 ; Fri, 27 Feb 2015 15:08:47 -0500 Received: from MSMR-GH1-UEA08.corp.nsa.gov (10.215.225.3) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 27 Feb 2015 15:08:29 -0500 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA08.corp.nsa.gov ([10.215.225.3]) with mapi id 14.02.0347.000; Fri, 27 Feb 2015 15:08:28 -0500 From: "Igoe, Kevin M." To: "'avt@ietf.org'" Thread-Topic: Are thare any existing uses of CCM mode in SRTP? Thread-Index: AdBSySZw1rAEskNLRrukGWoZmrPASA== Date: Fri, 27 Feb 2015 20:08:27 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CABC7F0078@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.224.46] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [AVTCORE] Are thare any existing uses of CCM mode in SRTP? X-BeenThere: avt@ietf.org 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: Fri, 27 Feb 2015 20:08:32 -0000 Despite its name, the ID draft-avtcore-srtp aes-gcm actually supports two (= 2) AEAD modes of operation, GCM and CCM. There are known GCM based develo= pments underway, but at a telechat held yesterday to discuss this ID it be= came apparent that no one participating in the chat was aware of ANY use of= CCM in SRTP. Hence it was suggested we purge CCM from the current ID =20 This is a call to the mailing list to see if anyone is aware of any concret= e existing projects underway that use CCM mode in SRTP. If there are none,= CCM will be eliminated from the current ID.=20 (Note that if at some date in the future someone wishes to deploy CCM in SR= TP, a simple cut and paste from previous drafts of the current ID can be us= ed to craft a new CCM only ID.) From nobody Fri Feb 27 12:19:59 2015 Return-Path: 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 98C631A0019 for ; Fri, 27 Feb 2015 12:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 cpbjxgJTVPdo for ; Fri, 27 Feb 2015 12:19:57 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0083.outbound.protection.outlook.com [207.46.100.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302391A00BD for ; Fri, 27 Feb 2015 12:19:43 -0800 (PST) Received: from CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) by CY1PR0501MB1435.namprd05.prod.outlook.com (25.160.148.153) with Microsoft SMTP Server (TLS) id 15.1.93.16; Fri, 27 Feb 2015 20:19:41 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com (25.161.161.153) by CY1PR0501MB1578.namprd05.prod.outlook.com (25.161.161.152) with Microsoft SMTP Server (TLS) id 15.1.93.16; Fri, 27 Feb 2015 20:19:40 +0000 Received: from CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) by CY1PR0501MB1579.namprd05.prod.outlook.com ([25.161.161.153]) with mapi id 15.01.0093.004; Fri, 27 Feb 2015 20:19:40 +0000 From: "Wyss, Felix" To: "Igoe, Kevin M." , "'avt@ietf.org'" Thread-Topic: Are thare any existing uses of CCM mode in SRTP? Thread-Index: AdBSySZw1rAEskNLRrukGWoZmrPASAAALbWg Date: Fri, 27 Feb 2015 20:19:40 +0000 Message-ID: References: <3C4AAD4B5304AB44A6BA85173B4675CABC7F0078@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CABC7F0078@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [107.147.12.61] authentication-results: nsa.gov; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1578;UriScan:; inin-custom-wld: WL-D x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1578; x-forefront-prvs: 05009853EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(51704005)(13464003)(99286002)(15975445007)(77156002)(62966003)(86362001)(74316001)(122556002)(102836002)(40100003)(76576001)(87936001)(19580405001)(2950100001)(19580395003)(2900100001)(107886001)(92566002)(33656002)(66066001)(76176999)(2656002)(46102003)(54356999)(50986999)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0501MB1578; H:CY1PR0501MB1579.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2015 20:19:40.4360 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8d07eb62-a903-4bae-bcc2-66c244e76b27 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1578 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1435; X-OriginatorOrg: inin.com Archived-At: Subject: Re: [AVTCORE] Are thare any existing uses of CCM mode in SRTP? X-BeenThere: avt@ietf.org 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: Fri, 27 Feb 2015 20:19:58 -0000 I am very much in favor of removing CCM. =20 Something I would like to ask for, though: Could you *please* add test vect= ors to the RFC? As an implementer, having meaningful test vectors greatly = helps in development and testing. IMHO test vectors should be a MUST requi= rement for any RFCs describing cryptographic protocols. Thanks, --Felix > -----Original Message----- > From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Igoe, Kevin M. > Sent: Friday, February 27, 2015 15:08 > To: 'avt@ietf.org' > Subject: [AVTCORE] Are thare any existing uses of CCM mode in SRTP? >=20 > Despite its name, the ID draft-avtcore-srtp aes-gcm actually supports two= (2) > AEAD modes of operation, GCM and CCM. There are known GCM based > developments underway, but at a telechat held yesterday to discuss this = ID > it became apparent that no one participating in the chat was aware of ANY > use of CCM in SRTP. Hence it was suggested we purge CCM from the current > ID >=20 > This is a call to the mailing list to see if anyone is aware of any concr= ete > existing projects underway that use CCM mode in SRTP. If there are none, > CCM will be eliminated from the current ID. >=20 > (Note that if at some date in the future someone wishes to deploy CCM in > SRTP, a simple cut and paste from previous drafts of the current ID can b= e > used to craft a new CCM only ID.) >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt