From nobody Mon May 2 11:47:06 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6F312D5CE; Mon, 2 May 2016 11:47:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502184703.15660.88412.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 11:47:03 -0700 Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: [avtext] Alissa Cooper's Yes on draft-ietf-avtext-sdes-hdr-ext-06: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 18:47:03 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-avtext-sdes-hdr-ext-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I too was confused about why MID was not being registered here, but then saw that it is being registered in draft-ietf-mmusic-sdp-bundle-negotiation. I think the text in Section 3 should make this more clear. I also gather that in some previous version of this draft it may have been registering both, and so there is language in 5.2 and 5.3 ("Initial assignments," "SDES Items") indicating that multiple things are being registered. I think these should be made singular. From nobody Mon May 2 11:54:14 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054E912D5D7; Mon, 2 May 2016 11:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 Y4MOgIZrQLAD; Mon, 2 May 2016 11:54:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 81F1E12D11C; Mon, 2 May 2016 11:54:07 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u42Is46C011248 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 May 2016 13:54:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Mirja Kuehlewind" , "Magnus Westerlund" Date: Mon, 02 May 2016 13:54:04 -0500 Message-ID: <55F7645B-3687-4813-893C-BCB533912054@nostrum.com> In-Reply-To: References: <20160426125513.29054.51279.idtracker@ietfa.amsl.com> <571F6D6F.5080103@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: draft-ietf-avtext-sdes-hdr-ext@ietf.org, Jonathan Lennox , avtext@ietf.org, The IESG , avtext-chairs@ietf.org Subject: Re: [avtext] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-avtext-sdes-hdr-ext-05=3A_=28with_COMMENT=29?= X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 18:54:09 -0000 On 26 Apr 2016, at 9:10, Mirja Kuehlewind (IETF) wrote: >>> 2) Should this doc also register MID? > >> >> Nope, as this document now has overtaken >> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ >> it will be BUNDLE that has to define the registration. Initially we >> thought that BUNDLE would be done, and we would catch up and have to >> move the registration, but that didn't happen. > > > Okay. Didn’t see that it also defines the RTP extension. That’s > fine. Magnus, since this draft mentions MID, would it make sense to also mention that it is (or will be) be registered in bundle-negotiation? Thanks! Ben. From nobody Mon May 2 15:38:14 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 332A612B01C; Mon, 2 May 2016 15:38:13 -0700 (PDT) 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: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160502223813.15846.67191.idtracker@ietfa.amsl.com> Date: Mon, 02 May 2016 15:38:13 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-rid-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 22:38:13 -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 Extensions of the IETF. Title : RTP Stream Identifier Source Description (SDES) Authors : Adam Roach Suhas Nandakumar Peter Thatcher Filename : draft-ietf-avtext-rid-02.txt Pages : 7 Date : 2016-05-02 Abstract: This document defines and registers two new RTCP SDES items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-rid-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rid-02 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 Mon May 2 15:43:36 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A71512D675; Mon, 2 May 2016 15:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 BglPS9KupVUj; Mon, 2 May 2016 15:43:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C5DDE12B01C; Mon, 2 May 2016 15:43:32 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u42MhVwx032630 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 2 May 2016 17:43:32 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <20160502223813.15846.67191.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <7bd5ac64-74ca-bcd0-7314-75b601868805@nostrum.com> Date: Mon, 2 May 2016 17:43:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160502223813.15846.67191.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: avtext@ietf.org Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rid-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 22:43:34 -0000 This update reflects the changes we discussed at the face-to-face meeting in Buenos Aires -- see the minutes [1] and slides [2] for details. Those present at the face-to-face meeting agreed that these changes represent the best path forward. If anyone objects to this set of changes, please speak up quickly. /a ____ [1] https://www.ietf.org/proceedings/95/minutes/minutes-95-avtext [2] https://www.ietf.org/proceedings/95/slides/slides-95-avtext-3.pdf On 5/2/16 17:38, 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 Extensions of the IETF. > > Title : RTP Stream Identifier Source Description (SDES) > Authors : Adam Roach > Suhas Nandakumar > Peter Thatcher > Filename : draft-ietf-avtext-rid-02.txt > Pages : 7 > Date : 2016-05-02 > > Abstract: > This document defines and registers two new RTCP SDES items. One, > named RtpStreamId, is used for unique identification of RTP streams. > The other, RepairedRtpStreamId, can be used to identify which stream > a redundancy RTP stream is to be used to repair. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-avtext-rid-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-rid-02 > > > 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/ > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue May 3 01:12:45 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28A912D10A; Tue, 3 May 2016 01:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Qf1Xhm7b-jE3; Tue, 3 May 2016 01:12:37 -0700 (PDT) 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 168E612D55F; Tue, 3 May 2016 01:12:36 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-dc-57285d738184 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6F.17.27088.37D58275; Tue, 3 May 2016 10:12:35 +0200 (CEST) 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.248.2; Tue, 3 May 2016 10:12:34 +0200 To: Alissa Cooper , The IESG References: <20160502184703.15660.88412.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <57285D71.40107@ericsson.com> Date: Tue, 3 May 2016 10:12:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160502184703.15660.88412.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM2K7vW5xrEa4Qf8ZAYvpZ/4yWrSfO8Fi 8fHeDVaL22s+sVnM+DOR2WL/4vPMDmweX568ZPJYsuQnk0fbszvsAcxRXDYpqTmZZalF+nYJ XBlXjy5iLTgqWHHm1HfGBsZdfF2MnBwSAiYSxy+tZYWwxSQu3FvP1sXIxSEkcIRR4sbra+wQ zjJGie/7pjKCVAkLhEt8WPycHcQWEbCXmHb1BxuILSTgKPH17QMWkAZmgSZGiXnPJ4Al2AQs JG7+aASzeQU0Jf69fQVUxMHBIqAisfQqN0hYVCBGovHBKSaIEkGJkzOfsIDYnAJOEm+vPQG7 jhlozMz55xkhbHmJ5q2zmSH2aks0NHWwTmAUnIWkfRaSlllIWhYwMq9iFC1OLU7KTTcy0kst ykwuLs7P08tLLdnECAzxg1t+G+xgfPnc8RCjAAejEg+vAptGuBBrYllxZe4hRgkOZiURXpUI oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFe/5eK4UIC6YklqdmpqQWpRTBZJg5OqQbGhJK8ztN/ GIN+eV9c8nDvNuHsL5OX3/NUVFL6vvFd75qCy1eYVU91iLgoejlN+VLsfKVY56wsr332+7gF F2NvvJwWaRBYIbztWHZOg3nLRpnzkror9K1fLNiQc30K4xrpSUIVbzU8rbh+SsyLkc9lbTaM a7kh0LGsMpjNXfTS+o8G+SWNUzWUWIozEg21mIuKEwGw7CajbQIAAA== Archived-At: Cc: Jonathan Lennox , avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: Re: [avtext] Alissa Cooper's Yes on draft-ietf-avtext-sdes-hdr-ext-06: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 08:12:39 -0000 Den 2016-05-02 kl. 20:47, skrev Alissa Cooper: > Alissa Cooper has entered the following ballot position for > draft-ietf-avtext-sdes-hdr-ext-06: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I too was confused about why MID was not being registered here, but then > saw that it is being registered in > draft-ietf-mmusic-sdp-bundle-negotiation. I think the text in Section 3 > should make this more clear. Yes, I think we can add a sentence after the description indicating it will be registered when that work is finished. > > I also gather that in some previous version of this draft it may have > been registering both, and so there is language in 5.2 and 5.3 ("Initial > assignments," "SDES Items") indicating that multiple things are being > registered. I think these should be made singular. > Another possibility is to have 5.3 be section 5.2.1 instead and change the title of that section to: "Initial Assignments" and remove the bullet prior to this section. The reason to have it as its own section is that it works better as an example for how a registration request to this registry can look. 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 May 3 01:16:08 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B4012D19E; Tue, 3 May 2016 01:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 U-WjQ2aVC-Vc; Tue, 3 May 2016 01:16:04 -0700 (PDT) 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 1458412D569; Tue, 3 May 2016 01:16:03 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-b7-57285e4202ae Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 96.C2.12926.24E58275; Tue, 3 May 2016 10:16:02 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.248.2; Tue, 3 May 2016 10:15:58 +0200 To: Alexey Melnikov , The IESG References: <20160430162207.31062.20470.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <57285E3D.1050700@ericsson.com> Date: Tue, 3 May 2016 10:15:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160430162207.31062.20470.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM2J7lK5TnEa4waOt0hb73x9ismg/d4LF 4uO9G6wWt9d8YrOY8Wcis8X+xeeZHdg8dp46wOaxZMlPJo+2Z3fYA5ijuGxSUnMyy1KL9O0S uDLO7hYv+MtXcXZ6M2MD436eLkYODgkBE4kFPyq6GDmBTDGJC/fWs4HYQgJHGCUWLBPpYuQC spcxSlxaO50RJCEskCQx9dY+FpBeEQE3iYfXHSHqHSX+7p7KDlLPLNDEKDHv+QSwQWwCFhI3 fzSC2bwC2hIv1+9nBbFZBFQkttw/AjZTVCBGovHBKSaIGkGJkzOfsIDYnAJOEv87b4L1MgPN mTn/PCOELS/RvHU2M8RibYmGpg7WCYyCs5C0z0LSMgtJywJG5lWMosWpxUm56UbGeqlFmcnF xfl5enmpJZsYgcF9cMtv1R2Ml984HmIU4GBU4uFVYNMIF2JNLCuuzD3EKMHBrCTCqxIBFOJN SaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cBo33ncsWJrkcf9 jvt2L5V8H1uUmCkeWxOsWMuVEJvmfNqh4ejGuinxjR5XXifPfHrtr3i7i/jPt2e+czLLbYkz 0lg78VO6lNZKrSdbpnJa6KYsWnr/tMvRx5HWr5anv9mnFTKnsm5JjMla3rRlL08s6Z859SG7 Sfr6bQ1uN39W3OwQODH7NpOnEktxRqKhFnNRcSIAivGM2WoCAAA= Archived-At: Cc: Jonathan Lennox , avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: Re: [avtext] Alexey Melnikov's No Objection on draft-ietf-avtext-sdes-hdr-ext-06: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 08:16:06 -0000 Den 2016-04-30 kl. 18:22, skrev Alexey Melnikov: > Alexey Melnikov has entered the following ballot position for > draft-ietf-avtext-sdes-hdr-ext-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The first mention of UTF-8 needs a reference. > > I am agreeing with Mirja about registering MID, as the document argues > that it would be a good idea. > To ensure that this is clear. The MID SDES item and its usage of this header extension will both be registered when the IANA processing after approval of draft-ietf-mmusic-sdp-bundle-negotiation happens. Otherwise we create unnecessary normative dependencies and confusing inter dependencies in the finished RFCs. But, as stated otherwise, we can make clear that this will be registered by the BUNDLE document when it finishes. 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 May 3 08:10:35 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00B412D549 for ; Tue, 3 May 2016 08:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=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 jt8RqMUJFXx8 for ; Tue, 3 May 2016 08:10:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 884FA12D534 for ; Tue, 3 May 2016 08:10:31 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u43FAUck050016 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 May 2016 10:10:30 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Magnus Westerlund" Date: Tue, 03 May 2016 10:10:30 -0500 Message-ID: <8DC07733-C53A-4525-89F6-B917BA5935FF@nostrum.com> In-Reply-To: <57285D71.40107@ericsson.com> References: <20160502184703.15660.88412.idtracker@ietfa.amsl.com> <57285D71.40107@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Jonathan Lennox , avtext@ietf.org, avtext-chairs@ietf.org, The IESG , draft-ietf-avtext-sdes-hdr-ext@ietf.org Subject: Re: [avtext] Alissa Cooper's Yes on draft-ietf-avtext-sdes-hdr-ext-06: (with COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:10:34 -0000 On 3 May 2016, at 3:12, Magnus Westerlund wrote: >> I also gather that in some previous version of this draft it may have >> been registering both, and so there is language in 5.2 and 5.3 >> ("Initial >> assignments," "SDES Items") indicating that multiple things are being >> registered. I think these should be made singular. >> > > > Another possibility is to have 5.3 be section 5.2.1 instead and change > the title of that section to: "Initial Assignments" and remove the > bullet prior to this section. The reason to have it as its own section > is that it works better as an example for how a registration request > to this registry can look. That would be fine, but I think you could solve the issue by simply removing the plurals from the aforementioned bullet and 5.3 title. Thanks, Ben. From nobody Tue May 3 08:21:18 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2745412D920; Tue, 3 May 2016 08:21:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160503152115.8264.83977.idtracker@ietfa.amsl.com> Date: Tue, 03 May 2016 08:21:15 -0700 Archived-At: Cc: jonathan@vidyo.com, avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-sdes-hdr-ext-06: (with DISCUSS and COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 15:21:15 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-avtext-sdes-hdr-ext-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'd like to check if there's a small hole in the security/privacy properties here. If there is I hope that a little re-wording will handle it. You say: (1) "In RTP sessions where any type of confidentiality protection is enabled for RTCP, the SDES item header extensions MUST also be protected." And then you say: (2) "The security level that is applied to RTCP packets carrying SDES items SHOULD also be applied to SDES items carried as RTP header extensions." My concerns are that the SHOULD in (2) isn't really well motivated (for me) - you just seem to say that someone who doesn't follow the SHOULD has to say why, but I don't think that's likely a run-time concept. Secondly, (1) doesn't say that the new stuff has to be protected in the same way, e.g. with the same endpoints having the keys, and not e.g. where the RTCP data has e2e protection but the new header field just has hop-by-hop protection. Are my concerns justified? (If not, that's fine you'll tell me and we're done:-) If these are justified concerns, I think we can easily get around them by (a) closing that potential loophole in (1) and (b) s/SHOULD/MUST/ in (2) or else (c) better specify an exception to the SHOULD that makes sense at coding time or at run time. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - So this one confused me for a bit but I was thinking about RFC4568 - shame about that acronym collision;-) It'd have helped this reader to say that this is not about sending keys in header fields:-) But I'm probably not the intended reader, so it's fine that you didn't. - I wonder if confidentiality protection of these header fields is likely? Is that more or less likely to be deployed than some security for RTCP? If there's a significant difference then I think that ought be called out. Just pointing at rfc6904 doesn't seem entirely sufficient to me if nobody ever does it. - Has someone done an analysis of the privacy implications of moving values from one context (RTCP) to another (RTP) over the range of likely deployments? Note: I'm not asserting that there is a significant privacy exposure here, I don't know if there is or not. So I'm just asking if folks have thought about that and e.g. whether or not some data exposed in this header field could allow easier re-identification or correlation or some similar and possibly subtle privacy issue. From nobody Wed May 4 03:13:30 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5079D12D149 for ; Wed, 4 May 2016 03:13:28 -0700 (PDT) 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, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 AvMStwgWKSnx for ; Wed, 4 May 2016 03:13:26 -0700 (PDT) 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 A0AAD12D140 for ; Wed, 4 May 2016 03:13:25 -0700 (PDT) Received: from [130.209.254.12] (port=57737 helo=vpn12.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1axto3-00054c-7J; Wed, 04 May 2016 11:13:24 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <7bd5ac64-74ca-bcd0-7314-75b601868805@nostrum.com> Date: Wed, 4 May 2016 11:13:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160502223813.15846.67191.idtracker@ietfa.amsl.com> <7bd5ac64-74ca-bcd0-7314-75b601868805@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: avtext@ietf.org Subject: Re: [avtext] I-D Action: draft-ietf-avtext-rid-02.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 10:13:28 -0000 No objection on my part. Colin > On 2 May 2016, at 23:43, Adam Roach wrote: >=20 > This update reflects the changes we discussed at the face-to-face = meeting in Buenos Aires -- see the minutes [1] and slides [2] for = details. >=20 > Those present at the face-to-face meeting agreed that these changes = represent the best path forward. If anyone objects to this set of = changes, please speak up quickly. >=20 > /a >=20 > ____ > [1] https://www.ietf.org/proceedings/95/minutes/minutes-95-avtext > [2] https://www.ietf.org/proceedings/95/slides/slides-95-avtext-3.pdf >=20 >=20 > On 5/2/16 17:38, 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 Extensions of = the IETF. >>=20 >> Title : RTP Stream Identifier Source Description = (SDES) >> Authors : Adam Roach >> Suhas Nandakumar >> Peter Thatcher >> Filename : draft-ietf-avtext-rid-02.txt >> Pages : 7 >> Date : 2016-05-02 >>=20 >> Abstract: >> This document defines and registers two new RTCP SDES items. One, >> named RtpStreamId, is used for unique identification of RTP = streams. >> The other, RepairedRtpStreamId, can be used to identify which = stream >> a redundancy RTP stream is to be used to repair. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtext-rid/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-avtext-rid-02 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-rid-02 >>=20 >>=20 >> 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. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >=20 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext --=20 Colin Perkins https://csperkins.org/ From nobody Fri May 6 10:09:05 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA8A12D15C for ; Fri, 6 May 2016 10:09:02 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0n0NaeAkijGj for ; Fri, 6 May 2016 10:08:59 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 9F41812D5ED for ; Fri, 6 May 2016 10:08:57 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id n129so65554545wmn.1 for ; Fri, 06 May 2016 10:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=TMCW71xkW4qEC2kj2ABbChiIV363I+/M8o33rN6TZ2c=; b=invH3Gr6SifahsITVOPez43l1fg/I8sOkHfs2qLvD/LO11+pFqdfhD+HO92zEGTxM3 mGnIsPsnZtngsQsU60RPpAPU+vY8ZZfD9lUf4gJS6FDtOLhU+wZn7Zg9eZi2oNDjips2 NQstk6lIm4GL10/zdhGFNlfNQJzQgRsbIO2pTZxkS0pIImq4dVqFWhtPqH2QU94oYSRf mXNEzB7uiaArSHyVA32ebRSXeuBJkM9JLZ25hYsjdni5FewsaqknLsl+14jWwLtPM5wf Abqa0PJbfYbJb0/J72/3BrDBxw5VzlvcvM48tIis+cA4TPqhyagLoocbSyUVSBMyNCn0 YPBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=TMCW71xkW4qEC2kj2ABbChiIV363I+/M8o33rN6TZ2c=; b=PxU8wzj1XaJ0cpoRxIKUGXOvtSTeOTDXfELtPyLzTk3Cjgeatwu/aYkgnt/dGkfrth H4N6nYE49HiNY509/lWHVRCsoubTMn2+YU/4LjS4Fx6FDQ6Rov1ToC+fFxybx8cquVhm JAbHahGeR+FNyZ16jpVXsdpQx7zlAZ+gtdYb7IcVymecJ9Nme5p10BkctT6ednNDtLSz 3usZblvFOdg3pzhH09awmduesu3cTNzO/Rs/RDka79PyFroxr+ZJ/9nG/TWigWuvGNaf rMJXXL/NR4GWSZjDwNEu5h8hmoBYRXFzyFVdjNcE6oGgVFq+sxqxVsuQYuwIoaedJnEg cDIQ== X-Gm-Message-State: AOPr4FVp7VoXvVk4kfNL4roq+4Xz+3gKlSm+w2xJZLW4uEIZMSN+vfTbiiFqeHC8kqkXnQ== X-Received: by 10.28.125.138 with SMTP id y132mr10568058wmc.90.1462554536191; Fri, 06 May 2016 10:08:56 -0700 (PDT) Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id c16sm9304499wme.16.2016.05.06.10.08.54 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 May 2016 10:08:54 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Huangyihong \(Rachel\)'" , References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> In-Reply-To: <57081F97.2030009@ericsson.com> Date: Fri, 6 May 2016 20:08:42 +0300 Message-ID: <053f01d1a7b9$f2588190$d70984b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIOc8oubpM7/Zgx3JHTW+BFLZpufQJK5H4AnyAz6oA= Content-Language: he Archived-At: Subject: Re: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 17:09:02 -0000 Hi Magnus, I looked at your comments about the security section. Since the slicer = is a RTP mixer or a RTP translator as specified in RFC 7667 I suggest = adding informative reference to RFC7667 for the security risks. There is = text that requires the splicer to authenticate the source of the = splicing time message. I propose the following text for the security section. "The security considerations of the RTP specification [RFC3550] and the = general mechanism for RTP header extensions [RFC5285] apply. The splicer = can either be a mixer or a translator, and has all the security = considerations on these two standard RTP intermediaries as such the = security consideration from [RFC7667] and [RFC7201] SHOULD be considered = for the splicer. The splicer replaces some content with other content in RTP packet, thus = breaking any RTP-level end-to-end security, such as source = authentication and integrity protection. End to end source = authentication is not possible with any known existing splicing = solution. A new solution can theoretically be developed that enables = identification of the participating entities and what each provides, = i.e., the different media sources, main and substituting, and the = splicer which provides the RTP-level integration of the media payloads = in a common timeline and synchronization context. Since splicer works as a trusted entity, any RTP-level or outside = security mechanism, such IPsec [RFC4301] or Datagram Transport Layer = Security [RFC6347], will use a security association between the splicer = and the receiver. When using the Secure Real-Time Transport Protocol = (SRTP) [RFC3711], the splicer could be provisioned with the same = security association as the main RTP sender. =20 If there is a concern about the confidentiality of the splicing time = information, header extension encryption [RFC6904] SHOULD be used. = However, a malicious endpoint may get the splicing time information by = other means, e.g., inferring from the communication between the main and = substitutive content sources. To avoid the insertion of invalid = substitutive content, the splicer MUST have some mechanisms to = authenticate the substitutive stream source. For cases that the splicing time information is changed by a malicious = endpoint, the splicing, for example, may fail since it will not be = available at the right time for the substitutive media to arrive.=20 A malicious endpoint may also break an undetectable splicing. To = mitigate this effect, the splicer SHOULD NOT forward the splicing time = information RTP header extension defined in Section 4.1 to the = receivers. And it MUST NOT forward this header extension when = considering an undetectable splicing." Thanks Roni =20 > -----Original Message----- > From: avtext [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus > Westerlund > Sent: Saturday, April 09, 2016 12:16 AM > To: Huangyihong (Rachel); avtext@ietf.org > Subject: Re: [avtext] Fwd: New Version Notification for = draft-ietf-avtext- > splicing-notification-06.txt >=20 > Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): > > Hi, > > > > This new version addresses Magnus's comment of using an agnostic > > format. That's the only change made in this version. >=20 > Hi, >=20 > So I have reviewed all the changes from the -04 to this -06 version. >=20 > First, I think people should be aware that the latest change do change = the > data format of the splicing header extension. This was not my = intention, but I > also don't care about. Just that people should be aware of this. I = understand > this is to enable the 2-bytes format to align with the 32-byte = boundaries > when it is the sole header extension present. > However, I would note that this is a unnecessary alignment most = likely. > This header extension, even when using 7-byte splicing out timestamps = do fit > within the 1-byte header extension. Thus, in most cases the sole = reason for > using the 2-byte header extension would be in cases where this header > extension is included together with another header extension requiring = the 2- > byte header extension header. So from my perspective, the old 7-byte > header extension could be used with both the 1 and 2-byte headers. >=20 > My other comment is that the Security consideration section still has = issues > from my perspective: >=20 > Since splicer works as a trusted entity, any RTP-level or outside > security mechanism, such IPsec[RFC4301] or Datagram Transport = Layer > Security [RFC6347], will use a security association between the > splicer and the receiver. When using the Secure Real-Time = Transport > Protocol (SRTP) [RFC3711], the splicer could be provisioned with = the > same security association as the main RTP sender. >=20 > So the alternatives when SRTP is to protect the content from the = Splicer to > the Receiver, then the splicer either has its own security context on = the > splicer to receiver leg, or it has as indicated access to the security = context > from main RTP sender. >=20 > Then the following paragraph seem to lack a requirement for = authenticating > the actual splicing notification, i.e. the whole RTP packet that it is = included > in. The text appear to discuss both the substitute RTP stream and if = the > notification is modified, but not an authentication requirement to = avoid this. >=20 > For cases that the splicing time information is changed by a > malicious endpoint, the splicing may fail since it will not be > available at the right time for the substitutive media to arrive >=20 > That is not the only issue, it can also be used to hide content that = the main > RTP sender intended to recieve. I think here is the right place to = insert the > authentication need. >=20 > , > which may also break an undetectable splicing. To mitigate this > effect, the splicer SHOULD NOT forward the splicing time = information > RTP header extension defined in Section 4.1 to the receivers. And = it > MUST NOT forward this header extension when considering an > undetectable splicing. >=20 > The undetectable part is a separate issue, please write it as separate > sentences. >=20 >=20 > Thanks for addressing the other issues. >=20 >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Mon May 9 08:05:27 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3133C12D511; Mon, 9 May 2016 08:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 WVRrTqjrwivA; Mon, 9 May 2016 08:05:17 -0700 (PDT) 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 E429312D50F; Mon, 9 May 2016 08:05:15 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-77-5730a70d46c2 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.E2.18043.D07A0375; Mon, 9 May 2016 17:04:45 +0200 (CEST) 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.248.2; Mon, 9 May 2016 17:04:44 +0200 To: Stephen Farrell , The IESG References: <20160503152115.8264.83977.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <5730A70B.5050300@ericsson.com> Date: Mon, 9 May 2016 17:04:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <20160503152115.8264.83977.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM2K7lq7mcoNwg+nPjCzaz51gsfh47war xe01n9gsZvyZyGyxf/F5Zovpe6+xO7B5rO2+yuaxZMlPJo+2Z3fYA5ijuGxSUnMyy1KL9O0S uDI29E1iLOgyqbi+oKyB8YNmFyMHh4SAicSr/qguRk4gU0ziwr31bF2MXBxCAkcYJa5+/csE 4SxjlFh39wwTSIOwQKbEuWMKIA0iAp4SD/tOsYDYQgIOEk0Lr7OC1DMLNDFKzHs+gQ0kwSZg IXHzRyOYzSugLdG7bDkTiM0ioCLx9sBPMFtUIEai8cEpJogaQYmTM5+ADeUUcJS4d24jWC8z 0JyZ888zQtjyEs1bZzNDLNaWaGjqYJ3AKDgLSfssJC2zkLQsYGRexShanFpcnJtuZKSXWpSZ XFycn6eXl1qyiREY3ge3/LbawXjwueMhRgEORiUeXoX3+uFCrIllxZW5hxglOJiVRHhvLjYI F+JNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEkNTs1tSC1CCbLxMEp1cDI9W73frfn wQvmXj9+Qna6VvZprsr/jyOez3m/+leEfvgmTwt1Z57EB0d51/9cvlbg8e1CnxTfLlVfF5MP b04/fbLgpmKAzlSmlkOOnHLfpl3bVZaR1MzaPLPulE729ZclPdGrFr8zDvica2TxRWxR+L3u OUZnJDmmP56/5z/H+6T16n7cj1VvK7EUZyQaajEXFScCABBTLkxrAgAA Archived-At: Cc: Jonathan Lennox , avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-sdes-hdr-ext-06: (with DISCUSS and COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 15:05:23 -0000 Hi Stephen, Please see inline. Den 2016-05-03 kl. 17:21, skrev Stephen Farrell: > Stephen Farrell has entered the following ballot position for > draft-ietf-avtext-sdes-hdr-ext-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > I'd like to check if there's a small hole in the > security/privacy properties here. If there is I hope that > a little re-wording will handle it. > > You say: (1) "In RTP sessions where any type of > confidentiality protection is enabled for RTCP, the SDES > item header extensions MUST also be protected." And then > you say: (2) "The security level that is applied to RTCP > packets carrying SDES items SHOULD also be applied to > SDES items carried as RTP header extensions." > > My concerns are that the SHOULD in (2) isn't really well > motivated (for me) - you just seem to say that someone > who doesn't follow the SHOULD has to say why, but I don't > think that's likely a run-time concept. So there are two aspects of this. The first is that protection really should be applied on matching level, if there are exceptions to this, then this is not a run-time decision for it. The run-time property here that makes this a bit more complicated, is that we have a much more limited set of algorithms for RTP header extension confidentiality protection, than we have for RTP and RTCP packets in general. Thus, there are a risk that there is not possible to find a matching security level. And we fairly often can end up in situations where the same security level is not available. However, this later case is handled by the general formulation of "security level" which gives some leeway for not having the same algorithms. Secondly, (1) > doesn't say that the new stuff has to be protected in the > same way, e.g. with the same endpoints having the keys, > and not e.g. where the RTCP data has e2e protection but > the new header field just has hop-by-hop protection. No, and for basic SRTP and existing specifications we only have mechanisms dealing with protection to the next RTP hop, that are trusted. The distinctions you are getting into become relevant in the PERC context, where it might not exist matching capabilities between hop-by-hop and end-to-end. If I correctly remember where the WGs discussion has ended up, we will be able to protected the SDES data end-to-end in the RTP header extension, but not in RTCP. I will note that the CNAME SDES item, when correctly generated is not privacy sensitive and also needed in the intermediate node to know which RTP streams that share synchronization context. I will also note that in my view having the same security level will mean that you will have to provide the same treatment in a PERC context in respect to end-to-end vs hop-by-hop. > > Are my concerns justified? (If not, that's fine you'll > tell me and we're done:-) Yes, I think they are justified. > > If these are justified concerns, I think we can easily > get around them by (a) closing that potential loophole in > (1) and (b) s/SHOULD/MUST/ in (2) or else (c) better > specify an exception to the SHOULD that makes sense at > coding time or at run time. I am fine with changing this to a MUST. I note that this might require a bit of an upgrade of the header extension protection mechanism to fulfil the MUST, but I don't see the lack of algorithm a valid exception to the SHOULD either. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > - So this one confused me for a bit but I was thinking > about RFC4568 - shame about that acronym collision;-) > It'd have helped this reader to say that this is not > about sending keys in header fields:-) But I'm probably > not the intended reader, so it's fine that you didn't. I agree that the collision is confusing, but I think we are fairly clear in the first sentences in the Introduction and abstract: This specification defines an RTP header extension [RFC3550][RFC5285] that can carry RTCP source description (SDES) items. Normally the SDES items are carried in their own RTCP packet type [RFC3550]. I intended to ignore this comment. > > - I wonder if confidentiality protection of these header > fields is likely? Is that more or less likely to be > deployed than some security for RTCP? If there's a > significant difference then I think that ought be called > out. Just pointing at rfc6904 doesn't seem entirely > sufficient to me if nobody ever does it. I don't really know about the implementation status for RFC6904. I found that Google just a couple of days ago committed to chronium a patch for RFC6904 support. > > - Has someone done an analysis of the privacy > implications of moving values from one context (RTCP) to > another (RTP) over the range of likely deployments? Note: > I'm not asserting that there is a significant privacy > exposure here, I don't know if there is or not. So I'm > just asking if folks have thought about that and e.g. > whether or not some data exposed in this header field > could allow easier re-identification or correlation or > some similar and possibly subtle privacy issue. So RTP/RTCP really is one protocol. However, I don't think there has been any deeper analytics of this. What I believe this can reveal to a party watching the packet fly by, is identifying the RTP/RTCP implementation. 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 May 16 03:10:59 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1EE12B015 for ; Mon, 16 May 2016 03:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ub5qJs2pms67 for ; Mon, 16 May 2016 03:10:56 -0700 (PDT) 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 81CF0127058 for ; Mon, 16 May 2016 03:10:55 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-7f-57399cad906f Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.94.12516.DAC99375; Mon, 16 May 2016 12:10:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.248.2; Mon, 16 May 2016 12:10:53 +0200 From: Magnus Westerlund To: "Huangyihong (Rachel)" , "avtext@ietf.org" References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86EA05A3@nkgeml513-mbx.china.huawei.com> Message-ID: <57399CAB.4050006@ericsson.com> Date: Mon, 16 May 2016 12:10:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86EA05A3@nkgeml513-mbx.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM2K7h+7aOZbhBocXqlt8vHeD1WJp5yl2 ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx+tZFloLLRhUHv79lbmB8otHFyMkhIWAi Mf9uMyuELSZx4d56ti5GLg4hgSOMEjvu7mGHcJYzSnQ3NjGDVLEJWEjc/NEIVMXBISyQIbHl BAtIWEQgWuLswy4wW0jgMKNEz2l5EJtXQFvi7KH3YAtYBFQlNuydxA5iiwrESDQ+OMUEUSMo cXLmE7BeToEwiRfbF4LFmYFWzZx/nhHClpdo3jqbGWK+tkRDUwfrBEaBWUjaZyFpmYWkZQEj 8ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwLA8uOW37g7G1a8dDzEKcDAq8fAu0LQMF2JN LCuuzD3EKMHBrCTCGzsLKMSbklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFq EUyWiYNTqoFR7u4Zg+M8srOmp4YXLEiySExuXFG/bP6ni5GfVZk3z/4t8Oz/m3VGG4w1bV8d iTzOa39QTT/8x3X2NS8PvFznPLNdseHZxPeb/mQmhCTzp1WtnJEtfHdtcKGcg37/j5XzV89Y 4mtYrZN1wupYmO4WA54dhzYdjjGZ/Gv51aTjLqbbrtvw+hbNVWIpzkg01GIuKk4EAA80CdtH AgAA Archived-At: Subject: Re: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 10:10:57 -0000 Hi, I am very sorry for the long delay in responding to this. Please see inline. Den 2016-04-12 kl. 11:36, skrev Huangyihong (Rachel): >> -----Original Message----- From: Magnus Westerlund >> [mailto:magnus.westerlund@ericsson.com] Sent: Saturday, April 09, >> 2016 5:16 AM To: Huangyihong (Rachel); avtext@ietf.org Subject: Re: >> [avtext] Fwd: New Version Notification for >> draft-ietf-avtext-splicing-notification-06.txt >> >> Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): >>> Hi, >>> >>> This new version addresses Magnus's comment of using an agnostic >>> format. That's the only change made in this version. >> >> Hi, >> >> So I have reviewed all the changes from the -04 to this -06 >> version. >> >> First, I think people should be aware that the latest change do >> change the data format of the splicing header extension. This was >> not my intention, but I also don't care about. Just that people >> should be aware of this. I understand this is to enable the 2-bytes >> format to align with the 32-byte boundaries when it is the sole >> header extension present. However, I would note that this is a >> unnecessary alignment most likely. This header extension, even when >> using 7-byte splicing out timestamps do fit within the 1-byte >> header extension. Thus, in most cases the sole reason for using the >> 2-byte header extension would be in cases where this header >> extension is included together with another header extension >> requiring the 2-byte header extension header. So from my >> perspective, the old 7-byte header extension could be used with >> both the 1 and 2-byte headers. > > [Rachel]: Yes, I agree. Both 7-byte and 6-byte extension are > applicable in this case. The only difference is alignment and bit > saving. So if you think that there's no need to have such > consideration, I'll change it to old 7-byte. Ok > >> >> My other comment is that the Security consideration section still >> has issues from my perspective: >> >> Since splicer works as a trusted entity, any RTP-level or outside >> security mechanism, such IPsec[RFC4301] or Datagram Transport >> Layer Security [RFC6347], will use a security association between >> the splicer and the receiver. When using the Secure Real-Time >> Transport Protocol (SRTP) [RFC3711], the splicer could be >> provisioned with the same security association as the main RTP >> sender. >> >> So the alternatives when SRTP is to protect the content from the >> Splicer to the Receiver, then the splicer either has its own >> security context on the splicer to receiver leg, or it has as >> indicated access to the security context from main RTP sender. >> >> Then the following paragraph seem to lack a requirement for >> authenticating the actual splicing notification, i.e. the whole RTP >> packet that it is included in. The text appear to discuss both the >> substitute RTP stream and if the notification is modified, but not >> an authentication requirement to avoid this. >> >> For cases that the splicing time information is changed by a >> malicious endpoint, the splicing may fail since it will not be >> available at the right time for the substitutive media to arrive >> >> That is not the only issue, it can also be used to hide content >> that the main RTP sender intended to recieve. I think here is the >> right place to insert the > > [Rachel]: What do you mean by hiding content that the main RTP sender > intended to receive? I can see that it only hides the content that > the substitutive sender wants to send to the receivers, but the main > RTP sender...? What do I miss? So what I mean with hiding, is that the attacker injects a splicing indication for an interval that the main RTP sender does not intend to be spliced. Such an extra splicing injection can be used to hide content from the main sender so that the receiver(s) don't get to see this, and instead get the spliced content. > >> authentication need. > > [Rachel]: So how about the following changes? > > OLD " For cases that the splicing time information is changed by a > malicious endpoint, the splicing may fail since it will not be > available at the right time for the substitutive media to arrive, > which may also break an undetectable splicing. To mitigate this > effect, the splicer SHOULD NOT forward the splicing time information > RTP header extension defined in Section 4.1 to the receivers. And it > MUST NOT forward this header extension when considering an > undetectable splicing. " > > NEW " For cases that the splicing time information is changed by a > malicious endpoint, the splicing may fail since it will not be > available at the right time for the substitutive media to arrive. To > avoid it, authentication of the RTP header extension for splicing > time information SHOULD be considered. " > Yes, I think this takes care of the first part. But I would really prefer if the text also can include a discussion of why authentication of splicing intervals are required from a point of maintaining control of the content actually forwarded to the receivers. >> >> , which may also break an undetectable splicing. To mitigate this >> effect, the splicer SHOULD NOT forward the splicing time >> information RTP header extension defined in Section 4.1 to the >> receivers. And it MUST NOT forward this header extension when >> considering an undetectable splicing. >> >> The undetectable part is a separate issue, please write it as >> separate sentences. > > [Rachel]: Okay, then a new paragraph can be added in the end. How > about that? > > " When splicing fails, the splicer SHOULD NOT forward the splicing > time information RTP header extension defined in Section 4.1 to the > receivers. And it MUST NOT forward the header extension when > considering an undetectable splicing. " > Okay, not really what I intended, but it works. 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 May 16 03:14:00 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8550112D0B0 for ; Mon, 16 May 2016 03:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wRfsOHgTMvD2 for ; Mon, 16 May 2016 03:13:57 -0700 (PDT) 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 4A3ED127058 for ; Mon, 16 May 2016 03:13:57 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-9c-57399d636411 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 24.BD.18043.36D99375; Mon, 16 May 2016 12:13:55 +0200 (CEST) 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.248.2; Mon, 16 May 2016 12:13:55 +0200 To: Roni Even , "'Huangyihong (Rachel)'" , References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> <053f01d1a7b9$f2588190$d70984b0$@gmail.com> From: Magnus Westerlund Message-ID: <57399D62.30500@ericsson.com> Date: Mon, 16 May 2016 12:13:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <053f01d1a7b9$f2588190$d70984b0$@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7nG7yXMtwg+ZnWhYf791gtVjaeYrd 4m87swOzx85Zd9k9Wo68ZfVYsuQnUwBzFJdNSmpOZllqkb5dAlfGoflTWQrW2FTMPv2TtYFx umEXIyeHhICJxNHzkxghbDGJC/fWs3UxcnEICRxhlLiz+DgThLOcUeL5o0dADgeHsECGxJYT LCANIgL5Et8vrGWFqFnMKPF530qwBJuAhcTNH41sIDavgKbE2eZXYDaLgKrE26tfmEBsUYEY icYHp5ggagQlTs58AtbLCdS7fvtHsIuYgeyZ889D2fISzVtnM4PYQgLaEg1NHawTGAVmIWmf haRlFpKWBYzMqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECQ/Xglt9WOxgPPnc8xCjAwajE w7tA0zJciDWxrLgy9xCjBAezkggv0xygEG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLp iSWp2ampBalFMFkmDk6pBsY2tu1cIvfP3bCd7iEbE76Jr5pj99FDWQd32/MfnLL9x4NCMf0U hRPL7n12jbgvEXt/85HVy0wX89fy7+Q81iBm87FWlkfIRHfKiSrPjoZXq3hvb6xbvfvXgnMx VaLia7m1XO9EMwZkpDNOZmP0lClc4vH/3JfCrhcOmh/vXH395M7zaoOz1pOVWIozEg21mIuK EwHulxJ8UQIAAA== Archived-At: Subject: Re: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 10:13:59 -0000 Hi, See one issue inline. Sorry for the delay in responding. Den 2016-05-06 kl. 19:08, skrev Roni Even: > Hi Magnus, I looked at your comments about the security section. > Since the slicer is a RTP mixer or a RTP translator as specified in > RFC 7667 I suggest adding informative reference to RFC7667 for the > security risks. There is text that requires the splicer to > authenticate the source of the splicing time message. I propose the > following text for the security section. > > > "The security considerations of the RTP specification [RFC3550] and > the general mechanism for RTP header extensions [RFC5285] apply. The > splicer can either be a mixer or a translator, and has all the > security considerations on these two standard RTP intermediaries as > such the security consideration from [RFC7667] and [RFC7201] SHOULD > be considered for the splicer. The second sentence has very strange grammar. Please address. /Magnus > > The splicer replaces some content with other content in RTP packet, > thus breaking any RTP-level end-to-end security, such as source > authentication and integrity protection. End to end source > authentication is not possible with any known existing splicing > solution. A new solution can theoretically be developed that enables > identification of the participating entities and what each provides, > i.e., the different media sources, main and substituting, and the > splicer which provides the RTP-level integration of the media > payloads in a common timeline and synchronization context. > > Since splicer works as a trusted entity, any RTP-level or outside > security mechanism, such IPsec [RFC4301] or Datagram Transport Layer > Security [RFC6347], will use a security association between the > splicer and the receiver. When using the Secure Real-Time Transport > Protocol (SRTP) [RFC3711], the splicer could be provisioned with the > same security association as the main RTP sender. > > If there is a concern about the confidentiality of the splicing time > information, header extension encryption [RFC6904] SHOULD be used. > However, a malicious endpoint may get the splicing time information > by other means, e.g., inferring from the communication between the > main and substitutive content sources. To avoid the insertion of > invalid substitutive content, the splicer MUST have some mechanisms > to authenticate the substitutive stream source. > > For cases that the splicing time information is changed by a > malicious endpoint, the splicing, for example, may fail since it will > not be available at the right time for the substitutive media to > arrive. > > A malicious endpoint may also break an undetectable splicing. To > mitigate this effect, the splicer SHOULD NOT forward the splicing > time information RTP header extension defined in Section 4.1 to the > receivers. And it MUST NOT forward this header extension when > considering an undetectable splicing." > > Thanks Roni > > > >> -----Original Message----- From: avtext >> [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Saturday, April 09, 2016 12:16 AM To: Huangyihong (Rachel); >> avtext@ietf.org Subject: Re: [avtext] Fwd: New Version Notification >> for draft-ietf-avtext- splicing-notification-06.txt >> >> Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): >>> Hi, >>> >>> This new version addresses Magnus's comment of using an agnostic >>> format. That's the only change made in this version. >> >> Hi, >> >> So I have reviewed all the changes from the -04 to this -06 >> version. >> >> First, I think people should be aware that the latest change do >> change the data format of the splicing header extension. This was >> not my intention, but I also don't care about. Just that people >> should be aware of this. I understand this is to enable the 2-bytes >> format to align with the 32-byte boundaries when it is the sole >> header extension present. However, I would note that this is a >> unnecessary alignment most likely. This header extension, even when >> using 7-byte splicing out timestamps do fit within the 1-byte >> header extension. Thus, in most cases the sole reason for using the >> 2-byte header extension would be in cases where this header >> extension is included together with another header extension >> requiring the 2- byte header extension header. So from my >> perspective, the old 7-byte header extension could be used with >> both the 1 and 2-byte headers. >> >> My other comment is that the Security consideration section still >> has issues from my perspective: >> >> Since splicer works as a trusted entity, any RTP-level or outside >> security mechanism, such IPsec[RFC4301] or Datagram Transport >> Layer Security [RFC6347], will use a security association between >> the splicer and the receiver. When using the Secure Real-Time >> Transport Protocol (SRTP) [RFC3711], the splicer could be >> provisioned with the same security association as the main RTP >> sender. >> >> So the alternatives when SRTP is to protect the content from the >> Splicer to the Receiver, then the splicer either has its own >> security context on the splicer to receiver leg, or it has as >> indicated access to the security context from main RTP sender. >> >> Then the following paragraph seem to lack a requirement for >> authenticating the actual splicing notification, i.e. the whole RTP >> packet that it is included in. The text appear to discuss both the >> substitute RTP stream and if the notification is modified, but not >> an authentication requirement to avoid this. >> >> For cases that the splicing time information is changed by a >> malicious endpoint, the splicing may fail since it will not be >> available at the right time for the substitutive media to arrive >> >> That is not the only issue, it can also be used to hide content >> that the main RTP sender intended to recieve. I think here is the >> right place to insert the authentication need. >> >> , which may also break an undetectable splicing. To mitigate this >> effect, the splicer SHOULD NOT forward the splicing time >> information RTP header extension defined in Section 4.1 to the >> receivers. And it MUST NOT forward this header extension when >> considering an undetectable splicing. >> >> The undetectable part is a separate issue, please write it as >> separate sentences. >> >> >> Thanks for addressing the other issues. >> >> >> Cheers >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> >> _______________________________________________ >> avtext mailing list avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext > > -- 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 May 16 04:27:21 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3AD12D157 for ; Mon, 16 May 2016 04:27:18 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PKpiifLeTK7x for ; Mon, 16 May 2016 04:27:16 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 332DA12D120 for ; Mon, 16 May 2016 04:27:16 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id g17so130880697wme.1 for ; Mon, 16 May 2016 04:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=hGnm2JOAJXgUNXOBpszx95Q2QCvz0w8qSU7Kn2mBrSk=; b=glpuCqjxkOB0VQZ5RIYiDB4e1LZC6AwCWq+Gk/pEtO7ExdQsvhuqoSd7Q5aLqOqYNL RtBoe0xFGAsg57CyonBUkCrkaTjWhnA0otESCnM5DdOWwbjGZbMbHpykPsisrUfDcOJk 1VPaqA+poC1KTCdPGdDEAVrbMSTdclqbG00Pl+ohsDDOnm8lqeUtYs0Gec9bwAcX61Sk WuTfNPEQerr/6MnFpC/6xwJE90Y525mir5STzOXyshOeT8jng8JcUSvKa02dCGvT6fOR eLXrIotbJb/vy2LYsQjcKSnhc0aDLnaFi+3gbUEj5RKIMPFHv8HTFWbLckJlbShz/dKP 3aCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=hGnm2JOAJXgUNXOBpszx95Q2QCvz0w8qSU7Kn2mBrSk=; b=MVZ2YEI9uF+1LOLPllU4/AyzBsOaqcgaTCQSeE+dfTerCO+XiBsxeDhDMMbzLN6+qL jbBdv0XldqZURKZz2pvNZKeITCSAdEHYNVrhi1ESMy2ZJKx6t5O3ZPsIYhFwcOo+v/i4 jAYJ/bxqojQNhbIRKTp0Vqq7b08AEPetyCZoWmVwi1D0Q2vbo+KmI6r1924ASbodGPSO g5McA27/k6fwrmcokFw43u3/hVCaFMQ2X2Tk4mLuc/y82Vqan7w/ORCIBXzkRPp6z39X dRLLIIMR5SpGEG/phf3DwXIZ+Gf/FGxf0z4MUPSxpQonyDwMi2OJ5WpIamitRsmOCEJC s+7A== X-Gm-Message-State: AOPr4FVZXDJ8+RwAC57Ta1u6WrBq26HLEpaBq3C7k0YBV6a/Vw/bvxRpCYEZ8c2XLSoS7Q== X-Received: by 10.194.139.65 with SMTP id qw1mr17604890wjb.19.1463398034719; Mon, 16 May 2016 04:27:14 -0700 (PDT) Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id t3sm2134960wmf.20.2016.05.16.04.27.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 04:27:13 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Huangyihong \(Rachel\)'" , References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> <053f01d1a7b9$f2588190$d70984b0$@gmail.com> <57399D62.30500@ericsson.com> In-Reply-To: <57399D62.30500@ericsson.com> Date: Mon, 16 May 2016 14:26:21 +0300 Message-ID: <00dd01d1af65$c72ae590$5580b0b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIOc8oubpM7/Zgx3JHTW+BFLZpufQJK5H4AAZ7DhfkB7Blyz58TNSQQ Content-Language: he Archived-At: Subject: Re: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 11:27:19 -0000 Hi Magnus, Sorry, I hope this is better "The security considerations of the RTP specification [RFC3550] and the = general mechanism for RTP header extensions [RFC5285] apply. The splicer = can be either a mixer or a translator, and all the security = considerations of these two RTP intermediaries topologies described in = [RFC7667] and [RFC7201] are applicable for the splicer." Roni > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Monday, May 16, 2016 1:14 PM > To: Roni Even; 'Huangyihong (Rachel)'; avtext@ietf.org > Subject: Re: [avtext] Fwd: New Version Notification for = draft-ietf-avtext- > splicing-notification-06.txt >=20 > Hi, >=20 > See one issue inline. Sorry for the delay in responding. >=20 > Den 2016-05-06 kl. 19:08, skrev Roni Even: > > Hi Magnus, I looked at your comments about the security section. > > Since the slicer is a RTP mixer or a RTP translator as specified in > > RFC 7667 I suggest adding informative reference to RFC7667 for the > > security risks. There is text that requires the splicer to > > authenticate the source of the splicing time message. I propose the > > following text for the security section. > > > > > > "The security considerations of the RTP specification [RFC3550] and > > the general mechanism for RTP header extensions [RFC5285] apply. The > > splicer can either be a mixer or a translator, and has all the > > security considerations on these two standard RTP intermediaries as > > such the security consideration from [RFC7667] and [RFC7201] SHOULD = be > > considered for the splicer. >=20 > The second sentence has very strange grammar. Please address. >=20 > /Magnus >=20 >=20 > > > > The splicer replaces some content with other content in RTP packet, > > thus breaking any RTP-level end-to-end security, such as source > > authentication and integrity protection. End to end source > > authentication is not possible with any known existing splicing > > solution. A new solution can theoretically be developed that enables > > identification of the participating entities and what each provides, > > i.e., the different media sources, main and substituting, and the > > splicer which provides the RTP-level integration of the media = payloads > > in a common timeline and synchronization context. > > > > Since splicer works as a trusted entity, any RTP-level or outside > > security mechanism, such IPsec [RFC4301] or Datagram Transport Layer > > Security [RFC6347], will use a security association between the > > splicer and the receiver. When using the Secure Real-Time Transport > > Protocol (SRTP) [RFC3711], the splicer could be provisioned with the > > same security association as the main RTP sender. > > > > If there is a concern about the confidentiality of the splicing time > > information, header extension encryption [RFC6904] SHOULD be used. > > However, a malicious endpoint may get the splicing time information = by > > other means, e.g., inferring from the communication between the main > > and substitutive content sources. To avoid the insertion of invalid > > substitutive content, the splicer MUST have some mechanisms to > > authenticate the substitutive stream source. > > > > For cases that the splicing time information is changed by a = malicious > > endpoint, the splicing, for example, may fail since it will not be > > available at the right time for the substitutive media to arrive. > > > > A malicious endpoint may also break an undetectable splicing. To > > mitigate this effect, the splicer SHOULD NOT forward the splicing = time > > information RTP header extension defined in Section 4.1 to the > > receivers. And it MUST NOT forward this header extension when > > considering an undetectable splicing." > > > > Thanks Roni > > > > > > > >> -----Original Message----- From: avtext > >> [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund > >> Sent: Saturday, April 09, 2016 12:16 AM To: Huangyihong (Rachel); > >> avtext@ietf.org Subject: Re: [avtext] Fwd: New Version Notification > >> for draft-ietf-avtext- splicing-notification-06.txt > >> > >> Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): > >>> Hi, > >>> > >>> This new version addresses Magnus's comment of using an agnostic > >>> format. That's the only change made in this version. > >> > >> Hi, > >> > >> So I have reviewed all the changes from the -04 to this -06 = version. > >> > >> First, I think people should be aware that the latest change do > >> change the data format of the splicing header extension. This was = not > >> my intention, but I also don't care about. Just that people should = be > >> aware of this. I understand this is to enable the 2-bytes format to > >> align with the 32-byte boundaries when it is the sole header > >> extension present. However, I would note that this is a unnecessary > >> alignment most likely. This header extension, even when using = 7-byte > >> splicing out timestamps do fit within the 1-byte header extension. > >> Thus, in most cases the sole reason for using the 2-byte header > >> extension would be in cases where this header extension is included > >> together with another header extension requiring the 2- byte header > >> extension header. So from my perspective, the old 7-byte header > >> extension could be used with both the 1 and 2-byte headers. > >> > >> My other comment is that the Security consideration section still = has > >> issues from my perspective: > >> > >> Since splicer works as a trusted entity, any RTP-level or outside > >> security mechanism, such IPsec[RFC4301] or Datagram Transport Layer > >> Security [RFC6347], will use a security association between the > >> splicer and the receiver. When using the Secure Real-Time Transport > >> Protocol (SRTP) [RFC3711], the splicer could be provisioned with = the > >> same security association as the main RTP sender. > >> > >> So the alternatives when SRTP is to protect the content from the > >> Splicer to the Receiver, then the splicer either has its own = security > >> context on the splicer to receiver leg, or it has as indicated = access > >> to the security context from main RTP sender. > >> > >> Then the following paragraph seem to lack a requirement for > >> authenticating the actual splicing notification, i.e. the whole RTP > >> packet that it is included in. The text appear to discuss both the > >> substitute RTP stream and if the notification is modified, but not = an > >> authentication requirement to avoid this. > >> > >> For cases that the splicing time information is changed by a > >> malicious endpoint, the splicing may fail since it will not be > >> available at the right time for the substitutive media to arrive > >> > >> That is not the only issue, it can also be used to hide content = that > >> the main RTP sender intended to recieve. I think here is the right > >> place to insert the authentication need. > >> > >> , which may also break an undetectable splicing. To mitigate this > >> effect, the splicer SHOULD NOT forward the splicing time = information > >> RTP header extension defined in Section 4.1 to the receivers. And = it > >> MUST NOT forward this header extension when considering an > >> undetectable splicing. > >> > >> The undetectable part is a separate issue, please write it as > >> separate sentences. > >> > >> > >> Thanks for addressing the other issues. > >> > >> > >> 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 > >> = --------------------------------------------------------------------- > >> - > >> > >> > >> > _______________________________________________ > >> avtext mailing list avtext@ietf.org > >> https://www.ietf.org/mailman/listinfo/avtext > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 Mon May 16 06:47:23 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CF112D185; Mon, 16 May 2016 06:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ziOv7ksVSiEw; Mon, 16 May 2016 06:47:01 -0700 (PDT) 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 CFFA512D6BD; Mon, 16 May 2016 06:46:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B2265BDD0; Mon, 16 May 2016 14:46:53 +0100 (IST) 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 3eMyb2NGd5y8; Mon, 16 May 2016 14:46:53 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 41380BE2C; Mon, 16 May 2016 14:46:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463406410; bh=ln8ymnzbTp2hlEhrWb8KXsBYdKuVOmy5yk4ijrziPOs=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=i6LxfPmCqNUsrUsX1fCiTojrSlbGCdi5XHru1wBXI+Wd+l6qqvBsLx5koDJlQH0pm 4xqyZy3uI/nH8GTyEuD/NzsMHbZ7NJl2KxKiI3lVCF9MJF2Apy46VQ8+rPtRZAgVNQ tB3T8nRL3yayGSVzZb/65+PsWxtuVp20x9pGvjiA= To: Magnus Westerlund , The IESG References: <20160503152115.8264.83977.idtracker@ietfa.amsl.com> <5730A70B.5050300@ericsson.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5739CF49.4080007@cs.tcd.ie> Date: Mon, 16 May 2016 14:46:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5730A70B.5050300@ericsson.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030506060404070509090009" Archived-At: Cc: Jonathan Lennox , avtext@ietf.org, draft-ietf-avtext-sdes-hdr-ext@ietf.org, avtext-chairs@ietf.org Subject: Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-sdes-hdr-ext-06: (with DISCUSS and COMMENT) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 13:47:21 -0000 This is a cryptographically signed message in MIME format. --------------ms030506060404070509090009 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Sorry for the slow response, was travelling... On 09/05/16 16:04, Magnus Westerlund wrote: > Hi Stephen, >=20 > Please see inline. >=20 > Den 2016-05-03 kl. 17:21, skrev Stephen Farrell: >> Stephen Farrell has entered the following ballot position for >> draft-ietf-avtext-sdes-hdr-ext-06: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut thi= s >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-avtext-sdes-hdr-ext/ >> >> >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> I'd like to check if there's a small hole in the >> security/privacy properties here. If there is I hope that >> a little re-wording will handle it. >> >> You say: (1) "In RTP sessions where any type of >> confidentiality protection is enabled for RTCP, the SDES >> item header extensions MUST also be protected." And then >> you say: (2) "The security level that is applied to RTCP >> packets carrying SDES items SHOULD also be applied to >> SDES items carried as RTP header extensions." >> >> My concerns are that the SHOULD in (2) isn't really well >> motivated (for me) - you just seem to say that someone >> who doesn't follow the SHOULD has to say why, but I don't >> think that's likely a run-time concept. >=20 > So there are two aspects of this. The first is that protection really > should be applied on matching level, if there are exceptions to this, > then this is not a run-time decision for it. The run-time property here= > that makes this a bit more complicated, is that we have a much more > limited set of algorithms for RTP header extension confidentiality > protection, than we have for RTP and RTCP packets in general. Thus, > there are a risk that there is not possible to find a matching security= > level. And we fairly often can end up in situations where the same > security level is not available. However, this later case is handled by= > the general formulation of "security level" which gives some leeway for= > not having the same algorithms. Ok, if this is down to crypto algorithms or modes of operation of crypto algorithms, then would something like "MUST use commensurate strength algorithms and SHOULD use the same cryptographic primitives (algorithms, modes)" work? >=20 >=20 > Secondly, (1) >> doesn't say that the new stuff has to be protected in the >> same way, e.g. with the same endpoints having the keys, >> and not e.g. where the RTCP data has e2e protection but >> the new header field just has hop-by-hop protection. >=20 > No, and for basic SRTP and existing specifications we only have > mechanisms dealing with protection to the next RTP hop, that are > trusted.=20 I think that'd be worth explaining a bit in the document, as it wasn't at all clear to me. Would it be clear to folks who know loads about RTP/RTCP but less about security? If not, then I'd say explaining it would be good. The distinctions you are getting into become relevant in the > PERC context, where it might not exist matching capabilities between > hop-by-hop and end-to-end. If I correctly remember where the WGs > discussion has ended up, we will be able to protected the SDES data > end-to-end in the RTP header extension, but not in RTCP. >=20 > I will note that the CNAME SDES item, when correctly generated is not > privacy sensitive and also needed in the intermediate node to know whic= h > RTP streams that share synchronization context. >=20 > I will also note that in my view having the same security level will > mean that you will have to provide the same treatment in a PERC context= > in respect to end-to-end vs hop-by-hop. >=20 >> >> Are my concerns justified? (If not, that's fine you'll >> tell me and we're done:-) >=20 > Yes, I think they are justified. >=20 >> >> If these are justified concerns, I think we can easily >> get around them by (a) closing that potential loophole in >> (1) and (b) s/SHOULD/MUST/ in (2) or else (c) better >> specify an exception to the SHOULD that makes sense at >> coding time or at run time. >=20 > I am fine with changing this to a MUST. I note that this might require = a > bit of an upgrade of the header extension protection mechanism to fulfi= l > the MUST, but I don't see the lack of algorithm a valid exception to th= e > SHOULD either. See if the text suggestion above works. Cheers, S. PS: Your responses to the comments below are just fine too. >=20 >> >> >> ----------------------------------------------------------------------= >> COMMENT: >> ----------------------------------------------------------------------= >> >> >> - So this one confused me for a bit but I was thinking >> about RFC4568 - shame about that acronym collision;-) >> It'd have helped this reader to say that this is not >> about sending keys in header fields:-) But I'm probably >> not the intended reader, so it's fine that you didn't. >=20 > I agree that the collision is confusing, but I think we are fairly clea= r > in the first sentences in the Introduction and abstract: >=20 > This specification defines an RTP header extension [RFC3550][RFC5285] > that can carry RTCP source description (SDES) items. Normally the > SDES items are carried in their own RTCP packet type [RFC3550]. >=20 > I intended to ignore this comment. >=20 >> >> - I wonder if confidentiality protection of these header >> fields is likely? Is that more or less likely to be >> deployed than some security for RTCP? If there's a >> significant difference then I think that ought be called >> out. Just pointing at rfc6904 doesn't seem entirely >> sufficient to me if nobody ever does it. >=20 > I don't really know about the implementation status for RFC6904. I foun= d > that Google just a couple of days ago committed to chronium a patch for= > RFC6904 support. >=20 >> >> - Has someone done an analysis of the privacy >> implications of moving values from one context (RTCP) to >> another (RTP) over the range of likely deployments? Note: >> I'm not asserting that there is a significant privacy >> exposure here, I don't know if there is or not. So I'm >> just asking if folks have thought about that and e.g. >> whether or not some data exposed in this header field >> could allow easier re-identification or correlation or >> some similar and possibly subtle privacy issue. >=20 > So RTP/RTCP really is one protocol. >=20 > However, I don't think there has been any deeper analytics of this. Wha= t > I believe this can reveal to a party watching the packet fly by, is > identifying the RTP/RTCP implementation. >=20 > Cheers >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > 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 > ---------------------------------------------------------------------- >=20 --------------ms030506060404070509090009 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTYx MzQ2NDlaMC8GCSqGSIb3DQEJBDEiBCB1zINImRIIKsYcqpFealvRuUiRnsTlXk6j51MjLJH9 ZDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA8oB5684u9vB3Bc7yTqXXj7UEJ2VGAe3slSih1uPl6luvH0ajKEHES lOvhdm0QkQW38yTeQk7MfB3McT57xCmSmHAE51fR+FDtlD3eEzK7uBdz/HMU5YDW3B6gfBvz 2xqNI4ycXFbrnAnZPJ74C42hAYu1y0doPkUas2GjND50XwRynP8zHFjY5UMhiri5I9Vuehou qh1lW3bFniSLfNwgfgSOjtmtNxVD6aPApyHnlOD5kFC5aPJYM1qONumSQEi/Y6hei3NB3KHp QxQphQRCD79XlhahOFTP2xfMIDBHof5bIBvUekAC+XZ+PY3g9Gh3pqabZc+dUhjWKMm2YqAR AAAAAAAA --------------ms030506060404070509090009-- From nobody Mon May 16 08:46:43 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88DE12D6F9 for ; Mon, 16 May 2016 08:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GgV-95V0wJTp for ; Mon, 16 May 2016 08:46:40 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65A6012D1B9 for ; Mon, 16 May 2016 08:46:39 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u4GFkYbr001525 for ; Mon, 16 May 2016 11:46:34 -0400 Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 22tr3pckdn-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 16 May 2016 11:46:33 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Mon, 16 May 2016 10:46:32 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: 2nd WGLC: draft-ietf-avtext-rid-02 Thread-Index: AQHRr4oesklw464og0Kd9+LcGwuNFA== Date: Mon, 16 May 2016 15:46:32 +0000 Message-ID: <3186E797-0143-4A35-B693-CF719778B986@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <19B8F245C2F94D4583B0F619EB434970@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-05-16_07:2016-05-16,2016-05-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1603290000 definitions=main-1605160210 Archived-At: Subject: [avtext] 2nd WGLC: draft-ietf-avtext-rid-02 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 15:46:42 -0000 Rm9sbG93aW5nIHRoZSBkb2N1bWVudOKAmXMgY2hhbmdlcyBhZnRlciB0aGUgQnVlbm9zIEFpcmVz IGRpc2N1c3Npb24sIHRoaXMgaXMgdG8gYW5ub3VuY2UgYSBzZWNvbmQsIDIgd2VlayBXb3JraW5n IEdyb3VwIExhc3QgQ2FsbCBmb3INCg0KCWRyYWZ0LWlldGYtYXZ0ZXh0LXJpZC0wMg0KDQphcyBw cm9wb3NlZCBzdGFuZGFyZC4NCg0KUGxlYXNlIHJldmlldyBhbmQgcHJvdmlkZSBhbnkgY29tbWVu dHMgeW91IG1heSBoYXZlIG9uIHRoZSBkb2N1bWVudCBieSBNb25kYXksIE1heSAzMHRoLiBDb21t ZW50cyBzaG91bGQgYmUgc2VudCB0byB0aGUgZG9jdW1lbnQgYXV0aG9ycyBhbmQgdGhlIEFWVEVY VCBXRyBsaXN0Lg0KDQpJZiB5b3UgcmV2aWV3IHRoZSBkb2N1bWVudCBidXQgZG8gbm90IGhhdmUg YW55IGNvbW1lbnRzLCBwbGVhc2Ugc2VuZCBhIG5vdGUgdG8gdGhhdCBlZmZlY3QgYXMgd2VsbC4N Cg0KVGhhbmsgeW91IQ0KDQogICAgICAgSm9uYXRoYW4gKEFWVEVYVCBjby1jaGFpcik= From nobody Mon May 16 19:13:13 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DCD12D1A0 for ; Mon, 16 May 2016 19:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CPkTY-sZSLco for ; Mon, 16 May 2016 19:13:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE2D12D592 for ; Mon, 16 May 2016 19:13:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKA69650; Tue, 17 May 2016 02:13:07 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 17 May 2016 03:13:06 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.148]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 17 May 2016 10:13:01 +0800 From: "Huangyihong (Rachel)" To: Magnus Westerlund , "avtext@ietf.org" Thread-Topic: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt Thread-Index: AQHRkdyyduEzFzil3kGXbQ2A5yKoH5+GB/KQgDUEq4CAAYwC8A== Date: Tue, 17 May 2016 02:13:00 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86EB7EE6@nkgeml513-mbx.china.huawei.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> <51E6A56BD6A85142B9D172C87FC3ABBB86EA05A3@nkgeml513-mbx.china.huawei.com> <57399CAB.4050006@ericsson.com> In-Reply-To: <57399CAB.4050006@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.573A7E34.00B5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 2cec4ee5452af897a84b2a0ddc78a4b4 Archived-At: Subject: Re: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 02:13:13 -0000 SGkgTWFnbnVzLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcmVwbGllcy4gV2UnbGwgbW9kaWZ5IHRo ZSBkcmFmdCBhcyBzb29uIGFzIHBvc3NpYmxlIHRvIGFkZHJlc3MgeW91ciBjb21tZW50cy4gUGxl YXNlIHNlZSBpbmxpbmUuIEkgcmVtb3ZlIHRoZSBwYXJ0cyB0aGF0IGRvbid0IG5lZWQgZnVydGhl ciBkaXNjdXNzaW9uLg0KDQpCUiwNClJhY2hlbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21haWx0bzptYWdudXMud2VzdGVybHVu ZEBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDY6MTEgUE0NCj4g VG86IEh1YW5neWlob25nIChSYWNoZWwpOyBhdnRleHRAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFthdnRleHRdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1pZXRm LWF2dGV4dC1zcGxpY2luZy1ub3RpZmljYXRpb24tMDYudHh0DQo+IA0KPiBIaSwNCj4gDQo+IEkg YW0gdmVyeSBzb3JyeSBmb3IgdGhlIGxvbmcgZGVsYXkgaW4gcmVzcG9uZGluZyB0byB0aGlzLg0K PiANCj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+IA0KPiANCj4gPg0KPiA+IFtSYWNoZWxdOiBXaGF0 IGRvIHlvdSBtZWFuIGJ5IGhpZGluZyBjb250ZW50IHRoYXQgdGhlIG1haW4gUlRQIHNlbmRlcg0K PiA+IGludGVuZGVkIHRvIHJlY2VpdmU/IEkgY2FuIHNlZSB0aGF0IGl0IG9ubHkgaGlkZXMgdGhl IGNvbnRlbnQgdGhhdCB0aGUNCj4gPiBzdWJzdGl0dXRpdmUgc2VuZGVyIHdhbnRzIHRvIHNlbmQg dG8gdGhlIHJlY2VpdmVycywgYnV0IHRoZSBtYWluIFJUUA0KPiA+IHNlbmRlci4uLj8gV2hhdCBk byBJIG1pc3M/DQo+IA0KPiBTbyB3aGF0IEkgbWVhbiB3aXRoIGhpZGluZywgaXMgdGhhdCB0aGUg YXR0YWNrZXIgaW5qZWN0cyBhIHNwbGljaW5nIGluZGljYXRpb24gZm9yDQo+IGFuIGludGVydmFs IHRoYXQgdGhlIG1haW4gUlRQIHNlbmRlciBkb2VzIG5vdCBpbnRlbmQgdG8gYmUgc3BsaWNlZC4g U3VjaCBhbg0KPiBleHRyYSBzcGxpY2luZyBpbmplY3Rpb24gY2FuIGJlIHVzZWQgdG8gaGlkZSBj b250ZW50IGZyb20gdGhlIG1haW4gc2VuZGVyIHNvDQo+IHRoYXQgdGhlIHJlY2VpdmVyKHMpIGRv bid0IGdldCB0byBzZWUgdGhpcywgYW5kIGluc3RlYWQgZ2V0IHRoZSBzcGxpY2VkIGNvbnRlbnQu DQo+IA0KPiANCg0KW1JhY2hlbF06IEdvdCBpdC4NCg0KPiA+DQo+ID4+IGF1dGhlbnRpY2F0aW9u IG5lZWQuDQo+ID4NCj4gPiBbUmFjaGVsXTogU28gaG93IGFib3V0IHRoZSBmb2xsb3dpbmcgY2hh bmdlcz8NCj4gPg0KPiA+IE9MRCAiIEZvciBjYXNlcyB0aGF0IHRoZSBzcGxpY2luZyB0aW1lIGlu Zm9ybWF0aW9uIGlzIGNoYW5nZWQgYnkgYQ0KPiA+IG1hbGljaW91cyBlbmRwb2ludCwgdGhlIHNw bGljaW5nIG1heSBmYWlsIHNpbmNlIGl0IHdpbGwgbm90IGJlDQo+ID4gYXZhaWxhYmxlIGF0IHRo ZSByaWdodCB0aW1lIGZvciB0aGUgc3Vic3RpdHV0aXZlIG1lZGlhIHRvIGFycml2ZSwNCj4gPiB3 aGljaCBtYXkgYWxzbyBicmVhayBhbiB1bmRldGVjdGFibGUgc3BsaWNpbmcuIFRvIG1pdGlnYXRl IHRoaXMNCj4gPiBlZmZlY3QsIHRoZSBzcGxpY2VyIFNIT1VMRCBOT1QgZm9yd2FyZCB0aGUgc3Bs aWNpbmcgdGltZSBpbmZvcm1hdGlvbg0KPiA+IFJUUCBoZWFkZXIgZXh0ZW5zaW9uIGRlZmluZWQg aW4gU2VjdGlvbiA0LjEgdG8gdGhlIHJlY2VpdmVycy4gQW5kIGl0DQo+ID4gTVVTVCBOT1QgZm9y d2FyZCB0aGlzIGhlYWRlciBleHRlbnNpb24gd2hlbiBjb25zaWRlcmluZyBhbg0KPiA+IHVuZGV0 ZWN0YWJsZSBzcGxpY2luZy4gIg0KPiA+DQo+ID4gTkVXICIgRm9yIGNhc2VzIHRoYXQgdGhlIHNw bGljaW5nIHRpbWUgaW5mb3JtYXRpb24gaXMgY2hhbmdlZCBieSBhDQo+ID4gbWFsaWNpb3VzIGVu ZHBvaW50LCB0aGUgc3BsaWNpbmcgbWF5IGZhaWwgc2luY2UgaXQgd2lsbCBub3QgYmUNCj4gPiBh dmFpbGFibGUgYXQgdGhlIHJpZ2h0IHRpbWUgZm9yIHRoZSBzdWJzdGl0dXRpdmUgbWVkaWEgdG8g YXJyaXZlLiBUbw0KPiA+IGF2b2lkIGl0LCBhdXRoZW50aWNhdGlvbiBvZiB0aGUgUlRQIGhlYWRl ciBleHRlbnNpb24gZm9yIHNwbGljaW5nIHRpbWUNCj4gPiBpbmZvcm1hdGlvbiBTSE9VTEQgYmUg Y29uc2lkZXJlZC4gIg0KPiA+DQo+IA0KPiBZZXMsIEkgdGhpbmsgdGhpcyB0YWtlcyBjYXJlIG9m IHRoZSBmaXJzdCBwYXJ0LiBCdXQgSSB3b3VsZCByZWFsbHkgcHJlZmVyIGlmIHRoZSB0ZXh0DQo+ IGFsc28gY2FuIGluY2x1ZGUgYSBkaXNjdXNzaW9uIG9mIHdoeSBhdXRoZW50aWNhdGlvbiBvZiBz cGxpY2luZyBpbnRlcnZhbHMgYXJlDQo+IHJlcXVpcmVkIGZyb20gYSBwb2ludCBvZiBtYWludGFp bmluZyBjb250cm9sIG9mIHRoZSBjb250ZW50IGFjdHVhbGx5IGZvcndhcmRlZA0KPiB0byB0aGUg cmVjZWl2ZXJzLg0KPiANCg0KW1JhY2hlbF06IFNvIGRvZXMgdGhlIGZvbGxvd2luZyBwcm9wb3Nh bCBjbGVhciB5b3VyIGNvbmNlcm4/DQoNCiBORVcNCg0KIiBGb3IgY2FzZXMgdGhhdCB0aGUgc3Bs aWNpbmcgdGltZSBpbmZvcm1hdGlvbiBpcyBjaGFuZ2VkIGJ5IGENCiBtYWxpY2lvdXMgZW5kcG9p bnQsIHRoZSBzcGxpY2luZyBtYXkgZmFpbCBzaW5jZSBpdCB3aWxsIG5vdCBiZQ0KIGF2YWlsYWJs ZSBhdCB0aGUgcmlnaHQgdGltZSBmb3IgdGhlIHN1YnN0aXR1dGl2ZSBtZWRpYSB0byBhcnJpdmUu IE9yLCBhbiBhdHRhY2tlciBtYXkgDQogcHJldmVudCB0aGUgcmVjZWl2ZXJzIHJlY2VpdmluZyB0 aGUgY29udGVudCBmcm9tIHRoZSBtYWluIHNlbmRlciBieSBpbnNlcnRpbmcgYWRkaXRpb25hbCBz cGxpY2luZyB0aW1lDQogaW5mb3JtYXRpb24uIFRvIGF2b2lkIHN1Y2ggY2FzZXMgaGFwcGVuaW5n LCBhdXRoZW50aWNhdGlvbiBvZiB0aGUgUlRQIGhlYWRlciBleHRlbnNpb24gZm9yIHNwbGljaW5n IHRpbWUNCmluZm9ybWF0aW9uIFNIT1VMRCBiZSBjb25zaWRlcmVkLg0KIg0KDQoNCg== From nobody Mon May 16 23:46:58 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2012B05C; Mon, 16 May 2016 23:46:57 -0700 (PDT) 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: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160517064657.16837.12960.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 23:46:57 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-07.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 06:46:57 -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 Extensions of the IETF. Title : RTP/RTCP extension for RTP Splicing Notification Authors : Jinwei Xia Roni Even Rachel Huang Lingli Deng Filename : draft-ietf-avtext-splicing-notification-07.txt Pages : 20 Date : 2016-05-16 Abstract: Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-07 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 Mon May 16 23:51:49 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F8312D10A for ; Mon, 16 May 2016 23:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 L7kRsPrmMoMk for ; Mon, 16 May 2016 23:51:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23DE012D0CD for ; Mon, 16 May 2016 23:51:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id COV42300; Tue, 17 May 2016 06:51:42 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 17 May 2016 07:51:41 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.148]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 17 May 2016 14:51:38 +0800 From: "Huangyihong (Rachel)" To: "avtext@ietf.org" Thread-Topic: [avtext]FW: New Version Notification for draft-ietf-avtext-splicing-notification-07.txt Thread-Index: AQHRsAiPCgWhXZGw00iLkURndsw4cw== Date: Tue, 17 May 2016 06:51:37 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB86EB8328@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.79.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.573ABF7F.000A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.148, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 42e95e86c6b85f2b322d413650ba3353 Archived-At: Subject: [avtext] FW: New Version Notification for draft-ietf-avtext-splicing-notification-07.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 06:51:47 -0000 SGkgV0csDQoNClRoaXMgbmV3IHZlcnNpb24gdHJpZXMgdG8gYWRkcmVzcyBNYWdudXMncyBmdXJ0 aGVyIGNvbW1lbnRzLiBUaGUgbWFpbiBjaGFuZ2VzIGluY2x1ZGUgdXNpbmcgNy1ieXRlIGV4dGVu c2lvbiBpbnN0ZWFkIG9mIDctYnl0ZSBhbmQgbW9kaWZ5aW5nIHRoZSBzZWN1cml0eSBzZWN0aW9u Lg0KDQpCUiwNClJhY2hlbA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd IA0KU2VudDogVHVlc2RheSwgTWF5IDE3LCAyMDE2IDI6NDcgUE0NClRvOiBEZW5nIExpbmdsaTsg Um9uaSBFdmVuOyBYaWFqaW53ZWk7IEh1YW5neWlob25nIChSYWNoZWwpOyBMaW5nbGkgRGVuZw0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWF2dGV4dC1z cGxpY2luZy1ub3RpZmljYXRpb24tMDcudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNy50eHQNCmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUmFjaGVsIEh1YW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElF VEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlm aWNhdGlvbg0KUmV2aXNpb246CTA3DQpUaXRsZToJCVJUUC9SVENQIGV4dGVuc2lvbiBmb3IgUlRQ IFNwbGljaW5nIE5vdGlmaWNhdGlvbg0KRG9jdW1lbnQgZGF0ZToJMjAxNi0wNS0xNw0KR3JvdXA6 CQlhdnRleHQNClBhZ2VzOgkJMjANClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmctbm90aWZpY2F0aW9u LTA3LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi8NCkh0bWxpemVkOiAgICAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hdnRleHQtc3BsaWNpbmct bm90aWZpY2F0aW9uLTA3DQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtYXZ0ZXh0LXNwbGljaW5nLW5vdGlmaWNhdGlvbi0wNw0KDQpB YnN0cmFjdDoNCiAgIENvbnRlbnQgc3BsaWNpbmcgaXMgYSBwcm9jZXNzIHRoYXQgcmVwbGFjZXMg dGhlIGNvbnRlbnQgb2YgYSBtYWluDQogICBtdWx0aW1lZGlhIHN0cmVhbSB3aXRoIG90aGVyIG11 bHRpbWVkaWEgY29udGVudCwgYW5kIGRlbGl2ZXJzIHRoZQ0KICAgc3Vic3RpdHV0aXZlIG11bHRp bWVkaWEgY29udGVudCB0byB0aGUgcmVjZWl2ZXJzIGZvciBhIHBlcmlvZCBvZg0KICAgdGltZS4g VGhlIHNwbGljZXIgaXMgZGVzaWduZWQgdG8gaGFuZGxlIFJUUCBzcGxpY2luZyBhbmQgbmVlZHMg dG8NCiAgIGtub3cgd2hlbiB0byBzdGFydCBhbmQgZW5kIHRoZSBzcGxpY2luZy4NCg0KICAgVGhp cyBtZW1vIGRlZmluZXMgdHdvIFJUUC9SVENQIGV4dGVuc2lvbnMgdG8gaW5kaWNhdGUgdGhlIHNw bGljaW5nDQogICByZWxhdGVkIGluZm9ybWF0aW9uIHRvIHRoZSBzcGxpY2VyOiBhbiBSVFAgaGVh ZGVyIGV4dGVuc2lvbiB0aGF0DQogICBjb252ZXlzIHRoZSBpbmZvcm1hdGlvbiBpbi1iYW5kIGFu ZCBhbiBSVENQIHBhY2tldCB0aGF0IGNvbnZleXMgdGhlDQogICBpbmZvcm1hdGlvbiBvdXQtb2Yt YmFuZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQg aXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Np b24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue May 17 02:00:00 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB2412B00C for ; Tue, 17 May 2016 01:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 u2dVC-T_qqL9 for ; Tue, 17 May 2016 01:59:57 -0700 (PDT) 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 BD54712B055 for ; Tue, 17 May 2016 01:59:56 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-67-573add8a7c6a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D3.BA.27088.A8DDA375; Tue, 17 May 2016 10:59:55 +0200 (CEST) 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.248.2; Tue, 17 May 2016 10:59:54 +0200 To: "Huangyihong (Rachel)" , "avtext@ietf.org" References: <51E6A56BD6A85142B9D172C87FC3ABBB86EB8328@nkgeml513-mbx.china.huawei.com> From: Magnus Westerlund Message-ID: <573ADD8A.5080606@ericsson.com> Date: Tue, 17 May 2016 10:59:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB86EB8328@nkgeml513-mbx.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM2K7t273Xatwgz93uCw+3rvBarG08xS7 A5NHy5G3rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpofvyfuWATW8XuPx2MDYyzWbsYOTkkBEwk Fh88zQhhi0lcuLeerYuRi0NI4AijxIbTl6Cc5YwSlz68A6sSFkiXODR9KRuILSIQLXH2YRcL iC0kECrxe9lUJhCbTcBC4uaPRrAaXgFtiZO3Z4H1sgioSjQ1f2QHsUUFYiQaH5xigqgRlDg5 8wnYHE6BMIkzDSuBajg4mAXsJR5sLQMJMwvISzRvnc0MsUpboqGpg3UCo8AsJN2zEDpmIelY wMi8ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwKA9u+W2wg/Hlc8dDjAIcjEo8vA+crMKF WBPLiitzDzFKcDArifA23QIK8aYkVlalFuXHF5XmpBYfYpTmYFES5/V/qRguJJCeWJKanZpa kFoEk2Xi4JRqYORhNGFgCO+cteh2umvG50Tz31t0pG2zkuba7VmdsayLv6hSa3NNnYdPaHzO sR7HlMuB0Xzf5cKfur6Uf29y4eaPyNZ7jwpj+LsfbvPWM5N065xiw6bn+4dhqsSxh7dU5h4I Zv/all1y6WnjZBt1O3OO2dnJNVOWqm16p/bs1OU5uRuEL660UGIpzkg01GIuKk4EADhjl9lG AgAA Archived-At: Subject: Re: [avtext] FW: New Version Notification for draft-ietf-avtext-splicing-notification-07.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 08:59:58 -0000 Den 2016-05-17 kl. 08:51, skrev Huangyihong (Rachel): > Hi WG, > > This new version tries to address Magnus's further comments. The main > changes include using 7-byte extension instead of 7-byte and > modifying the security section. Hi, I think this is good enough and the next steps for publication can be done. 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 May 17 09:29:10 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 529DE12DAC8; Tue, 17 May 2016 09:29:06 -0700 (PDT) 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: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160517162906.22229.92580.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 09:29:06 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-avpf-ccm-layered-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 16:29:06 -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 Extensions of the IETF. Title : Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs Authors : Stephan Wenger Jonathan Lennox Bo Burman Magnus Westerlund Filename : draft-ietf-avtext-avpf-ccm-layered-01.txt Pages : 11 Date : 2016-05-17 Abstract: This document fixes a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) as defined in RFC5104 when using with layered codecs. In particular, a Decoder Refresh Point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless on whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 as updated by RFC 5506 have also been analyzed, and no corresponding shortcomings have been found. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-avpf-ccm-layered/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-avpf-ccm-layered-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-avpf-ccm-layered-01 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 May 17 09:33:24 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F6212D997 for ; Tue, 17 May 2016 09:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TZEJ4MpK59lh for ; Tue, 17 May 2016 09:33:21 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB33712D707 for ; Tue, 17 May 2016 09:33:20 -0700 (PDT) Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0274.namprd17.prod.outlook.com (10.162.235.145) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 16:33:18 +0000 Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0497.019; Tue, 17 May 2016 16:33:18 +0000 From: Stephan Wenger To: "avtext@ietf.org" Thread-Topic: New Version Notification for draft-ietf-avtext-avpf-ccm-layered-01.txt Thread-Index: AQHRsFk80LSl2c6bvEuxZoT2wLXVrp+83ZaA Date: Tue, 17 May 2016 16:33:18 +0000 Message-ID: References: <20160517162906.22229.82660.idtracker@ietfa.amsl.com> In-Reply-To: <20160517162906.22229.82660.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-ms-office365-filtering-correlation-id: 3b6698ee-4a40-4f2d-75f5-08d37e70f403 x-microsoft-exchange-diagnostics: 1; BLUPR17MB0274; 5:ljf/kbDus4UrspxgAeHEeWGjeGkUka3DGVnHrczXRAOQY12XOIS+uvCISb+k+Qr33hkcyNzxOxbos1thfjckefq1lS7hHrb2ygjIJCw/osQJac6KU43CqV0s+oWjhVWZ9D1s11Q6og6qK5B4HCIbOA==; 24:icZyf0LLOdsTKLdTjYa57V0OUO5JgU9D2222Zczy2p90YRpfVQVwoNd3HitqHnwJTq9dWXqhELboJfQJGbqf+WRMMTkAqYCkNSgXRUAeCFQ=; 7:E+WwtS/XftKDCnwXiU8Szu0YHb/yKrkefMyR+g7bTIoyG3oc3huR6jCMA42gkkDNWM1jWQsF5jkOFPoG8fu0w1W9RE8bysxTlO9eUgRxk94gXLrI7S2jI4zEIst5GG22VNpe2XCQmKGTMupdWrW6JKvQAqg8nxEv9/m22bD93mycpUTzA+wz31QbvuYj/OFR x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0274; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040130)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041072)(6043046); SRVR:BLUPR17MB0274; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0274; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(24454002)(53754006)(450100001)(15650500001)(1220700001)(106116001)(10400500002)(230783001)(87936001)(189998001)(19580405001)(82746002)(5640700001)(19580395003)(8936002)(83716003)(2906002)(5004730100002)(11100500001)(92566002)(36756003)(5008740100001)(8676002)(86362001)(81166006)(2351001)(33656002)(110136002)(3846002)(2501003)(102836003)(6116002)(15975445007)(77096005)(107886002)(5002640100001)(54356999)(50986999)(76176999)(1730700003)(2950100001)(586003)(2900100001)(122556002)(66066001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0274; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 16:33:18.1551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0274 Archived-At: Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-avpf-ccm-layered-01.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 16:33:23 -0000 SGkgYWxsLA0KDQpJIGhhdmUgcG9zdGVkIGFuIHVwZGF0ZSB0byB0aGUgY2NtLWxheWVyZWQgZHJh ZnQuICBUaGVyZSBpcyBvbmx5IG9uZSBjaGFuZ2UuICBGcm9tIHRoZSBjaGFuZ2UtbG9nOg0KDQpk cmFmdC1pZXRmLWF2dGV4dC1hdnBmLWNjbS1sYXllcmVkLTAwOiBJbiBzZWN0aW9uICJJZGVudGlm eWluZyB0aGUgdXNlIG9mIExheWVyZWQgQ29kZWNzIChJbmZvcm1hdGl2ZSkiLCByZW1vdmVkIGxh c3Qgc2VudGVuY2UgdGhhdCBjb3VsZCBiZSBtaXNyZWFkIHRoYXQgdGhlIGV4cGxpY2l0IHNpZ25h bGluZyBvZiBzaW11bGNhc3RpbmcgaW4gY29uanVuY3Rpb24gd2l0aCBwYXlsb2FkIGZvcm1hdHMg c3VwcG9ydGluZyBsYXllcmVkIGNvZGluZyBpbXBsaWVzIG5vIGxheWVyaW5nLg0KDQpXZSBoYWQg YSBzaG9ydCBkaXNjdXNzaW9uIGFib3V0IHRoaXMgaXNzdWUgaW4gQnVlbm9zIEFpcmVzLiAgVGhl IHByZXZpb3VzIHZlcnNpb24gaW5kaWNhdGVkIHRoYXQgd2hlbiBzaW11bGNhc3RpbmcgaXMgc2ln bmFsZWQsIGl0IGNvdWxkIGJlIGFzc3VtZWQgdGhhdCBweXJhbWlkLXNoYXBlZCBsYXllcmluZyBp cyBub3QgaW4gcGxhY2UuICBUaGVyZSBpcyBubyBjb25jZXB0dWFsIHJlc3RyaWN0aW9uIHRoYXQg d291bGQgZGlzYWxsb3cgdGhlIHNpbXVsY2FzdGluZyBvZiBweXJhbWlkLXNoYXBlZCBiaXRzdHJl YW1zLCBzbyB0aGF0IHNlbnRlbmNlIHdhcyBtaXNsZWFkaW5nLiAgVGhlcmVmb3JlLCBpdCBpcyBy ZW1vdmVkLg0KDQpXaXRoIHRoaXMgY2hhbmdlLCBhbmQgYmFzZWQgb24gdGhlIGlucHV0IHdlIHJl Y2VpdmVkIGluIEJ1ZW5vcyBBaXJlcywgd2UgdGhpbmsgdGhlIGRyYWZ0IGlzIHJlYWR5IGZvciBX R0xDLiAgQ2hhaXJzLCBwbGVhc2UgY29uc2lkZXIuDQoNClRoYW5rcywNClN0ZXBoYW4NCg0KDQoN Cg0KDQpPbiA1LzE3LzE2LCAwOToyOSwgImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCj4NCj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtaWV0Zi1hdnRleHQtYXZwZi1jY20tbGF5ZXJlZC0wMS50eHQNCj5oYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN0ZXBoYW4gV2VuZ2VyIGFuZCBwb3N0ZWQgdG8gdGhlDQo+ SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFmdC1pZXRmLWF2dGV4dC1hdnBmLWNjbS1s YXllcmVkDQo+UmV2aXNpb246CTAxDQo+VGl0bGU6CQlVc2luZyBDb2RlYyBDb250cm9sIE1lc3Nh Z2VzIGluIHRoZSBSVFAgQXVkaW8tVmlzdWFsIFByb2ZpbGUgd2l0aCBGZWVkYmFjayB3aXRoIExh eWVyZWQgQ29kZWNzDQo+RG9jdW1lbnQgZGF0ZToJMjAxNi0wNS0xNw0KPkdyb3VwOgkJYXZ0ZXh0 DQo+UGFnZXM6CQkxMQ0KPlVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hdnRleHQtYXZwZi1jY20tbGF5ZXJlZC0wMS50eHQNCj5T dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1hdnRleHQtYXZwZi1jY20tbGF5ZXJlZC8NCj5IdG1saXplZDogICAgICAgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LWF2cGYtY2NtLWxheWVyZWQtMDENCj5E aWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtYXZ0ZXh0LWF2cGYtY2NtLWxheWVyZWQtMDENCj4NCj5BYnN0cmFjdDoNCj4gICBUaGlzIGRv Y3VtZW50IGZpeGVzIGEgc2hvcnRjb21pbmcgaW4gdGhlIHNwZWNpZmljYXRpb24gbGFuZ3VhZ2Ug b2YNCj4gICB0aGUgQ29kZWMgQ29udHJvbCBNZXNzYWdlIEZ1bGwgSW50cmEgUmVxdWVzdCAoRklS KSBhcyBkZWZpbmVkIGluDQo+ICAgUkZDNTEwNCB3aGVuIHVzaW5nIHdpdGggbGF5ZXJlZCBjb2Rl Y3MuICBJbiBwYXJ0aWN1bGFyLCBhIERlY29kZXINCj4gICBSZWZyZXNoIFBvaW50IG5lZWRzIHRv IGJlIHNlbnQgYnkgYSBtZWRpYSBzZW5kZXIgd2hlbiBhIEZJUiBpcw0KPiAgIHJlY2VpdmVkIG9u IGFueSBsYXllciBvZiB0aGUgbGF5ZXJlZCBiaXRzdHJlYW0sIHJlZ2FyZGxlc3Mgb24gd2hldGhl cg0KPiAgIHRob3NlIGxheWVycyBhcmUgYmVpbmcgc2VudCBpbiBhIHNpbmdsZSBvciBpbiBtdWx0 aXBsZSBSVFAgZmxvd3MuDQo+ICAgVGhlIG90aGVyIHBheWxvYWQtc3BlY2lmaWMgZmVlZGJhY2sg bWVzc2FnZXMgZGVmaW5lZCBpbiBSRkMgNTEwNCBhbmQNCj4gICBSRkMgNDU4NSBhcyB1cGRhdGVk IGJ5IFJGQyA1NTA2IGhhdmUgYWxzbyBiZWVuIGFuYWx5emVkLCBhbmQgbm8NCj4gICBjb3JyZXNw b25kaW5nIHNob3J0Y29taW5ncyBoYXZlIGJlZW4gZm91bmQuDQo+DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUg b2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0K PlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo= From nobody Thu May 19 17:30:04 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1151812B005; Thu, 19 May 2016 17:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520003001.15464.41721.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 17:30:01 -0700 Archived-At: Cc: Rachel@huawei.com, avtext@ietf.org, avtext-chairs@ietf.org Subject: [avtext] avtext - New Meeting Session Request for IETF 96 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 00:30:02 -0000 A new meeting session request has just been submitted by Rachel Huang, a Chair of the avtext working group. --------------------------------------------------------- Working Group Name: Audio/Video Transport Extensions Area Name: Applications and Real-Time Area Session Requester: Rachel Huang Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: avtcore mmusic dispatch rmcat rtcweb perc payload netvc cellar Second Priority: tsvwg sipcore tram apparea artarea taps Special Requests: --------------------------------------------------------- From nobody Tue May 24 15:50:58 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC2D12D58F; Tue, 24 May 2016 15:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 oWSEhc3L5mql; Tue, 24 May 2016 15:50:52 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4DD7F12D17D; Tue, 24 May 2016 15:50:49 -0700 (PDT) Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4OMoaqb067185 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 May 2016 17:50:37 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Roni Even" , draft-ietf-avtext-splicing-notification.all@ietf.org Date: Tue, 24 May 2016 17:50:34 -0500 Message-ID: <61F3D149-1D09-47C9-93DC-BACFBD1DCAAC@nostrum.com> In-Reply-To: <00dd01d1af65$c72ae590$5580b0b0$@gmail.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> <053f01d1a7b9$f2588190$d70984b0$@gmail.com> <57399D62.30500@ericsson.com> <00dd01d1af65$c72ae590$5580b0b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: avtext@ietf.org Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 22:50:56 -0000 Hi, In going back over the changes in version 7, I just noticed the addition of normative references to RFCs 7667 and 7201. Those are both informational RFCs. That doesn't mean we can't have a normative reference to them, but it would require re-running the IETF last call. Before I do that, do people think that is the right thing to do? Are the normative references necessary? (If they were not normative, the security considerations wording around the citations would need to change.) Thanks! Ben. On 16 May 2016, at 6:26, Roni Even wrote: > Hi Magnus, > Sorry, I hope this is better > > "The security considerations of the RTP specification [RFC3550] and > the general mechanism for RTP header extensions [RFC5285] apply. The > splicer can be either a mixer or a translator, and all the security > considerations of these two RTP intermediaries topologies described in > [RFC7667] and [RFC7201] are applicable for the splicer." > > Roni > > >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Monday, May 16, 2016 1:14 PM >> To: Roni Even; 'Huangyihong (Rachel)'; avtext@ietf.org >> Subject: Re: [avtext] Fwd: New Version Notification for >> draft-ietf-avtext- >> splicing-notification-06.txt >> >> Hi, >> >> See one issue inline. Sorry for the delay in responding. >> >> Den 2016-05-06 kl. 19:08, skrev Roni Even: >>> Hi Magnus, I looked at your comments about the security section. >>> Since the slicer is a RTP mixer or a RTP translator as specified in >>> RFC 7667 I suggest adding informative reference to RFC7667 for the >>> security risks. There is text that requires the splicer to >>> authenticate the source of the splicing time message. I propose the >>> following text for the security section. >>> >>> >>> "The security considerations of the RTP specification [RFC3550] and >>> the general mechanism for RTP header extensions [RFC5285] apply. The >>> splicer can either be a mixer or a translator, and has all the >>> security considerations on these two standard RTP intermediaries as >>> such the security consideration from [RFC7667] and [RFC7201] SHOULD >>> be >>> considered for the splicer. >> >> The second sentence has very strange grammar. Please address. >> >> /Magnus >> >> >>> >>> The splicer replaces some content with other content in RTP packet, >>> thus breaking any RTP-level end-to-end security, such as source >>> authentication and integrity protection. End to end source >>> authentication is not possible with any known existing splicing >>> solution. A new solution can theoretically be developed that enables >>> identification of the participating entities and what each provides, >>> i.e., the different media sources, main and substituting, and the >>> splicer which provides the RTP-level integration of the media >>> payloads >>> in a common timeline and synchronization context. >>> >>> Since splicer works as a trusted entity, any RTP-level or outside >>> security mechanism, such IPsec [RFC4301] or Datagram Transport Layer >>> Security [RFC6347], will use a security association between the >>> splicer and the receiver. When using the Secure Real-Time Transport >>> Protocol (SRTP) [RFC3711], the splicer could be provisioned with the >>> same security association as the main RTP sender. >>> >>> If there is a concern about the confidentiality of the splicing time >>> information, header extension encryption [RFC6904] SHOULD be used. >>> However, a malicious endpoint may get the splicing time information >>> by >>> other means, e.g., inferring from the communication between the main >>> and substitutive content sources. To avoid the insertion of invalid >>> substitutive content, the splicer MUST have some mechanisms to >>> authenticate the substitutive stream source. >>> >>> For cases that the splicing time information is changed by a >>> malicious >>> endpoint, the splicing, for example, may fail since it will not be >>> available at the right time for the substitutive media to arrive. >>> >>> A malicious endpoint may also break an undetectable splicing. To >>> mitigate this effect, the splicer SHOULD NOT forward the splicing >>> time >>> information RTP header extension defined in Section 4.1 to the >>> receivers. And it MUST NOT forward this header extension when >>> considering an undetectable splicing." >>> >>> Thanks Roni >>> >>> >>> >>>> -----Original Message----- From: avtext >>>> [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund >>>> Sent: Saturday, April 09, 2016 12:16 AM To: Huangyihong (Rachel); >>>> avtext@ietf.org Subject: Re: [avtext] Fwd: New Version Notification >>>> for draft-ietf-avtext- splicing-notification-06.txt >>>> >>>> Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): >>>>> Hi, >>>>> >>>>> This new version addresses Magnus's comment of using an agnostic >>>>> format. That's the only change made in this version. >>>> >>>> Hi, >>>> >>>> So I have reviewed all the changes from the -04 to this -06 >>>> version. >>>> >>>> First, I think people should be aware that the latest change do >>>> change the data format of the splicing header extension. This was >>>> not >>>> my intention, but I also don't care about. Just that people should >>>> be >>>> aware of this. I understand this is to enable the 2-bytes format to >>>> align with the 32-byte boundaries when it is the sole header >>>> extension present. However, I would note that this is a unnecessary >>>> alignment most likely. This header extension, even when using >>>> 7-byte >>>> splicing out timestamps do fit within the 1-byte header extension. >>>> Thus, in most cases the sole reason for using the 2-byte header >>>> extension would be in cases where this header extension is included >>>> together with another header extension requiring the 2- byte header >>>> extension header. So from my perspective, the old 7-byte header >>>> extension could be used with both the 1 and 2-byte headers. >>>> >>>> My other comment is that the Security consideration section still >>>> has >>>> issues from my perspective: >>>> >>>> Since splicer works as a trusted entity, any RTP-level or outside >>>> security mechanism, such IPsec[RFC4301] or Datagram Transport Layer >>>> Security [RFC6347], will use a security association between the >>>> splicer and the receiver. When using the Secure Real-Time Transport >>>> Protocol (SRTP) [RFC3711], the splicer could be provisioned with >>>> the >>>> same security association as the main RTP sender. >>>> >>>> So the alternatives when SRTP is to protect the content from the >>>> Splicer to the Receiver, then the splicer either has its own >>>> security >>>> context on the splicer to receiver leg, or it has as indicated >>>> access >>>> to the security context from main RTP sender. >>>> >>>> Then the following paragraph seem to lack a requirement for >>>> authenticating the actual splicing notification, i.e. the whole RTP >>>> packet that it is included in. The text appear to discuss both the >>>> substitute RTP stream and if the notification is modified, but not >>>> an >>>> authentication requirement to avoid this. >>>> >>>> For cases that the splicing time information is changed by a >>>> malicious endpoint, the splicing may fail since it will not be >>>> available at the right time for the substitutive media to arrive >>>> >>>> That is not the only issue, it can also be used to hide content >>>> that >>>> the main RTP sender intended to recieve. I think here is the right >>>> place to insert the authentication need. >>>> >>>> , which may also break an undetectable splicing. To mitigate this >>>> effect, the splicer SHOULD NOT forward the splicing time >>>> information >>>> RTP header extension defined in Section 4.1 to the receivers. And >>>> it >>>> MUST NOT forward this header extension when considering an >>>> undetectable splicing. >>>> >>>> The undetectable part is a separate issue, please write it as >>>> separate sentences. >>>> >>>> >>>> Thanks for addressing the other issues. >>>> >>>> >>>> Cheers >>>> >>>> Magnus Westerlund >>>> >>>> --------------------------------------------------------------------- >>>> - >>>> >>>> >> Services, Media and Network features, Ericsson Research EAB/TXM >>>> --------------------------------------------------------------------- >>>> - >>>> >>>> >> Ericsson AB | Phone +46 10 7148287 >>>> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >>>> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>>> --------------------------------------------------------------------- >>>> - >>>> >>>> >>>> >> _______________________________________________ >>>> avtext mailing list avtext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/avtext >>> >>> >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue May 24 23:03:30 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE59F12B077; Tue, 24 May 2016 23:03:28 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HvnXGQ2dXM3u; Tue, 24 May 2016 23:03:26 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 A4D8A12D1E1; Tue, 24 May 2016 23:03:25 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id n129so162913269wmn.1; Tue, 24 May 2016 23:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=r1iNl/nj88v/jfEKKHMc1I/AgHd1Rl5GRC4aMpOPg7U=; b=esvqK6ESUf6OjZBzKZ4tig19KC+Att4uq2qxvccJeJ2bufa8DNRy31GwugcKTJPKF0 Vnt+33NoLF6TIVRqMh83uDFdyYxMs0ycORrawVgIa/pNRrma4yD1sXVjI8FiYTiVr8Fx /w08rbWU6NpZ+IE9Lsk2xgz6WKz6lR+TQKolDiNHxavbXJNGWsV6+MJt2FR0vQPkclFg uMH8NNKgU3mscJzvm5ryepD5bJiXjD/Pgo82QNx/0yiITIh7bKGgQw9vmDgO4tJdKdxn u0HKzVkQHIUc8k6BWuEzwxU1O3xG+hb6bmD6ipieMcjkOd6dhov5it/HtvvOgkUPHwIY rMCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=r1iNl/nj88v/jfEKKHMc1I/AgHd1Rl5GRC4aMpOPg7U=; b=XBSNaW9XC94DdQ6ktWvOAAQWySiJdv/MqbCRquqj0YRTMMwi7YvswU492QH1HYTCdS WoBB+k17woAX+O7OViEymX+C7wakzhq4XKcgVTodD2YZbzL/fNy44gqgZBQOeg6uLiFK bfARJHrS8+9e5P//1Qo61twBppLlwvVTFQmDxJqWy3elm9rfYotABGeSa1YEn3YIPhxF CqYrqJVYSB1m36YX6jOtXQsDMOTUckE/YgtQiS/fEKDJ6iE3vJ5EwvDIwuf3r3V5UOWs tviGZb2fp2w+spa3/WO+1aWzZP4HhushIsuvFgHgbP0riENGymp6/1Uw0NW8AZxvCbH6 s+jA== X-Gm-Message-State: ALyK8tJ9zTrVhuoaRiiqvuJJQH7VxBCdhfv/+wPAIT8jtPF7YLtqHnZTrHMecJqJFgkdmA== X-Received: by 10.194.171.7 with SMTP id aq7mr1670752wjc.8.1464156204072; Tue, 24 May 2016 23:03:24 -0700 (PDT) Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id wb10sm6779853wjc.8.2016.05.24.23.03.22 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2016 23:03:22 -0700 (PDT) From: "Roni Even" To: "'Ben Campbell'" , References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> <053f01d1a7b9$f2588190$d70984b0$@gmail.com> <57399D62.30500@ericsson.com> <00dd01d1af65$c72ae590$5580b0b0$@gmail.com> <61F3D149-1D09-47C9-93DC-BACFBD1DCAAC@nostrum.com> In-Reply-To: <61F3D149-1D09-47C9-93DC-BACFBD1DCAAC@nostrum.com> Date: Wed, 25 May 2016 09:02:28 +0300 Message-ID: <018301d1b64b$05366b70$0fa34250$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIOc8oubpM7/Zgx3JHTW+BFLZpufQJK5H4AAZ7DhfkB7BlyzwHOF8UwAovb5Sae/i+/8A== Content-Language: he Archived-At: Cc: avtext@ietf.org Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 06:03:29 -0000 Hi Ben, I think that they can be informative references with the current text = which does not have any normative language. The security considerations = of RFC7667 do not mandate any security solution, that section mostly = analyze the security issues with the different topologies Roni > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, May 25, 2016 1:51 AM > To: Roni Even; draft-ietf-avtext-splicing-notification.all@ietf.org > Cc: Magnus Westerlund; Huangyihong; avtext@ietf.org > Subject: Re: [avtext] New Version Notification for = draft-ietf-avtext-splicing- > notification-06.txt >=20 > Hi, >=20 > In going back over the changes in version 7, I just noticed the = addition of > normative references to RFCs 7667 and 7201. Those are both = informational > RFCs. That doesn't mean we can't have a normative reference to them, = but it > would require re-running the IETF last call. >=20 > Before I do that, do people think that is the right thing to do? Are = the > normative references necessary? (If they were not normative, the = security > considerations wording around the citations would need to > change.) >=20 > Thanks! >=20 > Ben. >=20 > On 16 May 2016, at 6:26, Roni Even wrote: >=20 > > Hi Magnus, > > Sorry, I hope this is better > > > > "The security considerations of the RTP specification [RFC3550] and > > the general mechanism for RTP header extensions [RFC5285] apply. The > > splicer can be either a mixer or a translator, and all the security > > considerations of these two RTP intermediaries topologies described = in > > [RFC7667] and [RFC7201] are applicable for the splicer." > > > > Roni > > > > > >> -----Original Message----- > >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >> Sent: Monday, May 16, 2016 1:14 PM > >> To: Roni Even; 'Huangyihong (Rachel)'; avtext@ietf.org > >> Subject: Re: [avtext] Fwd: New Version Notification for > >> draft-ietf-avtext- > >> splicing-notification-06.txt > >> > >> Hi, > >> > >> See one issue inline. Sorry for the delay in responding. > >> > >> Den 2016-05-06 kl. 19:08, skrev Roni Even: > >>> Hi Magnus, I looked at your comments about the security section. > >>> Since the slicer is a RTP mixer or a RTP translator as specified = in > >>> RFC 7667 I suggest adding informative reference to RFC7667 for the > >>> security risks. There is text that requires the splicer to > >>> authenticate the source of the splicing time message. I propose = the > >>> following text for the security section. > >>> > >>> > >>> "The security considerations of the RTP specification [RFC3550] = and > >>> the general mechanism for RTP header extensions [RFC5285] apply. = The > >>> splicer can either be a mixer or a translator, and has all the > >>> security considerations on these two standard RTP intermediaries = as > >>> such the security consideration from [RFC7667] and [RFC7201] = SHOULD > >>> be considered for the splicer. > >> > >> The second sentence has very strange grammar. Please address. > >> > >> /Magnus > >> > >> > >>> > >>> The splicer replaces some content with other content in RTP = packet, > >>> thus breaking any RTP-level end-to-end security, such as source > >>> authentication and integrity protection. End to end source > >>> authentication is not possible with any known existing splicing > >>> solution. A new solution can theoretically be developed that = enables > >>> identification of the participating entities and what each = provides, > >>> i.e., the different media sources, main and substituting, and the > >>> splicer which provides the RTP-level integration of the media > >>> payloads in a common timeline and synchronization context. > >>> > >>> Since splicer works as a trusted entity, any RTP-level or outside > >>> security mechanism, such IPsec [RFC4301] or Datagram Transport = Layer > >>> Security [RFC6347], will use a security association between the > >>> splicer and the receiver. When using the Secure Real-Time = Transport > >>> Protocol (SRTP) [RFC3711], the splicer could be provisioned with = the > >>> same security association as the main RTP sender. > >>> > >>> If there is a concern about the confidentiality of the splicing = time > >>> information, header extension encryption [RFC6904] SHOULD be used. > >>> However, a malicious endpoint may get the splicing time = information > >>> by other means, e.g., inferring from the communication between the > >>> main and substitutive content sources. To avoid the insertion of > >>> invalid substitutive content, the splicer MUST have some = mechanisms > >>> to authenticate the substitutive stream source. > >>> > >>> For cases that the splicing time information is changed by a > >>> malicious endpoint, the splicing, for example, may fail since it > >>> will not be available at the right time for the substitutive media > >>> to arrive. > >>> > >>> A malicious endpoint may also break an undetectable splicing. To > >>> mitigate this effect, the splicer SHOULD NOT forward the splicing > >>> time information RTP header extension defined in Section 4.1 to = the > >>> receivers. And it MUST NOT forward this header extension when > >>> considering an undetectable splicing." > >>> > >>> Thanks Roni > >>> > >>> > >>> > >>>> -----Original Message----- From: avtext > >>>> [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund > >>>> Sent: Saturday, April 09, 2016 12:16 AM To: Huangyihong (Rachel); > >>>> avtext@ietf.org Subject: Re: [avtext] Fwd: New Version = Notification > >>>> for draft-ietf-avtext- splicing-notification-06.txt > >>>> > >>>> Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): > >>>>> Hi, > >>>>> > >>>>> This new version addresses Magnus's comment of using an agnostic > >>>>> format. That's the only change made in this version. > >>>> > >>>> Hi, > >>>> > >>>> So I have reviewed all the changes from the -04 to this -06 > >>>> version. > >>>> > >>>> First, I think people should be aware that the latest change do > >>>> change the data format of the splicing header extension. This was > >>>> not my intention, but I also don't care about. Just that people > >>>> should be aware of this. I understand this is to enable the = 2-bytes > >>>> format to align with the 32-byte boundaries when it is the sole > >>>> header extension present. However, I would note that this is a > >>>> unnecessary alignment most likely. This header extension, even = when > >>>> using 7-byte splicing out timestamps do fit within the 1-byte > >>>> header extension. > >>>> Thus, in most cases the sole reason for using the 2-byte header > >>>> extension would be in cases where this header extension is = included > >>>> together with another header extension requiring the 2- byte = header > >>>> extension header. So from my perspective, the old 7-byte header > >>>> extension could be used with both the 1 and 2-byte headers. > >>>> > >>>> My other comment is that the Security consideration section still > >>>> has issues from my perspective: > >>>> > >>>> Since splicer works as a trusted entity, any RTP-level or outside > >>>> security mechanism, such IPsec[RFC4301] or Datagram Transport = Layer > >>>> Security [RFC6347], will use a security association between the > >>>> splicer and the receiver. When using the Secure Real-Time = Transport > >>>> Protocol (SRTP) [RFC3711], the splicer could be provisioned with > >>>> the same security association as the main RTP sender. > >>>> > >>>> So the alternatives when SRTP is to protect the content from the > >>>> Splicer to the Receiver, then the splicer either has its own > >>>> security context on the splicer to receiver leg, or it has as > >>>> indicated access to the security context from main RTP sender. > >>>> > >>>> Then the following paragraph seem to lack a requirement for > >>>> authenticating the actual splicing notification, i.e. the whole = RTP > >>>> packet that it is included in. The text appear to discuss both = the > >>>> substitute RTP stream and if the notification is modified, but = not > >>>> an authentication requirement to avoid this. > >>>> > >>>> For cases that the splicing time information is changed by a > >>>> malicious endpoint, the splicing may fail since it will not be > >>>> available at the right time for the substitutive media to arrive > >>>> > >>>> That is not the only issue, it can also be used to hide content > >>>> that the main RTP sender intended to recieve. I think here is the > >>>> right place to insert the authentication need. > >>>> > >>>> , which may also break an undetectable splicing. To mitigate this > >>>> effect, the splicer SHOULD NOT forward the splicing time > >>>> information RTP header extension defined in Section 4.1 to the > >>>> receivers. And it MUST NOT forward this header extension when > >>>> considering an undetectable splicing. > >>>> > >>>> The undetectable part is a separate issue, please write it as > >>>> separate sentences. > >>>> > >>>> > >>>> Thanks for addressing the other issues. > >>>> > >>>> > >>>> 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 > >>>> = ------------------------------------------------------------------- > >>>> -- > >>>> - > >>>> > >>>> > >>>> > >> _______________________________________________ > >>>> avtext mailing list avtext@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/avtext > >>> > >>> > >> > >> > >> -- > >> > >> 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 > >> = --------------------------------------------------------------------- > >> - > > > > _______________________________________________ > > avtext mailing list > > avtext@ietf.org > > https://www.ietf.org/mailman/listinfo/avtext From nobody Tue May 24 23:18:32 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935E212D62A; Tue, 24 May 2016 23:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 bJTpfFaEZkV8; Tue, 24 May 2016 23:18:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 87ACC12D1E1; Tue, 24 May 2016 23:18:26 -0700 (PDT) Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4P6ID33004449 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2016 01:18:14 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Roni Even" Date: Wed, 25 May 2016 01:18:12 -0500 Message-ID: In-Reply-To: <018301d1b64b$05366b70$0fa34250$@gmail.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> <053f01d1a7b9$f2588190$d70984b0$@gmail.com> <57399D62.30500@ericsson.com> <00dd01d1af65$c72ae590$5580b0b0$@gmail.com> <61F3D149-1D09-47C9-93DC-BACFBD1DCAAC@nostrum.com> <018301d1b64b$05366b70$0fa34250$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: avtext@ietf.org, draft-ietf-avtext-splicing-notification.all@ietf.org Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 06:18:28 -0000 Hi Roni, It's not just a matter of normative language. Can the security considerations of this document be understood without reading the references? Thanks, Ben. On 25 May 2016, at 1:02, Roni Even wrote: > Hi Ben, > I think that they can be informative references with the current text > which does not have any normative language. The security > considerations of RFC7667 do not mandate any security solution, that > section mostly analyze the security issues with the different > topologies > Roni > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, May 25, 2016 1:51 AM >> To: Roni Even; draft-ietf-avtext-splicing-notification.all@ietf.org >> Cc: Magnus Westerlund; Huangyihong; avtext@ietf.org >> Subject: Re: [avtext] New Version Notification for >> draft-ietf-avtext-splicing- >> notification-06.txt >> >> Hi, >> >> In going back over the changes in version 7, I just noticed the >> addition of >> normative references to RFCs 7667 and 7201. Those are both >> informational >> RFCs. That doesn't mean we can't have a normative reference to them, >> but it >> would require re-running the IETF last call. >> >> Before I do that, do people think that is the right thing to do? Are >> the >> normative references necessary? (If they were not normative, the >> security >> considerations wording around the citations would need to >> change.) >> >> Thanks! >> >> Ben. >> >> On 16 May 2016, at 6:26, Roni Even wrote: >> >>> Hi Magnus, >>> Sorry, I hope this is better >>> >>> "The security considerations of the RTP specification [RFC3550] and >>> the general mechanism for RTP header extensions [RFC5285] apply. The >>> splicer can be either a mixer or a translator, and all the security >>> considerations of these two RTP intermediaries topologies described >>> in >>> [RFC7667] and [RFC7201] are applicable for the splicer." >>> >>> Roni >>> >>> >>>> -----Original Message----- >>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>>> Sent: Monday, May 16, 2016 1:14 PM >>>> To: Roni Even; 'Huangyihong (Rachel)'; avtext@ietf.org >>>> Subject: Re: [avtext] Fwd: New Version Notification for >>>> draft-ietf-avtext- >>>> splicing-notification-06.txt >>>> >>>> Hi, >>>> >>>> See one issue inline. Sorry for the delay in responding. >>>> >>>> Den 2016-05-06 kl. 19:08, skrev Roni Even: >>>>> Hi Magnus, I looked at your comments about the security section. >>>>> Since the slicer is a RTP mixer or a RTP translator as specified >>>>> in >>>>> RFC 7667 I suggest adding informative reference to RFC7667 for the >>>>> security risks. There is text that requires the splicer to >>>>> authenticate the source of the splicing time message. I propose >>>>> the >>>>> following text for the security section. >>>>> >>>>> >>>>> "The security considerations of the RTP specification [RFC3550] >>>>> and >>>>> the general mechanism for RTP header extensions [RFC5285] apply. >>>>> The >>>>> splicer can either be a mixer or a translator, and has all the >>>>> security considerations on these two standard RTP intermediaries >>>>> as >>>>> such the security consideration from [RFC7667] and [RFC7201] >>>>> SHOULD >>>>> be considered for the splicer. >>>> >>>> The second sentence has very strange grammar. Please address. >>>> >>>> /Magnus >>>> >>>> >>>>> >>>>> The splicer replaces some content with other content in RTP >>>>> packet, >>>>> thus breaking any RTP-level end-to-end security, such as source >>>>> authentication and integrity protection. End to end source >>>>> authentication is not possible with any known existing splicing >>>>> solution. A new solution can theoretically be developed that >>>>> enables >>>>> identification of the participating entities and what each >>>>> provides, >>>>> i.e., the different media sources, main and substituting, and the >>>>> splicer which provides the RTP-level integration of the media >>>>> payloads in a common timeline and synchronization context. >>>>> >>>>> Since splicer works as a trusted entity, any RTP-level or outside >>>>> security mechanism, such IPsec [RFC4301] or Datagram Transport >>>>> Layer >>>>> Security [RFC6347], will use a security association between the >>>>> splicer and the receiver. When using the Secure Real-Time >>>>> Transport >>>>> Protocol (SRTP) [RFC3711], the splicer could be provisioned with >>>>> the >>>>> same security association as the main RTP sender. >>>>> >>>>> If there is a concern about the confidentiality of the splicing >>>>> time >>>>> information, header extension encryption [RFC6904] SHOULD be used. >>>>> However, a malicious endpoint may get the splicing time >>>>> information >>>>> by other means, e.g., inferring from the communication between the >>>>> main and substitutive content sources. To avoid the insertion of >>>>> invalid substitutive content, the splicer MUST have some >>>>> mechanisms >>>>> to authenticate the substitutive stream source. >>>>> >>>>> For cases that the splicing time information is changed by a >>>>> malicious endpoint, the splicing, for example, may fail since it >>>>> will not be available at the right time for the substitutive media >>>>> to arrive. >>>>> >>>>> A malicious endpoint may also break an undetectable splicing. To >>>>> mitigate this effect, the splicer SHOULD NOT forward the splicing >>>>> time information RTP header extension defined in Section 4.1 to >>>>> the >>>>> receivers. And it MUST NOT forward this header extension when >>>>> considering an undetectable splicing." >>>>> >>>>> Thanks Roni >>>>> >>>>> >>>>> >>>>>> -----Original Message----- From: avtext >>>>>> [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund >>>>>> Sent: Saturday, April 09, 2016 12:16 AM To: Huangyihong (Rachel); >>>>>> avtext@ietf.org Subject: Re: [avtext] Fwd: New Version >>>>>> Notification >>>>>> for draft-ietf-avtext- splicing-notification-06.txt >>>>>> >>>>>> Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): >>>>>>> Hi, >>>>>>> >>>>>>> This new version addresses Magnus's comment of using an agnostic >>>>>>> format. That's the only change made in this version. >>>>>> >>>>>> Hi, >>>>>> >>>>>> So I have reviewed all the changes from the -04 to this -06 >>>>>> version. >>>>>> >>>>>> First, I think people should be aware that the latest change do >>>>>> change the data format of the splicing header extension. This was >>>>>> not my intention, but I also don't care about. Just that people >>>>>> should be aware of this. I understand this is to enable the >>>>>> 2-bytes >>>>>> format to align with the 32-byte boundaries when it is the sole >>>>>> header extension present. However, I would note that this is a >>>>>> unnecessary alignment most likely. This header extension, even >>>>>> when >>>>>> using 7-byte splicing out timestamps do fit within the 1-byte >>>>>> header extension. >>>>>> Thus, in most cases the sole reason for using the 2-byte header >>>>>> extension would be in cases where this header extension is >>>>>> included >>>>>> together with another header extension requiring the 2- byte >>>>>> header >>>>>> extension header. So from my perspective, the old 7-byte header >>>>>> extension could be used with both the 1 and 2-byte headers. >>>>>> >>>>>> My other comment is that the Security consideration section still >>>>>> has issues from my perspective: >>>>>> >>>>>> Since splicer works as a trusted entity, any RTP-level or outside >>>>>> security mechanism, such IPsec[RFC4301] or Datagram Transport >>>>>> Layer >>>>>> Security [RFC6347], will use a security association between the >>>>>> splicer and the receiver. When using the Secure Real-Time >>>>>> Transport >>>>>> Protocol (SRTP) [RFC3711], the splicer could be provisioned with >>>>>> the same security association as the main RTP sender. >>>>>> >>>>>> So the alternatives when SRTP is to protect the content from the >>>>>> Splicer to the Receiver, then the splicer either has its own >>>>>> security context on the splicer to receiver leg, or it has as >>>>>> indicated access to the security context from main RTP sender. >>>>>> >>>>>> Then the following paragraph seem to lack a requirement for >>>>>> authenticating the actual splicing notification, i.e. the whole >>>>>> RTP >>>>>> packet that it is included in. The text appear to discuss both >>>>>> the >>>>>> substitute RTP stream and if the notification is modified, but >>>>>> not >>>>>> an authentication requirement to avoid this. >>>>>> >>>>>> For cases that the splicing time information is changed by a >>>>>> malicious endpoint, the splicing may fail since it will not be >>>>>> available at the right time for the substitutive media to arrive >>>>>> >>>>>> That is not the only issue, it can also be used to hide content >>>>>> that the main RTP sender intended to recieve. I think here is the >>>>>> right place to insert the authentication need. >>>>>> >>>>>> , which may also break an undetectable splicing. To mitigate this >>>>>> effect, the splicer SHOULD NOT forward the splicing time >>>>>> information RTP header extension defined in Section 4.1 to the >>>>>> receivers. And it MUST NOT forward this header extension when >>>>>> considering an undetectable splicing. >>>>>> >>>>>> The undetectable part is a separate issue, please write it as >>>>>> separate sentences. >>>>>> >>>>>> >>>>>> Thanks for addressing the other issues. >>>>>> >>>>>> >>>>>> Cheers >>>>>> >>>>>> Magnus Westerlund >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> -- >>>>>> - >>>>>> >>>>>> >>>> Services, Media and Network features, Ericsson Research EAB/TXM >>>>>> ------------------------------------------------------------------- >>>>>> -- >>>>>> - >>>>>> >>>>>> >>>> Ericsson AB | Phone +46 10 7148287 >>>>>> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >>>>>> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>>>>> ------------------------------------------------------------------- >>>>>> -- >>>>>> - >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>>>> avtext mailing list avtext@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/avtext >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Magnus Westerlund >>>> >>>> --------------------------------------------------------------------- >>>> - Services, Media and Network features, Ericsson Research EAB/TXM >>>> ---------------------------------------------------------------------- >>>> Ericsson AB | Phone +46 10 7148287 >>>> Färögatan 6 | Mobile +46 73 0949079 >>>> SE-164 80 Stockholm, Sweden | mailto: >> magnus.westerlund@ericsson.com >>>> --------------------------------------------------------------------- >>>> - >>> >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext From nobody Wed May 25 06:21:30 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D79C12DCF7; Wed, 25 May 2016 06:21:28 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pWkPvO3hOeQ1; Wed, 25 May 2016 06:21:16 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 76DF212DBCE; Wed, 25 May 2016 06:16:44 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id n129so181542051wmn.1; Wed, 25 May 2016 06:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=JhAq3oCuBguTDhrYsTMwcNR6o5CI2XW3LdiazwtfsHQ=; b=EN9ZQWHmz3vDlhaM3ZDxxr0abrHg0KkOTfI4oJBSgNovXXSaMlq5w7DM4vH4yMkSkH I+Xe2053qyPkWKokLYVsQAgAdZwvmYhQltyiopYKWPfyeyT1/qoXjB6BEO2PwSphcaAl jfi4sxMOj+jVnfLR4HVrtC1+6j6vuFVVr8Frk958Y3GkQ76w5zxobSseW0THkxmubSXS gQZ6A+/KbIk3F/PKJkqjgFOMzVBVcHpaFl4wHZW1nzyTSSY2L7/F+eWDh0oOGLNwI6Dj S4o34uOIH/dQzk5aUYC/Vin913y5vimVWF7O0Xu23c1jOLnP33kIO2u3DQs6RGZni6cL Omog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=JhAq3oCuBguTDhrYsTMwcNR6o5CI2XW3LdiazwtfsHQ=; b=eFeX5yWL8mcGvSb8PwQamFNka/l1K9DInYWhGgvIWoYX3r2roH0VNr3yvxQckdbGBk XSywPfEjvAXy1XLkHyFHFtACvGWG2Seq7xB/2YRRrkqjSzCzUsUQAKaMrMEBex31xiqp nWnZS2gawXUv532Gfw0wdM/0Uj1ZFlo8Z3VIiV4FR5nKEjFsw6+/KKzQl3oFalpzjMhq K87T3ytjmOpao4vDiXG3wMkV+H5R/hLJG4RNCyQ4Aa42e1TV82Itt8G9N7hcHIyKIq4j /1SWY+B1hUjvMI43COq8O1KXSsEBX7nqkEgfYbps3fzJ1Shfk1erMTew3wRqzqlHp5HH 0VRg== X-Gm-Message-State: ALyK8tL80j/BFm+RzSO7HG3Uehw0LWYGEeqpLiLGQ6MI1/hd7gvT3C3AoGNNJ9qO+Gig/Q== X-Received: by 10.194.77.140 with SMTP id s12mr3947902wjw.24.1464182202918; Wed, 25 May 2016 06:16:42 -0700 (PDT) Received: from RoniPC (bzq-79-178-104-140.red.bezeqint.net. [79.178.104.140]) by smtp.gmail.com with ESMTPSA id t3sm24707511wmf.20.2016.05.25.06.16.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2016 06:16:41 -0700 (PDT) From: "Roni Even" To: "'Ben Campbell'" References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> <053f01d1a7b9$f2588190$d70984b0$@gmail.com> <57399D62.30500@ericsson.com> <00dd01d1af65$c72ae590$5580b0b0$@gmail.com> <61F3D149-1D09-47C9-93DC-BACFBD1DCAAC@nostrum.com> <018301d1b64b$05366b70$0fa34250$@gmail.com> In-Reply-To: Date: Wed, 25 May 2016 16:15:46 +0300 Message-ID: <01cb01d1b687$8d414440$a7c3ccc0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIOc8oubpM7/Zgx3JHTW+BFLZpufQJK5H4AAZ7DhfkB7BlyzwHOF8UwAovb5SYB7eQH8QGup9RfnuHFRgA= Content-Language: he Archived-At: Cc: avtext@ietf.org, draft-ietf-avtext-splicing-notification.all@ietf.org Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 13:21:29 -0000 Hi Ben, It should be normative. BTW draft-ietf-rtcweb-rtp-usage-26 also has = normative reference to RFC7667 (topologies-update) Roni > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, May 25, 2016 9:18 AM > To: Roni Even > Cc: draft-ietf-avtext-splicing-notification.all@ietf.org; Magnus = Westerlund; > Huangyihong; avtext@ietf.org > Subject: Re: [avtext] New Version Notification for = draft-ietf-avtext-splicing- > notification-06.txt >=20 > Hi Roni, >=20 > It's not just a matter of normative language. Can the security = considerations > of this document be understood without reading the references? >=20 > Thanks, >=20 > Ben. >=20 > On 25 May 2016, at 1:02, Roni Even wrote: >=20 > > Hi Ben, > > I think that they can be informative references with the current = text > > which does not have any normative language. The security > > considerations of RFC7667 do not mandate any security solution, that > > section mostly analyze the security issues with the different > > topologies Roni > > > >> -----Original Message----- > >> From: Ben Campbell [mailto:ben@nostrum.com] > >> Sent: Wednesday, May 25, 2016 1:51 AM > >> To: Roni Even; draft-ietf-avtext-splicing-notification.all@ietf.org > >> Cc: Magnus Westerlund; Huangyihong; avtext@ietf.org > >> Subject: Re: [avtext] New Version Notification for > >> draft-ietf-avtext-splicing- > >> notification-06.txt > >> > >> Hi, > >> > >> In going back over the changes in version 7, I just noticed the > >> addition of normative references to RFCs 7667 and 7201. Those are > >> both informational RFCs. That doesn't mean we can't have a = normative > >> reference to them, but it would require re-running the IETF last > >> call. > >> > >> Before I do that, do people think that is the right thing to do? = Are > >> the normative references necessary? (If they were not normative, = the > >> security considerations wording around the citations would need to > >> change.) > >> > >> Thanks! > >> > >> Ben. > >> > >> On 16 May 2016, at 6:26, Roni Even wrote: > >> > >>> Hi Magnus, > >>> Sorry, I hope this is better > >>> > >>> "The security considerations of the RTP specification [RFC3550] = and > >>> the general mechanism for RTP header extensions [RFC5285] apply. = The > >>> splicer can be either a mixer or a translator, and all the = security > >>> considerations of these two RTP intermediaries topologies = described > >>> in [RFC7667] and [RFC7201] are applicable for the splicer." > >>> > >>> Roni > >>> > >>> > >>>> -----Original Message----- > >>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >>>> Sent: Monday, May 16, 2016 1:14 PM > >>>> To: Roni Even; 'Huangyihong (Rachel)'; avtext@ietf.org > >>>> Subject: Re: [avtext] Fwd: New Version Notification for > >>>> draft-ietf-avtext- > >>>> splicing-notification-06.txt > >>>> > >>>> Hi, > >>>> > >>>> See one issue inline. Sorry for the delay in responding. > >>>> > >>>> Den 2016-05-06 kl. 19:08, skrev Roni Even: > >>>>> Hi Magnus, I looked at your comments about the security section. > >>>>> Since the slicer is a RTP mixer or a RTP translator as specified > >>>>> in RFC 7667 I suggest adding informative reference to RFC7667 = for > >>>>> the security risks. There is text that requires the splicer to > >>>>> authenticate the source of the splicing time message. I propose > >>>>> the following text for the security section. > >>>>> > >>>>> > >>>>> "The security considerations of the RTP specification [RFC3550] > >>>>> and the general mechanism for RTP header extensions [RFC5285] > >>>>> apply. > >>>>> The > >>>>> splicer can either be a mixer or a translator, and has all the > >>>>> security considerations on these two standard RTP intermediaries > >>>>> as such the security consideration from [RFC7667] and [RFC7201] > >>>>> SHOULD be considered for the splicer. > >>>> > >>>> The second sentence has very strange grammar. Please address. > >>>> > >>>> /Magnus > >>>> > >>>> > >>>>> > >>>>> The splicer replaces some content with other content in RTP > >>>>> packet, thus breaking any RTP-level end-to-end security, such as > >>>>> source authentication and integrity protection. End to end = source > >>>>> authentication is not possible with any known existing splicing > >>>>> solution. A new solution can theoretically be developed that > >>>>> enables identification of the participating entities and what = each > >>>>> provides, i.e., the different media sources, main and > >>>>> substituting, and the splicer which provides the RTP-level > >>>>> integration of the media payloads in a common timeline and > >>>>> synchronization context. > >>>>> > >>>>> Since splicer works as a trusted entity, any RTP-level or = outside > >>>>> security mechanism, such IPsec [RFC4301] or Datagram Transport > >>>>> Layer Security [RFC6347], will use a security association = between > >>>>> the splicer and the receiver. When using the Secure Real-Time > >>>>> Transport Protocol (SRTP) [RFC3711], the splicer could be > >>>>> provisioned with the same security association as the main RTP > >>>>> sender. > >>>>> > >>>>> If there is a concern about the confidentiality of the splicing > >>>>> time information, header extension encryption [RFC6904] SHOULD = be > >>>>> used. > >>>>> However, a malicious endpoint may get the splicing time > >>>>> information by other means, e.g., inferring from the = communication > >>>>> between the main and substitutive content sources. To avoid the > >>>>> insertion of invalid substitutive content, the splicer MUST have > >>>>> some mechanisms to authenticate the substitutive stream source. > >>>>> > >>>>> For cases that the splicing time information is changed by a > >>>>> malicious endpoint, the splicing, for example, may fail since it > >>>>> will not be available at the right time for the substitutive = media > >>>>> to arrive. > >>>>> > >>>>> A malicious endpoint may also break an undetectable splicing. To > >>>>> mitigate this effect, the splicer SHOULD NOT forward the = splicing > >>>>> time information RTP header extension defined in Section 4.1 to > >>>>> the receivers. And it MUST NOT forward this header extension = when > >>>>> considering an undetectable splicing." > >>>>> > >>>>> Thanks Roni > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- From: avtext > >>>>>> [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund > >>>>>> Sent: Saturday, April 09, 2016 12:16 AM To: Huangyihong = (Rachel); > >>>>>> avtext@ietf.org Subject: Re: [avtext] Fwd: New Version > >>>>>> Notification for draft-ietf-avtext- = splicing-notification-06.txt > >>>>>> > >>>>>> Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): > >>>>>>> Hi, > >>>>>>> > >>>>>>> This new version addresses Magnus's comment of using an = agnostic > >>>>>>> format. That's the only change made in this version. > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> So I have reviewed all the changes from the -04 to this -06 > >>>>>> version. > >>>>>> > >>>>>> First, I think people should be aware that the latest change do > >>>>>> change the data format of the splicing header extension. This = was > >>>>>> not my intention, but I also don't care about. Just that people > >>>>>> should be aware of this. I understand this is to enable the > >>>>>> 2-bytes format to align with the 32-byte boundaries when it is > >>>>>> the sole header extension present. However, I would note that > >>>>>> this is a unnecessary alignment most likely. This header > >>>>>> extension, even when using 7-byte splicing out timestamps do = fit > >>>>>> within the 1-byte header extension. > >>>>>> Thus, in most cases the sole reason for using the 2-byte header > >>>>>> extension would be in cases where this header extension is > >>>>>> included together with another header extension requiring the = 2- > >>>>>> byte header extension header. So from my perspective, the old > >>>>>> 7-byte header extension could be used with both the 1 and = 2-byte > >>>>>> headers. > >>>>>> > >>>>>> My other comment is that the Security consideration section = still > >>>>>> has issues from my perspective: > >>>>>> > >>>>>> Since splicer works as a trusted entity, any RTP-level or = outside > >>>>>> security mechanism, such IPsec[RFC4301] or Datagram Transport > >>>>>> Layer Security [RFC6347], will use a security association = between > >>>>>> the splicer and the receiver. When using the Secure Real-Time > >>>>>> Transport Protocol (SRTP) [RFC3711], the splicer could be > >>>>>> provisioned with the same security association as the main RTP > >>>>>> sender. > >>>>>> > >>>>>> So the alternatives when SRTP is to protect the content from = the > >>>>>> Splicer to the Receiver, then the splicer either has its own > >>>>>> security context on the splicer to receiver leg, or it has as > >>>>>> indicated access to the security context from main RTP sender. > >>>>>> > >>>>>> Then the following paragraph seem to lack a requirement for > >>>>>> authenticating the actual splicing notification, i.e. the whole > >>>>>> RTP packet that it is included in. The text appear to discuss > >>>>>> both the substitute RTP stream and if the notification is > >>>>>> modified, but not an authentication requirement to avoid this. > >>>>>> > >>>>>> For cases that the splicing time information is changed by a > >>>>>> malicious endpoint, the splicing may fail since it will not be > >>>>>> available at the right time for the substitutive media to = arrive > >>>>>> > >>>>>> That is not the only issue, it can also be used to hide content > >>>>>> that the main RTP sender intended to recieve. I think here is = the > >>>>>> right place to insert the authentication need. > >>>>>> > >>>>>> , which may also break an undetectable splicing. To mitigate = this > >>>>>> effect, the splicer SHOULD NOT forward the splicing time > >>>>>> information RTP header extension defined in Section 4.1 to the > >>>>>> receivers. And it MUST NOT forward this header extension when > >>>>>> considering an undetectable splicing. > >>>>>> > >>>>>> The undetectable part is a separate issue, please write it as > >>>>>> separate sentences. > >>>>>> > >>>>>> > >>>>>> Thanks for addressing the other issues. > >>>>>> > >>>>>> > >>>>>> 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 > >>>>>> = ----------------------------------------------------------------- > >>>>>> -- > >>>>>> -- > >>>>>> - > >>>>>> > >>>>>> > >>>>>> > >>>> _______________________________________________ > >>>>>> avtext mailing list avtext@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/avtext > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> 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 > >>>> = ------------------------------------------------------------------- > >>>> -- > >>>> - > >>> > >>> _______________________________________________ > >>> avtext mailing list > >>> avtext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/avtext From nobody Wed May 25 08:40:26 2016 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2231E12D0F4; Wed, 25 May 2016 08:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 rBzfuSpLofp0; Wed, 25 May 2016 08:40:21 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 49D8812D61A; Wed, 25 May 2016 08:40:19 -0700 (PDT) Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4PFe6qu011157 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2016 10:40:06 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Roni Even" Date: Wed, 25 May 2016 10:40:05 -0500 Message-ID: <2EC7228B-2CDF-4989-9E1E-49FF54A1810F@nostrum.com> In-Reply-To: <01cb01d1b687$8d414440$a7c3ccc0$@gmail.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB86E9EAB9@nkgeml513-mbx.china.huawei.com> <57081F97.2030009@ericsson.com> <053f01d1a7b9$f2588190$d70984b0$@gmail.com> <57399D62.30500@ericsson.com> <00dd01d1af65$c72ae590$5580b0b0$@gmail.com> <61F3D149-1D09-47C9-93DC-BACFBD1DCAAC@nostrum.com> <018301d1b64b$05366b70$0fa34250$@gmail.com> <01cb01d1b687$8d414440$a7c3ccc0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: avtext@ietf.org, draft-ietf-avtext-splicing-notification.all@ietf.org Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-notification-06.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:40:24 -0000 On 25 May 2016, at 8:15, Roni Even wrote: > Hi Ben, > It should be normative. > BTW draft-ietf-rtcweb-rtp-usage-26 also has normative reference to > RFC7667 (topologies-update) I think you are right, unless we want to recreate a good bit of the referenced language in this draft. I'm going to start another IETF LC on this draft. I think we can get by with a shortened last call (1 week.) Then, if there are no objections, I will add one or both of them to the approved downref registry so we can remove some of the red tape for future drafts that need to reference these. Thanks! Ben. > Roni > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Wednesday, May 25, 2016 9:18 AM >> To: Roni Even >> Cc: draft-ietf-avtext-splicing-notification.all@ietf.org; Magnus >> Westerlund; >> Huangyihong; avtext@ietf.org >> Subject: Re: [avtext] New Version Notification for >> draft-ietf-avtext-splicing- >> notification-06.txt >> >> Hi Roni, >> >> It's not just a matter of normative language. Can the security >> considerations >> of this document be understood without reading the references? >> >> Thanks, >> >> Ben. >> >> On 25 May 2016, at 1:02, Roni Even wrote: >> >>> Hi Ben, >>> I think that they can be informative references with the current >>> text >>> which does not have any normative language. The security >>> considerations of RFC7667 do not mandate any security solution, that >>> section mostly analyze the security issues with the different >>> topologies Roni >>> >>>> -----Original Message----- >>>> From: Ben Campbell [mailto:ben@nostrum.com] >>>> Sent: Wednesday, May 25, 2016 1:51 AM >>>> To: Roni Even; draft-ietf-avtext-splicing-notification.all@ietf.org >>>> Cc: Magnus Westerlund; Huangyihong; avtext@ietf.org >>>> Subject: Re: [avtext] New Version Notification for >>>> draft-ietf-avtext-splicing- >>>> notification-06.txt >>>> >>>> Hi, >>>> >>>> In going back over the changes in version 7, I just noticed the >>>> addition of normative references to RFCs 7667 and 7201. Those are >>>> both informational RFCs. That doesn't mean we can't have a >>>> normative >>>> reference to them, but it would require re-running the IETF last >>>> call. >>>> >>>> Before I do that, do people think that is the right thing to do? >>>> Are >>>> the normative references necessary? (If they were not normative, >>>> the >>>> security considerations wording around the citations would need to >>>> change.) >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> On 16 May 2016, at 6:26, Roni Even wrote: >>>> >>>>> Hi Magnus, >>>>> Sorry, I hope this is better >>>>> >>>>> "The security considerations of the RTP specification [RFC3550] >>>>> and >>>>> the general mechanism for RTP header extensions [RFC5285] apply. >>>>> The >>>>> splicer can be either a mixer or a translator, and all the >>>>> security >>>>> considerations of these two RTP intermediaries topologies >>>>> described >>>>> in [RFC7667] and [RFC7201] are applicable for the splicer." >>>>> >>>>> Roni >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>>>>> Sent: Monday, May 16, 2016 1:14 PM >>>>>> To: Roni Even; 'Huangyihong (Rachel)'; avtext@ietf.org >>>>>> Subject: Re: [avtext] Fwd: New Version Notification for >>>>>> draft-ietf-avtext- >>>>>> splicing-notification-06.txt >>>>>> >>>>>> Hi, >>>>>> >>>>>> See one issue inline. Sorry for the delay in responding. >>>>>> >>>>>> Den 2016-05-06 kl. 19:08, skrev Roni Even: >>>>>>> Hi Magnus, I looked at your comments about the security section. >>>>>>> Since the slicer is a RTP mixer or a RTP translator as specified >>>>>>> in RFC 7667 I suggest adding informative reference to RFC7667 >>>>>>> for >>>>>>> the security risks. There is text that requires the splicer to >>>>>>> authenticate the source of the splicing time message. I propose >>>>>>> the following text for the security section. >>>>>>> >>>>>>> >>>>>>> "The security considerations of the RTP specification [RFC3550] >>>>>>> and the general mechanism for RTP header extensions [RFC5285] >>>>>>> apply. >>>>>>> The >>>>>>> splicer can either be a mixer or a translator, and has all the >>>>>>> security considerations on these two standard RTP intermediaries >>>>>>> as such the security consideration from [RFC7667] and [RFC7201] >>>>>>> SHOULD be considered for the splicer. >>>>>> >>>>>> The second sentence has very strange grammar. Please address. >>>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>>> >>>>>>> The splicer replaces some content with other content in RTP >>>>>>> packet, thus breaking any RTP-level end-to-end security, such as >>>>>>> source authentication and integrity protection. End to end >>>>>>> source >>>>>>> authentication is not possible with any known existing splicing >>>>>>> solution. A new solution can theoretically be developed that >>>>>>> enables identification of the participating entities and what >>>>>>> each >>>>>>> provides, i.e., the different media sources, main and >>>>>>> substituting, and the splicer which provides the RTP-level >>>>>>> integration of the media payloads in a common timeline and >>>>>>> synchronization context. >>>>>>> >>>>>>> Since splicer works as a trusted entity, any RTP-level or >>>>>>> outside >>>>>>> security mechanism, such IPsec [RFC4301] or Datagram Transport >>>>>>> Layer Security [RFC6347], will use a security association >>>>>>> between >>>>>>> the splicer and the receiver. When using the Secure Real-Time >>>>>>> Transport Protocol (SRTP) [RFC3711], the splicer could be >>>>>>> provisioned with the same security association as the main RTP >>>>>>> sender. >>>>>>> >>>>>>> If there is a concern about the confidentiality of the splicing >>>>>>> time information, header extension encryption [RFC6904] SHOULD >>>>>>> be >>>>>>> used. >>>>>>> However, a malicious endpoint may get the splicing time >>>>>>> information by other means, e.g., inferring from the >>>>>>> communication >>>>>>> between the main and substitutive content sources. To avoid the >>>>>>> insertion of invalid substitutive content, the splicer MUST have >>>>>>> some mechanisms to authenticate the substitutive stream source. >>>>>>> >>>>>>> For cases that the splicing time information is changed by a >>>>>>> malicious endpoint, the splicing, for example, may fail since it >>>>>>> will not be available at the right time for the substitutive >>>>>>> media >>>>>>> to arrive. >>>>>>> >>>>>>> A malicious endpoint may also break an undetectable splicing. To >>>>>>> mitigate this effect, the splicer SHOULD NOT forward the >>>>>>> splicing >>>>>>> time information RTP header extension defined in Section 4.1 to >>>>>>> the receivers. And it MUST NOT forward this header extension >>>>>>> when >>>>>>> considering an undetectable splicing." >>>>>>> >>>>>>> Thanks Roni >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- From: avtext >>>>>>>> [mailto:avtext-bounces@ietf.org] On Behalf Of Magnus Westerlund >>>>>>>> Sent: Saturday, April 09, 2016 12:16 AM To: Huangyihong >>>>>>>> (Rachel); >>>>>>>> avtext@ietf.org Subject: Re: [avtext] Fwd: New Version >>>>>>>> Notification for draft-ietf-avtext- >>>>>>>> splicing-notification-06.txt >>>>>>>> >>>>>>>> Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel): >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This new version addresses Magnus's comment of using an >>>>>>>>> agnostic >>>>>>>>> format. That's the only change made in this version. >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> So I have reviewed all the changes from the -04 to this -06 >>>>>>>> version. >>>>>>>> >>>>>>>> First, I think people should be aware that the latest change do >>>>>>>> change the data format of the splicing header extension. This >>>>>>>> was >>>>>>>> not my intention, but I also don't care about. Just that people >>>>>>>> should be aware of this. I understand this is to enable the >>>>>>>> 2-bytes format to align with the 32-byte boundaries when it is >>>>>>>> the sole header extension present. However, I would note that >>>>>>>> this is a unnecessary alignment most likely. This header >>>>>>>> extension, even when using 7-byte splicing out timestamps do >>>>>>>> fit >>>>>>>> within the 1-byte header extension. >>>>>>>> Thus, in most cases the sole reason for using the 2-byte header >>>>>>>> extension would be in cases where this header extension is >>>>>>>> included together with another header extension requiring the >>>>>>>> 2- >>>>>>>> byte header extension header. So from my perspective, the old >>>>>>>> 7-byte header extension could be used with both the 1 and >>>>>>>> 2-byte >>>>>>>> headers. >>>>>>>> >>>>>>>> My other comment is that the Security consideration section >>>>>>>> still >>>>>>>> has issues from my perspective: >>>>>>>> >>>>>>>> Since splicer works as a trusted entity, any RTP-level or >>>>>>>> outside >>>>>>>> security mechanism, such IPsec[RFC4301] or Datagram Transport >>>>>>>> Layer Security [RFC6347], will use a security association >>>>>>>> between >>>>>>>> the splicer and the receiver. When using the Secure Real-Time >>>>>>>> Transport Protocol (SRTP) [RFC3711], the splicer could be >>>>>>>> provisioned with the same security association as the main RTP >>>>>>>> sender. >>>>>>>> >>>>>>>> So the alternatives when SRTP is to protect the content from >>>>>>>> the >>>>>>>> Splicer to the Receiver, then the splicer either has its own >>>>>>>> security context on the splicer to receiver leg, or it has as >>>>>>>> indicated access to the security context from main RTP sender. >>>>>>>> >>>>>>>> Then the following paragraph seem to lack a requirement for >>>>>>>> authenticating the actual splicing notification, i.e. the whole >>>>>>>> RTP packet that it is included in. The text appear to discuss >>>>>>>> both the substitute RTP stream and if the notification is >>>>>>>> modified, but not an authentication requirement to avoid this. >>>>>>>> >>>>>>>> For cases that the splicing time information is changed by a >>>>>>>> malicious endpoint, the splicing may fail since it will not be >>>>>>>> available at the right time for the substitutive media to >>>>>>>> arrive >>>>>>>> >>>>>>>> That is not the only issue, it can also be used to hide content >>>>>>>> that the main RTP sender intended to recieve. I think here is >>>>>>>> the >>>>>>>> right place to insert the authentication need. >>>>>>>> >>>>>>>> , which may also break an undetectable splicing. To mitigate >>>>>>>> this >>>>>>>> effect, the splicer SHOULD NOT forward the splicing time >>>>>>>> information RTP header extension defined in Section 4.1 to the >>>>>>>> receivers. And it MUST NOT forward this header extension when >>>>>>>> considering an undetectable splicing. >>>>>>>> >>>>>>>> The undetectable part is a separate issue, please write it as >>>>>>>> separate sentences. >>>>>>>> >>>>>>>> >>>>>>>> Thanks for addressing the other issues. >>>>>>>> >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> Magnus Westerlund >>>>>>>> >>>>>>>> ----------------------------------------------------------------- >>>>>>>> -- >>>>>>>> -- >>>>>>>> - >>>>>>>> >>>>>>>> >>>>>> Services, Media and Network features, Ericsson Research EAB/TXM >>>>>>>> ----------------------------------------------------------------- >>>>>>>> -- >>>>>>>> -- >>>>>>>> - >>>>>>>> >>>>>>>> >>>>>> Ericsson AB | Phone +46 10 7148287 >>>>>>>> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >>>>>>>> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>>>>>>> ----------------------------------------------------------------- >>>>>>>> -- >>>>>>>> -- >>>>>>>> - >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> _______________________________________________ >>>>>>>> avtext mailing list avtext@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/avtext >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Magnus Westerlund >>>>>> >>>>>> ------------------------------------------------------------------- >>>>>> -- >>>>>> - Services, Media and Network features, Ericsson Research EAB/TXM >>>>>> ---------------------------------------------------------------------- >>>>>> Ericsson AB | Phone +46 10 7148287 >>>>>> Färögatan 6 | Mobile +46 73 0949079 >>>>>> SE-164 80 Stockholm, Sweden | mailto: >>>> magnus.westerlund@ericsson.com >>>>>> ------------------------------------------------------------------- >>>>>> -- >>>>>> - >>>>> >>>>> _______________________________________________ >>>>> avtext mailing list >>>>> avtext@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/avtext From nobody Wed May 25 11:37:46 2016 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D65DA12D8C6; Wed, 25 May 2016 11:37:43 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160525183743.18297.20919.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2016 11:37:43 -0700 Archived-At: Cc: avtext@ietf.org, draft-ietf-avtext-splicing-notification@ietf.org, jonathan@vidyo.com, avtext-chairs@ietf.org Subject: [avtext] Last Call: (RTP/RTCP extension for RTP Splicing Notification) to Proposed Standard X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 18:37:44 -0000 The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'RTP/RTCP extension for RTP Splicing Notification' as Proposed Standard This is a shortened second last call to consider two normative references to informational RFCs that have been added as a result of comments from the initial last call. The referenced RFCs are RFC 7201 and RFC 7667. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-06-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2500/