From nobody Thu Oct 9 15:53:42 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414251A89FA; Thu, 9 Oct 2014 15:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfEE3chl-yaa; Thu, 9 Oct 2014 15:53:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5211A8A61; Thu, 9 Oct 2014 15:53:34 -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: 5.6.3.p4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141009225334.30557.96321.idtracker@ietfa.amsl.com> Date: Thu, 09 Oct 2014 15:53:34 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/Lm2LD_gWBBTkZcvsTpMyklG4YOU Cc: straw chair , straw mailing list , RFC Editor Subject: [straw] Protocol Action: 'A Media-based Traceroute Function for the Session Initiation Protocol (SIP)' to Proposed Standard (draft-ietf-straw-sip-traceroute-03.txt) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 22:53:40 -0000 The IESG has approved the following document: - 'A Media-based Traceroute Function for the Session Initiation Protocol (SIP)' (draft-ietf-straw-sip-traceroute-03.txt) as Proposed Standard This document is the product of the Sip Traversal Required for Applications to Work Working Group. The IESG contact persons are Richard Barnes and Alissa Cooper. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-straw-sip-traceroute/ Technical Summary: Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. In many deployments, the media for SIP-created sessions does not flow directly from the originating user's UAC to the answering user's UAS. Often, SIP B2BUAs in the SIP signaling path also insert themselves in the media plane path by manipulating SDP, either for injecting media such as rich-ringtones or music-on-hold, or for relaying media in order to provide functions such as transcoding, IPv4-IPv6 conversion, NAT traversal, SRTP termination, media steering, etc. As more and more SIP domains get deployed and interconnect, the odds of a SIP session crossing such media-plane B2BUAs increases, as well as the number of such B2BUAs any given SIP session may go through. In other words, any given SIP session may cross any number of B2BUA's both in the SIP signaling plane as well as media plane. If failures or degradation occur in the media plane, it is difficult to determine where in the media path they occur. In order to aid managing and troubleshooting SIP-based sessions and media crossing such B2BUAs, it would be useful to be able to progressively test the media path as it reaches successive B2BUAs with a test controlled in a single-ended way from the source UA. A mechanism to perform media-loopback test sessions has been defined in [RFC6849], but it cannot be used to directly to test B2BUAs because typically the B2BUAs do not have an Address of Record (AoR) to be targeted, nor is it known a priori which B2BUAs will be crossed for any given session. For example, suppose calls from Alice to Bob have media problems. Alice would like to test the media path to each B2BUA in the path to Bob separately, to determine which segment has the issues. Alice cannot target the B2BUAs directly for each test call, because she doesn't know what URIs to use to target them; nor would using such URIs guarantee the same media path be used as a call to Bob. A better solution would be to make a test call targeted to Bob, but with a SIP traceroute-type mechanism that makes the call terminate at the B2BUAs, such that she can perform test sessions to test the media path to each downstream B2BUA. This document defines how such a mechanism can be employed, using the [RFC6849] mechanism along with the Max-Forwards SIP header field such that a SIP User Agent can make multiple test calls, each reaching a B2BUA further downstream. Each B2BUA in the path that supports the mechanism in [RFC6849] would answer the media-loopback call, and thus the originating SIP UA can test the media path up to that B2BUA. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The WG path of this document was reasonably short and efficient. Several technical comments were made during reviews and all were resolved with consensus. There is consensus in the STRAW WG to publish this document. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The guidelines and procedures in the document is based on input and experience from the implementer community. Personnel: Who is the Document Shepherd? Victor Pascual (victor.pascual.avila@gmail.com -- STRAW WG co-chair) Who is the Responsible Area Director? Richard Barnes From nobody Mon Oct 20 00:25:57 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772151A6FCC for ; Mon, 20 Oct 2014 00:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VwkJpp8v3Uy for ; Mon, 20 Oct 2014 00:25:54 -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 DF1841A1BF8 for ; Mon, 20 Oct 2014 00:25:52 -0700 (PDT) X-AuditID: c1b4fb3a-f79596d000001123-c7-5444b8fe2af0 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 52.1E.04387.EF8B4445; Mon, 20 Oct 2014 09:25:50 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Mon, 20 Oct 2014 09:25:50 +0200 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: IETF#91: Agenda time request Thread-Index: Ac/sNuEFqkNpVqUTQeeUXFsV12Rwag== Date: Mon, 20 Oct 2014 07:25:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4B1A1A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4B1A1AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje6/HS4hButazSxuNT9mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRseWL6wFrfIVf/4oNzBuke5i5OSQEDCReNO/nRnCFpO4cG89 G4gtJHCUUaL/VFkXIxeQvYRR4tKrd0AJDg42AQuJ7n/aIDUiAqoSE77cZASxhYHsZ58msYKU iAhoSay8qgdRoicxf+M3VhCbBajk8YZ3YDavgK/Ejmu7mUBsRqC130+tAbOZBcQlbj2ZzwRx joDEkj3noU4TlXj5+B8rhK0ksWL7JUaI+nyJJxdboGYKSpyc+YRlAqPQLCSjZiEpm4WkDCKu I7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIyG g1t+W+1gPPjc8RCjAAejEg/vghyXECHWxLLiytxDjNIcLErivAvPzQsWEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwDj3odtGQ7FjE3aUiBsFFJ9cPXPpjLZzE0TuB6jUBVwzlhCxtIv0m/yg dc5SrshP92SfNRf3r18eM4lho9Dy95KtDuIPkqS3GDPlnd18eeKiMpulPPuShKoij62oTHaI yOTWsn/l/f59waUjjnHf9hsw9fWX1W//IWT5edL9KmWpjMmLO3R/siuxFGckGmoxFxUnAgDr NydbZwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/straw/FDmDjq0RIr38eZud9ZlhPJpwFS8 Subject: [straw] IETF#91: Agenda time request X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 07:25:55 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4B1A1AESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (As co-chair) Hi, At IETF#91, STRAW is scheduled for Afternoon Session II (15:20-16:50) on We= dnesday 12th. https://datatracker.ietf.org/meeting/91/agenda.txt Please send an e-mail to the chairs in order to request agenda time. Please= indicate how much time you need, and what the main issues you intend to di= scuss are. Regards, Christer & Victor --_000_7594FB04B1934943A5C02806D1A2204B1D4B1A1AESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(As co-chair)

 

Hi,

 

At IETF#91, STRAW is scheduled for Afternoon Session= II (15:20-16:50) on Wednesday 12th.

 

https://datatracker.ietf.org/meeting/91/agenda.txt

 

Please send an e-mail to the chairs in order to requ= est agenda time. Please indicate how much time you need, and what the main = issues you intend to discuss are.

 

Regards,

 

Christer & Victor

 

--_000_7594FB04B1934943A5C02806D1A2204B1D4B1A1AESESSMB209erics_-- From nobody Tue Oct 21 09:05:39 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEEE1A88F1 for ; Tue, 21 Oct 2014 09:05:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz6u0tsisPgu for ; Tue, 21 Oct 2014 09:05:31 -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 3CC181A876B for ; Tue, 21 Oct 2014 09:05:31 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-2d-54468449404c Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 60.2D.21334.94486445; Tue, 21 Oct 2014 18:05:29 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0174.001; Tue, 21 Oct 2014 18:05:28 +0200 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: IETF#91: Agenda time request Thread-Index: Ac/sNuEFqkNpVqUTQeeUXFsV12RwagBEea5A Date: Tue, 21 Oct 2014 16:05:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4BEA3C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4B1A1A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4B1A1A@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4BEA3CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+Jvja5ni1uIwa2bCha3mh+zOjB6LFny kymAMYrLJiU1J7MstUjfLoEro+PAbKaCN2oVnevvsDcwblTqYuTkkBAwkTi99AM7hC0mceHe erYuRi4OIYGjjBKfptxngnCWMEqceweS4eBgE7CQ6P6nDdIgIqAqMeHLTUYQW1hAU+L0l+0s ICUiAloSK6/qQZQYSXQe2AJWwgJUvuDuEmYQm1fAV2LphD+sILYQkP1hwmQ2EJtTwE/i9oen YPWMQPd8P7WGCcRmFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCmErSSy6/RmqPl9i/d9bbBC7 BCVOznzCMoFRZBaSUbOQlM1CUgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYX 56YbGeulFmUmFxfn5+nlpZZsYgRG0MEtv3V3MK5+7XiIUYCDUYmHV2Gfa4gQa2JZcWXuIUZp DhYlcd5F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCsC9r2qfJEa9Ejllc+R94nCrzL Sf3IfXjWMVV+lV3mf5dI1oRfvDF9U8UzMZcjsms8D8ZbHJLjbn+Uv3hK8z93z4owlhvy09tT /OyWC0xOmOrb4H/z0a/1egxNCz/kxdxcdzmzK2zdpevuq98t+HLisUXGqocPGBU3Tyw7Irt/ uYH0utgsv2+XlFiKMxINtZiLihMBqNMzr4ECAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/straw/t_i19sTCmE8dI3CUPwyO6cT9J1Q Subject: Re: [straw] IETF#91: Agenda time request X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Oct 2014 16:05:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4BEA3CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable REMINDER. From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 20 October 2014 10:26 To: straw@ietf.org Subject: [straw] IETF#91: Agenda time request (As co-chair) Hi, At IETF#91, STRAW is scheduled for Afternoon Session II (15:20-16:50) on We= dnesday 12th. https://datatracker.ietf.org/meeting/91/agenda.txt Please send an e-mail to the chairs in order to request agenda time. Please= indicate how much time you need, and what the main issues you intend to di= scuss are. Regards, Christer & Victor --_000_7594FB04B1934943A5C02806D1A2204B1D4BEA3CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

REMINDER.

 

From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 20 October 2014 10:26
To: straw@ietf.org
Subject: [straw] IETF#91: Agenda time request

 

(As co-chair)

 

Hi,

 

At IETF#91, STRAW is scheduled for Afternoon Session= II (15:20-16:50) on Wednesday 12th.

 

https://datatracker.ietf.org/meeting/91/agenda.txt

 

Please send an e-mail to the chairs in order to requ= est agenda time. Please indicate how much time you need, and what the main = issues you intend to discuss are.

 

Regards,

 

Christer & Victor

 

--_000_7594FB04B1934943A5C02806D1A2204B1D4BEA3CESESSMB209erics_-- From nobody Fri Oct 24 05:52:49 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057911A902B for ; Fri, 24 Oct 2014 05:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxoDSYRJQbY7 for ; Fri, 24 Oct 2014 05:52:45 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9B11A8F3D for ; Fri, 24 Oct 2014 05:52:14 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id 10so2528603lbg.28 for ; Fri, 24 Oct 2014 05:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5kytOaTC9WC0X5XEXFKJHBzpMJPROO/GTWpck6FeMXA=; b=dYVwaxIJ5MAr2B2rm9Qsp5iv/np+/iBAHABToXI2DAGRAcuWP/n4nKe94bWyI1SFWK SAlf0vy30UKJRuZbk9wd89rMZcxFxrg7qag4tUTS2/nTAtF/SZm651vRPshEUoHO7z6/ 7jz11hSOVSCv56VgCbT0oGBGopsjN3DQM1EAme3xqACxWwx87ybWaGQAzzVtwSjondYD Y+HgQMO6aeK4ovzNpFeWMfXwWYo319dRyuau9gRhULXHGpDJWKdrjg41DZGvr8mKHgXN QJNKwo66gpAkuUsOGsDmBZK3w5Sc3lsytWyGd3a/EWBEXEVr0g4z/spzJ3OalQL8FtC+ /W4w== MIME-Version: 1.0 X-Received: by 10.152.116.102 with SMTP id jv6mr4391428lab.40.1414155133054; Fri, 24 Oct 2014 05:52:13 -0700 (PDT) Received: by 10.25.77.73 with HTTP; Fri, 24 Oct 2014 05:52:12 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4BEA3C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4B1A1A@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D4BEA3C@ESESSMB209.ericsson.se> Date: Fri, 24 Oct 2014 14:52:12 +0200 Message-ID: From: Victor Pascual Avila To: "straw@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/straw/m_jhISVpHSEJFJ_typGi9TKumGY Cc: Christer Holmberg Subject: Re: [straw] IETF#91: Agenda time request X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 12:52:47 -0000 Draft agenda for straw @ietf91 has been posted, please let us know if you have any comment http://www.ietf.org/proceedings/91/agenda/agenda-91-straw Christer and Victor, WG chairs On Tue, Oct 21, 2014 at 6:05 PM, Christer Holmberg wrote: > REMINDER. > > > > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer Holmber= g > Sent: 20 October 2014 10:26 > To: straw@ietf.org > Subject: [straw] IETF#91: Agenda time request > > > > (As co-chair) > > > > Hi, > > > > At IETF#91, STRAW is scheduled for Afternoon Session II (15:20-16:50) on > Wednesday 12th. > > > > https://datatracker.ietf.org/meeting/91/agenda.txt > > > > Please send an e-mail to the chairs in order to request agenda time. Plea= se > indicate how much time you need, and what the main issues you intend to > discuss are. > > > > Regards, > > > > Christer & Victor > > > > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw > --=20 Victor Pascual =C3=81vila From nobody Fri Oct 24 06:48:56 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F95B1A007E; Fri, 24 Oct 2014 06:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9anVnMIYKAQg; Fri, 24 Oct 2014 06:48:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 729231A0006; Fri, 24 Oct 2014 06:48:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141024134844.18793.86352.idtracker@ietfa.amsl.com> Date: Fri, 24 Oct 2014 06:48:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/OfVarh7ENUEZECSo6Nl1gcZWEhA Cc: straw@ietf.org Subject: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-02.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:48:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip Traversal Required for Applications to Work Working Group of the IETF. Title : Guidelines to support RTCP end-to-end in Back-to-Back User Agents (B2BUAs) Authors : Lorenzo Miniero Sergio Garcia Murillo Victor Pascual Filename : draft-ietf-straw-b2bua-rtcp-02.txt Pages : 14 Date : 2014-10-24 Abstract: SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be on the media path, rather than just intercepting signalling. This means that B2BUAs often implement an RTP/RTCP stack as well, whether to act as media transcoders or to just passthrough the media themselves, thus leading to separate multimedia sessions that the B2BUA correlates and bridges together. If not disciplined, though, this behaviour can severely impact the communication experience, especially when statistics and feedback information contained in RTCP packets get lost because of mismatches in the reported data. This document defines the proper behaviour B2BUAs should follow when also acting on the signalling/media plane in order to preserve the end-to-end functionality of RTCP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-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 Fri Oct 24 06:58:44 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BE1A014A for ; Fri, 24 Oct 2014 06:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvwILbYUqdcF for ; Fri, 24 Oct 2014 06:58:40 -0700 (PDT) Received: from smtpcmd01217.aruba.it (smtpcmd01217.aruba.it [62.149.158.217]) by ietfa.amsl.com (Postfix) with ESMTP id 61E0E1A008C for ; Fri, 24 Oct 2014 06:58:39 -0700 (PDT) Received: from lminiero ([87.1.90.147]) by smtpcmd01.ad.aruba.it with bizsmtp id 71yc1p0123Al88v011ycAD; Fri, 24 Oct 2014 15:58:37 +0200 Date: Fri, 24 Oct 2014 15:58:35 +0200 From: Lorenzo Miniero To: straw@ietf.org Message-ID: <20141024155835.32af61d7@lminiero> In-Reply-To: <20141024134844.18793.86352.idtracker@ietfa.amsl.com> References: <20141024134844.18793.86352.idtracker@ietfa.amsl.com> Organization: Meetecho X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.19; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/straw/rY3hVoRc5wmfeYWiH8CZmMGNViI Subject: Re: [straw] I-D Action: draft-ietf-straw-b2bua-rtcp-02.txt X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2014 13:58:42 -0000 Hi all, this version tries to address the latest comments, particularly with respect to the grouping taxonomy and the media security stuff that caused so much havoc in Toronto. With respect to the SRTP stuff, the section has not been removed (we need something along those lines in the document after all), but just rephrased to make it look less scary. Feedback welcome, Lorenzo On Fri, 24 Oct 2014 06:48:44 -0700 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 Sip Traversal Required > for Applications to Work Working Group of the IETF. > > Title : Guidelines to support RTCP end-to-end in > Back-to-Back User Agents (B2BUAs) Authors : Lorenzo Miniero > Sergio Garcia Murillo > Victor Pascual > Filename : draft-ietf-straw-b2bua-rtcp-02.txt > Pages : 14 > Date : 2014-10-24 > > Abstract: > SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also > be on the media path, rather than just intercepting signalling. This > means that B2BUAs often implement an RTP/RTCP stack as well, > whether to act as media transcoders or to just passthrough the media > themselves, thus leading to separate multimedia sessions that the > B2BUA correlates and bridges together. If not disciplined, though, > this behaviour can severely impact the communication experience, > especially when statistics and feedback information contained in > RTCP packets get lost because of mismatches in the reported data. > > This document defines the proper behaviour B2BUAs should follow > when also acting on the signalling/media plane in order to preserve > the end-to-end functionality of RTCP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-rtcp/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-straw-b2bua-rtcp-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-straw-b2bua-rtcp-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/ > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Tue Oct 28 16:28:13 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFF7E1A03E1 for ; Tue, 28 Oct 2014 16:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLnrFal2w_pm for ; Tue, 28 Oct 2014 16:28:03 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF5E1A1B64 for ; Tue, 28 Oct 2014 16:28:00 -0700 (PDT) Received: from userPC (unknown [122.167.202.51]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 1E40A3C0392; Tue, 28 Oct 2014 23:27:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1414538879; bh=IgvI8XAMzbYtrW8BU2tOqK0uyDBQ67HLdm67IlGvHHk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NFf9yrWTJW+jHAqT6jEEhqvEzxgD9ze9s0piFRnRFdm+en9t60COU0+C/Aklyoutq 6kaKM1d8y9MfUIsaWVa2pH38V/B4LjKEbdOgSpPIDIikw82CrO08hWDKRp4gvLJjR5 18kWittUqIZXoQzfmvTIk6zSRLOCVw8d4ngKx1WI= From: "Parthasarathi R" To: "'Stephen Farrell'" , "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> In-Reply-To: <53D8BC2D.6050408@cs.tcd.ie> Date: Wed, 29 Oct 2014 04:57:46 +0530 Message-ID: <01f701cff306$cdddeb20$6999c160$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+r2Yquq/a2YoMJTTCgDWFD28Q39BHLIW2w Content-Language: en-us X-CTCH-RefID: str=0001.0A020205.5450267F.00D4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.93 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/LjNF5rfr7gL0h13B9JaFJQJkVXQ Cc: 'Richard Barnes' , 'Sean Turner' Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 23:28:11 -0000 Hi all, One of the way to address MITM issue in STRAW WG B2BUA handling of = DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of = draft-ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or Media = Termination" (Sec 3.2 of draft-ram-straw-b2bua-dtls-srtp-00).=20 By this proposal, the scope of the work is to cover only end-to-end = DTLS-SRTP through B2BUA. The media relay provides end-to-end security = but there are challenges w.r.t NAT, forking, ICE, identity (RTCWeb IdP, = RFC4474bis, etc.,) which shall be sorted out in this milestone.=20 During IETF-90 and in the mailing alias, I haven't heard any concern for = Media relay handling in B2BUA. please let me know your opinion on the = same. Thanks Partha > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, July 30, 2014 3:05 PM > To: Parthasarathi R; 'Christer Holmberg'; straw@ietf.org > Cc: 'Richard Barnes'; 'Sean Turner' > Subject: Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: > Draft STRAW minutes] >=20 >=20 > on vacation, back in a week >=20 > terminating DTLS-SRTP is maybe fine but means being one of the > endpoints intended to be involved in the TLS session. Doing a > MITM on TLS is not at all fine. >=20 > S. >=20 > On 30/07/14 02:34, Parthasarathi R wrote: > > Hi all, > > > > > > > > I have different view than the security folks look at this draft. > This draft > > intention is not to violate RFC 2804. In case this draft is not > > standardized, all B2BUA handling DTLS-SRTP will end up in violating > RFC 2804 > > due to the lack of guidelines/standards to follow. Please look into > this > > draft from SIP recording architecture in B2BUA (Fig 1 of RFC 7245) > usage > > perspective wherein the senders/receiver is informed about the call > > recording (like call centre usage scenario) and no RFC 2804 > violation. > > > > > > > > In IETF-90 meeting, the security concerns are raised about this = draft > usage. > > It will be good to document as part of this document if it is really > > security issue. I'm not seeing any major security concerns as B2BUA > is yet > > another UA. Please let me know the list of security concern specific > to > > B2BUA in DTLS-SRTP. > > > > > > > > In reality, B2BUA terminating DTLS-SRTP is not avoidable because of > the > > different codec profile between the deployed SIP UAs. Say SIPoWS in > browser > > (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as of today > and SIP > > Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion to > terminate the > > media in the middle as there is no solution exists in IETF for the > same. The > > lack of standard leads to proprietary session border controller = (SBC) > > solutions which breaks other SIP enhancements as well. > > > > > > > > Thanks > > > > Partha > > > > > > > > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer > Holmberg > > Sent: Saturday, July 26, 2014 7:54 PM > > To: straw@ietf.org > > Cc: Richard Barnes (rlb@ipv.sx); Sean Turner; Stephen Farrell > > Subject: [straw] IETF#90: Draft STRAW minutes > > > > > > > > (Co-chair) > > > > > > > > Hi, > > > > > > > > Below are the STRAW minutes that the chairs intend to upload. > > > > > > > > However, before we do that, we would like to ask the community to > take a > > look at least at the notes associated with the DTLS-SRTP > presentation, as it > > caused lots of discussion. > > > > > > > > Note that the minutes do not contain who-said-what information (that > can be > > found elsewhere), but if you think there are some important things > missing, > > or if you think something is wrong, please let the chairs now. > > > > > > > > Thanks! > > > > > > > > Regards, > > > > > > > > Christer & Victor > > > > > > > > ------------------- > > > > > > > > IETF 90 - STRAW > > > > 1150-1320 EDT Friday Afternoon Session I > > > > > > > > > > > > Topic: Agenda bashing, IETF Note Well and WG status > > > > Presenter: Christer Holmberg (co-chair) > > > > Slides: > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf > > > > Draft: N/A > > > > > > > > > > > > No issues were identified. > > > > > > > > > > > > > > > > Topic: Guidelines to support RTCP in B2BUAs > > > > Presenter: Lorenzo Miniero > > > > Slides: > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf > > > > Draft: draft-ietf-straw-b2bua-rtcp > > > > > > > > > > > > It was indicated that XR needs to be looked into, to see whether > something > > needs to be covered in the draft. > > > > > > > > It was indicated that the terminology will be aligned with the > > grouping-taxonomy draft. In case there are conflicts, or other = issues > are > > found, the STRAW community is requested to provide comments on the > > grouping-taxonomy draft. > > > > > > > > It was requested whether the draft should also cover RTP specific > issues. It > > was indicated that the scope of the RTCP, and that we should be very > careful > > about introducing RTP issues. It was recommended to talk to Colin > Perkins > > whether he has any opinions regarding the need to cover RTP. > > > > > > > > I was asked how the document will relate to the work on multisource > > optimisation taking place in AVTEXT. > > > > > > > > It was indicated that the text recommending man in the middle > functionality > > for SRTP most likely will cause issues with IESG. After the = DTLS-SRTP > > discussion (see further down) it was suggested that the RTCP draft > should > > not talk about SRTP. > > > > > > > > > > > > > > > > Topic: Taxonomy Discussion > > > > Presenter: Lorenzo Miniero > > > > Slides: > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf > > > > Draft: All STRAW deliveries > > > > > > > > > > > > It was agreed the STRAW shall use the terms in the avtext-grouping- > taxonomy > > document in preference to definitions elsewhere is they are > appropriate, > > with a note indicating any differences in other documents that may > influence > > understanding. > > > > > > > > > > > > > > > > Topic: STUN handling in B2BUAs > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > Slides: > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf > > > > Draft: draft-ram-straw-b2bua-stun > > > > > > > > > > > > It was indicated that B2BUA, due to policy reasons, may strip > candidates > > from SDP. > > > > > > > > It was indicated that B2BUAs must be very careful to not perform > actions > > that will cause ICE mismatch. > > > > > > > > The chair informed the community that a WG adoption request will be > sent out > > within the upcoming weeks. > > > > > > > > It was indicated that the group needs to follow the ICE bis work > taking > > place in MMUSIC, in case there will be any impacts on the STRAW > draft. > > > > > > > > > > > > > > > > Topic: DTLS-SRTP handling in B2BUAs > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > Slides: > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf > > > > Draft: draft-ram-straw-b2bua-dtls-srtp > > > > > > > > > > > > The presentation triggered lots of discussions and controversy, as = it > was > > seen as an attempt to standardize MITM (man in the middle > procedures). While > > people did realize such actions take place in deployments, they > claimed that > > IETF/STRAW should not standardize such procedures. It was also > indicated > > that it goes against a number of BCP specifications, and RFC 2804. > Others > > indicated that the purpose is to make sure that entities doing this > kind of > > functionality do it in a way which does not cause interoperability > problems, > > which could cause people to not use security to begin with. > > > > > > > > It was indicated that one possible way forward could be to simply > document, > > in an informal delivery, how different vendors do things in the > network, but > > in such case the vendors should also be listed in the document. > > > > > > > > Before the draft is adopted as a WG item, further discussions need = to > take > > place. The ADs will help with finding the correct people (security, > IESG, > > etc) to involve in such discussions. The chair indicated that the > draft > > implements a charter delivery, but that one possible outcome will be > to > > remove/re-scope the charter delivery. > > > > > > > > > > > > From nobody Tue Oct 28 23:49:26 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08341A1A04 for ; Tue, 28 Oct 2014 23:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DNHPI4eW2YH for ; Tue, 28 Oct 2014 23:49:22 -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 40D5F1A19F0 for ; Tue, 28 Oct 2014 23:49:21 -0700 (PDT) X-AuditID: c1b4fb25-f791c6d00000617b-3e-54508dee4ea0 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EA.6A.24955.EED80545; Wed, 29 Oct 2014 07:49:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 07:49:18 +0100 From: Christer Holmberg To: Parthasarathi R , 'Stephen Farrell' , "straw@ietf.org" Thread-Topic: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: Draft STRAW minutes] Thread-Index: AQHPq5ZhnPh8EjJl6UG8BttJ7FbyRJu4OkGAgI5rXQCAAIuTQA== Date: Wed, 29 Oct 2014 06:49:17 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D25F2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> <01f701cff306$cdddeb20$6999c160$@co.in> In-Reply-To: <01f701cff306$cdddeb20$6999c160$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3Rvddb0CIwcYvFhaTP/WxWkzts7WY vvcau8Wt5sesFjvOTWBxYPVY232VzePOnA+sHkuW/GTymLxxFovHh/lf2ANYo7hsUlJzMstS i/TtErgyGm6fZS7oS67o69nM2sB4IqGLkZNDQsBEYmP7RUYIW0ziwr31bF2MXBxCAkcYJdae +AKWEBJYwijRsieoi5GDg03AQqL7nzZIjYhAC6PEn839YDXMAs4Slzp3MYHYwgJREku/djOD 2CIC0RLfls9lgbCdJA7uuMIGYrMIqEqsv94N1ssr4Cvxc81iRojF+xglLk94zwqS4AS6rufl a7BBjEDXfT+1hglimbjErSfzmSCuFpBYsuc8M4QtKvHy8T9WkEMlBBQllvfLgZjMApoS63fp Q3QqSkzpfsgOsVZQ4uTMJywTGMVmIRk6C6FjFpKOWUg6FjCyrGIULU4tTspNNzLWSy3KTC4u zs/Ty0st2cQIjLqDW36r7mC8/MbxEKMAB6MSD+8GNv8QIdbEsuLK3EOM0hwsSuK8C8/NCxYS SE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAqF09Q3vT+RlzrS4+ktbZ583vMDtxlfWiPfJnz7x9 9iynIPU6x0wXvpXX579jM33It2bH2tCtLdPWKvKwBH4V7d4m/i9lQdNX75mL509ccqZTrdHZ MnxGb91iz93CC89c+rR7/s2LEy9+st2hfy902fIz13xTZv4I6lLZpiAqqbTrVNGsjFl3d4Uq sRRnJBpqMRcVJwIALAAET5sCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/straw/pSGjH29-zl2a9oBYA3SDbMIPLDM Cc: 'Richard Barnes' , 'Sean Turner' Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 06:49:25 -0000 KEFzIGNvLWNoYWlyKQ0KDQpIaSwNCg0KSWYgYW55b25lIGhhcyBhbiBpc3N1ZSB3aXRoIHRoZSBn ZW5lcmFsIGFwcHJvYWNoIHN1Z2dlc3RlZCBieSBQYXJ0aGEsIHBsZWFzZSBpbmRpY2F0ZSB0byBv biB0aGUgbGlzdCwgc28gdGhhdCB3ZSBpbiBIb25vbHVsdSBjYW4gZm9jdXMgb24gdGhlIHRlY2hu aWNhbCBhc3BlY3RzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogUGFydGhhc2FyYXRoaSBSIFttYWlsdG86cGFydGhhQHBhcnRoYXNh cmF0aGkuY28uaW5dIA0KU2VudDogMjkuIGxva2FrdXV0YSAyMDE0IDE6MjgNClRvOiAnU3RlcGhl biBGYXJyZWxsJzsgQ2hyaXN0ZXIgSG9sbWJlcmc7IHN0cmF3QGlldGYub3JnDQpDYzogJ1JpY2hh cmQgQmFybmVzJzsgJ1NlYW4gVHVybmVyJw0KU3ViamVjdDogUkU6IEIyQlVBIGhhbmRsaW5nIGlu IERUTFMtU1JUUCBbd2FzIFJFOiBbc3RyYXddIElFVEYjOTA6IERyYWZ0IFNUUkFXIG1pbnV0ZXNd DQoNCkhpIGFsbCwNCg0KT25lIG9mIHRoZSB3YXkgdG8gYWRkcmVzcyBNSVRNIGlzc3VlIGluIFNU UkFXIFdHIEIyQlVBIGhhbmRsaW5nIG9mIERUTFMtU1JUUCBtaWxlc3RvbmUgaXMgdG8gZm9jdXMg b25seSBvbiBNZWRpYSByZWxheSAoU2VjIDMuMSBvZiBkcmFmdC1yYW0tc3RyYXctYjJidWEtZHRs cy1zcnRwLTAwKSBhbmQgcmVtb3ZpbmcgIk1lZGlhIEF3YXJlIG9yIE1lZGlhIFRlcm1pbmF0aW9u IiAoU2VjIDMuMiBvZiBkcmFmdC1yYW0tc3RyYXctYjJidWEtZHRscy1zcnRwLTAwKS4gDQoNCkJ5 IHRoaXMgcHJvcG9zYWwsIHRoZSBzY29wZSBvZiB0aGUgd29yayBpcyB0byBjb3ZlciBvbmx5IGVu ZC10by1lbmQgRFRMUy1TUlRQIHRocm91Z2ggQjJCVUEuIFRoZSBtZWRpYSByZWxheSBwcm92aWRl cyBlbmQtdG8tZW5kIHNlY3VyaXR5IGJ1dCB0aGVyZSBhcmUgY2hhbGxlbmdlcyB3LnIudCBOQVQs IGZvcmtpbmcsIElDRSwgaWRlbnRpdHkgKFJUQ1dlYiBJZFAsIFJGQzQ0NzRiaXMsIGV0Yy4sKSB3 aGljaCBzaGFsbCBiZSBzb3J0ZWQgb3V0IGluIHRoaXMgbWlsZXN0b25lLiANCg0KRHVyaW5nIElF VEYtOTAgYW5kIGluIHRoZSBtYWlsaW5nIGFsaWFzLCBJIGhhdmVuJ3QgaGVhcmQgYW55IGNvbmNl cm4gZm9yIE1lZGlhIHJlbGF5IGhhbmRsaW5nIGluIEIyQlVBLiBwbGVhc2UgbGV0IG1lIGtub3cg eW91ciBvcGluaW9uIG9uIHRoZSBzYW1lLg0KDQpUaGFua3MNClBhcnRoYQ0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBo ZW4uZmFycmVsbEBjcy50Y2QuaWVdDQo+IFNlbnQ6IFdlZG5lc2RheSwgSnVseSAzMCwgMjAxNCAz OjA1IFBNDQo+IFRvOiBQYXJ0aGFzYXJhdGhpIFI7ICdDaHJpc3RlciBIb2xtYmVyZyc7IHN0cmF3 QGlldGYub3JnDQo+IENjOiAnUmljaGFyZCBCYXJuZXMnOyAnU2VhbiBUdXJuZXInDQo+IFN1Ympl Y3Q6IFJlOiBCMkJVQSBoYW5kbGluZyBpbiBEVExTLVNSVFAgW3dhcyBSRTogW3N0cmF3XSBJRVRG IzkwOg0KPiBEcmFmdCBTVFJBVyBtaW51dGVzXQ0KPiANCj4gDQo+IG9uIHZhY2F0aW9uLCBiYWNr IGluIGEgd2Vlaw0KPiANCj4gdGVybWluYXRpbmcgRFRMUy1TUlRQIGlzIG1heWJlIGZpbmUgYnV0 IG1lYW5zIGJlaW5nIG9uZSBvZiB0aGUgDQo+IGVuZHBvaW50cyBpbnRlbmRlZCB0byBiZSBpbnZv bHZlZCBpbiB0aGUgVExTIHNlc3Npb24uIERvaW5nIGEgTUlUTSBvbiANCj4gVExTIGlzICBub3Qg YXQgYWxsIGZpbmUuDQo+IA0KPiBTLg0KPiANCj4gT24gMzAvMDcvMTQgMDI6MzQsIFBhcnRoYXNh cmF0aGkgUiB3cm90ZToNCj4gPiBIaSBhbGwsDQo+ID4NCj4gPg0KPiA+DQo+ID4gSSBoYXZlIGRp ZmZlcmVudCB2aWV3IHRoYW4gdGhlIHNlY3VyaXR5IGZvbGtzIGxvb2sgYXQgdGhpcyBkcmFmdC4N Cj4gVGhpcyBkcmFmdA0KPiA+IGludGVudGlvbiBpcyBub3QgdG8gdmlvbGF0ZSBSRkMgMjgwNC4g SW4gY2FzZSB0aGlzIGRyYWZ0IGlzIG5vdCANCj4gPiBzdGFuZGFyZGl6ZWQsIGFsbCBCMkJVQSBo YW5kbGluZyBEVExTLVNSVFAgd2lsbCBlbmQgdXAgaW4gdmlvbGF0aW5nDQo+IFJGQyAyODA0DQo+ ID4gZHVlIHRvIHRoZSBsYWNrIG9mIGd1aWRlbGluZXMvc3RhbmRhcmRzIHRvIGZvbGxvdy4gUGxl YXNlIGxvb2sgaW50bw0KPiB0aGlzDQo+ID4gZHJhZnQgZnJvbSBTSVAgcmVjb3JkaW5nIGFyY2hp dGVjdHVyZSBpbiBCMkJVQSAoRmlnIDEgb2YgUkZDIDcyNDUpDQo+IHVzYWdlDQo+ID4gcGVyc3Bl Y3RpdmUgd2hlcmVpbiB0aGUgc2VuZGVycy9yZWNlaXZlciBpcyBpbmZvcm1lZCBhYm91dCB0aGUg Y2FsbCANCj4gPiByZWNvcmRpbmcgKGxpa2UgY2FsbCBjZW50cmUgdXNhZ2Ugc2NlbmFyaW8pIGFu ZCBubyBSRkMgMjgwNA0KPiB2aW9sYXRpb24uDQo+ID4NCj4gPg0KPiA+DQo+ID4gSW4gSUVURi05 MCBtZWV0aW5nLCB0aGUgc2VjdXJpdHkgY29uY2VybnMgYXJlIHJhaXNlZCBhYm91dCB0aGlzIA0K PiA+IGRyYWZ0DQo+IHVzYWdlLg0KPiA+IEl0IHdpbGwgYmUgZ29vZCB0byBkb2N1bWVudCBhcyBw YXJ0IG9mIHRoaXMgZG9jdW1lbnQgaWYgaXQgaXMgcmVhbGx5IA0KPiA+IHNlY3VyaXR5IGlzc3Vl LiBJJ20gbm90IHNlZWluZyBhbnkgbWFqb3Igc2VjdXJpdHkgY29uY2VybnMgYXMgQjJCVUENCj4g aXMgeWV0DQo+ID4gYW5vdGhlciBVQS4gUGxlYXNlIGxldCBtZSBrbm93IHRoZSBsaXN0IG9mIHNl Y3VyaXR5IGNvbmNlcm4gc3BlY2lmaWMNCj4gdG8NCj4gPiBCMkJVQSBpbiBEVExTLVNSVFAuDQo+ ID4NCj4gPg0KPiA+DQo+ID4gSW4gcmVhbGl0eSwgQjJCVUEgdGVybWluYXRpbmcgRFRMUy1TUlRQ IGlzIG5vdCBhdm9pZGFibGUgYmVjYXVzZSBvZg0KPiB0aGUNCj4gPiBkaWZmZXJlbnQgY29kZWMg cHJvZmlsZSBiZXR3ZWVuIHRoZSBkZXBsb3llZCBTSVAgVUFzLiBTYXkgU0lQb1dTIGluDQo+IGJy b3dzZXINCj4gPiAoV2ViUlRDIGVuZHBvaW50L1NJUCBVQSkgdXNlcyBPcHVzL0c3MTEvVlA4IGFz IGEgY29kZWMgYXMgb2YgdG9kYXkNCj4gYW5kIFNJUA0KPiA+IE1vYmlsZSBkZXZpY2VzIHVzZXMg QU1SL0FNUi1XQi9ILjI2NC4gVGhlcmUgaXMgYSBjb21wdWxzaW9uIHRvDQo+IHRlcm1pbmF0ZSB0 aGUNCj4gPiBtZWRpYSBpbiB0aGUgbWlkZGxlIGFzIHRoZXJlIGlzIG5vIHNvbHV0aW9uIGV4aXN0 cyBpbiBJRVRGIGZvciB0aGUNCj4gc2FtZS4gVGhlDQo+ID4gbGFjayBvZiBzdGFuZGFyZCBsZWFk cyB0byBwcm9wcmlldGFyeSBzZXNzaW9uIGJvcmRlciBjb250cm9sbGVyIA0KPiA+IChTQkMpIHNv bHV0aW9ucyB3aGljaCBicmVha3Mgb3RoZXIgU0lQIGVuaGFuY2VtZW50cyBhcyB3ZWxsLg0KPiA+ DQo+ID4NCj4gPg0KPiA+IFRoYW5rcw0KPiA+DQo+ID4gUGFydGhhDQo+ID4NCj4gPg0KPiA+DQo+ ID4gRnJvbTogc3RyYXcgW21haWx0bzpzdHJhdy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQ2hyaXN0ZXINCj4gSG9sbWJlcmcNCj4gPiBTZW50OiBTYXR1cmRheSwgSnVseSAyNiwgMjAx NCA3OjU0IFBNDQo+ID4gVG86IHN0cmF3QGlldGYub3JnDQo+ID4gQ2M6IFJpY2hhcmQgQmFybmVz IChybGJAaXB2LnN4KTsgU2VhbiBUdXJuZXI7IFN0ZXBoZW4gRmFycmVsbA0KPiA+IFN1YmplY3Q6 IFtzdHJhd10gSUVURiM5MDogRHJhZnQgU1RSQVcgbWludXRlcw0KPiA+DQo+ID4NCj4gPg0KPiA+ IChDby1jaGFpcikNCj4gPg0KPiA+DQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+DQo+ID4NCj4gPiBC ZWxvdyBhcmUgdGhlIFNUUkFXIG1pbnV0ZXMgdGhhdCB0aGUgY2hhaXJzIGludGVuZCB0byB1cGxv YWQuDQo+ID4NCj4gPg0KPiA+DQo+ID4gSG93ZXZlciwgYmVmb3JlIHdlIGRvIHRoYXQsIHdlIHdv dWxkIGxpa2UgdG8gYXNrIHRoZSBjb21tdW5pdHkgdG8NCj4gdGFrZSBhDQo+ID4gbG9vayBhdCBs ZWFzdCBhdCB0aGUgbm90ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSBEVExTLVNSVFANCj4gcHJlc2Vu dGF0aW9uLCBhcyBpdA0KPiA+IGNhdXNlZCBsb3RzIG9mIGRpc2N1c3Npb24uDQo+ID4NCj4gPg0K PiA+DQo+ID4gTm90ZSB0aGF0IHRoZSBtaW51dGVzIGRvIG5vdCBjb250YWluIHdoby1zYWlkLXdo YXQgaW5mb3JtYXRpb24gKHRoYXQNCj4gY2FuIGJlDQo+ID4gZm91bmQgZWxzZXdoZXJlKSwgYnV0 IGlmIHlvdSB0aGluayB0aGVyZSBhcmUgc29tZSBpbXBvcnRhbnQgdGhpbmdzDQo+IG1pc3Npbmcs DQo+ID4gb3IgaWYgeW91IHRoaW5rIHNvbWV0aGluZyBpcyB3cm9uZywgcGxlYXNlIGxldCB0aGUg Y2hhaXJzIG5vdy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MhDQo+ID4NCj4gPg0KPiA+DQo+ ID4gUmVnYXJkcywNCj4gPg0KPiA+DQo+ID4NCj4gPiBDaHJpc3RlciAmIFZpY3Rvcg0KPiA+DQo+ ID4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+DQo+ID4NCj4gPiBJRVRG IDkwIC0gU1RSQVcNCj4gPg0KPiA+IDExNTAtMTMyMCBFRFQgICAgRnJpZGF5IEFmdGVybm9vbiBT ZXNzaW9uIEkNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gVG9waWM6ICAgICBBZ2VuZGEg YmFzaGluZywgSUVURiBOb3RlIFdlbGwgYW5kIFdHIHN0YXR1cw0KPiA+DQo+ID4gUHJlc2VudGVy OiBDaHJpc3RlciBIb2xtYmVyZyAoY28tY2hhaXIpDQo+ID4NCj4gPiBTbGlkZXM6DQo+ID4gaHR0 cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9zbGlkZXMvc2xpZGVzLTkwLXN0cmF3LTAu cGRmDQo+ID4NCj4gPiBEcmFmdDogICAgIE4vQQ0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4g PiBObyBpc3N1ZXMgd2VyZSBpZGVudGlmaWVkLg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+DQo+ID4gVG9waWM6ICAgICBHdWlkZWxpbmVzIHRvIHN1cHBvcnQgUlRDUCBpbiBCMkJV QXMNCj4gPg0KPiA+IFByZXNlbnRlcjogTG9yZW56byBNaW5pZXJvDQo+ID4NCj4gPiBTbGlkZXM6 DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9zbGlkZXMvc2xpZGVzLTkw LXN0cmF3LTEucGRmDQo+ID4NCj4gPiBEcmFmdDogICAgIGRyYWZ0LWlldGYtc3RyYXctYjJidWEt cnRjcA0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBJdCB3YXMgaW5kaWNhdGVkIHRoYXQg WFIgbmVlZHMgdG8gYmUgbG9va2VkIGludG8sIHRvIHNlZSB3aGV0aGVyDQo+IHNvbWV0aGluZw0K PiA+IG5lZWRzIHRvIGJlIGNvdmVyZWQgaW4gdGhlIGRyYWZ0Lg0KPiA+DQo+ID4NCj4gPg0KPiA+ IEl0IHdhcyBpbmRpY2F0ZWQgdGhhdCB0aGUgdGVybWlub2xvZ3kgd2lsbCBiZSBhbGlnbmVkIHdp dGggdGhlIA0KPiA+IGdyb3VwaW5nLXRheG9ub215IGRyYWZ0LiBJbiBjYXNlIHRoZXJlIGFyZSBj b25mbGljdHMsIG9yIG90aGVyIA0KPiA+IGlzc3Vlcw0KPiBhcmUNCj4gPiBmb3VuZCwgdGhlIFNU UkFXIGNvbW11bml0eSBpcyByZXF1ZXN0ZWQgdG8gcHJvdmlkZSBjb21tZW50cyBvbiB0aGUgDQo+ ID4gZ3JvdXBpbmctdGF4b25vbXkgZHJhZnQuDQo+ID4NCj4gPg0KPiA+DQo+ID4gSXQgd2FzIHJl cXVlc3RlZCB3aGV0aGVyIHRoZSBkcmFmdCBzaG91bGQgYWxzbyBjb3ZlciBSVFAgc3BlY2lmaWMN Cj4gaXNzdWVzLiBJdA0KPiA+IHdhcyBpbmRpY2F0ZWQgdGhhdCB0aGUgc2NvcGUgb2YgdGhlIFJU Q1AsIGFuZCB0aGF0IHdlIHNob3VsZCBiZSB2ZXJ5DQo+IGNhcmVmdWwNCj4gPiBhYm91dCBpbnRy b2R1Y2luZyBSVFAgaXNzdWVzLiBJdCB3YXMgcmVjb21tZW5kZWQgdG8gdGFsayB0byBDb2xpbg0K PiBQZXJraW5zDQo+ID4gd2hldGhlciBoZSBoYXMgYW55IG9waW5pb25zIHJlZ2FyZGluZyB0aGUg bmVlZCB0byBjb3ZlciBSVFAuDQo+ID4NCj4gPg0KPiA+DQo+ID4gSSB3YXMgYXNrZWQgaG93IHRo ZSBkb2N1bWVudCB3aWxsIHJlbGF0ZSB0byB0aGUgd29yayBvbiBtdWx0aXNvdXJjZSANCj4gPiBv cHRpbWlzYXRpb24gdGFraW5nIHBsYWNlIGluIEFWVEVYVC4NCj4gPg0KPiA+DQo+ID4NCj4gPiBJ dCB3YXMgaW5kaWNhdGVkIHRoYXQgdGhlIHRleHQgcmVjb21tZW5kaW5nIG1hbiBpbiB0aGUgbWlk ZGxlDQo+IGZ1bmN0aW9uYWxpdHkNCj4gPiBmb3IgU1JUUCBtb3N0IGxpa2VseSB3aWxsIGNhdXNl IGlzc3VlcyB3aXRoIElFU0cuIEFmdGVyIHRoZSANCj4gPiBEVExTLVNSVFAgZGlzY3Vzc2lvbiAo c2VlIGZ1cnRoZXIgZG93bikgaXQgd2FzIHN1Z2dlc3RlZCB0aGF0IHRoZSANCj4gPiBSVENQIGRy YWZ0DQo+IHNob3VsZA0KPiA+IG5vdCB0YWxrIGFib3V0IFNSVFAuDQo+ID4NCj4gPg0KPiA+DQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUb3BpYzogICAgIFRheG9ub215IERpc2N1c3Npb24NCj4g Pg0KPiA+IFByZXNlbnRlcjogTG9yZW56byBNaW5pZXJvDQo+ID4NCj4gPiBTbGlkZXM6DQo+ID4g aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9zbGlkZXMvc2xpZGVzLTkwLXN0cmF3 LTIucGRmDQo+ID4NCj4gPiBEcmFmdDogICAgIEFsbCBTVFJBVyBkZWxpdmVyaWVzDQo+ID4NCj4g Pg0KPiA+DQo+ID4NCj4gPg0KPiA+IEl0IHdhcyBhZ3JlZWQgdGhlIFNUUkFXIHNoYWxsIHVzZSB0 aGUgdGVybXMgaW4gdGhlIGF2dGV4dC1ncm91cGluZy0NCj4gdGF4b25vbXkNCj4gPiBkb2N1bWVu dCBpbiBwcmVmZXJlbmNlIHRvIGRlZmluaXRpb25zIGVsc2V3aGVyZSBpcyB0aGV5IGFyZQ0KPiBh cHByb3ByaWF0ZSwNCj4gPiB3aXRoIGEgbm90ZSBpbmRpY2F0aW5nIGFueSBkaWZmZXJlbmNlcyBp biBvdGhlciBkb2N1bWVudHMgdGhhdCBtYXkNCj4gaW5mbHVlbmNlDQo+ID4gdW5kZXJzdGFuZGlu Zy4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRvcGljOiAgICAgU1RV TiBoYW5kbGluZyBpbiBCMkJVQXMNCj4gPg0KPiA+IFByZXNlbnRlcjogTG9yZW56byBNaW5pZXJv IChvbiBiZWhhbGYgb2YgdGhlIGRyYWZ0IGF1dGhvcnMpDQo+ID4NCj4gPiBTbGlkZXM6DQo+ID4g aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9zbGlkZXMvc2xpZGVzLTkwLXN0cmF3 LTMucGRmDQo+ID4NCj4gPiBEcmFmdDogICAgIGRyYWZ0LXJhbS1zdHJhdy1iMmJ1YS1zdHVuDQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IEl0IHdhcyBpbmRpY2F0ZWQgdGhhdCBCMkJVQSwg ZHVlIHRvIHBvbGljeSByZWFzb25zLCBtYXkgc3RyaXANCj4gY2FuZGlkYXRlcw0KPiA+IGZyb20g U0RQLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEl0IHdhcyBpbmRpY2F0ZWQgdGhhdCBCMkJVQXMgbXVz dCBiZSB2ZXJ5IGNhcmVmdWwgdG8gbm90IHBlcmZvcm0NCj4gYWN0aW9ucw0KPiA+IHRoYXQgd2ls bCBjYXVzZSBJQ0UgbWlzbWF0Y2guDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIGNoYWlyIGluZm9y bWVkIHRoZSBjb21tdW5pdHkgdGhhdCBhIFdHIGFkb3B0aW9uIHJlcXVlc3Qgd2lsbCBiZQ0KPiBz ZW50IG91dA0KPiA+IHdpdGhpbiB0aGUgdXBjb21pbmcgd2Vla3MuDQo+ID4NCj4gPg0KPiA+DQo+ ID4gSXQgd2FzIGluZGljYXRlZCB0aGF0IHRoZSBncm91cCBuZWVkcyB0byBmb2xsb3cgdGhlIElD RSBiaXMgd29yaw0KPiB0YWtpbmcNCj4gPiBwbGFjZSBpbiBNTVVTSUMsIGluIGNhc2UgdGhlcmUg d2lsbCBiZSBhbnkgaW1wYWN0cyBvbiB0aGUgU1RSQVcNCj4gZHJhZnQuDQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUb3BpYzogICAgIERUTFMtU1JUUCBoYW5kbGluZyBp biBCMkJVQXMNCj4gPg0KPiA+IFByZXNlbnRlcjogTG9yZW56byBNaW5pZXJvIChvbiBiZWhhbGYg b2YgdGhlIGRyYWZ0IGF1dGhvcnMpDQo+ID4NCj4gPiBTbGlkZXM6DQo+ID4gaHR0cDovL3d3dy5p ZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9zbGlkZXMvc2xpZGVzLTkwLXN0cmF3LTQucGRmDQo+ID4N Cj4gPiBEcmFmdDogICAgIGRyYWZ0LXJhbS1zdHJhdy1iMmJ1YS1kdGxzLXNydHANCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIHByZXNlbnRhdGlvbiB0cmlnZ2VyZWQgbG90cyBvZiBk aXNjdXNzaW9ucyBhbmQgY29udHJvdmVyc3ksIGFzIA0KPiA+IGl0DQo+IHdhcw0KPiA+IHNlZW4g YXMgYW4gYXR0ZW1wdCB0byBzdGFuZGFyZGl6ZSBNSVRNIChtYW4gaW4gdGhlIG1pZGRsZQ0KPiBw cm9jZWR1cmVzKS4gV2hpbGUNCj4gPiBwZW9wbGUgZGlkIHJlYWxpemUgc3VjaCBhY3Rpb25zIHRh a2UgcGxhY2UgaW4gZGVwbG95bWVudHMsIHRoZXkNCj4gY2xhaW1lZCB0aGF0DQo+ID4gSUVURi9T VFJBVyBzaG91bGQgbm90IHN0YW5kYXJkaXplIHN1Y2ggcHJvY2VkdXJlcy4gSXQgd2FzIGFsc28N Cj4gaW5kaWNhdGVkDQo+ID4gdGhhdCBpdCBnb2VzIGFnYWluc3QgYSBudW1iZXIgb2YgQkNQIHNw ZWNpZmljYXRpb25zLCBhbmQgUkZDIDI4MDQuDQo+IE90aGVycw0KPiA+IGluZGljYXRlZCB0aGF0 IHRoZSBwdXJwb3NlIGlzIHRvIG1ha2Ugc3VyZSB0aGF0IGVudGl0aWVzIGRvaW5nIHRoaXMNCj4g a2luZCBvZg0KPiA+IGZ1bmN0aW9uYWxpdHkgZG8gaXQgaW4gYSB3YXkgd2hpY2ggZG9lcyBub3Qg Y2F1c2UgaW50ZXJvcGVyYWJpbGl0eQ0KPiBwcm9ibGVtcywNCj4gPiB3aGljaCBjb3VsZCBjYXVz ZSBwZW9wbGUgdG8gbm90IHVzZSBzZWN1cml0eSB0byBiZWdpbiB3aXRoLg0KPiA+DQo+ID4NCj4g Pg0KPiA+IEl0IHdhcyBpbmRpY2F0ZWQgdGhhdCBvbmUgcG9zc2libGUgd2F5IGZvcndhcmQgY291 bGQgYmUgdG8gc2ltcGx5DQo+IGRvY3VtZW50LA0KPiA+IGluIGFuIGluZm9ybWFsIGRlbGl2ZXJ5 LCBob3cgZGlmZmVyZW50IHZlbmRvcnMgZG8gdGhpbmdzIGluIHRoZQ0KPiBuZXR3b3JrLCBidXQN Cj4gPiBpbiBzdWNoIGNhc2UgdGhlIHZlbmRvcnMgc2hvdWxkIGFsc28gYmUgbGlzdGVkIGluIHRo ZSBkb2N1bWVudC4NCj4gPg0KPiA+DQo+ID4NCj4gPiBCZWZvcmUgdGhlIGRyYWZ0IGlzIGFkb3B0 ZWQgYXMgYSBXRyBpdGVtLCBmdXJ0aGVyIGRpc2N1c3Npb25zIG5lZWQgDQo+ID4gdG8NCj4gdGFr ZQ0KPiA+IHBsYWNlLiBUaGUgQURzIHdpbGwgaGVscCB3aXRoIGZpbmRpbmcgdGhlIGNvcnJlY3Qg cGVvcGxlIChzZWN1cml0eSwNCj4gSUVTRywNCj4gPiBldGMpIHRvIGludm9sdmUgaW4gc3VjaCBk aXNjdXNzaW9ucy4gVGhlIGNoYWlyIGluZGljYXRlZCB0aGF0IHRoZQ0KPiBkcmFmdA0KPiA+IGlt cGxlbWVudHMgYSBjaGFydGVyIGRlbGl2ZXJ5LCBidXQgdGhhdCBvbmUgcG9zc2libGUgb3V0Y29t ZSB3aWxsIGJlDQo+IHRvDQo+ID4gcmVtb3ZlL3JlLXNjb3BlIHRoZSBjaGFydGVyIGRlbGl2ZXJ5 Lg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KDQo= From nobody Wed Oct 29 00:19:24 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D1A1A03A7 for ; Wed, 29 Oct 2014 00:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njlIqF7EM9_i for ; Wed, 29 Oct 2014 00:19:19 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 16C781A008A for ; Wed, 29 Oct 2014 00:19:18 -0700 (PDT) Received: from rainpc ([80.183.65.186]) by smtpcmd04.ad.aruba.it with bizsmtp id 8vKA1p00P416z9401vKAYj; Wed, 29 Oct 2014 08:19:17 +0100 Date: Wed, 29 Oct 2014 08:19:10 +0100 From: Lorenzo Miniero To: Christer Holmberg Message-ID: <20141029081910.6d592960@rainpc> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4D25F2@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> <01f701cff306$cdddeb20$6999c160$@co.in> <7594FB04B1934943A5C02806D1A2204B1D4D25F2@ESESSMB209.ericsson.se> Organization: Meetecho X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/straw/LkcUt8RM5Ip-KQOn_6AozJdmbGI Cc: 'Richard Barnes' , 'Sean Turner' , "straw@ietf.org" , Parthasarathi R , 'Stephen Farrell' Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 07:19:23 -0000 On Wed, 29 Oct 2014 06:49:17 +0000 Christer Holmberg wrote: > (As co-chair) > > Hi, > > If anyone has an issue with the general approach suggested by Partha, please indicate to on the list, so that we in Honolulu can focus on the technical aspects. > I'm not convinced that we should give up on those. Media Aware and Media Termination are part of the STRAW taxonomy, and act as if they just didn't exist doesn't seem the right thing to do IMHO. In Toronto it has been made clear that there are issues and concerns about what looked like standardizing a MITM for media. My personal feeling is that this can be considered mostly a matter of trust. The B2BUA should not necessarily be a sneaky or "transparent" component as long as participants are involved. This means that, as long as I trust the B2BUA in any scenario that involves Media Aware/Terminartion stuff, and so trust the B2BUA to secure the session on the other end or not do anything I didn't sign up for, the B2BUA is actually my "peer" in that respect. Without preventing additional mechanismsto be involved for end-to-end validation of some kind, of course. Everytihng outside of that is, I agree, MITM and shouldn't be avalled or fostered in any way. These are just some thoughts I tried to give to the idea, and how I basically changed the related text in the RTCP draft as well to try and address the issue, so I guess there will be plenty of time to bash me when I talk about this in Honolulu :-) Lorenzo > Regards, > > Christer > > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 29. lokakuuta 2014 1:28 > To: 'Stephen Farrell'; Christer Holmberg; straw@ietf.org > Cc: 'Richard Barnes'; 'Sean Turner' > Subject: RE: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: Draft STRAW minutes] > > Hi all, > > One of the way to address MITM issue in STRAW WG B2BUA handling of DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of draft-ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or Media Termination" (Sec 3.2 of draft-ram-straw-b2bua-dtls-srtp-00). > > By this proposal, the scope of the work is to cover only end-to-end DTLS-SRTP through B2BUA. The media relay provides end-to-end security but there are challenges w.r.t NAT, forking, ICE, identity (RTCWeb IdP, RFC4474bis, etc.,) which shall be sorted out in this milestone. > > During IETF-90 and in the mailing alias, I haven't heard any concern for Media relay handling in B2BUA. please let me know your opinion on the same. > > Thanks > Partha > > > -----Original Message----- > > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > Sent: Wednesday, July 30, 2014 3:05 PM > > To: Parthasarathi R; 'Christer Holmberg'; straw@ietf.org > > Cc: 'Richard Barnes'; 'Sean Turner' > > Subject: Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: > > Draft STRAW minutes] > > > > > > on vacation, back in a week > > > > terminating DTLS-SRTP is maybe fine but means being one of the > > endpoints intended to be involved in the TLS session. Doing a MITM on > > TLS is not at all fine. > > > > S. > > > > On 30/07/14 02:34, Parthasarathi R wrote: > > > Hi all, > > > > > > > > > > > > I have different view than the security folks look at this draft. > > This draft > > > intention is not to violate RFC 2804. In case this draft is not > > > standardized, all B2BUA handling DTLS-SRTP will end up in violating > > RFC 2804 > > > due to the lack of guidelines/standards to follow. Please look into > > this > > > draft from SIP recording architecture in B2BUA (Fig 1 of RFC 7245) > > usage > > > perspective wherein the senders/receiver is informed about the call > > > recording (like call centre usage scenario) and no RFC 2804 > > violation. > > > > > > > > > > > > In IETF-90 meeting, the security concerns are raised about this > > > draft > > usage. > > > It will be good to document as part of this document if it is really > > > security issue. I'm not seeing any major security concerns as B2BUA > > is yet > > > another UA. Please let me know the list of security concern specific > > to > > > B2BUA in DTLS-SRTP. > > > > > > > > > > > > In reality, B2BUA terminating DTLS-SRTP is not avoidable because of > > the > > > different codec profile between the deployed SIP UAs. Say SIPoWS in > > browser > > > (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as of today > > and SIP > > > Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion to > > terminate the > > > media in the middle as there is no solution exists in IETF for the > > same. The > > > lack of standard leads to proprietary session border controller > > > (SBC) solutions which breaks other SIP enhancements as well. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer > > Holmberg > > > Sent: Saturday, July 26, 2014 7:54 PM > > > To: straw@ietf.org > > > Cc: Richard Barnes (rlb@ipv.sx); Sean Turner; Stephen Farrell > > > Subject: [straw] IETF#90: Draft STRAW minutes > > > > > > > > > > > > (Co-chair) > > > > > > > > > > > > Hi, > > > > > > > > > > > > Below are the STRAW minutes that the chairs intend to upload. > > > > > > > > > > > > However, before we do that, we would like to ask the community to > > take a > > > look at least at the notes associated with the DTLS-SRTP > > presentation, as it > > > caused lots of discussion. > > > > > > > > > > > > Note that the minutes do not contain who-said-what information (that > > can be > > > found elsewhere), but if you think there are some important things > > missing, > > > or if you think something is wrong, please let the chairs now. > > > > > > > > > > > > Thanks! > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer & Victor > > > > > > > > > > > > ------------------- > > > > > > > > > > > > IETF 90 - STRAW > > > > > > 1150-1320 EDT Friday Afternoon Session I > > > > > > > > > > > > > > > > > > Topic: Agenda bashing, IETF Note Well and WG status > > > > > > Presenter: Christer Holmberg (co-chair) > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf > > > > > > Draft: N/A > > > > > > > > > > > > > > > > > > No issues were identified. > > > > > > > > > > > > > > > > > > > > > > > > Topic: Guidelines to support RTCP in B2BUAs > > > > > > Presenter: Lorenzo Miniero > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf > > > > > > Draft: draft-ietf-straw-b2bua-rtcp > > > > > > > > > > > > > > > > > > It was indicated that XR needs to be looked into, to see whether > > something > > > needs to be covered in the draft. > > > > > > > > > > > > It was indicated that the terminology will be aligned with the > > > grouping-taxonomy draft. In case there are conflicts, or other > > > issues > > are > > > found, the STRAW community is requested to provide comments on the > > > grouping-taxonomy draft. > > > > > > > > > > > > It was requested whether the draft should also cover RTP specific > > issues. It > > > was indicated that the scope of the RTCP, and that we should be very > > careful > > > about introducing RTP issues. It was recommended to talk to Colin > > Perkins > > > whether he has any opinions regarding the need to cover RTP. > > > > > > > > > > > > I was asked how the document will relate to the work on multisource > > > optimisation taking place in AVTEXT. > > > > > > > > > > > > It was indicated that the text recommending man in the middle > > functionality > > > for SRTP most likely will cause issues with IESG. After the > > > DTLS-SRTP discussion (see further down) it was suggested that the > > > RTCP draft > > should > > > not talk about SRTP. > > > > > > > > > > > > > > > > > > > > > > > > Topic: Taxonomy Discussion > > > > > > Presenter: Lorenzo Miniero > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf > > > > > > Draft: All STRAW deliveries > > > > > > > > > > > > > > > > > > It was agreed the STRAW shall use the terms in the avtext-grouping- > > taxonomy > > > document in preference to definitions elsewhere is they are > > appropriate, > > > with a note indicating any differences in other documents that may > > influence > > > understanding. > > > > > > > > > > > > > > > > > > > > > > > > Topic: STUN handling in B2BUAs > > > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf > > > > > > Draft: draft-ram-straw-b2bua-stun > > > > > > > > > > > > > > > > > > It was indicated that B2BUA, due to policy reasons, may strip > > candidates > > > from SDP. > > > > > > > > > > > > It was indicated that B2BUAs must be very careful to not perform > > actions > > > that will cause ICE mismatch. > > > > > > > > > > > > The chair informed the community that a WG adoption request will be > > sent out > > > within the upcoming weeks. > > > > > > > > > > > > It was indicated that the group needs to follow the ICE bis work > > taking > > > place in MMUSIC, in case there will be any impacts on the STRAW > > draft. > > > > > > > > > > > > > > > > > > > > > > > > Topic: DTLS-SRTP handling in B2BUAs > > > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf > > > > > > Draft: draft-ram-straw-b2bua-dtls-srtp > > > > > > > > > > > > > > > > > > The presentation triggered lots of discussions and controversy, as > > > it > > was > > > seen as an attempt to standardize MITM (man in the middle > > procedures). While > > > people did realize such actions take place in deployments, they > > claimed that > > > IETF/STRAW should not standardize such procedures. It was also > > indicated > > > that it goes against a number of BCP specifications, and RFC 2804. > > Others > > > indicated that the purpose is to make sure that entities doing this > > kind of > > > functionality do it in a way which does not cause interoperability > > problems, > > > which could cause people to not use security to begin with. > > > > > > > > > > > > It was indicated that one possible way forward could be to simply > > document, > > > in an informal delivery, how different vendors do things in the > > network, but > > > in such case the vendors should also be listed in the document. > > > > > > > > > > > > Before the draft is adopted as a WG item, further discussions need > > > to > > take > > > place. The ADs will help with finding the correct people (security, > > IESG, > > > etc) to involve in such discussions. The chair indicated that the > > draft > > > implements a charter delivery, but that one possible outcome will be > > to > > > remove/re-scope the charter delivery. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From nobody Wed Oct 29 00:23:19 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E154C1A01AE for ; Wed, 29 Oct 2014 00:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfhkZnpU6Y5w for ; Wed, 29 Oct 2014 00:23:11 -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 3563D1A1B73 for ; Wed, 29 Oct 2014 00:23:10 -0700 (PDT) X-AuditID: c1b4fb2d-f79fc6d000001087-98-545095db6725 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 80.F0.04231.BD590545; Wed, 29 Oct 2014 08:23:07 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Wed, 29 Oct 2014 08:23:07 +0100 From: Christer Holmberg To: Lorenzo Miniero Thread-Topic: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] Thread-Index: AQHP80inXd2FhLbyXUOt/XsOzYzXPZxGq27Q Date: Wed, 29 Oct 2014 07:23:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4D27AD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> <01f701cff306$cdddeb20$6999c160$@co.in> <7594FB04B1934943A5C02806D1A2204B1D4D25F2@ESESSMB209.ericsson.se> <20141029081910.6d592960@rainpc> In-Reply-To: <20141029081910.6d592960@rainpc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM+Jvje7tqQEhBp+u2Vhs37KAyWLypz5W i6l9thbT915jt7jV/JjVYse5CSwObB5ru6+yedyZ84HVY8mSn0wekzfOYvHoeHif3ePD/C/s AWxRXDYpqTmZZalF+nYJXBmzlvSwF6xKqJj3dz9jA+Mjjy5GTg4JAROJD4camCFsMYkL99az dTFycQgJHGGU6L4/hR3CWcIo0bRwEksXIwcHm4CFRPc/bZAGEQEtiRlz5zGC1DALnGSU2Dqz gxUkISwQKbG+fQMzRFGUxK8rz1khbCOJl81n2UHmsAioSvz4pg4S5hXwlTjZOg1q8VImievr TrKDJDgFdCV65mwFm8MIdN33U2uYQGxmAXGJW0/mM0FcLSCxZM95qA9EJV4+/scKMl9CQFFi eb8cRLmOxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIps5C0jILScssJC0LGFlWMYoWpxYX 56YbGeulFmUmFxfn5+nlpZZsYgRG48Etv3V3MK5+7XiIUYCDUYmHt2BCQIgQa2JZcWXuIUZp DhYlcd5F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamA0X2PIpvlxxmsXQcngrbm35Zot Hc+t373r04pvU35dnbBWPn3ylbccl33E7nzT/cv0P+4/AzcLu+zVq+aCK08/f9vC4Lb/tTtv Zownz7eVW7Svr5hpG3qj6IE4f/3teX5vHu5TW9H2w/356+4qh831+UIywjy1fvYyEttaZzOu 19kZfFV3QmSmEktxRqKhFnNRcSIArpvC/acCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/straw/5IqjDJEh2pqi5xM1_DMUii3bkjw Cc: 'Richard Barnes' , 'Sean Turner' , "straw@ietf.org" , Parthasarathi R , 'Stephen Farrell' Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 07:23:15 -0000 (As co-chair) People are of course also welcome to (actually, encouraged to) bash on the = list, between meetings :) Regards, Christer -----Original Message----- From: Lorenzo Miniero [mailto:lorenzo@meetecho.com]=20 Sent: 29. lokakuuta 2014 9:19 To: Christer Holmberg Cc: Parthasarathi R; 'Stephen Farrell'; straw@ietf.org; 'Richard Barnes'; '= Sean Turner' Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft ST= RAW minutes] On Wed, 29 Oct 2014 06:49:17 +0000 Christer Holmberg wrote: > (As co-chair) >=20 > Hi, >=20 > If anyone has an issue with the general approach suggested by Partha, ple= ase indicate to on the list, so that we in Honolulu can focus on the techni= cal aspects. >=20 I'm not convinced that we should give up on those. Media Aware and Media Te= rmination are part of the STRAW taxonomy, and act as if they just didn't ex= ist doesn't seem the right thing to do IMHO. In Toronto it has been made clear that there are issues and concerns about = what looked like standardizing a MITM for media. My personal feeling is tha= t this can be considered mostly a matter of trust. The B2BUA should not nec= essarily be a sneaky or "transparent" component as long as participants are= involved. This means that, as long as I trust the B2BUA in any scenario th= at involves Media Aware/Terminartion stuff, and so trust the B2BUA to secur= e the session on the other end or not do anything I didn't sign up for, the= B2BUA is actually my "peer" in that respect. Without preventing additional= mechanismsto be involved for end-to-end validation of some kind, of course= . Everytihng outside of that is, I agree, MITM and shouldn't be avalled or = fostered in any way. These are just some thoughts I tried to give to the idea, and how I basical= ly changed the related text in the RTCP draft as well to try and address th= e issue, so I guess there will be plenty of time to bash me when I talk abo= ut this in Honolulu :-) Lorenzo > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: 29. lokakuuta 2014 1:28 > To: 'Stephen Farrell'; Christer Holmberg; straw@ietf.org > Cc: 'Richard Barnes'; 'Sean Turner' > Subject: RE: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90:=20 > Draft STRAW minutes] >=20 > Hi all, >=20 > One of the way to address MITM issue in STRAW WG B2BUA handling of DTLS-S= RTP milestone is to focus only on Media relay (Sec 3.1 of draft-ram-straw-b= 2bua-dtls-srtp-00) and removing "Media Aware or Media Termination" (Sec 3.2= of draft-ram-straw-b2bua-dtls-srtp-00).=20 >=20 > By this proposal, the scope of the work is to cover only end-to-end DTLS-= SRTP through B2BUA. The media relay provides end-to-end security but there = are challenges w.r.t NAT, forking, ICE, identity (RTCWeb IdP, RFC4474bis, e= tc.,) which shall be sorted out in this milestone.=20 >=20 > During IETF-90 and in the mailing alias, I haven't heard any concern for = Media relay handling in B2BUA. please let me know your opinion on the same. >=20 > Thanks > Partha >=20 > > -----Original Message----- > > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > Sent: Wednesday, July 30, 2014 3:05 PM > > To: Parthasarathi R; 'Christer Holmberg'; straw@ietf.org > > Cc: 'Richard Barnes'; 'Sean Turner' > > Subject: Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: > > Draft STRAW minutes] > >=20 > >=20 > > on vacation, back in a week > >=20 > > terminating DTLS-SRTP is maybe fine but means being one of the=20 > > endpoints intended to be involved in the TLS session. Doing a MITM=20 > > on TLS is not at all fine. > >=20 > > S. > >=20 > > On 30/07/14 02:34, Parthasarathi R wrote: > > > Hi all, > > > > > > > > > > > > I have different view than the security folks look at this draft. > > This draft > > > intention is not to violate RFC 2804. In case this draft is not=20 > > > standardized, all B2BUA handling DTLS-SRTP will end up in=20 > > > violating > > RFC 2804 > > > due to the lack of guidelines/standards to follow. Please look=20 > > > into > > this > > > draft from SIP recording architecture in B2BUA (Fig 1 of RFC 7245) > > usage > > > perspective wherein the senders/receiver is informed about the=20 > > > call recording (like call centre usage scenario) and no RFC 2804 > > violation. > > > > > > > > > > > > In IETF-90 meeting, the security concerns are raised about this=20 > > > draft > > usage. > > > It will be good to document as part of this document if it is=20 > > > really security issue. I'm not seeing any major security concerns=20 > > > as B2BUA > > is yet > > > another UA. Please let me know the list of security concern=20 > > > specific > > to > > > B2BUA in DTLS-SRTP. > > > > > > > > > > > > In reality, B2BUA terminating DTLS-SRTP is not avoidable because=20 > > > of > > the > > > different codec profile between the deployed SIP UAs. Say SIPoWS=20 > > > in > > browser > > > (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as of today > > and SIP > > > Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion to > > terminate the > > > media in the middle as there is no solution exists in IETF for the > > same. The > > > lack of standard leads to proprietary session border controller > > > (SBC) solutions which breaks other SIP enhancements as well. > > > > > > > > > > > > Thanks > > > > > > Partha > > > > > > > > > > > > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer > > Holmberg > > > Sent: Saturday, July 26, 2014 7:54 PM > > > To: straw@ietf.org > > > Cc: Richard Barnes (rlb@ipv.sx); Sean Turner; Stephen Farrell > > > Subject: [straw] IETF#90: Draft STRAW minutes > > > > > > > > > > > > (Co-chair) > > > > > > > > > > > > Hi, > > > > > > > > > > > > Below are the STRAW minutes that the chairs intend to upload. > > > > > > > > > > > > However, before we do that, we would like to ask the community to > > take a > > > look at least at the notes associated with the DTLS-SRTP > > presentation, as it > > > caused lots of discussion. > > > > > > > > > > > > Note that the minutes do not contain who-said-what information=20 > > > (that > > can be > > > found elsewhere), but if you think there are some important things > > missing, > > > or if you think something is wrong, please let the chairs now. > > > > > > > > > > > > Thanks! > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer & Victor > > > > > > > > > > > > ------------------- > > > > > > > > > > > > IETF 90 - STRAW > > > > > > 1150-1320 EDT Friday Afternoon Session I > > > > > > > > > > > > > > > > > > Topic: Agenda bashing, IETF Note Well and WG status > > > > > > Presenter: Christer Holmberg (co-chair) > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf > > > > > > Draft: N/A > > > > > > > > > > > > > > > > > > No issues were identified. > > > > > > > > > > > > > > > > > > > > > > > > Topic: Guidelines to support RTCP in B2BUAs > > > > > > Presenter: Lorenzo Miniero > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf > > > > > > Draft: draft-ietf-straw-b2bua-rtcp > > > > > > > > > > > > > > > > > > It was indicated that XR needs to be looked into, to see whether > > something > > > needs to be covered in the draft. > > > > > > > > > > > > It was indicated that the terminology will be aligned with the=20 > > > grouping-taxonomy draft. In case there are conflicts, or other=20 > > > issues > > are > > > found, the STRAW community is requested to provide comments on the=20 > > > grouping-taxonomy draft. > > > > > > > > > > > > It was requested whether the draft should also cover RTP specific > > issues. It > > > was indicated that the scope of the RTCP, and that we should be=20 > > > very > > careful > > > about introducing RTP issues. It was recommended to talk to Colin > > Perkins > > > whether he has any opinions regarding the need to cover RTP. > > > > > > > > > > > > I was asked how the document will relate to the work on=20 > > > multisource optimisation taking place in AVTEXT. > > > > > > > > > > > > It was indicated that the text recommending man in the middle > > functionality > > > for SRTP most likely will cause issues with IESG. After the=20 > > > DTLS-SRTP discussion (see further down) it was suggested that the=20 > > > RTCP draft > > should > > > not talk about SRTP. > > > > > > > > > > > > > > > > > > > > > > > > Topic: Taxonomy Discussion > > > > > > Presenter: Lorenzo Miniero > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf > > > > > > Draft: All STRAW deliveries > > > > > > > > > > > > > > > > > > It was agreed the STRAW shall use the terms in the=20 > > > avtext-grouping- > > taxonomy > > > document in preference to definitions elsewhere is they are > > appropriate, > > > with a note indicating any differences in other documents that may > > influence > > > understanding. > > > > > > > > > > > > > > > > > > > > > > > > Topic: STUN handling in B2BUAs > > > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf > > > > > > Draft: draft-ram-straw-b2bua-stun > > > > > > > > > > > > > > > > > > It was indicated that B2BUA, due to policy reasons, may strip > > candidates > > > from SDP. > > > > > > > > > > > > It was indicated that B2BUAs must be very careful to not perform > > actions > > > that will cause ICE mismatch. > > > > > > > > > > > > The chair informed the community that a WG adoption request will=20 > > > be > > sent out > > > within the upcoming weeks. > > > > > > > > > > > > It was indicated that the group needs to follow the ICE bis work > > taking > > > place in MMUSIC, in case there will be any impacts on the STRAW > > draft. > > > > > > > > > > > > > > > > > > > > > > > > Topic: DTLS-SRTP handling in B2BUAs > > > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > > > Slides: > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf > > > > > > Draft: draft-ram-straw-b2bua-dtls-srtp > > > > > > > > > > > > > > > > > > The presentation triggered lots of discussions and controversy, as=20 > > > it > > was > > > seen as an attempt to standardize MITM (man in the middle > > procedures). While > > > people did realize such actions take place in deployments, they > > claimed that > > > IETF/STRAW should not standardize such procedures. It was also > > indicated > > > that it goes against a number of BCP specifications, and RFC 2804. > > Others > > > indicated that the purpose is to make sure that entities doing=20 > > > this > > kind of > > > functionality do it in a way which does not cause interoperability > > problems, > > > which could cause people to not use security to begin with. > > > > > > > > > > > > It was indicated that one possible way forward could be to simply > > document, > > > in an informal delivery, how different vendors do things in the > > network, but > > > in such case the vendors should also be listed in the document. > > > > > > > > > > > > Before the draft is adopted as a WG item, further discussions need=20 > > > to > > take > > > place. The ADs will help with finding the correct people=20 > > > (security, > > IESG, > > > etc) to involve in such discussions. The chair indicated that the > > draft > > > implements a charter delivery, but that one possible outcome will=20 > > > be > > to > > > remove/re-scope the charter delivery. > > > > > > > > > > > > > > > > > > >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From nobody Wed Oct 29 16:51:34 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B737E1ACD64 for ; Wed, 29 Oct 2014 16:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDQINN7bVILC for ; Wed, 29 Oct 2014 16:51:06 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.21]) by ietfa.amsl.com (Postfix) with ESMTP id 598561AC3F3 for ; Wed, 29 Oct 2014 16:51:05 -0700 (PDT) Received: from userPC (unknown [122.167.248.173]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 9D328E28053; Wed, 29 Oct 2014 23:50:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1414626665; bh=yowk8h6XskacdlTRJsrs3GMIAKnEhWhkUxY0YRBKvSE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=GHwIw8IYeMzWhyK9auh2s0Iy+tFk1dkU5sG5oqtXBxQHkrbrPYh8h8ctI6+rudtlD xsbr4JC6ZbOHp1sIniPoPF1zrZjwHKVp7vdiuONxcLZHZMR3HuT200kImTvwYBjvqJ MMCMZgcS2DZkwYIex3Fsb0IWqkLpOSPK0+26+WJM= From: "Parthasarathi R" To: "'Lorenzo Miniero'" , "'Christer Holmberg'" References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> <01f701cff306$cdddeb20$6999c160$@co.in> <7594FB04B1934943A5C02806D1A2204B1D4D25F2@ESESSMB209.ericsson.se> <20141029081910.6d592960@rainpc> In-Reply-To: <20141029081910.6d592960@rainpc> Date: Thu, 30 Oct 2014 05:20:37 +0530 Message-ID: <003601cff3d3$313f1320$93bd3960$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/zSKulC3H+7819SOi3HOXT2GcG4AAh4JJg Content-Language: en-us X-CTCH-RefID: str=0001.0A020204.54517D69.0078, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: C_4847, X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/9dPXzd9d9whsHIuoHYlAZkzEW-s Cc: 'Richard Barnes' , 'Sean Turner' , straw@ietf.org, 'Stephen Farrell' Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 23:51:32 -0000 Hi Lorenzo, I'm not seeing the convincing mechanism in your proposal which overcome MITM issue except trusting B2BUA. The most complex requirement in your e-mail is that " Without preventing additional mechanismsto be involved for > end-to-end validation of some kind, of course. Could you please elaborate end-to-end validation in your mind. Thanks Partha > -----Original Message----- > From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] > Sent: Wednesday, October 29, 2014 12:49 PM > To: Christer Holmberg > Cc: Parthasarathi R; 'Stephen Farrell'; straw@ietf.org; 'Richard > Barnes'; 'Sean Turner' > Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: > Draft STRAW minutes] > > On Wed, 29 Oct 2014 06:49:17 +0000 > Christer Holmberg wrote: > > > (As co-chair) > > > > Hi, > > > > If anyone has an issue with the general approach suggested by Partha, > please indicate to on the list, so that we in Honolulu can focus on the > technical aspects. > > > > > I'm not convinced that we should give up on those. Media Aware and > Media Termination are part of the STRAW taxonomy, and act as if they > just didn't exist doesn't seem the right thing to do IMHO. > > In Toronto it has been made clear that there are issues and concerns > about what looked like standardizing a MITM for media. My personal > feeling is that this can be considered mostly a matter of trust. The > B2BUA should not necessarily be a sneaky or "transparent" component as > long as participants are involved. This means that, as long as I trust > the B2BUA in any scenario that involves Media Aware/Terminartion stuff, > and so trust the B2BUA to secure the session on the other end or not do > anything I didn't sign up for, the B2BUA is actually my "peer" in that > respect. Without preventing additional mechanismsto be involved for > end-to-end validation of some kind, of course. Everytihng outside of > that is, I agree, MITM and shouldn't be avalled or fostered in any way. > > These are just some thoughts I tried to give to the idea, and how I > basically changed the related text in the RTCP draft as well to try and > address the issue, so I guess there will be plenty of time to bash me > when I talk about this in Honolulu :-) > > Lorenzo > > > > Regards, > > > > Christer > > > > -----Original Message----- > > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > > Sent: 29. lokakuuta 2014 1:28 > > To: 'Stephen Farrell'; Christer Holmberg; straw@ietf.org > > Cc: 'Richard Barnes'; 'Sean Turner' > > Subject: RE: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: > Draft STRAW minutes] > > > > Hi all, > > > > One of the way to address MITM issue in STRAW WG B2BUA handling of > DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of draft- > ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or Media > Termination" (Sec 3.2 of draft-ram-straw-b2bua-dtls-srtp-00). > > > > By this proposal, the scope of the work is to cover only end-to-end > DTLS-SRTP through B2BUA. The media relay provides end-to-end security > but there are challenges w.r.t NAT, forking, ICE, identity (RTCWeb IdP, > RFC4474bis, etc.,) which shall be sorted out in this milestone. > > > > During IETF-90 and in the mailing alias, I haven't heard any concern > for Media relay handling in B2BUA. please let me know your opinion on > the same. > > > > Thanks > > Partha > > > > > -----Original Message----- > > > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > > Sent: Wednesday, July 30, 2014 3:05 PM > > > To: Parthasarathi R; 'Christer Holmberg'; straw@ietf.org > > > Cc: 'Richard Barnes'; 'Sean Turner' > > > Subject: Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: > > > Draft STRAW minutes] > > > > > > > > > on vacation, back in a week > > > > > > terminating DTLS-SRTP is maybe fine but means being one of the > > > endpoints intended to be involved in the TLS session. Doing a MITM > on > > > TLS is not at all fine. > > > > > > S. > > > > > > On 30/07/14 02:34, Parthasarathi R wrote: > > > > Hi all, > > > > > > > > > > > > > > > > I have different view than the security folks look at this draft. > > > This draft > > > > intention is not to violate RFC 2804. In case this draft is not > > > > standardized, all B2BUA handling DTLS-SRTP will end up in > violating > > > RFC 2804 > > > > due to the lack of guidelines/standards to follow. Please look > into > > > this > > > > draft from SIP recording architecture in B2BUA (Fig 1 of RFC > 7245) > > > usage > > > > perspective wherein the senders/receiver is informed about the > call > > > > recording (like call centre usage scenario) and no RFC 2804 > > > violation. > > > > > > > > > > > > > > > > In IETF-90 meeting, the security concerns are raised about this > > > > draft > > > usage. > > > > It will be good to document as part of this document if it is > really > > > > security issue. I'm not seeing any major security concerns as > B2BUA > > > is yet > > > > another UA. Please let me know the list of security concern > specific > > > to > > > > B2BUA in DTLS-SRTP. > > > > > > > > > > > > > > > > In reality, B2BUA terminating DTLS-SRTP is not avoidable because > of > > > the > > > > different codec profile between the deployed SIP UAs. Say SIPoWS > in > > > browser > > > > (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as of > today > > > and SIP > > > > Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion to > > > terminate the > > > > media in the middle as there is no solution exists in IETF for > the > > > same. The > > > > lack of standard leads to proprietary session border controller > > > > (SBC) solutions which breaks other SIP enhancements as well. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Partha > > > > > > > > > > > > > > > > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer > > > Holmberg > > > > Sent: Saturday, July 26, 2014 7:54 PM > > > > To: straw@ietf.org > > > > Cc: Richard Barnes (rlb@ipv.sx); Sean Turner; Stephen Farrell > > > > Subject: [straw] IETF#90: Draft STRAW minutes > > > > > > > > > > > > > > > > (Co-chair) > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > Below are the STRAW minutes that the chairs intend to upload. > > > > > > > > > > > > > > > > However, before we do that, we would like to ask the community to > > > take a > > > > look at least at the notes associated with the DTLS-SRTP > > > presentation, as it > > > > caused lots of discussion. > > > > > > > > > > > > > > > > Note that the minutes do not contain who-said-what information > (that > > > can be > > > > found elsewhere), but if you think there are some important > things > > > missing, > > > > or if you think something is wrong, please let the chairs now. > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > Christer & Victor > > > > > > > > > > > > > > > > ------------------- > > > > > > > > > > > > > > > > IETF 90 - STRAW > > > > > > > > 1150-1320 EDT Friday Afternoon Session I > > > > > > > > > > > > > > > > > > > > > > > > Topic: Agenda bashing, IETF Note Well and WG status > > > > > > > > Presenter: Christer Holmberg (co-chair) > > > > > > > > Slides: > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf > > > > > > > > Draft: N/A > > > > > > > > > > > > > > > > > > > > > > > > No issues were identified. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Topic: Guidelines to support RTCP in B2BUAs > > > > > > > > Presenter: Lorenzo Miniero > > > > > > > > Slides: > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf > > > > > > > > Draft: draft-ietf-straw-b2bua-rtcp > > > > > > > > > > > > > > > > > > > > > > > > It was indicated that XR needs to be looked into, to see whether > > > something > > > > needs to be covered in the draft. > > > > > > > > > > > > > > > > It was indicated that the terminology will be aligned with the > > > > grouping-taxonomy draft. In case there are conflicts, or other > > > > issues > > > are > > > > found, the STRAW community is requested to provide comments on > the > > > > grouping-taxonomy draft. > > > > > > > > > > > > > > > > It was requested whether the draft should also cover RTP specific > > > issues. It > > > > was indicated that the scope of the RTCP, and that we should be > very > > > careful > > > > about introducing RTP issues. It was recommended to talk to Colin > > > Perkins > > > > whether he has any opinions regarding the need to cover RTP. > > > > > > > > > > > > > > > > I was asked how the document will relate to the work on > multisource > > > > optimisation taking place in AVTEXT. > > > > > > > > > > > > > > > > It was indicated that the text recommending man in the middle > > > functionality > > > > for SRTP most likely will cause issues with IESG. After the > > > > DTLS-SRTP discussion (see further down) it was suggested that the > > > > RTCP draft > > > should > > > > not talk about SRTP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Topic: Taxonomy Discussion > > > > > > > > Presenter: Lorenzo Miniero > > > > > > > > Slides: > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf > > > > > > > > Draft: All STRAW deliveries > > > > > > > > > > > > > > > > > > > > > > > > It was agreed the STRAW shall use the terms in the avtext- > grouping- > > > taxonomy > > > > document in preference to definitions elsewhere is they are > > > appropriate, > > > > with a note indicating any differences in other documents that > may > > > influence > > > > understanding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Topic: STUN handling in B2BUAs > > > > > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > > > > > Slides: > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf > > > > > > > > Draft: draft-ram-straw-b2bua-stun > > > > > > > > > > > > > > > > > > > > > > > > It was indicated that B2BUA, due to policy reasons, may strip > > > candidates > > > > from SDP. > > > > > > > > > > > > > > > > It was indicated that B2BUAs must be very careful to not perform > > > actions > > > > that will cause ICE mismatch. > > > > > > > > > > > > > > > > The chair informed the community that a WG adoption request will > be > > > sent out > > > > within the upcoming weeks. > > > > > > > > > > > > > > > > It was indicated that the group needs to follow the ICE bis work > > > taking > > > > place in MMUSIC, in case there will be any impacts on the STRAW > > > draft. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Topic: DTLS-SRTP handling in B2BUAs > > > > > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > > > > > Slides: > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf > > > > > > > > Draft: draft-ram-straw-b2bua-dtls-srtp > > > > > > > > > > > > > > > > > > > > > > > > The presentation triggered lots of discussions and controversy, > as > > > > it > > > was > > > > seen as an attempt to standardize MITM (man in the middle > > > procedures). While > > > > people did realize such actions take place in deployments, they > > > claimed that > > > > IETF/STRAW should not standardize such procedures. It was also > > > indicated > > > > that it goes against a number of BCP specifications, and RFC > 2804. > > > Others > > > > indicated that the purpose is to make sure that entities doing > this > > > kind of > > > > functionality do it in a way which does not cause > interoperability > > > problems, > > > > which could cause people to not use security to begin with. > > > > > > > > > > > > > > > > It was indicated that one possible way forward could be to simply > > > document, > > > > in an informal delivery, how different vendors do things in the > > > network, but > > > > in such case the vendors should also be listed in the document. > > > > > > > > > > > > > > > > Before the draft is adopted as a WG item, further discussions > need > > > > to > > > take > > > > place. The ADs will help with finding the correct people > (security, > > > IESG, > > > > etc) to involve in such discussions. The chair indicated that the > > > draft > > > > implements a charter delivery, but that one possible outcome will > be > > > to > > > > remove/re-scope the charter delivery. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > straw mailing list > > straw@ietf.org > > https://www.ietf.org/mailman/listinfo/straw > > > -- > Lorenzo Miniero, COB > > Meetecho s.r.l. > Web Conferencing and Collaboration Tools > http://www.meetecho.com From nobody Thu Oct 30 00:07:32 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C38B1AD031 for ; Thu, 30 Oct 2014 00:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_52=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIYPj2AnAHO1 for ; Thu, 30 Oct 2014 00:07:22 -0700 (PDT) Received: from smtpcmd01217.aruba.it (smtpcmd01217.aruba.it [62.149.158.217]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0E51AD029 for ; Thu, 30 Oct 2014 00:07:21 -0700 (PDT) Received: from rainpc ([79.13.23.133]) by smtpcmd01.ad.aruba.it with bizsmtp id 9K7D1p00M2sHQaP01K7DGi; Thu, 30 Oct 2014 08:07:20 +0100 Date: Thu, 30 Oct 2014 08:07:12 +0100 From: Lorenzo Miniero To: "Parthasarathi R" Message-ID: <20141030080712.28c98ca9@rainpc> In-Reply-To: <003601cff3d3$313f1320$93bd3960$@co.in> References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> <01f701cff306$cdddeb20$6999c160$@co.in> <7594FB04B1934943A5C02806D1A2204B1D4D25F2@ESESSMB209.ericsson.se> <20141029081910.6d592960@rainpc> <003601cff3d3$313f1320$93bd3960$@co.in> Organization: Meetecho X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/straw/G13EWCEb-471PN5dwF0XSz1Dfn0 Cc: 'Richard Barnes' , 'Sean Turner' , 'Stephen Farrell' , straw@ietf.org, 'Christer Holmberg' Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 07:07:27 -0000 On Thu, 30 Oct 2014 05:20:37 +0530 "Parthasarathi R" wrote: > Hi Lorenzo, > > I'm not seeing the convincing mechanism in your proposal which overcome MITM > issue except trusting B2BUA. The most complex requirement in your e-mail is > that > > > " Without preventing additional mechanismsto be involved for > > end-to-end validation of some kind, of course. > > > Could you please elaborate end-to-end validation in your mind. > Hi Partha, sorry, I should have been clearer about an aspect. I agree it's still MITM: when I said "everything else's MITM" I actually meant "everything else is not any different from a MITM attack", and that's why I believe the trust is an important aspect. About the additional mechanism, I don't have any specific solution in mind. It's my understanding, though, that the IETF community has understood there's a problem to solve there, and is already trying to address it somehow, which is why I continue to believe we shouldn't give up on it either. For insta,ce, I do recall a presentation at the AVTCORE session in Toronto which tried to address a similar concern: http://www.ietf.org/proceedings/90/slides/slides-90-avtcore-6.pdf The presentation was called "Requirements for Secure RTP Media Switching", which should at least allow for a more proper management of media-aware as well, for instance. I believe there are use cases that justify both media-aware and media-termination in secure scenarios, and ignoring them will result in the same unpredictable consequences that lead to WGs like BLISS or STRAW itself: without some guide from IETF documents, developers will either drop security entirely (something we obviously don't want) or start doing things one way or another to make it work. Lorenzo > Thanks > Partha > > > -----Original Message----- > > From: Lorenzo Miniero [mailto:lorenzo@meetecho.com] > > Sent: Wednesday, October 29, 2014 12:49 PM > > To: Christer Holmberg > > Cc: Parthasarathi R; 'Stephen Farrell'; straw@ietf.org; 'Richard > > Barnes'; 'Sean Turner' > > Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: > > Draft STRAW minutes] > > > > On Wed, 29 Oct 2014 06:49:17 +0000 > > Christer Holmberg wrote: > > > > > (As co-chair) > > > > > > Hi, > > > > > > If anyone has an issue with the general approach suggested by Partha, > > please indicate to on the list, so that we in Honolulu can focus on the > > technical aspects. > > > > > > > > > I'm not convinced that we should give up on those. Media Aware and > > Media Termination are part of the STRAW taxonomy, and act as if they > > just didn't exist doesn't seem the right thing to do IMHO. > > > > In Toronto it has been made clear that there are issues and concerns > > about what looked like standardizing a MITM for media. My personal > > feeling is that this can be considered mostly a matter of trust. The > > B2BUA should not necessarily be a sneaky or "transparent" component as > > long as participants are involved. This means that, as long as I trust > > the B2BUA in any scenario that involves Media Aware/Terminartion stuff, > > and so trust the B2BUA to secure the session on the other end or not do > > anything I didn't sign up for, the B2BUA is actually my "peer" in that > > respect. Without preventing additional mechanismsto be involved for > > end-to-end validation of some kind, of course. Everytihng outside of > > that is, I agree, MITM and shouldn't be avalled or fostered in any way. > > > > These are just some thoughts I tried to give to the idea, and how I > > basically changed the related text in the RTCP draft as well to try and > > address the issue, so I guess there will be plenty of time to bash me > > when I talk about this in Honolulu :-) > > > > Lorenzo > > > > > > > Regards, > > > > > > Christer > > > > > > -----Original Message----- > > > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > > > Sent: 29. lokakuuta 2014 1:28 > > > To: 'Stephen Farrell'; Christer Holmberg; straw@ietf.org > > > Cc: 'Richard Barnes'; 'Sean Turner' > > > Subject: RE: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: > > Draft STRAW minutes] > > > > > > Hi all, > > > > > > One of the way to address MITM issue in STRAW WG B2BUA handling of > > DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of draft- > > ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or Media > > Termination" (Sec 3.2 of draft-ram-straw-b2bua-dtls-srtp-00). > > > > > > By this proposal, the scope of the work is to cover only end-to-end > > DTLS-SRTP through B2BUA. The media relay provides end-to-end security > > but there are challenges w.r.t NAT, forking, ICE, identity (RTCWeb IdP, > > RFC4474bis, etc.,) which shall be sorted out in this milestone. > > > > > > During IETF-90 and in the mailing alias, I haven't heard any concern > > for Media relay handling in B2BUA. please let me know your opinion on > > the same. > > > > > > Thanks > > > Partha > > > > > > > -----Original Message----- > > > > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > > > Sent: Wednesday, July 30, 2014 3:05 PM > > > > To: Parthasarathi R; 'Christer Holmberg'; straw@ietf.org > > > > Cc: 'Richard Barnes'; 'Sean Turner' > > > > Subject: Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: > > > > Draft STRAW minutes] > > > > > > > > > > > > on vacation, back in a week > > > > > > > > terminating DTLS-SRTP is maybe fine but means being one of the > > > > endpoints intended to be involved in the TLS session. Doing a MITM > > on > > > > TLS is not at all fine. > > > > > > > > S. > > > > > > > > On 30/07/14 02:34, Parthasarathi R wrote: > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > I have different view than the security folks look at this draft. > > > > This draft > > > > > intention is not to violate RFC 2804. In case this draft is not > > > > > standardized, all B2BUA handling DTLS-SRTP will end up in > > violating > > > > RFC 2804 > > > > > due to the lack of guidelines/standards to follow. Please look > > into > > > > this > > > > > draft from SIP recording architecture in B2BUA (Fig 1 of RFC > > 7245) > > > > usage > > > > > perspective wherein the senders/receiver is informed about the > > call > > > > > recording (like call centre usage scenario) and no RFC 2804 > > > > violation. > > > > > > > > > > > > > > > > > > > > In IETF-90 meeting, the security concerns are raised about this > > > > > draft > > > > usage. > > > > > It will be good to document as part of this document if it is > > really > > > > > security issue. I'm not seeing any major security concerns as > > B2BUA > > > > is yet > > > > > another UA. Please let me know the list of security concern > > specific > > > > to > > > > > B2BUA in DTLS-SRTP. > > > > > > > > > > > > > > > > > > > > In reality, B2BUA terminating DTLS-SRTP is not avoidable because > > of > > > > the > > > > > different codec profile between the deployed SIP UAs. Say SIPoWS > > in > > > > browser > > > > > (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as of > > today > > > > and SIP > > > > > Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion to > > > > terminate the > > > > > media in the middle as there is no solution exists in IETF for > > the > > > > same. The > > > > > lack of standard leads to proprietary session border controller > > > > > (SBC) solutions which breaks other SIP enhancements as well. > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Partha > > > > > > > > > > > > > > > > > > > > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer > > > > Holmberg > > > > > Sent: Saturday, July 26, 2014 7:54 PM > > > > > To: straw@ietf.org > > > > > Cc: Richard Barnes (rlb@ipv.sx); Sean Turner; Stephen Farrell > > > > > Subject: [straw] IETF#90: Draft STRAW minutes > > > > > > > > > > > > > > > > > > > > (Co-chair) > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Below are the STRAW minutes that the chairs intend to upload. > > > > > > > > > > > > > > > > > > > > However, before we do that, we would like to ask the community to > > > > take a > > > > > look at least at the notes associated with the DTLS-SRTP > > > > presentation, as it > > > > > caused lots of discussion. > > > > > > > > > > > > > > > > > > > > Note that the minutes do not contain who-said-what information > > (that > > > > can be > > > > > found elsewhere), but if you think there are some important > > things > > > > missing, > > > > > or if you think something is wrong, please let the chairs now. > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > Christer & Victor > > > > > > > > > > > > > > > > > > > > ------------------- > > > > > > > > > > > > > > > > > > > > IETF 90 - STRAW > > > > > > > > > > 1150-1320 EDT Friday Afternoon Session I > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Topic: Agenda bashing, IETF Note Well and WG status > > > > > > > > > > Presenter: Christer Holmberg (co-chair) > > > > > > > > > > Slides: > > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf > > > > > > > > > > Draft: N/A > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > No issues were identified. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Topic: Guidelines to support RTCP in B2BUAs > > > > > > > > > > Presenter: Lorenzo Miniero > > > > > > > > > > Slides: > > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf > > > > > > > > > > Draft: draft-ietf-straw-b2bua-rtcp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It was indicated that XR needs to be looked into, to see whether > > > > something > > > > > needs to be covered in the draft. > > > > > > > > > > > > > > > > > > > > It was indicated that the terminology will be aligned with the > > > > > grouping-taxonomy draft. In case there are conflicts, or other > > > > > issues > > > > are > > > > > found, the STRAW community is requested to provide comments on > > the > > > > > grouping-taxonomy draft. > > > > > > > > > > > > > > > > > > > > It was requested whether the draft should also cover RTP specific > > > > issues. It > > > > > was indicated that the scope of the RTCP, and that we should be > > very > > > > careful > > > > > about introducing RTP issues. It was recommended to talk to Colin > > > > Perkins > > > > > whether he has any opinions regarding the need to cover RTP. > > > > > > > > > > > > > > > > > > > > I was asked how the document will relate to the work on > > multisource > > > > > optimisation taking place in AVTEXT. > > > > > > > > > > > > > > > > > > > > It was indicated that the text recommending man in the middle > > > > functionality > > > > > for SRTP most likely will cause issues with IESG. After the > > > > > DTLS-SRTP discussion (see further down) it was suggested that the > > > > > RTCP draft > > > > should > > > > > not talk about SRTP. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Topic: Taxonomy Discussion > > > > > > > > > > Presenter: Lorenzo Miniero > > > > > > > > > > Slides: > > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf > > > > > > > > > > Draft: All STRAW deliveries > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It was agreed the STRAW shall use the terms in the avtext- > > grouping- > > > > taxonomy > > > > > document in preference to definitions elsewhere is they are > > > > appropriate, > > > > > with a note indicating any differences in other documents that > > may > > > > influence > > > > > understanding. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Topic: STUN handling in B2BUAs > > > > > > > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > > > > > > > Slides: > > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf > > > > > > > > > > Draft: draft-ram-straw-b2bua-stun > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It was indicated that B2BUA, due to policy reasons, may strip > > > > candidates > > > > > from SDP. > > > > > > > > > > > > > > > > > > > > It was indicated that B2BUAs must be very careful to not perform > > > > actions > > > > > that will cause ICE mismatch. > > > > > > > > > > > > > > > > > > > > The chair informed the community that a WG adoption request will > > be > > > > sent out > > > > > within the upcoming weeks. > > > > > > > > > > > > > > > > > > > > It was indicated that the group needs to follow the ICE bis work > > > > taking > > > > > place in MMUSIC, in case there will be any impacts on the STRAW > > > > draft. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Topic: DTLS-SRTP handling in B2BUAs > > > > > > > > > > Presenter: Lorenzo Miniero (on behalf of the draft authors) > > > > > > > > > > Slides: > > > > > http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf > > > > > > > > > > Draft: draft-ram-straw-b2bua-dtls-srtp > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The presentation triggered lots of discussions and controversy, > > as > > > > > it > > > > was > > > > > seen as an attempt to standardize MITM (man in the middle > > > > procedures). While > > > > > people did realize such actions take place in deployments, they > > > > claimed that > > > > > IETF/STRAW should not standardize such procedures. It was also > > > > indicated > > > > > that it goes against a number of BCP specifications, and RFC > > 2804. > > > > Others > > > > > indicated that the purpose is to make sure that entities doing > > this > > > > kind of > > > > > functionality do it in a way which does not cause > > interoperability > > > > problems, > > > > > which could cause people to not use security to begin with. > > > > > > > > > > > > > > > > > > > > It was indicated that one possible way forward could be to simply > > > > document, > > > > > in an informal delivery, how different vendors do things in the > > > > network, but > > > > > in such case the vendors should also be listed in the document. > > > > > > > > > > > > > > > > > > > > Before the draft is adopted as a WG item, further discussions > > need > > > > > to > > > > take > > > > > place. The ADs will help with finding the correct people > > (security, > > > > IESG, > > > > > etc) to involve in such discussions. The chair indicated that the > > > > draft > > > > > implements a charter delivery, but that one possible outcome will > > be > > > > to > > > > > remove/re-scope the charter delivery. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > straw mailing list > > > straw@ietf.org > > > https://www.ietf.org/mailman/listinfo/straw > > > > > > -- > > Lorenzo Miniero, COB > > > > Meetecho s.r.l. > > Web Conferencing and Collaboration Tools > > http://www.meetecho.com > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com From nobody Thu Oct 30 03:56:31 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244741AD0B1 for ; Thu, 30 Oct 2014 03:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_52=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRoIiPUJgiJZ for ; Thu, 30 Oct 2014 03:56:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD9A1AD05F for ; Thu, 30 Oct 2014 03:56:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0A181BE39; Thu, 30 Oct 2014 10:56:22 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOMLPfJGYg1w; Thu, 30 Oct 2014 10:56:18 +0000 (GMT) Received: from [10.87.48.12] (unknown [86.46.30.148]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8AD5BBE14; Thu, 30 Oct 2014 10:56:18 +0000 (GMT) Message-ID: <54521952.3060105@cs.tcd.ie> Date: Thu, 30 Oct 2014 10:56:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Lorenzo Miniero , Parthasarathi R References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> <01f701cff306$cdddeb20$6999c160$@co.in> <7594FB04B1934943A5C02806D1A2204B1D4D25F2@ESESSMB209.ericsson.se> <20141029081910.6d592960@rainpc> <003601cff3d3$313f1320$93bd3960$@co.in> <20141030080712.28c98ca9@rainpc> In-Reply-To: <20141030080712.28c98ca9@rainpc> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/straw/JXFiXlxcsOgE3EXJwsF7UtVzZs8 Cc: 'Richard Barnes' , 'Sean Turner' , straw@ietf.org, 'Christer Holmberg' Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 10:56:30 -0000 On 30/10/14 07:07, Lorenzo Miniero wrote: > On Thu, 30 Oct 2014 05:20:37 +0530 "Parthasarathi R" > wrote: > >> Hi Lorenzo, >> >> I'm not seeing the convincing mechanism in your proposal which >> overcome MITM issue except trusting B2BUA. The most complex >> requirement in your e-mail is that >> >> " Without preventing additional mechanismsto be involved >> for >>> end-to-end validation of some kind, of course. >> >> >> Could you please elaborate end-to-end validation in your mind. >> > > > Hi Partha, > > sorry, I should have been clearer about an aspect. I agree it's still > MITM: when I said "everything else's MITM" I actually meant > "everything else is not any different from a MITM attack", and that's > why I believe the trust is an important aspect. And the IETF has also decided a number of times to not MITM TLS. The impact of making that mistake would be huge and none of the proponents of the various MITM schemes have ever evaluated that impact as part of their proposal. That, and the fact that changing from a two-part to a multi-party security protocol is very very hard are among the reasons that all such proposals so far have been DOA. Gratuitously throwing the misplaced word "trust" into such a discussion does not help. S. > > About the additional mechanism, I don't have any specific solution in > mind. It's my understanding, though, that the IETF community has > understood there's a problem to solve there, and is already trying to > address it somehow, which is why I continue to believe we shouldn't > give up on it either. For insta,ce, I do recall a presentation at the > AVTCORE session in Toronto which tried to address a similar concern: > > http://www.ietf.org/proceedings/90/slides/slides-90-avtcore-6.pdf > > The presentation was called "Requirements for Secure RTP Media > Switching", which should at least allow for a more proper management > of media-aware as well, for instance. I believe there are use cases > that justify both media-aware and media-termination in secure > scenarios, and ignoring them will result in the same unpredictable > consequences that lead to WGs like BLISS or STRAW itself: without > some guide from IETF documents, developers will either drop security > entirely (something we obviously don't want) or start doing things > one way or another to make it work. > > Lorenzo > > >> Thanks Partha >> >>> -----Original Message----- From: Lorenzo Miniero >>> [mailto:lorenzo@meetecho.com] Sent: Wednesday, October 29, 2014 >>> 12:49 PM To: Christer Holmberg Cc: Parthasarathi R; 'Stephen >>> Farrell'; straw@ietf.org; 'Richard Barnes'; 'Sean Turner' >>> Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: >>> IETF#90: Draft STRAW minutes] >>> >>> On Wed, 29 Oct 2014 06:49:17 +0000 Christer Holmberg >>> wrote: >>> >>>> (As co-chair) >>>> >>>> Hi, >>>> >>>> If anyone has an issue with the general approach suggested by >>>> Partha, >>> please indicate to on the list, so that we in Honolulu can focus >>> on the technical aspects. >>>> >>> >>> >>> I'm not convinced that we should give up on those. Media Aware >>> and Media Termination are part of the STRAW taxonomy, and act as >>> if they just didn't exist doesn't seem the right thing to do >>> IMHO. >>> >>> In Toronto it has been made clear that there are issues and >>> concerns about what looked like standardizing a MITM for media. >>> My personal feeling is that this can be considered mostly a >>> matter of trust. The B2BUA should not necessarily be a sneaky or >>> "transparent" component as long as participants are involved. >>> This means that, as long as I trust the B2BUA in any scenario >>> that involves Media Aware/Terminartion stuff, and so trust the >>> B2BUA to secure the session on the other end or not do anything I >>> didn't sign up for, the B2BUA is actually my "peer" in that >>> respect. Without preventing additional mechanismsto be involved >>> for end-to-end validation of some kind, of course. Everytihng >>> outside of that is, I agree, MITM and shouldn't be avalled or >>> fostered in any way. >>> >>> These are just some thoughts I tried to give to the idea, and how >>> I basically changed the related text in the RTCP draft as well to >>> try and address the issue, so I guess there will be plenty of >>> time to bash me when I talk about this in Honolulu :-) >>> >>> Lorenzo >>> >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- From: Parthasarathi R >>>> [mailto:partha@parthasarathi.co.in] Sent: 29. lokakuuta 2014 >>>> 1:28 To: 'Stephen Farrell'; Christer Holmberg; straw@ietf.org >>>> Cc: 'Richard Barnes'; 'Sean Turner' Subject: RE: B2BUA handling >>>> in DTLS-SRTP [was RE: [straw] IETF#90: >>> Draft STRAW minutes] >>>> >>>> Hi all, >>>> >>>> One of the way to address MITM issue in STRAW WG B2BUA handling >>>> of >>> DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of >>> draft- ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or >>> Media Termination" (Sec 3.2 of >>> draft-ram-straw-b2bua-dtls-srtp-00). >>>> >>>> By this proposal, the scope of the work is to cover only >>>> end-to-end >>> DTLS-SRTP through B2BUA. The media relay provides end-to-end >>> security but there are challenges w.r.t NAT, forking, ICE, >>> identity (RTCWeb IdP, RFC4474bis, etc.,) which shall be sorted >>> out in this milestone. >>>> >>>> During IETF-90 and in the mailing alias, I haven't heard any >>>> concern >>> for Media relay handling in B2BUA. please let me know your >>> opinion on the same. >>>> >>>> Thanks Partha >>>> >>>>> -----Original Message----- From: Stephen Farrell >>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, July 30, >>>>> 2014 3:05 PM To: Parthasarathi R; 'Christer Holmberg'; >>>>> straw@ietf.org Cc: 'Richard Barnes'; 'Sean Turner' Subject: >>>>> Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: >>>>> Draft STRAW minutes] >>>>> >>>>> >>>>> on vacation, back in a week >>>>> >>>>> terminating DTLS-SRTP is maybe fine but means being one of >>>>> the endpoints intended to be involved in the TLS session. >>>>> Doing a MITM >>> on >>>>> TLS is not at all fine. >>>>> >>>>> S. >>>>> >>>>> On 30/07/14 02:34, Parthasarathi R wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> >>>>>> I have different view than the security folks look at this >>>>>> draft. >>>>> This draft >>>>>> intention is not to violate RFC 2804. In case this draft is >>>>>> not standardized, all B2BUA handling DTLS-SRTP will end up >>>>>> in >>> violating >>>>> RFC 2804 >>>>>> due to the lack of guidelines/standards to follow. Please >>>>>> look >>> into >>>>> this >>>>>> draft from SIP recording architecture in B2BUA (Fig 1 of >>>>>> RFC >>> 7245) >>>>> usage >>>>>> perspective wherein the senders/receiver is informed about >>>>>> the >>> call >>>>>> recording (like call centre usage scenario) and no RFC >>>>>> 2804 >>>>> violation. >>>>>> >>>>>> >>>>>> >>>>>> In IETF-90 meeting, the security concerns are raised about >>>>>> this draft >>>>> usage. >>>>>> It will be good to document as part of this document if it >>>>>> is >>> really >>>>>> security issue. I'm not seeing any major security concerns >>>>>> as >>> B2BUA >>>>> is yet >>>>>> another UA. Please let me know the list of security >>>>>> concern >>> specific >>>>> to >>>>>> B2BUA in DTLS-SRTP. >>>>>> >>>>>> >>>>>> >>>>>> In reality, B2BUA terminating DTLS-SRTP is not avoidable >>>>>> because >>> of >>>>> the >>>>>> different codec profile between the deployed SIP UAs. Say >>>>>> SIPoWS >>> in >>>>> browser >>>>>> (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as >>>>>> of >>> today >>>>> and SIP >>>>>> Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion >>>>>> to >>>>> terminate the >>>>>> media in the middle as there is no solution exists in IETF >>>>>> for >>> the >>>>> same. The >>>>>> lack of standard leads to proprietary session border >>>>>> controller (SBC) solutions which breaks other SIP >>>>>> enhancements as well. >>>>>> >>>>>> >>>>>> >>>>>> Thanks >>>>>> >>>>>> Partha >>>>>> >>>>>> >>>>>> >>>>>> From: straw [mailto:straw-bounces@ietf.org] On Behalf Of >>>>>> Christer >>>>> Holmberg >>>>>> Sent: Saturday, July 26, 2014 7:54 PM To: straw@ietf.org >>>>>> Cc: Richard Barnes (rlb@ipv.sx); Sean Turner; Stephen >>>>>> Farrell Subject: [straw] IETF#90: Draft STRAW minutes >>>>>> >>>>>> >>>>>> >>>>>> (Co-chair) >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>> >>>>>> Below are the STRAW minutes that the chairs intend to >>>>>> upload. >>>>>> >>>>>> >>>>>> >>>>>> However, before we do that, we would like to ask the >>>>>> community to >>>>> take a >>>>>> look at least at the notes associated with the DTLS-SRTP >>>>> presentation, as it >>>>>> caused lots of discussion. >>>>>> >>>>>> >>>>>> >>>>>> Note that the minutes do not contain who-said-what >>>>>> information >>> (that >>>>> can be >>>>>> found elsewhere), but if you think there are some >>>>>> important >>> things >>>>> missing, >>>>>> or if you think something is wrong, please let the chairs >>>>>> now. >>>>>> >>>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> >>>>>> >>>>>> Christer & Victor >>>>>> >>>>>> >>>>>> >>>>>> ------------------- >>>>>> >>>>>> >>>>>> >>>>>> IETF 90 - STRAW >>>>>> >>>>>> 1150-1320 EDT Friday Afternoon Session I >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Topic: Agenda bashing, IETF Note Well and WG status >>>>>> >>>>>> Presenter: Christer Holmberg (co-chair) >>>>>> >>>>>> Slides: >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf >>>>>> >>>>>> >>>>>> Draft: N/A >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> No issues were identified. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Topic: Guidelines to support RTCP in B2BUAs >>>>>> >>>>>> Presenter: Lorenzo Miniero >>>>>> >>>>>> Slides: >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf >>>>>> >>>>>> >>>>>> Draft: draft-ietf-straw-b2bua-rtcp >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It was indicated that XR needs to be looked into, to see >>>>>> whether >>>>> something >>>>>> needs to be covered in the draft. >>>>>> >>>>>> >>>>>> >>>>>> It was indicated that the terminology will be aligned with >>>>>> the grouping-taxonomy draft. In case there are conflicts, >>>>>> or other issues >>>>> are >>>>>> found, the STRAW community is requested to provide comments >>>>>> on >>> the >>>>>> grouping-taxonomy draft. >>>>>> >>>>>> >>>>>> >>>>>> It was requested whether the draft should also cover RTP >>>>>> specific >>>>> issues. It >>>>>> was indicated that the scope of the RTCP, and that we >>>>>> should be >>> very >>>>> careful >>>>>> about introducing RTP issues. It was recommended to talk to >>>>>> Colin >>>>> Perkins >>>>>> whether he has any opinions regarding the need to cover >>>>>> RTP. >>>>>> >>>>>> >>>>>> >>>>>> I was asked how the document will relate to the work on >>> multisource >>>>>> optimisation taking place in AVTEXT. >>>>>> >>>>>> >>>>>> >>>>>> It was indicated that the text recommending man in the >>>>>> middle >>>>> functionality >>>>>> for SRTP most likely will cause issues with IESG. After >>>>>> the DTLS-SRTP discussion (see further down) it was >>>>>> suggested that the RTCP draft >>>>> should >>>>>> not talk about SRTP. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Topic: Taxonomy Discussion >>>>>> >>>>>> Presenter: Lorenzo Miniero >>>>>> >>>>>> Slides: >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf >>>>>> >>>>>> >>>>>> Draft: All STRAW deliveries >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It was agreed the STRAW shall use the terms in the avtext- >>> grouping- >>>>> taxonomy >>>>>> document in preference to definitions elsewhere is they >>>>>> are >>>>> appropriate, >>>>>> with a note indicating any differences in other documents >>>>>> that >>> may >>>>> influence >>>>>> understanding. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Topic: STUN handling in B2BUAs >>>>>> >>>>>> Presenter: Lorenzo Miniero (on behalf of the draft >>>>>> authors) >>>>>> >>>>>> Slides: >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf >>>>>> >>>>>> >>>>>> Draft: draft-ram-straw-b2bua-stun >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It was indicated that B2BUA, due to policy reasons, may >>>>>> strip >>>>> candidates >>>>>> from SDP. >>>>>> >>>>>> >>>>>> >>>>>> It was indicated that B2BUAs must be very careful to not >>>>>> perform >>>>> actions >>>>>> that will cause ICE mismatch. >>>>>> >>>>>> >>>>>> >>>>>> The chair informed the community that a WG adoption request >>>>>> will >>> be >>>>> sent out >>>>>> within the upcoming weeks. >>>>>> >>>>>> >>>>>> >>>>>> It was indicated that the group needs to follow the ICE bis >>>>>> work >>>>> taking >>>>>> place in MMUSIC, in case there will be any impacts on the >>>>>> STRAW >>>>> draft. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Topic: DTLS-SRTP handling in B2BUAs >>>>>> >>>>>> Presenter: Lorenzo Miniero (on behalf of the draft >>>>>> authors) >>>>>> >>>>>> Slides: >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf >>>>>> >>>>>> >>>>>> Draft: draft-ram-straw-b2bua-dtls-srtp >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The presentation triggered lots of discussions and >>>>>> controversy, >>> as >>>>>> it >>>>> was >>>>>> seen as an attempt to standardize MITM (man in the middle >>>>> procedures). While >>>>>> people did realize such actions take place in deployments, >>>>>> they >>>>> claimed that >>>>>> IETF/STRAW should not standardize such procedures. It was >>>>>> also >>>>> indicated >>>>>> that it goes against a number of BCP specifications, and >>>>>> RFC >>> 2804. >>>>> Others >>>>>> indicated that the purpose is to make sure that entities >>>>>> doing >>> this >>>>> kind of >>>>>> functionality do it in a way which does not cause >>> interoperability >>>>> problems, >>>>>> which could cause people to not use security to begin >>>>>> with. >>>>>> >>>>>> >>>>>> >>>>>> It was indicated that one possible way forward could be to >>>>>> simply >>>>> document, >>>>>> in an informal delivery, how different vendors do things in >>>>>> the >>>>> network, but >>>>>> in such case the vendors should also be listed in the >>>>>> document. >>>>>> >>>>>> >>>>>> >>>>>> Before the draft is adopted as a WG item, further >>>>>> discussions >>> need >>>>>> to >>>>> take >>>>>> place. The ADs will help with finding the correct people >>> (security, >>>>> IESG, >>>>>> etc) to involve in such discussions. The chair indicated >>>>>> that the >>>>> draft >>>>>> implements a charter delivery, but that one possible >>>>>> outcome will >>> be >>>>> to >>>>>> remove/re-scope the charter delivery. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> _______________________________________________ straw mailing >>>> list straw@ietf.org >>>> https://www.ietf.org/mailman/listinfo/straw >>> >>> >>> -- Lorenzo Miniero, COB >>> >>> Meetecho s.r.l. Web Conferencing and Collaboration Tools >>> http://www.meetecho.com >> >> _______________________________________________ straw mailing list >> straw@ietf.org https://www.ietf.org/mailman/listinfo/straw > > From nobody Thu Oct 30 12:25:44 2014 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615631A1B84 for ; Thu, 30 Oct 2014 12:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.58 X-Spam-Level: X-Spam-Status: No, score=0.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RItdWLbMwOei for ; Thu, 30 Oct 2014 12:25:38 -0700 (PDT) Received: from smtpdg12.aruba.it (smtpdg228.aruba.it [62.149.158.228]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF8A1A1B81 for ; Thu, 30 Oct 2014 12:25:37 -0700 (PDT) Received: from rainpc ([79.13.23.133]) by smtpcmd04.ad.aruba.it with bizsmtp id 9XRV1p00G2sHQaP01XRVkX; Thu, 30 Oct 2014 20:25:35 +0100 Date: Thu, 30 Oct 2014 20:25:28 +0100 From: Lorenzo Miniero To: Stephen Farrell Message-ID: <20141030202528.562a959b@rainpc> In-Reply-To: <54521952.3060105@cs.tcd.ie> References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> <01f701cff306$cdddeb20$6999c160$@co.in> <7594FB04B1934943A5C02806D1A2204B1D4D25F2@ESESSMB209.ericsson.se> <20141029081910.6d592960@rainpc> <003601cff3d3$313f1320$93bd3960$@co.in> <20141030080712.28c98ca9@rainpc> <54521952.3060105@cs.tcd.ie> Organization: Meetecho X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.24; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/straw/Ew9Mp9Ay0sUwKCyGVaf48odKmRg Cc: 'Richard Barnes' , 'Sean Turner' , 'Christer Holmberg' , Parthasarathi R , straw@ietf.org Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 19:25:42 -0000 On Thu, 30 Oct 2014 10:56:18 +0000 Stephen Farrell wrote: > > > On 30/10/14 07:07, Lorenzo Miniero wrote: > > On Thu, 30 Oct 2014 05:20:37 +0530 "Parthasarathi R" > > wrote: > > > >> Hi Lorenzo, > >> > >> I'm not seeing the convincing mechanism in your proposal which > >> overcome MITM issue except trusting B2BUA. The most complex > >> requirement in your e-mail is that > >> > >> " Without preventing additional mechanismsto be involved > >> for > >>> end-to-end validation of some kind, of course. > >> > >> > >> Could you please elaborate end-to-end validation in your mind. > >> > > > > > > Hi Partha, > > > > sorry, I should have been clearer about an aspect. I agree it's still > > MITM: when I said "everything else's MITM" I actually meant > > "everything else is not any different from a MITM attack", and that's > > why I believe the trust is an important aspect. > > And the IETF has also decided a number of times to not MITM TLS. > The impact of making that mistake would be huge and none of the > proponents of the various MITM schemes have ever evaluated that > impact as part of their proposal. That, and the fact that changing > from a two-part to a multi-party security protocol is very very > hard are among the reasons that all such proposals so far have > been DOA. > > Gratuitously throwing the misplaced word "trust" into such a > discussion does not help. > > S. > I don't disagree, so I won't argue (especially since I'm all but a security expert). I'll just reinstate that my only concern, and I'm sure I'm not alone in this, is the risk of dropping a whole set of scenarios STRAW identified, and leave them in the wild without guidance on how to address them. The text I proposed is probably not the right one, and one can do better, but I'd rather say something than nothing at all. I already mentioned some attempts in other WGs to accomodate similar scenarios that *might* be first steps in the right direction, and I'm sure more will follow. Lorenzo > > > > About the additional mechanism, I don't have any specific solution in > > mind. It's my understanding, though, that the IETF community has > > understood there's a problem to solve there, and is already trying to > > address it somehow, which is why I continue to believe we shouldn't > > give up on it either. For insta,ce, I do recall a presentation at the > > AVTCORE session in Toronto which tried to address a similar concern: > > > > http://www.ietf.org/proceedings/90/slides/slides-90-avtcore-6.pdf > > > > The presentation was called "Requirements for Secure RTP Media > > Switching", which should at least allow for a more proper management > > of media-aware as well, for instance. I believe there are use cases > > that justify both media-aware and media-termination in secure > > scenarios, and ignoring them will result in the same unpredictable > > consequences that lead to WGs like BLISS or STRAW itself: without > > some guide from IETF documents, developers will either drop security > > entirely (something we obviously don't want) or start doing things > > one way or another to make it work. > > > > Lorenzo > > > > > >> Thanks Partha > >> > >>> -----Original Message----- From: Lorenzo Miniero > >>> [mailto:lorenzo@meetecho.com] Sent: Wednesday, October 29, 2014 > >>> 12:49 PM To: Christer Holmberg Cc: Parthasarathi R; 'Stephen > >>> Farrell'; straw@ietf.org; 'Richard Barnes'; 'Sean Turner' > >>> Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: > >>> IETF#90: Draft STRAW minutes] > >>> > >>> On Wed, 29 Oct 2014 06:49:17 +0000 Christer Holmberg > >>> wrote: > >>> > >>>> (As co-chair) > >>>> > >>>> Hi, > >>>> > >>>> If anyone has an issue with the general approach suggested by > >>>> Partha, > >>> please indicate to on the list, so that we in Honolulu can focus > >>> on the technical aspects. > >>>> > >>> > >>> > >>> I'm not convinced that we should give up on those. Media Aware > >>> and Media Termination are part of the STRAW taxonomy, and act as > >>> if they just didn't exist doesn't seem the right thing to do > >>> IMHO. > >>> > >>> In Toronto it has been made clear that there are issues and > >>> concerns about what looked like standardizing a MITM for media. > >>> My personal feeling is that this can be considered mostly a > >>> matter of trust. The B2BUA should not necessarily be a sneaky or > >>> "transparent" component as long as participants are involved. > >>> This means that, as long as I trust the B2BUA in any scenario > >>> that involves Media Aware/Terminartion stuff, and so trust the > >>> B2BUA to secure the session on the other end or not do anything I > >>> didn't sign up for, the B2BUA is actually my "peer" in that > >>> respect. Without preventing additional mechanismsto be involved > >>> for end-to-end validation of some kind, of course. Everytihng > >>> outside of that is, I agree, MITM and shouldn't be avalled or > >>> fostered in any way. > >>> > >>> These are just some thoughts I tried to give to the idea, and how > >>> I basically changed the related text in the RTCP draft as well to > >>> try and address the issue, so I guess there will be plenty of > >>> time to bash me when I talk about this in Honolulu :-) > >>> > >>> Lorenzo > >>> > >>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> -----Original Message----- From: Parthasarathi R > >>>> [mailto:partha@parthasarathi.co.in] Sent: 29. lokakuuta 2014 > >>>> 1:28 To: 'Stephen Farrell'; Christer Holmberg; straw@ietf.org > >>>> Cc: 'Richard Barnes'; 'Sean Turner' Subject: RE: B2BUA handling > >>>> in DTLS-SRTP [was RE: [straw] IETF#90: > >>> Draft STRAW minutes] > >>>> > >>>> Hi all, > >>>> > >>>> One of the way to address MITM issue in STRAW WG B2BUA handling > >>>> of > >>> DTLS-SRTP milestone is to focus only on Media relay (Sec 3.1 of > >>> draft- ram-straw-b2bua-dtls-srtp-00) and removing "Media Aware or > >>> Media Termination" (Sec 3.2 of > >>> draft-ram-straw-b2bua-dtls-srtp-00). > >>>> > >>>> By this proposal, the scope of the work is to cover only > >>>> end-to-end > >>> DTLS-SRTP through B2BUA. The media relay provides end-to-end > >>> security but there are challenges w.r.t NAT, forking, ICE, > >>> identity (RTCWeb IdP, RFC4474bis, etc.,) which shall be sorted > >>> out in this milestone. > >>>> > >>>> During IETF-90 and in the mailing alias, I haven't heard any > >>>> concern > >>> for Media relay handling in B2BUA. please let me know your > >>> opinion on the same. > >>>> > >>>> Thanks Partha > >>>> > >>>>> -----Original Message----- From: Stephen Farrell > >>>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Wednesday, July 30, > >>>>> 2014 3:05 PM To: Parthasarathi R; 'Christer Holmberg'; > >>>>> straw@ietf.org Cc: 'Richard Barnes'; 'Sean Turner' Subject: > >>>>> Re: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: > >>>>> Draft STRAW minutes] > >>>>> > >>>>> > >>>>> on vacation, back in a week > >>>>> > >>>>> terminating DTLS-SRTP is maybe fine but means being one of > >>>>> the endpoints intended to be involved in the TLS session. > >>>>> Doing a MITM > >>> on > >>>>> TLS is not at all fine. > >>>>> > >>>>> S. > >>>>> > >>>>> On 30/07/14 02:34, Parthasarathi R wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> > >>>>>> > >>>>>> I have different view than the security folks look at this > >>>>>> draft. > >>>>> This draft > >>>>>> intention is not to violate RFC 2804. In case this draft is > >>>>>> not standardized, all B2BUA handling DTLS-SRTP will end up > >>>>>> in > >>> violating > >>>>> RFC 2804 > >>>>>> due to the lack of guidelines/standards to follow. Please > >>>>>> look > >>> into > >>>>> this > >>>>>> draft from SIP recording architecture in B2BUA (Fig 1 of > >>>>>> RFC > >>> 7245) > >>>>> usage > >>>>>> perspective wherein the senders/receiver is informed about > >>>>>> the > >>> call > >>>>>> recording (like call centre usage scenario) and no RFC > >>>>>> 2804 > >>>>> violation. > >>>>>> > >>>>>> > >>>>>> > >>>>>> In IETF-90 meeting, the security concerns are raised about > >>>>>> this draft > >>>>> usage. > >>>>>> It will be good to document as part of this document if it > >>>>>> is > >>> really > >>>>>> security issue. I'm not seeing any major security concerns > >>>>>> as > >>> B2BUA > >>>>> is yet > >>>>>> another UA. Please let me know the list of security > >>>>>> concern > >>> specific > >>>>> to > >>>>>> B2BUA in DTLS-SRTP. > >>>>>> > >>>>>> > >>>>>> > >>>>>> In reality, B2BUA terminating DTLS-SRTP is not avoidable > >>>>>> because > >>> of > >>>>> the > >>>>>> different codec profile between the deployed SIP UAs. Say > >>>>>> SIPoWS > >>> in > >>>>> browser > >>>>>> (WebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as > >>>>>> of > >>> today > >>>>> and SIP > >>>>>> Mobile devices uses AMR/AMR-WB/H.264. There is a compulsion > >>>>>> to > >>>>> terminate the > >>>>>> media in the middle as there is no solution exists in IETF > >>>>>> for > >>> the > >>>>> same. The > >>>>>> lack of standard leads to proprietary session border > >>>>>> controller (SBC) solutions which breaks other SIP > >>>>>> enhancements as well. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks > >>>>>> > >>>>>> Partha > >>>>>> > >>>>>> > >>>>>> > >>>>>> From: straw [mailto:straw-bounces@ietf.org] On Behalf Of > >>>>>> Christer > >>>>> Holmberg > >>>>>> Sent: Saturday, July 26, 2014 7:54 PM To: straw@ietf.org > >>>>>> Cc: Richard Barnes (rlb@ipv.sx); Sean Turner; Stephen > >>>>>> Farrell Subject: [straw] IETF#90: Draft STRAW minutes > >>>>>> > >>>>>> > >>>>>> > >>>>>> (Co-chair) > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Below are the STRAW minutes that the chairs intend to > >>>>>> upload. > >>>>>> > >>>>>> > >>>>>> > >>>>>> However, before we do that, we would like to ask the > >>>>>> community to > >>>>> take a > >>>>>> look at least at the notes associated with the DTLS-SRTP > >>>>> presentation, as it > >>>>>> caused lots of discussion. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Note that the minutes do not contain who-said-what > >>>>>> information > >>> (that > >>>>> can be > >>>>>> found elsewhere), but if you think there are some > >>>>>> important > >>> things > >>>>> missing, > >>>>>> or if you think something is wrong, please let the chairs > >>>>>> now. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>>> > >>>>>> > >>>>>> Regards, > >>>>>> > >>>>>> > >>>>>> > >>>>>> Christer & Victor > >>>>>> > >>>>>> > >>>>>> > >>>>>> ------------------- > >>>>>> > >>>>>> > >>>>>> > >>>>>> IETF 90 - STRAW > >>>>>> > >>>>>> 1150-1320 EDT Friday Afternoon Session I > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Topic: Agenda bashing, IETF Note Well and WG status > >>>>>> > >>>>>> Presenter: Christer Holmberg (co-chair) > >>>>>> > >>>>>> Slides: > >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf > >>>>>> > >>>>>> > >>>>>> > Draft: N/A > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> No issues were identified. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Topic: Guidelines to support RTCP in B2BUAs > >>>>>> > >>>>>> Presenter: Lorenzo Miniero > >>>>>> > >>>>>> Slides: > >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-1.pdf > >>>>>> > >>>>>> > >>>>>> > Draft: draft-ietf-straw-b2bua-rtcp > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was indicated that XR needs to be looked into, to see > >>>>>> whether > >>>>> something > >>>>>> needs to be covered in the draft. > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was indicated that the terminology will be aligned with > >>>>>> the grouping-taxonomy draft. In case there are conflicts, > >>>>>> or other issues > >>>>> are > >>>>>> found, the STRAW community is requested to provide comments > >>>>>> on > >>> the > >>>>>> grouping-taxonomy draft. > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was requested whether the draft should also cover RTP > >>>>>> specific > >>>>> issues. It > >>>>>> was indicated that the scope of the RTCP, and that we > >>>>>> should be > >>> very > >>>>> careful > >>>>>> about introducing RTP issues. It was recommended to talk to > >>>>>> Colin > >>>>> Perkins > >>>>>> whether he has any opinions regarding the need to cover > >>>>>> RTP. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I was asked how the document will relate to the work on > >>> multisource > >>>>>> optimisation taking place in AVTEXT. > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was indicated that the text recommending man in the > >>>>>> middle > >>>>> functionality > >>>>>> for SRTP most likely will cause issues with IESG. After > >>>>>> the DTLS-SRTP discussion (see further down) it was > >>>>>> suggested that the RTCP draft > >>>>> should > >>>>>> not talk about SRTP. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Topic: Taxonomy Discussion > >>>>>> > >>>>>> Presenter: Lorenzo Miniero > >>>>>> > >>>>>> Slides: > >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.pdf > >>>>>> > >>>>>> > >>>>>> > Draft: All STRAW deliveries > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was agreed the STRAW shall use the terms in the avtext- > >>> grouping- > >>>>> taxonomy > >>>>>> document in preference to definitions elsewhere is they > >>>>>> are > >>>>> appropriate, > >>>>>> with a note indicating any differences in other documents > >>>>>> that > >>> may > >>>>> influence > >>>>>> understanding. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Topic: STUN handling in B2BUAs > >>>>>> > >>>>>> Presenter: Lorenzo Miniero (on behalf of the draft > >>>>>> authors) > >>>>>> > >>>>>> Slides: > >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-3.pdf > >>>>>> > >>>>>> > >>>>>> > Draft: draft-ram-straw-b2bua-stun > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was indicated that B2BUA, due to policy reasons, may > >>>>>> strip > >>>>> candidates > >>>>>> from SDP. > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was indicated that B2BUAs must be very careful to not > >>>>>> perform > >>>>> actions > >>>>>> that will cause ICE mismatch. > >>>>>> > >>>>>> > >>>>>> > >>>>>> The chair informed the community that a WG adoption request > >>>>>> will > >>> be > >>>>> sent out > >>>>>> within the upcoming weeks. > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was indicated that the group needs to follow the ICE bis > >>>>>> work > >>>>> taking > >>>>>> place in MMUSIC, in case there will be any impacts on the > >>>>>> STRAW > >>>>> draft. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Topic: DTLS-SRTP handling in B2BUAs > >>>>>> > >>>>>> Presenter: Lorenzo Miniero (on behalf of the draft > >>>>>> authors) > >>>>>> > >>>>>> Slides: > >>>>>> http://www.ietf.org/proceedings/90/slides/slides-90-straw-4.pdf > >>>>>> > >>>>>> > >>>>>> > Draft: draft-ram-straw-b2bua-dtls-srtp > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> The presentation triggered lots of discussions and > >>>>>> controversy, > >>> as > >>>>>> it > >>>>> was > >>>>>> seen as an attempt to standardize MITM (man in the middle > >>>>> procedures). While > >>>>>> people did realize such actions take place in deployments, > >>>>>> they > >>>>> claimed that > >>>>>> IETF/STRAW should not standardize such procedures. It was > >>>>>> also > >>>>> indicated > >>>>>> that it goes against a number of BCP specifications, and > >>>>>> RFC > >>> 2804. > >>>>> Others > >>>>>> indicated that the purpose is to make sure that entities > >>>>>> doing > >>> this > >>>>> kind of > >>>>>> functionality do it in a way which does not cause > >>> interoperability > >>>>> problems, > >>>>>> which could cause people to not use security to begin > >>>>>> with. > >>>>>> > >>>>>> > >>>>>> > >>>>>> It was indicated that one possible way forward could be to > >>>>>> simply > >>>>> document, > >>>>>> in an informal delivery, how different vendors do things in > >>>>>> the > >>>>> network, but > >>>>>> in such case the vendors should also be listed in the > >>>>>> document. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Before the draft is adopted as a WG item, further > >>>>>> discussions > >>> need > >>>>>> to > >>>>> take > >>>>>> place. The ADs will help with finding the correct people > >>> (security, > >>>>> IESG, > >>>>>> etc) to involve in such discussions. The chair indicated > >>>>>> that the > >>>>> draft > >>>>>> implements a charter delivery, but that one possible > >>>>>> outcome will > >>> be > >>>>> to > >>>>>> remove/re-scope the charter delivery. > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> _______________________________________________ straw mailing > >>>> list straw@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/straw > >>> > >>> > >>> -- Lorenzo Miniero, COB > >>> > >>> Meetecho s.r.l. Web Conferencing and Collaboration Tools > >>> http://www.meetecho.com > >> > >> _______________________________________________ straw mailing list > >> straw@ietf.org https://www.ietf.org/mailman/listinfo/straw > > > > > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw -- Lorenzo Miniero, COB Meetecho s.r.l. Web Conferencing and Collaboration Tools http://www.meetecho.com