From nobody Thu Jul 3 23:20:28 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 DC82D1B2B7A for ; Thu, 3 Jul 2014 23:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmPbSUiQc7zm for ; Thu, 3 Jul 2014 23:20:24 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E8F1A03CF for ; Thu, 3 Jul 2014 23:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6006; q=dns/txt; s=iport; t=1404454824; x=1405664424; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cTXYosOR6OdIc552bwePZOvWkiAEOa1RGDIjJ5DMLhE=; b=cK7+97/5eSeQv7nKmxEKApAV5d+hwsxF9GK/bCfxyB+SC6uDPXZMViz4 ok8iPgNOsy13i1SAi1uf7+kXX8Q2+n6fs2chO1mRsjkGYfYi39vY3u6hw C8GHjiYG6dkRhi3sDeMlWf2cfdLVav6xBlZJuHDy5gWDiUpl8OJDTso1d 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAHZGtlOtJV2b/2dsb2JhbABaDoJ/UlqCb7t3hz8BGXYWdYQDAQEBBAEBATE6CQ4EAgEIDgMDAQIBBCgCAiULHAEIAgQBEgmIOQ2SDJwfBpsyF4EmjUk6BoJrgVIFmnaBSJJEggGBAEJsgUQ X-IronPort-AV: E=Sophos;i="5.01,599,1400025600"; d="scan'208";a="58275061" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 04 Jul 2014 06:20:21 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s646KLHd030053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 06:20:21 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 01:20:21 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "straw@ietf.org" Thread-Topic: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.txt Thread-Index: AQHPjRIj83iRDiPHUUmzVsyJQX3Wqg== Date: Fri, 4 Jul 2014 06:20:20 +0000 Message-ID: References: <20140621053151.26750.39604.idtracker@ietfa.amsl.com> <53B18576.4010908@alum.mit.edu> In-Reply-To: <53B18576.4010908@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [173.39.64.76] Content-Type: text/plain; charset="euc-kr" Content-ID: <63BCE2D75BFFE54F8BC366DA2D6218D5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/rGe2Wrez9sa4ykT7tjmC3RNCDNE Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.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, 04 Jul 2014 06:20:26 -0000 SGkgUGF1bCwNCg0KVGhhbmtzIGZvciByZXZpZXdpbmcgdGhlIGRyYWZ0LiBQbGVhc2Ugc2VlIGlu bGluZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGF1bCBLeXppdmF0IDxw a3l6aXZhdEBhbHVtLm1pdC5lZHU+DQpEYXRlOiBNb25kYXksIDMwIEp1bmUgMjAxNCA5OjEyIHBt DQpUbzogInN0cmF3QGlldGYub3JnIiA8c3RyYXdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3N0 cmF3XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQtcmFtLXN0cmF3LWIy YnVhLWR0bHMtc3J0cC0wMC50eHQNCg0KPkNvbW1lbnRzIG9uIHRoZSBkcmFmdDoNCj4NCj5HZW5l cmFsIHBvaW50Og0KPg0KPlRoaXMgZHJhZnQgZG9lc24ndCBzYXkgYW55dGhpbmcgYWJvdXQgbWlk ZGxlYm94ZXMgdGhhdCAqcmVtb3ZlKiB0aGUNCj5lbmNyeXB0aW9uIG9uIHRoZSBtZWRpYSBzdHJl YW0uIEVzcGVjaWFsbHkgZ2l2ZW4gdGhlIHJlY2VudCBpc3N1ZXMgYWJvdXQNCj5zdXJ2ZWlsbGFu Y2UsIEkgd291bGQgdGhpbmsgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvIGlzIHNheSBNVVNUIE5PVCB0 bw0KPnRoaXMuIE9UT0gsIEkgYXNzdW1lIHRoYXQgdGhlcmUgYXJlIHVzZXJzIG9mIFNCQyB3aG8g ZXhwbGljaXRseSBkZXNpcmUNCj50aGlzIGJlaGF2aW9yLiBBdCB0aGUgbGVhc3QgaXQgc2hvdWxk IGJlIGRpc2N1c3NlZCBpbiB0aGUgc2VjdXJpdHkNCj5jb25zaWRlcmF0aW9ucy4NCg0KQWdyZWUu IEdvb2QgcG9pbnQuIFdpbGwgYWRkIHNvbWUgY29uc2lkZXJhdGlvbnMgaW4gdGhlIG5leHQgcmV2 aXNpb24uDQoNCj4NCj5TZWN0aW9uIDMuMjoNCj4NCj5JU1RNIHRoYXQgTWVkaWEgQXdhcmUgYW5k IE1lZGlhIFRlcm1pbmF0aW9uIGRlc2VydmUgc2VwYXJhdGUgdHJlYXRtZW50Lg0KPg0KPkEgTWVk aWEgQXdhcmUgcmVsYXkgZG9lc24ndCBuZWVkIHRvIGVuY3J5cHQgLSBpdCBjYW4gcGFzcyB0aGUg aW5jb21pbmcNCj5wYWNrZXRzIHRocm91Z2guIFNvIGl0IGNvdWxkIHNpbXBseSBvYnNlcnZlIHRo ZSBmaW5nZXJwcmludHMgYXMgdGhleSBnbw0KPmJ5IHdpdGhvdXQgY2hhbmdpbmcgdGhlbSwgYW5k IHRoZW4gdXNlIHRvIGRvIGRlY3J5cHRpb24uDQoNCklmIHRoZSBtZWRpYSBhd2FyZSByZWxheSBC MkJVQSBpcyBqdXN0IGZvcndhcmRpbmcgIGFmdGVyIGxvb2tpbmcgYXQgdGhlDQpoZWFkZXJzIChS VFAvUlRDUCBvciBmaW5nZXIpIHRoZSBETFRTIHNlc3Npb24gZG9lcyBub3QgbmVlZCB0byBiZQ0K dGVybWluYXRlZCBvbiB0aGUgQjJCVUEuIEl0IGNhbiBiZSBlbmQgdG8gZW5kIGluIHdoaWNoIGNh c2UgdGhlIGZsb3cgd2lsbA0KYmUgdmVyeSBzaW1pbGFyIHRvIHNlY3Rpb24gMy4xDQpJIHdpbGwg YWRkIHNvbWUgY2xhcmlmaWNhdGlvbiBmb3IgTWVkaWEgYXdhcmUgcmVsYXkgYW5kIHBlcmhhcHMg aGF2ZSBpdCBhcw0Kc2VwYXJhdGUgc2VjdGlvbiB3aXRoIGEgYnJpZWYgdGV4dCBhbmQgdGhlbiBw b2ludGluZyB0IHNlY3Rpb24gMy4xDQoNClJlZ2FyZHMsDQpSYW0NCg0KPg0KPkFsc28sIGRvZXNu J3QgdGhpcyBkZXBlbmQgb24gaG93IG11Y2ggc2NydXRpbnkgaXQgZ2l2ZXMgdG8gdGhlIHBhY2tl dHMuDQo+SUlVQywgd2l0aCBTUlRQIHRoZSBSVFAgcGFja2V0IGhlYWRlcnMgYXJlIG5vdCBlbmNy eXB0ZWQsIHNvIHNvbWUgYmFzaWMNCj5sZXZlbCBvZiBzY3J1dGlueSBvZiB0aGUgUlRQIGNhbiBi ZSBkb25lIHdpdGhvdXQgYW55IGRlY3J5cHRpb24uDQo+DQo+CVRoYW5rcywNCj4JUGF1bA0KPg0K Pk9uIDYvMjEvMTQgMTowMCBQTSwgUmFtIE1vaGFuIFIgKHJtb2hhbnIpIHdyb3RlOg0KPj4gV2Ug aGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdGhhdCBkZXNjcmliZXMgdGhlIGJlaGF2aW9yIEIy QlVBqfZzIHNob3VsZA0KPj4gZm9sbG93IHdoZW4gYWN0aW5nIG9uIGEgbWVkaWEgcGxhbmUgdGhh dCB1c2VzIERUTFMtU1JUUC4NCj4+DQo+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1yYW0tc3RyYXctYjJidWEtZHRscy1zcnRwLTAwDQo+Pg0KPj4NCj4+IENvbW1lbnRzIGFuZCBp bnB1dHMgYXJlIHdlbGNvbWUNCj4+DQo+PiBSZWdhcmRzLA0KPj4gQXV0aG9ycw0KPj4NCj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiAiaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPj4gRGF0ZTogU2F0dXJkYXksIDIxIEp1 bmUgMjAxNCAxMTowMSBhbQ0KPj4gVG86IFJhbSBNb2hhbiBSYXZpbmRyYW5hdGggPHJtb2hhbnJA Y2lzY28uY29tPiwgIlRpcnVtYWxlc3dhciBSZWRkeQ0KPj4gKHRpcmVkZHkpIiA8dGlyZWRkeUBj aXNjby5jb20+LCBWaWN0b3IgUGFzY3VhbA0KPj4gPHZpY3Rvci5wYXNjdWFsQHF1b2Jpcy5jb20+ LCBWaWN0b3IgUGFzY3VhbCA8dmljdG9yLnBhc2N1YWxAcXVvYmlzLmNvbT4sDQo+PiAiR29uemFs byBTYWxndWVpcm8gKGdzYWxndWVpKSIgPGdzYWxndWVpQGNpc2NvLmNvbT4sICJHb256YWxvIFNh bGd1ZWlybw0KPj4gKGdzYWxndWVpKSIgPGdzYWxndWVpQGNpc2NvLmNvbT4sICJUaXJ1bWFsZXN3 YXIgUmVkZHkgKHRpcmVkZHkpIg0KPj4gPHRpcmVkZHlAY2lzY28uY29tPiwgUmFtIE1vaGFuIFJh dmluZHJhbmF0aCA8cm1vaGFuckBjaXNjby5jb20+DQo+PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yDQo+PiBkcmFmdC1yYW0tc3RyYXctYjJidWEtZHRscy1zcnRwLTAwLnR4 dA0KPj4NCj4+Pg0KPj4+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yYW0tc3RyYXctYjJi dWEtZHRscy1zcnRwLTAwLnR4dA0KPj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg YnkgR29uemFsbyBTYWxndWVpcm8gYW5kIHBvc3RlZCB0byB0aGUNCj4+PiBJRVRGIHJlcG9zaXRv cnkuDQo+Pj4NCj4+PiBOYW1lOgkJZHJhZnQtcmFtLXN0cmF3LWIyYnVhLWR0bHMtc3J0cA0KPj4+ IFJldmlzaW9uOgkwMA0KPj4+IFRpdGxlOgkJRFRMUy1TUlRQIEhhbmRsaW5nIGluIFNlc3Npb24g SW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKQ0KPj4+IEJhY2stdG8tQmFjayBVc2VyIEFnZW50cyAo QjJCVUFzKQ0KPj4+IERvY3VtZW50IGRhdGU6CTIwMTQtMDYtMjANCj4+PiBHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPj4+IFBhZ2VzOgkJMTANCj4+PiBVUkw6DQo+Pj4gDQo+Pj5odHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yYW0tc3RyYXctYjJidWEtZHRs cy1zcnRwLTAwLnQNCj4+Pnh0DQo+Pj4gU3RhdHVzOg0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXJhbS1zdHJhdy1iMmJ1YS1kdGxzLXNydHAvDQo+Pj4gSHRtbGl6 ZWQ6DQo+Pj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFtLXN0cmF3LWIyYnVh LWR0bHMtc3J0cC0wMA0KPj4+DQo+Pj4NCj4+PiBBYnN0cmFjdDoNCj4+PiAgICBTZXNzaW9uIElu aXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgQmFjay10by1CYWNrIFVzZXIgQWdlbnRzIChCMkJVQXMp DQo+Pj4gICAgb2Z0ZW4gZnVuY3Rpb24gb24gdGhlIG1lZGlhIHBsYW5lLCByYXRoZXIgdGhhbiBq dXN0IG9uIHRoZSBzaWduYWxpbmcNCj4+PiAgICBwYXRoLiAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgdGhlIGJlaGF2aW9yIEIyQlVBcyBzaG91bGQgZm9sbG93DQo+Pj53aGVuDQo+Pj4gICAgYWN0 aW5nIG9uIHRoZSBtZWRpYSBwbGFuZSB0aGF0IHVzZSBTZWN1cmUgUmVhbC10aW1lIFRyYW5zcG9y dA0KPj4+ICAgIFByb3RvY29sIChTUlRQKSBzZWN1cml0eSBjb250ZXh0IHNldHVwIHdpdGggRGF0 YWdyYW0gVHJhbnNwb3J0IExheWVyDQo+Pj4gICAgU2VjdXJpdHkgKERUTFMpIHByb3RvY29sLg0K Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4+IHN1Ym1pc3Npb24NCj4+ PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRv b2xzLmlldGYub3JnLg0KPj4+DQo+Pj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+Pg0KPj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzdHJh dyBtYWlsaW5nIGxpc3QNCj4+IHN0cmF3QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0cmF3DQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+c3RyYXcgbWFpbGluZyBsaXN0DQo+c3RyYXdAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0cmF3DQoNCg== From nobody Fri Jul 4 02:35:35 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 679551B27BF for ; Fri, 4 Jul 2014 02:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMw4mUZ2Gznv for ; Fri, 4 Jul 2014 02:35:32 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479B81A0ABF for ; Fri, 4 Jul 2014 02:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=663; q=dns/txt; s=iport; t=1404466532; x=1405676132; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=b4mf+h+31M1fDZAiBRN9zC/05Z7c8fwcm7xrE1lkRi0=; b=G5Y/nbSowhqyHIypYsBpZj6N6IkSVELcHrdoWiJkyIk6mK0iS9ka0v7E tMyDDD8JaNeB8TKplsjn7ehET6Uhlu8NqALIHGGjV6RBfXY5A8z72iJo4 A08OKzOA9/Ab3+7eWcySdKlb0jBRM2LN8pbH/XPQiJ6kDaPolLXFExgru g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAFx0tlOtJV2T/2dsb2JhbABaDoJ/gSzGKQGBDBZ1hAMBAQEEdw4EAgEIDgMDAQIvMhwBCAIEARKIQsoNF45vOgaEPQEEiheQX5QMggGBAEKCMA X-IronPort-AV: E=Sophos;i="5.01,600,1400025600"; d="scan'208";a="58312962" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP; 04 Jul 2014 09:35:31 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s649ZVkT008402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Jul 2014 09:35:31 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 04:35:31 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "straw@ietf.org" Thread-Topic: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.txt Thread-Index: AQHPjRIj83iRDiPHUUmzVsyJQX3Wqg== Date: Fri, 4 Jul 2014 09:35:31 +0000 Message-ID: References: <20140621053151.26750.39604.idtracker@ietfa.amsl.com> <53B18576.4010908@alum.mit.edu> In-Reply-To: <53B18576.4010908@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [173.39.64.76] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/8x8ybC8qCCuh0xymWHQkcYZ7Wq0 Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.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, 04 Jul 2014 09:35:33 -0000 -----Original Message----- From: Paul Kyzivat Date: Monday, 30 June 2014 9:12 pm To: "straw@ietf.org" Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.txt >A Media Aware relay doesn't need to encrypt - it can pass the incoming >packets through. So it could simply observe the fingerprints as they go >by without changing them, and then use to do decryption. One comment on this - if the DTLS is not terminated on the B2BUA then it can=B9t decrypt the packets. So for a Media Aware relay it can=B9t decrypt = the packets. It can only inspect the headers. Ram From nobody Fri Jul 4 07:43:16 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 98FD41B2D97 for ; Fri, 4 Jul 2014 07:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpM2UM91Pb6F for ; Fri, 4 Jul 2014 07:43:06 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90F01B2D02 for ; Fri, 4 Jul 2014 07:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2416; q=dns/txt; s=iport; t=1404484984; x=1405694584; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NzIe+vPryYxECUa2dI9VDYDZzKQ4nWhJAIVtp4t/m24=; b=kACzElz50LlgOKoP/zVx7Sk5UmxN804OIJJF3dlrCErUqcWzjp8uWPJ9 5jilO7EPREvBQy5ttAUbTzXPfrUKcFtnk65S4CAd8SWiUdHY0RW7metMC 1t2w+kDxYI/9M6C9M8gvEwjHyqfyuadaS40JeYDBN3hjBtcHjb9tCLSaf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAIq8tlOtJV2Z/2dsb2JhbABagw5SWsYpAYELFnWEAwEBAQQ6PQ4EAgEIEQMBAh8QMhsBAQUDAgQTCYg5DcpAF48pBoQ9BZp2gUiSRINDbIFE X-IronPort-AV: E=Sophos;i="5.01,601,1400025600"; d="scan'208";a="58353436" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 04 Jul 2014 14:43:03 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s64Eh2O8028177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Jul 2014 14:43:02 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Fri, 4 Jul 2014 09:43:02 -0500 From: "Ram Mohan R (rmohanr)" To: "straw@ietf.org" Thread-Topic: New Version Notification for draft-ram-straw-b2bua-stun-00.txt Thread-Index: AQHPl5WxNmloNut7lEmP8rilhPLVnZuQrYwA Date: Fri, 4 Jul 2014 14:43:01 +0000 Message-ID: References: <20140704143857.20390.70771.idtracker@ietfa.amsl.com> In-Reply-To: <20140704143857.20390.70771.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.55.100] Content-Type: text/plain; charset="us-ascii" Content-ID: <878EFA77234D63488BFB21D53D6BED5C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/BbVdlfgIaln0nh_nksALUhEHbkY Subject: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.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, 04 Jul 2014 14:43:07 -0000 We have submitted a draft that describes the behavior B2BUAs should follow when acting on a media plane that receives STUN messages as part of ICE processing. http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt Comments and suggestions on how to make the draft better are welcome. Regards, Authors. -----Original Message----- From: "internet-drafts@ietf.org" Date: Friday, 4 July 2014 8:08 pm To: Ram Mohan Ravindranath , "Tirumaleswar Reddy (tireddy)" , "Gonzalo Salgueiro (gsalguei)" , "Gonzalo Salgueiro (gsalguei)" , "Tirumaleswar Reddy (tireddy)" , Ram Mohan Ravindranath Subject: New Version Notification for draft-ram-straw-b2bua-stun-00.txt > >A new version of I-D, draft-ram-straw-b2bua-stun-00.txt >has been successfully submitted by Ram Mohan Ravindranath and posted to >the >IETF repository. > >Name: draft-ram-straw-b2bua-stun >Revision: 00 >Title: Session Traversal Utilities for NAT (STUN) Message Handling for >Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) >Document date: 2014-07-04 >Group: Individual Submission >Pages: 14 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-stun/ >Htmlized: http://tools.ietf.org/html/draft-ram-straw-b2bua-stun-00 > > >Abstract: > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > are often designed to be on the media path, rather than just > intercepting signaling. This means that B2BUAs often act on the > media path leading to separate media legs that the B2BUA correlates > and bridges together. When acting on the media path, B2BUAs are > likely to receive Session Traversal Utilities for NAT (STUN) packets > as part of Interactive Connectivity Establishment (ICE) processing. > It is critical that B2BUAs handle these STUN messages properly. > > This document defines behavior for a B2BUA performing ICE processing. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Fri Jul 4 08:57:07 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 374B51A01F6 for ; Fri, 4 Jul 2014 08:57:06 -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 VoSJKyl7VEnl for ; Fri, 4 Jul 2014 08:57:04 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AE61A0353 for ; Fri, 4 Jul 2014 08:57:01 -0700 (PDT) X-AuditID: c1b4fb25-f79da6d000004ad3-8b-53b6cecba41f Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1C.C2.19155.BCEC6B35; Fri, 4 Jul 2014 17:57:00 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0174.001; Fri, 4 Jul 2014 17:56:59 +0200 From: Christer Holmberg To: "Ram Mohan R (rmohanr)" , "straw@ietf.org" Thread-Topic: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.txt Thread-Index: AQHPl5WxNmloNut7lEmP8rilhPLVnZuQrYwA//9j/ps= Date: Fri, 4 Jul 2014 15:56:59 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3B49EA@ESESSMB209.ericsson.se> References: <20140704143857.20390.70771.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje6Zc9uCDd5f4LFY3rWD0eJW82NW ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvjwtcHbAVbpCoev9jO0sB4VbSLkZNDQsBE 4vzVWcwQtpjEhXvr2UBsIYGjjBJbD4R1MXIB2QsZJT49OcfaxcjBwSZgIdH9TxukRkQgROJt xyewemGBSImGv1vZIeJREk/b3zND2FYSTU9OMIHYLAIqEvsaF4PV8Ar4Sjw/OxHIZgeanyKx RhokyimgL/HqwTwWEJsR6Jrvp9aAdTILiEvcejKfCeJKAYkle85DXSwq8fLxP7DDJAQUJZb3 y0GU60gs2A1xGLOAtsSyha+ZIZYKSpyc+YRlAqPoLCRTZyFpmYWkZRaSlgWMLKsYRYtTi5Ny 042M9VKLMpOLi/Pz9PJSSzYxAuPj4JbfqjsYL79xPMQowMGoxMOrMGtrsBBrYllxZe4hRmkO FiVx3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYIx0sYpZc2zDNt57O10OPf0vzcO0 Lv5xu/7+kk3vVrHtlzg3h1/21QV7oxdyKY/iVi+p/rDYvO59xfGb0btqgiyaU/RaRRfwae8x 9s6pvqIiUbyVe6dJ+YFDM1x+Pk57v6/z7xaDvIrOI0ublq3+ks777OuWRY6bA365yORumCSa b33y0FQfxutKLMUZiYZazEXFiQCOB40QcAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/straw/ksVZqXSc6J0YD5RSoDKkKAgDDTI Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.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, 04 Jul 2014 15:57:06 -0000 (As co-chair) Hi, Thanks for submitting the draft! Currently this is the only input draft we have for the following delivery: A document defining the requirements for B2BUAs to support STUN message tra= nsactions end-to-end submitted to the IESG as PS We ask people to take a look at it, to see whether there are some issues th= at need to be dealt with before we ask for WG adoption of the draft. Also, if someone intends to submit an alternative draft for the delivery, l= et the community know. Thanks! Regards, Christer ________________________________________ From: straw [straw-bounces@ietf.org] on behalf of Ram Mohan R (rmohanr) [rm= ohanr@cisco.com] Sent: Friday, 04 July 2014 5:43 PM To: straw@ietf.org Subject: [straw] FW: New Version Notification for draft-ram-straw-b2b= ua-stun-00.txt We have submitted a draft that describes the behavior B2BUAs should follow when acting on a media plane that receives STUN messages as part of ICE processing. http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt Comments and suggestions on how to make the draft better are welcome. Regards, Authors. -----Original Message----- From: "internet-drafts@ietf.org" Date: Friday, 4 July 2014 8:08 pm To: Ram Mohan Ravindranath , "Tirumaleswar Reddy (tireddy)" , "Gonzalo Salgueiro (gsalguei)" , "Gonzalo Salgueiro (gsalguei)" , "Tirumaleswar Reddy (tireddy)" , Ram Mohan Ravindranath Subject: New Version Notification for draft-ram-straw-b2bua-stun-00.txt > >A new version of I-D, draft-ram-straw-b2bua-stun-00.txt >has been successfully submitted by Ram Mohan Ravindranath and posted to >the >IETF repository. > >Name: draft-ram-straw-b2bua-stun >Revision: 00 >Title: Session Traversal Utilities for NAT (STUN) Message Handling= for >Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) >Document date: 2014-07-04 >Group: Individual Submission >Pages: 14 >URL: >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt >Status: >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-stun/ >Htmlized: http://tools.ietf.org/html/draft-ram-straw-b2bua-stun-00 > > >Abstract: > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > are often designed to be on the media path, rather than just > intercepting signaling. This means that B2BUAs often act on the > media path leading to separate media legs that the B2BUA correlates > and bridges together. When acting on the media path, B2BUAs are > likely to receive Session Traversal Utilities for NAT (STUN) packets > as part of Interactive Connectivity Establishment (ICE) processing. > It is critical that B2BUAs handle these STUN messages properly. > > This document defines behavior for a B2BUA performing ICE processing. > > > > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > _______________________________________________ straw mailing list straw@ietf.org https://www.ietf.org/mailman/listinfo/straw= From nobody Fri Jul 11 08:53:33 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 674FA1A0A8A; Fri, 11 Jul 2014 08:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YXe8wyCbGCk; Fri, 11 Jul 2014 08:53:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1793A1A0659; Fri, 11 Jul 2014 08:53:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140711155330.11443.81441.idtracker@ietfa.amsl.com> Date: Fri, 11 Jul 2014 08:53:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/m8JKqIeW-gvSdPmXIB3kAQv2d5U Cc: straw@ietf.org Subject: [straw] I-D ACTION: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: Fri, 11 Jul 2014 15:53:31 -0000 --NextPart 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 : A Media-based Traceroute Function for the Session Initiation Protocol (SIP) Author(s) : H. Kaplan Filename : draft-ietf-straw-sip-traceroute Pages : 7 Date : 2014-07-11 SIP already provides the ability to perform hop-by-hop traceroute for SIP messages using the Max-Forwards header field to determine the reachability path of requests to a target. A mechanism for media-loopback calls has also been defined separately, which enables test calls to be generated that result in media being looped back to the originator. This document describes a means of performing hop- by-hop traceroute-style test calls using the media-loopback mechanism to test the media path when SIP sessions go through media- relaying B2BUAs. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-straw-sip-traceroute-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-straw-sip-traceroute"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2014-07-11085330.I-D@ietf.org> --NextPart-- From nobody Sun Jul 13 09:08:01 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 23E621B2A80 for ; Sun, 13 Jul 2014 09:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sGf2WLkrSV5P for ; Sun, 13 Jul 2014 09:07:55 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5241B2A79 for ; Sun, 13 Jul 2014 09:07:55 -0700 (PDT) Received: from userPC (unknown [122.167.119.171]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id E8613639819; Sun, 13 Jul 2014 16:07:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1405267673; bh=gdSz5blug8Il3OZ8MvYjPmqIHviX24kRgPvQ1Gnb4SU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=dCYyAF9YS5+WXXFeAUy1G2bJamRxwpXQCXH3djxyuX9O9JcmT1x4vWhBj/UnmPwnr zZrdqTzjPQf0hLyK0aHJvjb/p3nWYYSemajikwCpH9A9vIoHMlQz9GgqtzDe4NMqeh WQc2G+ixuBTdEyRq5TGpIUak8eMvggdlAbdc3AYU= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , References: <20140621053151.26750.39604.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sun, 13 Jul 2014 21:37:45 +0530 Message-ID: <000001cf9eb4$983d4d90$c8b7e8b0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPjRIj83iRDiPHUUmzVsyJQX3Wqpt8enWAgCFfKvA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020208.53C2AED7.0046, 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: 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.134 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/__aZOtcfhzaHUoEhFpA_RIXfn7g Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.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: Sun, 13 Jul 2014 16:07:59 -0000 Hi all, The draft looks good. The example of SIP & DTLS-SRTP message in the = draft will provide more clarity about the different B2BUA usages. Thanks Partha=20 > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: Saturday, June 21, 2014 10:30 PM > To: straw@ietf.org > Subject: [straw] FW: New Version Notification for draft-ram-straw- > b2bua-dtls-srtp-00.txt >=20 > We have submitted a new draft that describes the behavior B2BUA=B9s > should > follow when acting on a media plane that uses DTLS-SRTP. >=20 > http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-00 >=20 >=20 > Comments and inputs are welcome >=20 > Regards, > Authors >=20 > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Saturday, 21 June 2014 11:01 am > To: Ram Mohan Ravindranath , "Tirumaleswar Reddy > (tireddy)" , Victor Pascual > , Victor Pascual > , > "Gonzalo Salgueiro (gsalguei)" , "Gonzalo = Salgueiro > (gsalguei)" , "Tirumaleswar Reddy (tireddy)" > , Ram Mohan Ravindranath > Subject: New Version Notification for > draft-ram-straw-b2bua-dtls-srtp-00.txt >=20 > > > >A new version of I-D, draft-ram-straw-b2bua-dtls-srtp-00.txt > >has been successfully submitted by Gonzalo Salgueiro and posted to = the > >IETF repository. > > > >Name: draft-ram-straw-b2bua-dtls-srtp > >Revision: 00 > >Title: DTLS-SRTP Handling in Session Initiation Protocol > (SIP) > >Back-to-Back User Agents (B2BUAs) > >Document date: 2014-06-20 > >Group: Individual Submission > >Pages: 10 > >URL: > >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-dtls-srtp- > 00.txt > >Status: > >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-dtls-srtp/ > >Htmlized: > >http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-00 > > > > > >Abstract: > > Session Initiation Protocol (SIP) Back-to-Back User Agents = (B2BUAs) > > often function on the media plane, rather than just on the > signaling > > path. This document describes the behavior B2BUAs should follow > when > > acting on the media plane that use Secure Real-time Transport > > Protocol (SRTP) security context setup with Datagram Transport > Layer > > Security (DTLS) protocol. > > > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >The IETF Secretariat > > >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Mon Jul 14 04:46:43 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 34ABA1A03A2 for ; Mon, 14 Jul 2014 04:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 1QNwDPOX50ZD for ; Mon, 14 Jul 2014 04:46:39 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7BB1A039F for ; Mon, 14 Jul 2014 04:46:39 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id 2A94523F0406; Mon, 14 Jul 2014 13:46:38 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.1.120]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Mon, 14 Jul 2014 13:46:37 +0200 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , "straw@ietf.org" Thread-Topic: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.txt Thread-Index: AQHPjRIj83iRDiPHUUmzVsyJQX3Wqpt8enWAgCMB4yA= Date: Mon, 14 Jul 2014 11:46:37 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17E22A0D@MCHP04MSX.global-ad.net> References: <20140621053151.26750.39604.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/8gZRSf0q9I3wdJg52G5GaPMCzyg Subject: Re: [straw] New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.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: Mon, 14 Jul 2014 11:46:41 -0000 Just one question at this time. Should this draft be "Informational" rather than "Standards Track"? Regards Andy > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: 21 June 2014 18:00 > To: straw@ietf.org > Subject: [straw] FW: New Version Notification for draft-ram-straw- > b2bua-dtls-srtp-00.txt >=20 > We have submitted a new draft that describes the behavior B2BUA=B9s > should > follow when acting on a media plane that uses DTLS-SRTP. >=20 > http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-00 >=20 >=20 > Comments and inputs are welcome >=20 > Regards, > Authors >=20 > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Saturday, 21 June 2014 11:01 am > To: Ram Mohan Ravindranath , "Tirumaleswar Reddy > (tireddy)" , Victor Pascual > , Victor Pascual > , > "Gonzalo Salgueiro (gsalguei)" , "Gonzalo Salgueiro > (gsalguei)" , "Tirumaleswar Reddy (tireddy)" > , Ram Mohan Ravindranath > Subject: New Version Notification for > draft-ram-straw-b2bua-dtls-srtp-00.txt >=20 > > > >A new version of I-D, draft-ram-straw-b2bua-dtls-srtp-00.txt > >has been successfully submitted by Gonzalo Salgueiro and posted to the > >IETF repository. > > > >Name: draft-ram-straw-b2bua-dtls-srtp > >Revision: 00 > >Title: DTLS-SRTP Handling in Session Initiation Protocol > (SIP) > >Back-to-Back User Agents (B2BUAs) > >Document date: 2014-06-20 > >Group: Individual Submission > >Pages: 10 > >URL: > >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-dtls-srtp- > 00.txt > >Status: > >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-dtls-srtp/ > >Htmlized: > >http://tools.ietf.org/html/draft-ram-straw-b2bua-dtls-srtp-00 > > > > > >Abstract: > > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > > often function on the media plane, rather than just on the > signaling > > path. This document describes the behavior B2BUAs should follow > when > > acting on the media plane that use Secure Real-time Transport > > Protocol (SRTP) security context setup with Datagram Transport > Layer > > Security (DTLS) protocol. > > > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >The IETF Secretariat > > >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Tue Jul 15 02:42:07 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 8F4A61A0379 for ; Tue, 15 Jul 2014 02:42:05 -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 R05tKvl8WGrC for ; Tue, 15 Jul 2014 02:42:03 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6921B27E8 for ; Tue, 15 Jul 2014 02:41:53 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id e16so2274657lan.3 for ; Tue, 15 Jul 2014 02:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7iBLEYh3S+/HiNrHeVIKzAnmAtUOjpiFgc8xYo7R3Mw=; b=qyRCY7QkSVZDqebyqDKtFLtyV8dqQ0EA+VoWHZ9vkGfTY6BnOBYvPhCh9m5Z6h0AKh dZmKR80ZgQ0gr9ooXIi/uURL4h4JWYvd8Lv++3/YkdiuQr/Qadd3SMLpUrwSM/Uswfdx M6TsqCUBxA78vvlwotQkdcTbEkPS1xpHDyIG3Toh/ET2c4Z28EN+UdXbYS965r73ATDJ VIoKAsqxDq/78nfuRautuz9d+9t8KtsYSt88PQwa7C7DQ/yAKQLEjTBsrOBylxAO3TXq 3SZff3RCadmRQwRHDyEUUqitjhPpZNkrqMsj5VBuSG0WSEC+wRByQxLIQIgIZLXkMcbu vwZA== MIME-Version: 1.0 X-Received: by 10.152.204.68 with SMTP id kw4mr10781073lac.48.1405417312306; Tue, 15 Jul 2014 02:41:52 -0700 (PDT) Received: by 10.114.99.72 with HTTP; Tue, 15 Jul 2014 02:41:52 -0700 (PDT) Date: Tue, 15 Jul 2014 11:41:52 +0200 Message-ID: From: Victor Pascual Avila To: "straw@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/U4aZWU-qA4D_DbSB48WbkLmawBQ Subject: [straw] Agenda for IETF90 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, 15 Jul 2014 09:42:05 -0000 Agenda for IETF90 has been published -- please let us know if you have any comment. http://www.ietf.org/proceedings/90/slides/slides-90-straw-0.pdf Thanks, Christer and Victor From nobody Thu Jul 17 18:25: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 00B2B1A0115 for ; Thu, 17 Jul 2014 18:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rJwAQqpUqLgx for ; Thu, 17 Jul 2014 18:25:26 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.15]) by ietfa.amsl.com (Postfix) with ESMTP id D77501A011E for ; Thu, 17 Jul 2014 18:25:26 -0700 (PDT) Received: from userPC (unknown [122.166.174.13]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id CB30F1908997; Fri, 18 Jul 2014 01:25:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1405646728; bh=JXV+5tvm48PTWuOp6siDSfHn6U4FDRcElvuUR3wxT+8=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=HDAFos9yVEH60U8K1nSW68bKLo+IdFySIu9VaBL07bCu5cAB+j/7rHMplrjK+1kIJ y6OUnUm3lsT3YjpBUMBUJDZ+JHgESyYptNFFw2auCAFiU4wm0CV89rtGYkfuUV1Q1x Tob5qPQH8UNqJjkkSzsaSGXUHOb5Lsmytk14tUrQ= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , References: <20140704143857.20390.70771.idtracker@ietfa.amsl.com> In-Reply-To: Date: Fri, 18 Jul 2014 06:55:15 +0530 Message-ID: <001b01cfa227$237220a0$6a5661e0$@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: AQHPl5WxNmloNut7lEmP8rilhPLVnZuQrYwAgBRwKhA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020201.53C87786.0003, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 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.92 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/0z-LMgEwm3_ZJTlNYfTEb-Pd85g Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.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, 18 Jul 2014 01:25:29 -0000 Hi Ram, The draft approach looks good. The following aspect has to be considered 1) ICE-TCP handling in STUN traversal 2) In case B2BUA is ICE-lite, the impact of STUN traversal w.r.t ICE termination and ICE passthrough mode in B2BUA. Thanks Partha > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Ram Mohan R > (rmohanr) > Sent: Friday, July 04, 2014 8:13 PM > To: straw@ietf.org > Subject: [straw] FW: New Version Notification for draft-ram-straw- > b2bua-stun-00.txt > > We have submitted a draft that describes the behavior B2BUAs should > follow when acting on a media plane that receives STUN messages as part > of > ICE processing. > > http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt > > > Comments and suggestions on how to make the draft better are welcome. > > Regards, > Authors. > > > > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Friday, 4 July 2014 8:08 pm > To: Ram Mohan Ravindranath , "Tirumaleswar Reddy > (tireddy)" , "Gonzalo Salgueiro (gsalguei)" > , "Gonzalo Salgueiro (gsalguei)" > , > "Tirumaleswar Reddy (tireddy)" , Ram Mohan > Ravindranath > > Subject: New Version Notification for draft-ram-straw-b2bua-stun-00.txt > > > > >A new version of I-D, draft-ram-straw-b2bua-stun-00.txt > >has been successfully submitted by Ram Mohan Ravindranath and posted > to > >the > >IETF repository. > > > >Name: draft-ram-straw-b2bua-stun > >Revision: 00 > >Title: Session Traversal Utilities for NAT (STUN) Message > Handling for > >Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > >Document date: 2014-07-04 > >Group: Individual Submission > >Pages: 14 > >URL: > >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt > >Status: > >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-stun/ > >Htmlized: http://tools.ietf.org/html/draft-ram-straw-b2bua-stun- > 00 > > > > > >Abstract: > > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > > are often designed to be on the media path, rather than just > > intercepting signaling. This means that B2BUAs often act on the > > media path leading to separate media legs that the B2BUA correlates > > and bridges together. When acting on the media path, B2BUAs are > > likely to receive Session Traversal Utilities for NAT (STUN) > packets > > as part of Interactive Connectivity Establishment (ICE) processing. > > It is critical that B2BUAs handle these STUN messages properly. > > > > This document defines behavior for a B2BUA performing ICE > processing. > > > > > > > > > > > >Please note that it may take a couple of minutes from the time of > >submission > >until the htmlized version and diff are available at tools.ietf.org. > > > >The IETF Secretariat > > > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Mon Jul 21 19:55:20 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 F19D81A03A7 for ; Mon, 21 Jul 2014 19:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaT--kIb2O-f for ; Mon, 21 Jul 2014 19:55:17 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639931A039A for ; Mon, 21 Jul 2014 19:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3890; q=dns/txt; s=iport; t=1405997717; x=1407207317; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CrxAeQLnInYua023QLIDoJfFpspdEOR9wd6zYM7KuqE=; b=mlGhQoNI9f0Vmg6FTMrp6Q7TNCm0laF2lJpeqG//MPjMfO9pMPa1hI9G eIcB4j+WHG+WjcASKksp/Ucl73R529mJ3sKmvZ/qxA6j/Ddf07JL2a8IP nsp8w4YAguwvo32F//grpjAwk2vCh2w7zyojksYILVR+K+bIOtGwH6HVr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAODRzVOtJV2c/2dsb2JhbABZgw5SVwTGaAqHRQGBFhZ2hAMBAQEEAQEBNzQJDgQCAQgRAwEBAR8JBycLFAgBCAIEARIJiDkNvlAXj1IGhEAFmyWBTZJig0RsAYFE X-IronPort-AV: E=Sophos;i="5.01,706,1400025600"; d="scan'208";a="341786036" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 22 Jul 2014 02:55:17 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6M2tG2w013025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 02:55:16 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Mon, 21 Jul 2014 21:55:16 -0500 From: "Ram Mohan R (rmohanr)" To: Parthasarathi R , "straw@ietf.org" Thread-Topic: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.txt Thread-Index: AQHPl5WxNmloNut7lEmP8rilhPLVnQ== Date: Tue, 22 Jul 2014 02:55:15 +0000 Message-ID: References: <20140704143857.20390.70771.idtracker@ietfa.amsl.com> <001b01cfa227$237220a0$6a5661e0$@co.in> In-Reply-To: <001b01cfa227$237220a0$6a5661e0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [173.39.64.69] Content-Type: text/plain; charset="us-ascii" Content-ID: <1C070781C88C814E8FC8AB04CC365D53@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/CQiNI0mYPJ84Gg7qLpd631DaCns Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.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: Tue, 22 Jul 2014 02:55:19 -0000 Please see inline -----Original Message----- From: Parthasarathi R Date: Friday, 18 July 2014 6:55 am To: Ram Mohan Ravindranath , "straw@ietf.org" Subject: RE: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.txt >Hi Ram, > >The draft approach looks good. The following aspect has to be considered > >1) ICE-TCP handling in STUN traversal Will add some text for this in the next revision. >2) In case B2BUA is ICE-lite, the impact of STUN traversal w.r.t ICE >termination and ICE passthrough mode in B2BUA. Is there any thing that you would like to see explicitly added for ICE lite ? All the procedures of ICE termination/ICE passthrough are equally applicable for Ice lite mode as well. Regards, Ram > >Thanks >Partha > >> -----Original Message----- >> From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Ram Mohan R >> (rmohanr) >> Sent: Friday, July 04, 2014 8:13 PM >> To: straw@ietf.org >> Subject: [straw] FW: New Version Notification for draft-ram-straw- >> b2bua-stun-00.txt >>=20 >> We have submitted a draft that describes the behavior B2BUAs should >> follow when acting on a media plane that receives STUN messages as part >> of >> ICE processing. >>=20 >> http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt >>=20 >>=20 >> Comments and suggestions on how to make the draft better are welcome. >>=20 >> Regards, >> Authors. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: "internet-drafts@ietf.org" >> Date: Friday, 4 July 2014 8:08 pm >> To: Ram Mohan Ravindranath , "Tirumaleswar Reddy >> (tireddy)" , "Gonzalo Salgueiro (gsalguei)" >> , "Gonzalo Salgueiro (gsalguei)" >> , >> "Tirumaleswar Reddy (tireddy)" , Ram Mohan >> Ravindranath >> >> Subject: New Version Notification for draft-ram-straw-b2bua-stun-00.txt >>=20 >> > >> >A new version of I-D, draft-ram-straw-b2bua-stun-00.txt >> >has been successfully submitted by Ram Mohan Ravindranath and posted >> to >> >the >> >IETF repository. >> > >> >Name: draft-ram-straw-b2bua-stun >> >Revision: 00 >> >Title: Session Traversal Utilities for NAT (STUN) Message >> Handling for >> >Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) >> >Document date: 2014-07-04 >> >Group: Individual Submission >> >Pages: 14 >> >URL: >> >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun-00.txt >> >Status: >> >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-stun/ >> >Htmlized: http://tools.ietf.org/html/draft-ram-straw-b2bua-stun- >> 00 >> > >> > >> >Abstract: >> > Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) >> > are often designed to be on the media path, rather than just >> > intercepting signaling. This means that B2BUAs often act on the >> > media path leading to separate media legs that the B2BUA correlates >> > and bridges together. When acting on the media path, B2BUAs are >> > likely to receive Session Traversal Utilities for NAT (STUN) >> packets >> > as part of Interactive Connectivity Establishment (ICE) processing. >> > It is critical that B2BUAs handle these STUN messages properly. >> > >> > This document defines behavior for a B2BUA performing ICE >> processing. >> > >> > >> > >> > >> > >> >Please note that it may take a couple of minutes from the time of >> >submission >> >until the htmlized version and diff are available at tools.ietf.org. >> > >> >The IETF Secretariat >> > >>=20 >> _______________________________________________ >> straw mailing list >> straw@ietf.org >> https://www.ietf.org/mailman/listinfo/straw > From nobody Mon Jul 21 22:46:55 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 3A04F1A04BA for ; Mon, 21 Jul 2014 22:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gncOXz36MKXt for ; Mon, 21 Jul 2014 22:46:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4EE1A04AC for ; Mon, 21 Jul 2014 22:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4566; q=dns/txt; s=iport; t=1406008010; x=1407217610; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6mCeviexCEsgI7kOgIZe/UTcTk+FPfDN9XAgXipMhsM=; b=U9U6v9l8b0ovksTLzxxbwGuEi839Ujz50QADhaxVic15zwrdfAJ5dGXv 8SX/Lr6rcoVOT7Au6cktd1hLPpUJY6sZLEuVA5jy+p4t9M+4lnObVF7AX 2iyofUZEeRI5sa1hkeeefjRkYYAIoSwRTZbL3IyJJ3H6YCISy611PDX8i s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FALj5zVOtJA2J/2dsb2JhbABYgw5SVwSCdMN1CodFARl5FnaEAwEBAQQBAQExOgkOBAIBCBEDAQEBBSMFAgIlCxQJCAIEARIJiDkNiw2cIQaXLheBJo1yCDIEAoJsgVQFmyaBTZJig0RsgUU X-IronPort-AV: E=Sophos;i="5.01,707,1400025600"; d="scan'208";a="341804976" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jul 2014 05:46:49 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s6M5kmYl015353 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Jul 2014 05:46:48 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 22 Jul 2014 00:46:48 -0500 From: "Ram Mohan R (rmohanr)" To: "Hutton, Andrew" , "straw@ietf.org" Thread-Topic: New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.txt Thread-Index: AQHPjRIj83iRDiPHUUmzVsyJQX3Wqg== Date: Tue, 22 Jul 2014 05:46:47 +0000 Message-ID: References: <20140621053151.26750.39604.idtracker@ietfa.amsl.com> <9F33F40F6F2CD847824537F3C4E37DDF17E22A0D@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17E22A0D@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [173.39.64.69] Content-Type: text/plain; charset="euc-kr" Content-ID: <2BE7112FCA4C6B4FA32820ACE03593BA@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/gFKRJEcvHoaDdr02InX8xF8yWYk Subject: Re: [straw] New Version Notification for draft-ram-straw-b2bua-dtls-srtp-00.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: Tue, 22 Jul 2014 05:46:52 -0000 UGxlYXNlIHNlZSBpbmxpbmUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IDxI dXR0b24+LCBBbmRyZXcgPGFuZHJldy5odXR0b25AdW5pZnkuY29tPg0KRGF0ZTogTW9uZGF5LCAx NCBKdWx5IDIwMTQgNToxNiBwbQ0KVG86IFJhbSBNb2hhbiBSYXZpbmRyYW5hdGggPHJtb2hhbnJA Y2lzY28uY29tPiwgInN0cmF3QGlldGYub3JnIg0KPHN0cmF3QGlldGYub3JnPg0KU3ViamVjdDog UkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCmRyYWZ0LXJhbS1zdHJhdy1iMmJ1YS1k dGxzLXNydHAtMDAudHh0DQoNCj5KdXN0IG9uZSBxdWVzdGlvbiBhdCB0aGlzIHRpbWUuDQo+DQo+ U2hvdWxkIHRoaXMgZHJhZnQgYmUgIkluZm9ybWF0aW9uYWwiIHJhdGhlciB0aGFuICJTdGFuZGFy ZHMgVHJhY2siPw0KDQpHb29kIHF1ZXN0aW9uLiBJTU8gdGhpcyBzaG91bGQgYmUgU3RhbmRhcmRz IFRyYWNrIGFzIHdlIGFyZSByZWNvbW1lbmRpbmcNCnRoZSBiZWhhdmlvciBCMkJVQXMgbXVzdCBm b2xsb3cgdG8gbWFrZSBEVExTLVNSVFAgdG8gd29yayBlbmQgdG8gZW5kLg0KDQpSZWdhcmRzLA0K UmFtDQoNCj4NCj5SZWdhcmRzDQo+QW5keQ0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IHN0cmF3IFttYWlsdG86c3RyYXctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFJhbSBNb2hhbiBSDQo+PiAocm1vaGFucikNCj4+IFNlbnQ6IDIxIEp1bmUgMjAxNCAx ODowMA0KPj4gVG86IHN0cmF3QGlldGYub3JnDQo+PiBTdWJqZWN0OiBbc3RyYXddIEZXOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJhbS1zdHJhdy0NCj4+IGIyYnVhLWR0bHMt c3J0cC0wMC50eHQNCj4+IA0KPj4gV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdGhhdCBk ZXNjcmliZXMgdGhlIGJlaGF2aW9yIEIyQlVBqfZzDQo+PiBzaG91bGQNCj4+IGZvbGxvdyB3aGVu IGFjdGluZyBvbiBhIG1lZGlhIHBsYW5lIHRoYXQgdXNlcyBEVExTLVNSVFAuDQo+PiANCj4+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhbS1zdHJhdy1iMmJ1YS1kdGxzLXNydHAt MDANCj4+IA0KPj4gDQo+PiBDb21tZW50cyBhbmQgaW5wdXRzIGFyZSB3ZWxjb21lDQo+PiANCj4+ IFJlZ2FyZHMsDQo+PiBBdXRob3JzDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+PiBGcm9tOiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPg0KPj4gRGF0ZTogU2F0dXJkYXksIDIxIEp1bmUgMjAxNCAxMTowMSBhbQ0KPj4gVG86 IFJhbSBNb2hhbiBSYXZpbmRyYW5hdGggPHJtb2hhbnJAY2lzY28uY29tPiwgIlRpcnVtYWxlc3dh ciBSZWRkeQ0KPj4gKHRpcmVkZHkpIiA8dGlyZWRkeUBjaXNjby5jb20+LCBWaWN0b3IgUGFzY3Vh bA0KPj4gPHZpY3Rvci5wYXNjdWFsQHF1b2Jpcy5jb20+LCBWaWN0b3IgUGFzY3VhbA0KPj4gPHZp Y3Rvci5wYXNjdWFsQHF1b2Jpcy5jb20+LA0KPj4gIkdvbnphbG8gU2FsZ3VlaXJvIChnc2FsZ3Vl aSkiIDxnc2FsZ3VlaUBjaXNjby5jb20+LCAiR29uemFsbyBTYWxndWVpcm8NCj4+IChnc2FsZ3Vl aSkiIDxnc2FsZ3VlaUBjaXNjby5jb20+LCAiVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSIN Cj4+IDx0aXJlZGR5QGNpc2NvLmNvbT4sIFJhbSBNb2hhbiBSYXZpbmRyYW5hdGggPHJtb2hhbnJA Y2lzY28uY29tPg0KPj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPj4g ZHJhZnQtcmFtLXN0cmF3LWIyYnVhLWR0bHMtc3J0cC0wMC50eHQNCj4+IA0KPj4gPg0KPj4gPkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yYW0tc3RyYXctYjJidWEtZHRscy1zcnRwLTAwLnR4 dA0KPj4gPmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgR29uemFsbyBTYWxndWVp cm8gYW5kIHBvc3RlZCB0byB0aGUNCj4+ID5JRVRGIHJlcG9zaXRvcnkuDQo+PiA+DQo+PiA+TmFt ZToJCWRyYWZ0LXJhbS1zdHJhdy1iMmJ1YS1kdGxzLXNydHANCj4+ID5SZXZpc2lvbjoJMDANCj4+ ID5UaXRsZToJCURUTFMtU1JUUCBIYW5kbGluZyBpbiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9j b2wNCj4+IChTSVApDQo+PiA+QmFjay10by1CYWNrIFVzZXIgQWdlbnRzIChCMkJVQXMpDQo+PiA+ RG9jdW1lbnQgZGF0ZToJMjAxNC0wNi0yMA0KPj4gPkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNz aW9uDQo+PiA+UGFnZXM6CQkxMA0KPj4gPlVSTDoNCj4+ID5odHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1yYW0tc3RyYXctYjJidWEtZHRscy1zcnRwLQ0KPj4gMDAudHh0 DQo+PiA+U3RhdHVzOg0KPj4gPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXJhbS1zdHJhdy1iMmJ1YS1kdGxzLXNydHAvDQo+PiA+SHRtbGl6ZWQ6DQo+PiA+aHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmFtLXN0cmF3LWIyYnVhLWR0bHMtc3J0cC0wMA0KPj4g Pg0KPj4gPg0KPj4gPkFic3RyYWN0Og0KPj4gPiAgIFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2Nv bCAoU0lQKSBCYWNrLXRvLUJhY2sgVXNlciBBZ2VudHMgKEIyQlVBcykNCj4+ID4gICBvZnRlbiBm dW5jdGlvbiBvbiB0aGUgbWVkaWEgcGxhbmUsIHJhdGhlciB0aGFuIGp1c3Qgb24gdGhlDQo+PiBz aWduYWxpbmcNCj4+ID4gICBwYXRoLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIGJlaGF2 aW9yIEIyQlVBcyBzaG91bGQgZm9sbG93DQo+PiB3aGVuDQo+PiA+ICAgYWN0aW5nIG9uIHRoZSBt ZWRpYSBwbGFuZSB0aGF0IHVzZSBTZWN1cmUgUmVhbC10aW1lIFRyYW5zcG9ydA0KPj4gPiAgIFBy b3RvY29sIChTUlRQKSBzZWN1cml0eSBjb250ZXh0IHNldHVwIHdpdGggRGF0YWdyYW0gVHJhbnNw b3J0DQo+PiBMYXllcg0KPj4gPiAgIFNlY3VyaXR5IChEVExTKSBwcm90b2NvbC4NCj4+ID4NCj4+ ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPj4gPnN1Ym1pc3Npb24NCj4+ID51 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KPj4gPg0KPj4gPlRoZSBJRVRGIFNlY3JldGFyaWF0DQo+PiA+DQo+PiANCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzdHJh dyBtYWlsaW5nIGxpc3QNCj4+IHN0cmF3QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3N0cmF3DQoNCg== From nobody Tue Jul 22 11:10:54 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 1FE971B2B54 for ; Tue, 22 Jul 2014 11:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7vOqX1TkteAh for ; Tue, 22 Jul 2014 11:10:49 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE201B2B59 for ; Tue, 22 Jul 2014 11:10:49 -0700 (PDT) Received: from userPC (unknown [122.178.241.128]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 57B081908125; Tue, 22 Jul 2014 18:10:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1406052647; bh=PxQZA8emVxYT+DhAA6i1XG2+y2xEpT9dIkKhJtzW6XU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=RK5Sdjp2A5i2uiWxCcU29rczB1dIUJz7R2TERyUcXX7sQNu9bnJDJ2CZZ+5ncrule M9/jdljaT/cHNUNOoS5rNPmOsY2rqq0G43KXsJmMBJ6/lYAG5jLhlFUBiA49PJJi0v d6N7cb4WyAYtyyZ6CQOe5vuuz8gh1T81cO19Fsdg= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , References: <20140704143857.20390.70771.idtracker@ietfa.amsl.com> <001b01cfa227$237220a0$6a5661e0$@co.in> In-Reply-To: Date: Tue, 22 Jul 2014 23:40:37 +0530 Message-ID: <014801cfa5d8$40381550$c0a83ff0$@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: AQHPl5WxNmloNut7lEmP8rilhPLVnZusfacg Content-Language: en-us X-CTCH-RefID: str=0001.0A02020A.53CEA925.0126, 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: 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.92 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/m7lGqjtVzqxUF_5YcXuH5QYGF2g Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.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: Tue, 22 Jul 2014 18:10:52 -0000 Hi Ram, In case of ICE termination of B2BUA with ICE-lite, ICE connectivity check starts from both UA side and the text has to be added to mention any initial media clipping will happen because of B2BUA with ICE-lite and the recommendation to avoid this situation in B2BUA implementation. In case of ICE pass through of B2BUA with ICE-lite, whether it is allowed to pass ICE connectivity check end-to-end through B2BUA and any side effects because of the same? Thanks Partha > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Tuesday, July 22, 2014 8:25 AM > To: Parthasarathi R; straw@ietf.org > Subject: Re: [straw] FW: New Version Notification for draft-ram-straw- > b2bua-stun-00.txt > > Please see inline > > -----Original Message----- > From: Parthasarathi R > Date: Friday, 18 July 2014 6:55 am > To: Ram Mohan Ravindranath , "straw@ietf.org" > > Subject: RE: [straw] FW: New Version Notification > for draft-ram-straw-b2bua-stun-00.txt > > >Hi Ram, > > > >The draft approach looks good. The following aspect has to be > considered > > > >1) ICE-TCP handling in STUN traversal > > Will add some text for this in the next revision. > > >2) In case B2BUA is ICE-lite, the impact of STUN traversal w.r.t ICE > >termination and ICE passthrough mode in B2BUA. > > Is there any thing that you would like to see explicitly added for ICE > lite ? All the procedures of ICE termination/ICE passthrough are > equally > applicable for Ice lite mode as well. > > Regards, > Ram > > > > >Thanks > >Partha > > > >> -----Original Message----- > >> From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Ram Mohan R > >> (rmohanr) > >> Sent: Friday, July 04, 2014 8:13 PM > >> To: straw@ietf.org > >> Subject: [straw] FW: New Version Notification for draft-ram-straw- > >> b2bua-stun-00.txt > >> > >> We have submitted a draft that describes the behavior B2BUAs should > >> follow when acting on a media plane that receives STUN messages as > part > >> of > >> ICE processing. > >> > >> http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun- > 00.txt > >> > >> > >> Comments and suggestions on how to make the draft better are > welcome. > >> > >> Regards, > >> Authors. > >> > >> > >> > >> -----Original Message----- > >> From: "internet-drafts@ietf.org" > >> Date: Friday, 4 July 2014 8:08 pm > >> To: Ram Mohan Ravindranath , "Tirumaleswar Reddy > >> (tireddy)" , "Gonzalo Salgueiro (gsalguei)" > >> , "Gonzalo Salgueiro (gsalguei)" > >> , > >> "Tirumaleswar Reddy (tireddy)" , Ram Mohan > >> Ravindranath > >> > >> Subject: New Version Notification for draft-ram-straw-b2bua-stun- > 00.txt > >> > >> > > >> >A new version of I-D, draft-ram-straw-b2bua-stun-00.txt > >> >has been successfully submitted by Ram Mohan Ravindranath and > posted > >> to > >> >the > >> >IETF repository. > >> > > >> >Name: draft-ram-straw-b2bua-stun > >> >Revision: 00 > >> >Title: Session Traversal Utilities for NAT (STUN) Message > >> Handling for > >> >Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) > >> >Document date: 2014-07-04 > >> >Group: Individual Submission > >> >Pages: 14 > >> >URL: > >> >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun- > 00.txt > >> >Status: > >> >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-stun/ > >> >Htmlized: http://tools.ietf.org/html/draft-ram-straw-b2bua- > stun- > >> 00 > >> > > >> > > >> >Abstract: > >> > Session Initiation Protocol (SIP) Back-to-Back User Agents > (B2BUAs) > >> > are often designed to be on the media path, rather than just > >> > intercepting signaling. This means that B2BUAs often act on the > >> > media path leading to separate media legs that the B2BUA > correlates > >> > and bridges together. When acting on the media path, B2BUAs are > >> > likely to receive Session Traversal Utilities for NAT (STUN) > >> packets > >> > as part of Interactive Connectivity Establishment (ICE) > processing. > >> > It is critical that B2BUAs handle these STUN messages properly. > >> > > >> > This document defines behavior for a B2BUA performing ICE > >> processing. > >> > > >> > > >> > > >> > > >> > > >> >Please note that it may take a couple of minutes from the time of > >> >submission > >> >until the htmlized version and diff are available at > tools.ietf.org. > >> > > >> >The IETF Secretariat > >> > > >> > >> _______________________________________________ > >> straw mailing list > >> straw@ietf.org > >> https://www.ietf.org/mailman/listinfo/straw > > From nobody Thu Jul 24 07:34:36 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 4AD181A034B for ; Thu, 24 Jul 2014 07:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gKfId9qZhje for ; Thu, 24 Jul 2014 07:34:32 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB2B1A03A8 for ; Thu, 24 Jul 2014 07:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6264; q=dns/txt; s=iport; t=1406212451; x=1407422051; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oCSVmiM53nPe+6NIGAG51fEXouxO5bcieb/QFNhS+Ks=; b=iOAIZBMQCH3IB/khIJDbpt+A3gZDIFA5wub4njnI3ppky8/vjcZTuxc6 O/UFsJpvQ46SDxI9+FFGtJ3NzjoquNWLKjNHXm1kFchKhpJud8UC88Xdw s+Kfd/qxnRibIrrP8b59qW4BtYQvLbi/z5Ei0eOgqyYNbFYyNeAgHakbr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAMAY0VOtJV2P/2dsb2JhbABZgw5SVwTJKQqHRQGBDRZ3hAMBAQEEAQEBawkOBAIBCBEDAQEBKAcnCxQIAQgCBAESCYg5DcBfF49SBoRABYovkQSBUpJwg0hsgUU X-IronPort-AV: E=Sophos;i="5.01,724,1400025600"; d="scan'208";a="63685653" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP; 24 Jul 2014 14:34:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s6OEYAXv022349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Jul 2014 14:34:10 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 09:34:10 -0500 From: "Ram Mohan R (rmohanr)" To: Parthasarathi R , "straw@ietf.org" Thread-Topic: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.txt Thread-Index: AQHPl5WxNmloNut7lEmP8rilhPLVnQ== Date: Thu, 24 Jul 2014 14:34:09 +0000 Message-ID: References: <20140704143857.20390.70771.idtracker@ietfa.amsl.com> <001b01cfa227$237220a0$6a5661e0$@co.in> <014801cfa5d8$40381550$c0a83ff0$@co.in> In-Reply-To: <014801cfa5d8$40381550$c0a83ff0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.76.173] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1B0597CAFC918D47A2276F3F83994757@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/P6DcBqoSXAYR7U4Ia5_XB1L8-V8 Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.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: Thu, 24 Jul 2014 14:34:34 -0000 Please see inline -----Original Message----- From: Parthasarathi R Date: Tuesday, 22 July 2014 11:40 pm To: Ram Mohan Ravindranath , "straw@ietf.org" Subject: RE: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.txt >Hi Ram, > >In case of ICE termination of B2BUA with ICE-lite, ICE connectivity check >starts from both UA side and the text has to be added to mention any >initial >media clipping will happen because of B2BUA with ICE-lite and the >recommendation to avoid this situation in B2BUA implementation. Irrespective of whether ICE-lite or full ICE, media clip is possible when ICE is terminated at B2BUA as there are two independent ICE contexts on each side of B2BUA. There is already some text in section 3.2. "Since there are two independent ICE contexts on either side of the B2BUA it is possible that ICE checks will conclude on one side before concluding on the other side. This could result in an ongoing media session for one end, while the other is still being set up. Any such media received by the B2BUA would continue to be sent to the other side on the default candidate address (that was sent in c=3D line).=B2 Let me know if this is not sufficient. >=20 > >In case of ICE pass through of B2BUA with ICE-lite, whether it is allowed >to >pass ICE connectivity check end-to-end through B2BUA and any side effects >because of the same? What side-effects do you for-see ? If the B2BUA is in ICE passthrough it will pass the ICE messages end to end by changing the UDP/IP header. Regards, Ram > >Thanks >Partha > >> -----Original Message----- >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> Sent: Tuesday, July 22, 2014 8:25 AM >> To: Parthasarathi R; straw@ietf.org >> Subject: Re: [straw] FW: New Version Notification for draft-ram-straw- >> b2bua-stun-00.txt >>=20 >> Please see inline >>=20 >> -----Original Message----- >> From: Parthasarathi R >> Date: Friday, 18 July 2014 6:55 am >> To: Ram Mohan Ravindranath , "straw@ietf.org" >> >> Subject: RE: [straw] FW: New Version Notification >> for draft-ram-straw-b2bua-stun-00.txt >>=20 >> >Hi Ram, >> > >> >The draft approach looks good. The following aspect has to be >> considered >> > >> >1) ICE-TCP handling in STUN traversal >>=20 >> Will add some text for this in the next revision. >>=20 >> >2) In case B2BUA is ICE-lite, the impact of STUN traversal w.r.t ICE >> >termination and ICE passthrough mode in B2BUA. >>=20 >> Is there any thing that you would like to see explicitly added for ICE >> lite ? All the procedures of ICE termination/ICE passthrough are >> equally >> applicable for Ice lite mode as well. >>=20 >> Regards, >> Ram >>=20 >> > >> >Thanks >> >Partha >> > >> >> -----Original Message----- >> >> From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Ram Mohan R >> >> (rmohanr) >> >> Sent: Friday, July 04, 2014 8:13 PM >> >> To: straw@ietf.org >> >> Subject: [straw] FW: New Version Notification for draft-ram-straw- >> >> b2bua-stun-00.txt >> >> >> >> We have submitted a draft that describes the behavior B2BUAs should >> >> follow when acting on a media plane that receives STUN messages as >> part >> >> of >> >> ICE processing. >> >> >> >> http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun- >> 00.txt >> >> >> >> >> >> Comments and suggestions on how to make the draft better are >> welcome. >> >> >> >> Regards, >> >> Authors. >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: "internet-drafts@ietf.org" >> >> Date: Friday, 4 July 2014 8:08 pm >> >> To: Ram Mohan Ravindranath , "Tirumaleswar Reddy >> >> (tireddy)" , "Gonzalo Salgueiro (gsalguei)" >> >> , "Gonzalo Salgueiro (gsalguei)" >> >> , >> >> "Tirumaleswar Reddy (tireddy)" , Ram Mohan >> >> Ravindranath >> >> >> >> Subject: New Version Notification for draft-ram-straw-b2bua-stun- >> 00.txt >> >> >> >> > >> >> >A new version of I-D, draft-ram-straw-b2bua-stun-00.txt >> >> >has been successfully submitted by Ram Mohan Ravindranath and >> posted >> >> to >> >> >the >> >> >IETF repository. >> >> > >> >> >Name: draft-ram-straw-b2bua-stun >> >> >Revision: 00 >> >> >Title: Session Traversal Utilities for NAT (STUN) Message >> >> Handling for >> >> >Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUAs) >> >> >Document date: 2014-07-04 >> >> >Group: Individual Submission >> >> >Pages: 14 >> >> >URL: >> >> >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun- >> 00.txt >> >> >Status: >> >> >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-stun/ >> >> >Htmlized: http://tools.ietf.org/html/draft-ram-straw-b2bua- >> stun- >> >> 00 >> >> > >> >> > >> >> >Abstract: >> >> > Session Initiation Protocol (SIP) Back-to-Back User Agents >> (B2BUAs) >> >> > are often designed to be on the media path, rather than just >> >> > intercepting signaling. This means that B2BUAs often act on the >> >> > media path leading to separate media legs that the B2BUA >> correlates >> >> > and bridges together. When acting on the media path, B2BUAs are >> >> > likely to receive Session Traversal Utilities for NAT (STUN) >> >> packets >> >> > as part of Interactive Connectivity Establishment (ICE) >> processing. >> >> > It is critical that B2BUAs handle these STUN messages properly. >> >> > >> >> > This document defines behavior for a B2BUA performing ICE >> >> processing. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >Please note that it may take a couple of minutes from the time of >> >> >submission >> >> >until the htmlized version and diff are available at >> tools.ietf.org. >> >> > >> >> >The IETF Secretariat >> >> > >> >> >> >> _______________________________________________ >> >> straw mailing list >> >> straw@ietf.org >> >> https://www.ietf.org/mailman/listinfo/straw >> > > From nobody Thu Jul 24 14:49:12 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 954B71B2904 for ; Thu, 24 Jul 2014 14:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s29yOd9N8Gdk for ; Thu, 24 Jul 2014 14:49:08 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9138C1B2913 for ; Thu, 24 Jul 2014 14:49:08 -0700 (PDT) Received: from userPC (unknown [122.167.76.199]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 4CE0318C80CC; Thu, 24 Jul 2014 21:49:07 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1406238550; bh=8KKHl6q1GytPBvDmenVlVu99J2Ve9Mrn3U3prKfdNdU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CMTQiZ+xHPOV1QY2fyp1n3qCsxC5YYBhpQVjxOZPerTNH+swmEM+59j9loBnZsXny nge5uaIG3H0dinroEwnEq96+5UFAto+I5DYntzX1tj+cMOw0YnUKj5rWJx+zsWEHe3 30ovrFEm0m3gnYp6EIEXWc5tTlh84/5wIlDAEYVA= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , References: <20140704143857.20390.70771.idtracker@ietfa.amsl.com> <001b01cfa227$237220a0$6a5661e0$@co.in> <014801cfa5d8$40381550$c0a83ff0$@co.in> In-Reply-To: Date: Fri, 25 Jul 2014 03:18:57 +0530 Message-ID: <00e801cfa789$15065b50$3f1311f0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPl5WxNmloNut7lEmP8rilhPLVnZuv3VYg Content-Language: en-us X-CTCH-RefID: str=0001.0A020206.53D17F53.0115, 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: 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/RRgpzTeIKoOsutFs3JFkGgKJN3s Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.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: Thu, 24 Jul 2014 21:49:10 -0000 Hi Ram, Please read inline. Thanks Partha > -----Original Message----- > From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > Sent: Thursday, July 24, 2014 8:04 PM > To: Parthasarathi R; straw@ietf.org > Subject: Re: [straw] FW: New Version Notification for draft-ram-straw- > b2bua-stun-00.txt >=20 > Please see inline >=20 > -----Original Message----- > From: Parthasarathi R > Date: Tuesday, 22 July 2014 11:40 pm > To: Ram Mohan Ravindranath , "straw@ietf.org" > > Subject: RE: [straw] FW: New Version Notification for > draft-ram-straw-b2bua-stun-00.txt >=20 > >Hi Ram, > > > >In case of ICE termination of B2BUA with ICE-lite, ICE connectivity > check > >starts from both UA side and the text has to be added to mention any > >initial > >media clipping will happen because of B2BUA with ICE-lite and the > >recommendation to avoid this situation in B2BUA implementation. >=20 > Irrespective of whether ICE-lite or full ICE, media clip is possible > when > ICE is terminated at B2BUA as there are two independent ICE contexts = on > each side of B2BUA. > There is already some text in section 3.2. >=20 > "Since there are two independent ICE contexts on either side of the > B2BUA it is possible that ICE checks will conclude on one side > before > concluding on the other side. This could result in an ongoing = media > session for one end, while the other is still being set up. Any > such > media received by the B2BUA would continue to be sent to the other > side on the default candidate address (that was sent in c=3D = line).=B2 >=20 > Let me know if this is not sufficient. In case of Full ICE, it is possible for media clip whereas in ICE-lite, the media clipping occurs in all the scenario. It is better to highlight this difference as it is the good information for the implementation. =20 >=20 > > > > > > >In case of ICE pass through of B2BUA with ICE-lite, whether it is > allowed > >to > >pass ICE connectivity check end-to-end through B2BUA and any side > effects > >because of the same? >=20 > What side-effects do you for-see ? If the B2BUA is in ICE passthrough > it > will pass the ICE messages end to end by changing the UDP/IP header. >=20 The callflow about this behavior will help as ICE-Lite is not initiating any response for connectivity check but the connectivity = check will be completed. It is not trivial to explain to any implementers as = the connectivity check is actually expected between UA & B2BUA whereas here, = it occurs end-to-end but looks hop-by-hop in terms of ICE. =20 > Regards, > Ram >=20 > > > >Thanks > >Partha > > > >> -----Original Message----- > >> From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >> Sent: Tuesday, July 22, 2014 8:25 AM > >> To: Parthasarathi R; straw@ietf.org > >> Subject: Re: [straw] FW: New Version Notification for draft-ram- > straw- > >> b2bua-stun-00.txt > >> > >> Please see inline > >> > >> -----Original Message----- > >> From: Parthasarathi R > >> Date: Friday, 18 July 2014 6:55 am > >> To: Ram Mohan Ravindranath , "straw@ietf.org" > >> > >> Subject: RE: [straw] FW: New Version Notification > >> for draft-ram-straw-b2bua-stun-00.txt > >> > >> >Hi Ram, > >> > > >> >The draft approach looks good. The following aspect has to be > >> considered > >> > > >> >1) ICE-TCP handling in STUN traversal > >> > >> Will add some text for this in the next revision. > >> > >> >2) In case B2BUA is ICE-lite, the impact of STUN traversal w.r.t > ICE > >> >termination and ICE passthrough mode in B2BUA. > >> > >> Is there any thing that you would like to see explicitly added for > ICE > >> lite ? All the procedures of ICE termination/ICE passthrough are > >> equally > >> applicable for Ice lite mode as well. > >> > >> Regards, > >> Ram > >> > >> > > >> >Thanks > >> >Partha > >> > > >> >> -----Original Message----- > >> >> From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Ram > Mohan R > >> >> (rmohanr) > >> >> Sent: Friday, July 04, 2014 8:13 PM > >> >> To: straw@ietf.org > >> >> Subject: [straw] FW: New Version Notification for draft-ram- > straw- > >> >> b2bua-stun-00.txt > >> >> > >> >> We have submitted a draft that describes the behavior B2BUAs > should > >> >> follow when acting on a media plane that receives STUN messages > as > >> part > >> >> of > >> >> ICE processing. > >> >> > >> >> http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun- > >> 00.txt > >> >> > >> >> > >> >> Comments and suggestions on how to make the draft better are > >> welcome. > >> >> > >> >> Regards, > >> >> Authors. > >> >> > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: "internet-drafts@ietf.org" > >> >> Date: Friday, 4 July 2014 8:08 pm > >> >> To: Ram Mohan Ravindranath , "Tirumaleswar > Reddy > >> >> (tireddy)" , "Gonzalo Salgueiro (gsalguei)" > >> >> , "Gonzalo Salgueiro (gsalguei)" > >> >> , > >> >> "Tirumaleswar Reddy (tireddy)" , Ram Mohan > >> >> Ravindranath > >> >> > >> >> Subject: New Version Notification for = draft-ram-straw-b2bua-stun- > >> 00.txt > >> >> > >> >> > > >> >> >A new version of I-D, draft-ram-straw-b2bua-stun-00.txt > >> >> >has been successfully submitted by Ram Mohan Ravindranath and > >> posted > >> >> to > >> >> >the > >> >> >IETF repository. > >> >> > > >> >> >Name: draft-ram-straw-b2bua-stun > >> >> >Revision: 00 > >> >> >Title: Session Traversal Utilities for NAT (STUN) > Message > >> >> Handling for > >> >> >Session Initiation Protocol (SIP) Back-to-Back User Agents > (B2BUAs) > >> >> >Document date: 2014-07-04 > >> >> >Group: Individual Submission > >> >> >Pages: 14 > >> >> >URL: > >> >> >http://www.ietf.org/internet-drafts/draft-ram-straw-b2bua-stun- > >> 00.txt > >> >> >Status: > >> >> >https://datatracker.ietf.org/doc/draft-ram-straw-b2bua-stun/ > >> >> >Htmlized: http://tools.ietf.org/html/draft-ram-straw- > b2bua- > >> stun- > >> >> 00 > >> >> > > >> >> > > >> >> >Abstract: > >> >> > Session Initiation Protocol (SIP) Back-to-Back User Agents > >> (B2BUAs) > >> >> > are often designed to be on the media path, rather than just > >> >> > intercepting signaling. This means that B2BUAs often act on > the > >> >> > media path leading to separate media legs that the B2BUA > >> correlates > >> >> > and bridges together. When acting on the media path, B2BUAs > are > >> >> > likely to receive Session Traversal Utilities for NAT (STUN) > >> >> packets > >> >> > as part of Interactive Connectivity Establishment (ICE) > >> processing. > >> >> > It is critical that B2BUAs handle these STUN messages > properly. > >> >> > > >> >> > This document defines behavior for a B2BUA performing ICE > >> >> processing. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >Please note that it may take a couple of minutes from the time > of > >> >> >submission > >> >> >until the htmlized version and diff are available at > >> tools.ietf.org. > >> >> > > >> >> >The IETF Secretariat > >> >> > > >> >> > >> >> _______________________________________________ > >> >> straw mailing list > >> >> straw@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/straw > >> > > > From nobody Thu Jul 24 19:59:00 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 06FAF1A0161 for ; Thu, 24 Jul 2014 19:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18fcmZymj_Uk for ; Thu, 24 Jul 2014 19:58:56 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41E51A004D for ; Thu, 24 Jul 2014 19:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11766; q=dns/txt; s=iport; t=1406257135; x=1407466735; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0NhL70InfbSc5K9pXUv+Z/R1J3TvX8XLewn/XZv7qkY=; b=SrPhf2L/x1ijHRgLm6+/U0aVYhLzD3OZjhCkyGwDLqYpqsKdxD2bqB0n 2jgHAhmZ8h1FSPzJUbsp/RoggqLy+kpBjvawv4Y6svdtzoKZZ5bUHpWdR 1h/Nz3WaQIIbQ8dcBNY+JNvTfVIqK0Sabv4jgK9vMegiB6SKhhC2sUynr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUFAFnH0VOtJA2K/2dsb2JhbABZgw5SVwSCdMZMCodFARl5FneEAwEBAQQBAQExOgkOBAIBCBEDAQEBBSMFAgIlCxQIAQgCBAESCYg5DYtjnCgGl0IXgSaNejICAgKCbIFVBZs9gVKSdoNIbIFF X-IronPort-AV: E=Sophos;i="5.01,727,1400025600"; d="scan'208";a="63864017" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 25 Jul 2014 02:58:54 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s6P2wsvf032535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Jul 2014 02:58:54 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.10]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 24 Jul 2014 21:58:54 -0500 From: "Ram Mohan R (rmohanr)" To: Parthasarathi R , "straw@ietf.org" Thread-Topic: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.txt Thread-Index: AQHPl5WxNmloNut7lEmP8rilhPLVnQ== Date: Fri, 25 Jul 2014 02:58:53 +0000 Message-ID: References: <20140704143857.20390.70771.idtracker@ietfa.amsl.com> <001b01cfa227$237220a0$6a5661e0$@co.in> <014801cfa5d8$40381550$c0a83ff0$@co.in> <00e801cfa789$15065b50$3f1311f0$@co.in> In-Reply-To: <00e801cfa789$15065b50$3f1311f0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [173.39.64.102] Content-Type: text/plain; charset="euc-kr" Content-ID: <9CF3C9C2C9A389498949013BBED24BE7@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/sbapDrmRPJk0VcCtFK_kQnS0jlU Subject: Re: [straw] FW: New Version Notification for draft-ram-straw-b2bua-stun-00.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, 25 Jul 2014 02:58:59 -0000 U2VlIGlubGluZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGFydGhhc2Fy YXRoaSBSIDxwYXJ0aGFAcGFydGhhc2FyYXRoaS5jby5pbj4NCkRhdGU6IEZyaWRheSwgMjUgSnVs eSAyMDE0IDM6MTggYW0NClRvOiBSYW0gTW9oYW4gUmF2aW5kcmFuYXRoIDxybW9oYW5yQGNpc2Nv LmNvbT4sICJzdHJhd0BpZXRmLm9yZyINCjxzdHJhd0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBb c3RyYXddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQpkcmFmdC1yYW0tc3RyYXct YjJidWEtc3R1bi0wMC50eHQNCg0KPkhpIFJhbSwNCj4NCj5QbGVhc2UgcmVhZCBpbmxpbmUuDQo+ DQo+VGhhbmtzDQo+UGFydGhhDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogUmFtIE1vaGFuIFIgKHJtb2hhbnIpIFttYWlsdG86cm1vaGFuckBjaXNjby5jb21dDQo+ PiBTZW50OiBUaHVyc2RheSwgSnVseSAyNCwgMjAxNCA4OjA0IFBNDQo+PiBUbzogUGFydGhhc2Fy YXRoaSBSOyBzdHJhd0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzdHJhd10gRlc6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtcmFtLXN0cmF3LQ0KPj4gYjJidWEtc3R1bi0w MC50eHQNCj4+IA0KPj4gUGxlYXNlIHNlZSBpbmxpbmUNCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+IEZyb206IFBhcnRoYXNhcmF0aGkgUiA8cGFydGhhQHBhcnRoYXNhcmF0 aGkuY28uaW4+DQo+PiBEYXRlOiBUdWVzZGF5LCAyMiBKdWx5IDIwMTQgMTE6NDAgcG0NCj4+IFRv OiBSYW0gTW9oYW4gUmF2aW5kcmFuYXRoIDxybW9oYW5yQGNpc2NvLmNvbT4sICJzdHJhd0BpZXRm Lm9yZyINCj4+IDxzdHJhd0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJFOiBbc3RyYXddIEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+PiBkcmFmdC1yYW0tc3RyYXctYjJidWEtc3R1 bi0wMC50eHQNCj4+IA0KPj4gPkhpIFJhbSwNCj4+ID4NCj4+ID5JbiBjYXNlIG9mIElDRSB0ZXJt aW5hdGlvbiBvZiBCMkJVQSB3aXRoIElDRS1saXRlLCBJQ0UgY29ubmVjdGl2aXR5DQo+PiBjaGVj aw0KPj4gPnN0YXJ0cyBmcm9tIGJvdGggVUEgc2lkZSBhbmQgdGhlIHRleHQgaGFzIHRvIGJlIGFk ZGVkIHRvIG1lbnRpb24gYW55DQo+PiA+aW5pdGlhbA0KPj4gPm1lZGlhIGNsaXBwaW5nIHdpbGwg aGFwcGVuIGJlY2F1c2Ugb2YgQjJCVUEgd2l0aCBJQ0UtbGl0ZSBhbmQgdGhlDQo+PiA+cmVjb21t ZW5kYXRpb24gdG8gYXZvaWQgdGhpcyBzaXR1YXRpb24gaW4gQjJCVUEgaW1wbGVtZW50YXRpb24u DQo+PiANCj4+IElycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIElDRS1saXRlIG9yIGZ1bGwgSUNFLCBt ZWRpYSBjbGlwIGlzIHBvc3NpYmxlDQo+PiB3aGVuDQo+PiBJQ0UgaXMgdGVybWluYXRlZCBhdCBC MkJVQSBhcyB0aGVyZSBhcmUgdHdvIGluZGVwZW5kZW50IElDRSBjb250ZXh0cyBvbg0KPj4gZWFj aCBzaWRlIG9mIEIyQlVBLg0KPj4gVGhlcmUgaXMgYWxyZWFkeSBzb21lIHRleHQgaW4gc2VjdGlv biAzLjIuDQo+PiANCj4+ICJTaW5jZSB0aGVyZSBhcmUgdHdvIGluZGVwZW5kZW50IElDRSBjb250 ZXh0cyBvbiBlaXRoZXIgc2lkZSBvZiB0aGUNCj4+ICAgIEIyQlVBIGl0IGlzIHBvc3NpYmxlIHRo YXQgSUNFIGNoZWNrcyB3aWxsIGNvbmNsdWRlIG9uIG9uZSBzaWRlDQo+PiBiZWZvcmUNCj4+ICAg IGNvbmNsdWRpbmcgb24gdGhlIG90aGVyIHNpZGUuICBUaGlzIGNvdWxkIHJlc3VsdCBpbiBhbiBv bmdvaW5nIG1lZGlhDQo+PiAgICBzZXNzaW9uIGZvciBvbmUgZW5kLCB3aGlsZSB0aGUgb3RoZXIg aXMgc3RpbGwgYmVpbmcgc2V0IHVwLiAgQW55DQo+PiBzdWNoDQo+PiAgICBtZWRpYSByZWNlaXZl ZCBieSB0aGUgQjJCVUEgd291bGQgY29udGludWUgdG8gYmUgc2VudCB0byB0aGUgb3RoZXINCj4+ ICAgIHNpZGUgb24gdGhlIGRlZmF1bHQgY2FuZGlkYXRlIGFkZHJlc3MgKHRoYXQgd2FzIHNlbnQg aW4gYz0gbGluZSkuqfcNCj4+IA0KPj4gTGV0IG1lIGtub3cgaWYgdGhpcyBpcyBub3Qgc3VmZmlj aWVudC4NCj48UGFydGhhPiAgSW4gY2FzZSBvZiBGdWxsIElDRSwgaXQgaXMgcG9zc2libGUgZm9y IG1lZGlhIGNsaXAgd2hlcmVhcyBpbg0KPklDRS1saXRlLCB0aGUgbWVkaWEgY2xpcHBpbmcgb2Nj dXJzIGluIGFsbCB0aGUgc2NlbmFyaW8uIEl0IGlzIGJldHRlciB0bw0KPmhpZ2hsaWdodCB0aGlz IGRpZmZlcmVuY2UgYXMgaXQgaXMgdGhlIGdvb2QgaW5mb3JtYXRpb24gZm9yIHRoZQ0KPmltcGxl bWVudGF0aW9uLiA8L1BhcnRoYT4NCg0KTWVkaWEgY2xpcCBpcyBwb3NzaWJsZSBmb3IgZnVsbCBJ Q0UgYXMgd2VsbC4gV2hlbiBCMkJVQSBpcyB0ZXJtaW5hdGluZyBJQ0UNCm9uIGVhY2ggc2lkZSwg dGhlcmUgd2lsbCBiZSB0d28gSUNFIHNlc3Npb25zLiBUaGUgSUNFIGNvbmNsdXNpb24gb24gZWFj aA0Kc2lkZSBjYW4gaGFwcGVuIGF0IGRpZmZlcmVudCB0aW1lcy4gVGhpcyBpcyBpcnJlc3BlY3Rp dmUgb2Ygd2hldGhlciBCMkJVQQ0KaXMgaW4gZnVsbCBJQ0Ugb3IgSWNlLWxpdGUuIEFtIEkgbWlz c2luZyBzb21lIHRoaW5nIGhlcmUgPw0KDQo+DQo+PiANCj4+DQo+PiA+DQo+PiA+DQo+PiA+SW4g Y2FzZSBvZiBJQ0UgcGFzcyB0aHJvdWdoIG9mIEIyQlVBIHdpdGggSUNFLWxpdGUsIHdoZXRoZXIg aXQgaXMNCj4+IGFsbG93ZWQNCj4+ID50bw0KPj4gPnBhc3MgSUNFIGNvbm5lY3Rpdml0eSBjaGVj ayBlbmQtdG8tZW5kIHRocm91Z2ggQjJCVUEgYW5kIGFueSBzaWRlDQo+PiBlZmZlY3RzDQo+PiA+ YmVjYXVzZSBvZiB0aGUgc2FtZT8NCj4+IA0KPj4gV2hhdCBzaWRlLWVmZmVjdHMgZG8geW91IGZv ci1zZWUgPyBJZiB0aGUgQjJCVUEgaXMgaW4gSUNFIHBhc3N0aHJvdWdoDQo+PiBpdA0KPj4gd2ls bCBwYXNzIHRoZSBJQ0UgbWVzc2FnZXMgZW5kIHRvIGVuZCBieSBjaGFuZ2luZyB0aGUgVURQL0lQ IGhlYWRlci4NCj4+IA0KPjxQYXJ0aGE+IFRoZSBjYWxsZmxvdyBhYm91dCB0aGlzIGJlaGF2aW9y IHdpbGwgaGVscCBhcyBJQ0UtTGl0ZSBpcyBub3QNCj5pbml0aWF0aW5nIGFueSByZXNwb25zZSBm b3IgY29ubmVjdGl2aXR5IGNoZWNrDQoNCiBUaGUgSUNFIGxpdGUgZW5kcG9pbnQgd2lsbCBzdGls bCByZXNwb25kIHRvIGNvbm5lY3Rpdml0eSBjaGVja3MgYnV0IGRvZXMNCm5vdCBnZW5lcmF0ZSBj b25uZWN0aXZpdHkgcmVxdWVzdHMuDQoNCg0KUmVnYXJkcywNClJhbQ0KDQo+YnV0IHRoZSBjb25u ZWN0aXZpdHkgY2hlY2sNCj53aWxsIGJlIGNvbXBsZXRlZC4gSXQgaXMgbm90IHRyaXZpYWwgdG8g ZXhwbGFpbiB0byBhbnkgaW1wbGVtZW50ZXJzIGFzIHRoZQ0KPmNvbm5lY3Rpdml0eSBjaGVjayBp cyBhY3R1YWxseSBleHBlY3RlZCBiZXR3ZWVuIFVBICYgQjJCVUEgd2hlcmVhcyBoZXJlLA0KPml0 DQo+b2NjdXJzIGVuZC10by1lbmQgYnV0IGxvb2tzIGhvcC1ieS1ob3AgaW4gdGVybXMgb2YgSUNF LiA8L1BhcnRoYT4NCg0KDQo+IA0KPg0KPj4gUmVnYXJkcywNCj4+IFJhbQ0KPj4gDQo+PiA+DQo+ PiA+VGhhbmtzDQo+PiA+UGFydGhhDQo+PiA+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4gPj4gRnJvbTogUmFtIE1vaGFuIFIgKHJtb2hhbnIpIFttYWlsdG86cm1vaGFuckBj aXNjby5jb21dDQo+PiA+PiBTZW50OiBUdWVzZGF5LCBKdWx5IDIyLCAyMDE0IDg6MjUgQU0NCj4+ ID4+IFRvOiBQYXJ0aGFzYXJhdGhpIFI7IHN0cmF3QGlldGYub3JnDQo+PiA+PiBTdWJqZWN0OiBS ZTogW3N0cmF3XSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1yYW0tDQo+ PiBzdHJhdy0NCj4+ID4+IGIyYnVhLXN0dW4tMDAudHh0DQo+PiA+Pg0KPj4gPj4gUGxlYXNlIHNl ZSBpbmxpbmUNCj4+ID4+DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4g RnJvbTogUGFydGhhc2FyYXRoaSBSIDxwYXJ0aGFAcGFydGhhc2FyYXRoaS5jby5pbj4NCj4+ID4+ IERhdGU6IEZyaWRheSwgMTggSnVseSAyMDE0IDY6NTUgYW0NCj4+ID4+IFRvOiBSYW0gTW9oYW4g UmF2aW5kcmFuYXRoIDxybW9oYW5yQGNpc2NvLmNvbT4sICJzdHJhd0BpZXRmLm9yZyINCj4+ID4+ IDxzdHJhd0BpZXRmLm9yZz4NCj4+ID4+IFN1YmplY3Q6IFJFOiBbc3RyYXddIEZXOiBOZXcgVmVy c2lvbiBOb3RpZmljYXRpb24NCj4+ID4+IGZvcglkcmFmdC1yYW0tc3RyYXctYjJidWEtc3R1bi0w MC50eHQNCj4+ID4+DQo+PiA+PiA+SGkgUmFtLA0KPj4gPj4gPg0KPj4gPj4gPlRoZSBkcmFmdCBh cHByb2FjaCBsb29rcyBnb29kLiBUaGUgZm9sbG93aW5nIGFzcGVjdCBoYXMgdG8gYmUNCj4+ID4+ IGNvbnNpZGVyZWQNCj4+ID4+ID4NCj4+ID4+ID4xKSBJQ0UtVENQIGhhbmRsaW5nIGluIFNUVU4g dHJhdmVyc2FsDQo+PiA+Pg0KPj4gPj4gV2lsbCBhZGQgc29tZSB0ZXh0IGZvciB0aGlzIGluIHRo ZSBuZXh0IHJldmlzaW9uLg0KPj4gPj4NCj4+ID4+ID4yKSBJbiBjYXNlIEIyQlVBIGlzIElDRS1s aXRlLCB0aGUgaW1wYWN0IG9mIFNUVU4gdHJhdmVyc2FsIHcuci50DQo+PiBJQ0UNCj4+ID4+ID50 ZXJtaW5hdGlvbiBhbmQgSUNFIHBhc3N0aHJvdWdoIG1vZGUgaW4gQjJCVUEuDQo+PiA+Pg0KPj4g Pj4gSXMgdGhlcmUgYW55IHRoaW5nIHRoYXQgeW91IHdvdWxkIGxpa2UgdG8gc2VlIGV4cGxpY2l0 bHkgYWRkZWQgZm9yDQo+PiBJQ0UNCj4+ID4+IGxpdGUgPyBBbGwgdGhlIHByb2NlZHVyZXMgb2Yg SUNFIHRlcm1pbmF0aW9uL0lDRSBwYXNzdGhyb3VnaCBhcmUNCj4+ID4+IGVxdWFsbHkNCj4+ID4+ IGFwcGxpY2FibGUgZm9yIEljZSBsaXRlIG1vZGUgYXMgd2VsbC4NCj4+ID4+DQo+PiA+PiBSZWdh cmRzLA0KPj4gPj4gUmFtDQo+PiA+Pg0KPj4gPj4gPg0KPj4gPj4gPlRoYW5rcw0KPj4gPj4gPlBh cnRoYQ0KPj4gPj4gPg0KPj4gPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ ID4+IEZyb206IHN0cmF3IFttYWlsdG86c3RyYXctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFJhbQ0KPj4gTW9oYW4gUg0KPj4gPj4gPj4gKHJtb2hhbnIpDQo+PiA+PiA+PiBTZW50OiBG cmlkYXksIEp1bHkgMDQsIDIwMTQgODoxMyBQTQ0KPj4gPj4gPj4gVG86IHN0cmF3QGlldGYub3Jn DQo+PiA+PiA+PiBTdWJqZWN0OiBbc3RyYXddIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXJhbS0NCj4+IHN0cmF3LQ0KPj4gPj4gPj4gYjJidWEtc3R1bi0wMC50eHQNCj4+ ID4+ID4+DQo+PiA+PiA+PiBXZSBoYXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHRoYXQgZGVzY3JpYmVz IHRoZSBiZWhhdmlvciBCMkJVQXMNCj4+IHNob3VsZA0KPj4gPj4gPj4gZm9sbG93IHdoZW4gYWN0 aW5nIG9uIGEgbWVkaWEgcGxhbmUgdGhhdCByZWNlaXZlcyBTVFVOIG1lc3NhZ2VzDQo+PiBhcw0K Pj4gPj4gcGFydA0KPj4gPj4gPj4gb2YNCj4+ID4+ID4+IElDRSBwcm9jZXNzaW5nLg0KPj4gPj4g Pj4NCj4+ID4+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXJh bS1zdHJhdy1iMmJ1YS1zdHVuLQ0KPj4gPj4gMDAudHh0DQo+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ ID4+ID4+IENvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBvbiBob3cgdG8gbWFrZSB0aGUgZHJhZnQg YmV0dGVyIGFyZQ0KPj4gPj4gd2VsY29tZS4NCj4+ID4+ID4+DQo+PiA+PiA+PiBSZWdhcmRzLA0K Pj4gPj4gPj4gQXV0aG9ycy4NCj4+ID4+ID4+DQo+PiA+PiA+Pg0KPj4gPj4gPj4NCj4+ID4+ID4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+PiBGcm9tOiAiaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KPj4gPj4gPj4gRGF0ZTog RnJpZGF5LCA0IEp1bHkgMjAxNCA4OjA4IHBtDQo+PiA+PiA+PiBUbzogUmFtIE1vaGFuIFJhdmlu ZHJhbmF0aCA8cm1vaGFuckBjaXNjby5jb20+LCAiVGlydW1hbGVzd2FyDQo+PiBSZWRkeQ0KPj4g Pj4gPj4gKHRpcmVkZHkpIiA8dGlyZWRkeUBjaXNjby5jb20+LCAiR29uemFsbyBTYWxndWVpcm8g KGdzYWxndWVpKSINCj4+ID4+ID4+IDxnc2FsZ3VlaUBjaXNjby5jb20+LCAiR29uemFsbyBTYWxn dWVpcm8gKGdzYWxndWVpKSINCj4+ID4+ID4+IDxnc2FsZ3VlaUBjaXNjby5jb20+LA0KPj4gPj4g Pj4gIlRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkiIDx0aXJlZGR5QGNpc2NvLmNvbT4sIFJh bSBNb2hhbg0KPj4gPj4gPj4gUmF2aW5kcmFuYXRoDQo+PiA+PiA+PiA8cm1vaGFuckBjaXNjby5j b20+DQo+PiA+PiA+PiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXJhbS1zdHJhdy1iMmJ1YS1zdHVuLQ0KPj4gPj4gMDAudHh0DQo+PiA+PiA+Pg0KPj4gPj4gPj4g Pg0KPj4gPj4gPj4gPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1yYW0tc3RyYXctYjJidWEt c3R1bi0wMC50eHQNCj4+ID4+ID4+ID5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFJhbSBNb2hhbiBSYXZpbmRyYW5hdGggYW5kDQo+PiA+PiBwb3N0ZWQNCj4+ID4+ID4+IHRvDQo+ PiA+PiA+PiA+dGhlDQo+PiA+PiA+PiA+SUVURiByZXBvc2l0b3J5Lg0KPj4gPj4gPj4gPg0KPj4g Pj4gPj4gPk5hbWU6CQlkcmFmdC1yYW0tc3RyYXctYjJidWEtc3R1bg0KPj4gPj4gPj4gPlJldmlz aW9uOgkwMA0KPj4gPj4gPj4gPlRpdGxlOgkJU2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZv ciBOQVQgKFNUVU4pDQo+PiBNZXNzYWdlDQo+PiA+PiA+PiBIYW5kbGluZyBmb3INCj4+ID4+ID4+ ID5TZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgKFNJUCkgQmFjay10by1CYWNrIFVzZXIgQWdl bnRzDQo+PiAoQjJCVUFzKQ0KPj4gPj4gPj4gPkRvY3VtZW50IGRhdGU6CTIwMTQtMDctMDQNCj4+ ID4+ID4+ID5Hcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4gPj4gPj4gPlBhZ2VzOgkJ MTQNCj4+ID4+ID4+ID5VUkw6DQo+PiA+PiA+PiA+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtcmFtLXN0cmF3LWIyYnVhLXN0dW4tDQo+PiA+PiAwMC50eHQNCj4+ID4+ ID4+ID5TdGF0dXM6DQo+PiA+PiA+PiA+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcmFtLXN0cmF3LWIyYnVhLXN0dW4vDQo+PiA+PiA+PiA+SHRtbGl6ZWQ6ICAgICAgIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhbS1zdHJhdy0NCj4+IGIyYnVhLQ0KPj4g Pj4gc3R1bi0NCj4+ID4+ID4+IDAwDQo+PiA+PiA+PiA+DQo+PiA+PiA+PiA+DQo+PiA+PiA+PiA+ QWJzdHJhY3Q6DQo+PiA+PiA+PiA+ICAgU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIChTSVAp IEJhY2stdG8tQmFjayBVc2VyIEFnZW50cw0KPj4gPj4gKEIyQlVBcykNCj4+ID4+ID4+ID4gICBh cmUgb2Z0ZW4gZGVzaWduZWQgdG8gYmUgb24gdGhlIG1lZGlhIHBhdGgsIHJhdGhlciB0aGFuIGp1 c3QNCj4+ID4+ID4+ID4gICBpbnRlcmNlcHRpbmcgc2lnbmFsaW5nLiAgVGhpcyBtZWFucyB0aGF0 IEIyQlVBcyBvZnRlbiBhY3Qgb24NCj4+IHRoZQ0KPj4gPj4gPj4gPiAgIG1lZGlhIHBhdGggbGVh ZGluZyB0byBzZXBhcmF0ZSBtZWRpYSBsZWdzIHRoYXQgdGhlIEIyQlVBDQo+PiA+PiBjb3JyZWxh dGVzDQo+PiA+PiA+PiA+ICAgYW5kIGJyaWRnZXMgdG9nZXRoZXIuICBXaGVuIGFjdGluZyBvbiB0 aGUgbWVkaWEgcGF0aCwgQjJCVUFzDQo+PiBhcmUNCj4+ID4+ID4+ID4gICBsaWtlbHkgdG8gcmVj ZWl2ZSBTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikNCj4+ID4+ID4+ IHBhY2tldHMNCj4+ID4+ID4+ID4gICBhcyBwYXJ0IG9mIEludGVyYWN0aXZlIENvbm5lY3Rpdml0 eSBFc3RhYmxpc2htZW50IChJQ0UpDQo+PiA+PiBwcm9jZXNzaW5nLg0KPj4gPj4gPj4gPiAgIEl0 IGlzIGNyaXRpY2FsIHRoYXQgQjJCVUFzIGhhbmRsZSB0aGVzZSBTVFVOIG1lc3NhZ2VzDQo+PiBw cm9wZXJseS4NCj4+ID4+ID4+ID4NCj4+ID4+ID4+ID4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMg YmVoYXZpb3IgZm9yIGEgQjJCVUEgcGVyZm9ybWluZyBJQ0UNCj4+ID4+ID4+IHByb2Nlc3Npbmcu DQo+PiA+PiA+PiA+DQo+PiA+PiA+PiA+DQo+PiA+PiA+PiA+DQo+PiA+PiA+PiA+DQo+PiA+PiA+ PiA+DQo+PiA+PiA+PiA+UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUNCj4+IG9mDQo+PiA+PiA+PiA+c3VibWlzc2lvbg0KPj4gPj4g Pj4gPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQN Cj4+ID4+IHRvb2xzLmlldGYub3JnLg0KPj4gPj4gPj4gPg0KPj4gPj4gPj4gPlRoZSBJRVRGIFNl Y3JldGFyaWF0DQo+PiA+PiA+PiA+DQo+PiA+PiA+Pg0KPj4gPj4gPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4+IHN0cmF3IG1haWxpbmcg bGlzdA0KPj4gPj4gPj4gc3RyYXdAaWV0Zi5vcmcNCj4+ID4+ID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3RyYXcNCj4+ID4+ID4NCj4+ID4NCj4NCg0K From nobody Sat Jul 26 07:23: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 9DAD01B2827 for ; Sat, 26 Jul 2014 07:23:37 -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 pA2g8NuqoUou for ; Sat, 26 Jul 2014 07:23:34 -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 E361B1B2825 for ; Sat, 26 Jul 2014 07:23:33 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-3d-53d3b9e39845 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 14.68.03739.3E9B3D35; Sat, 26 Jul 2014 16:23:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Sat, 26 Jul 2014 16:23:31 +0200 From: Christer Holmberg To: "straw@ietf.org" Thread-Topic: IETF#90: Draft STRAW minutes Thread-Index: Ac+o3OeZtAp1AN04RPy8c9sDjIscAA== Date: Sat, 26 Jul 2014 14:23:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@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_7594FB04B1934943A5C02806D1A2204B1D3D5B73ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+Jvje6TnZeDDb5nW0zts7WYvvcau8Wt 5sesFjvOTWBxYPFY232VzePOnA+sHkuW/GTymLxxFksASxSXTUpqTmZZapG+XQJXxoQ3S5gL Hi5krLh7aRNjA2NfL2MXIyeHhICJRPOqLWwQtpjEhXvrwWwhgaOMEj1vOSDsRYwSHevVuxg5 ONgELCS6/2mDhEUEVCUmfLkJNoZZoFZiYt8EdhBbGCj+sbWDCaJGS2LPu1dQtp7E2ytbwcaz ANX8OziHGcTmFfCV2PVxHVicEeiE76fWMEHMFJe49WQ+E8RpAhJL9pxnhrBFJV4+/scKYStJ rNh+CeqGfIk5f7tYIGYKSpyc+YRlAqPwLCSjZiEpm4WkDCKuI7Fg9yc2CFtbYtnC18ww9pkD j5mQxRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECIyxg1t+6+5gXP3a8RCjAAejEg+v wuxLwUKsiWXFlbmHGKU5WJTEeRedmxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZFd8/Pk tY8KtU32ax1XF0rr2uEdaSypUHmzZucHgSnrjF5PU+xWuiz3f+ER5XCGZqvrT5qdDpksVWqf lc1zJu7pDscdis9ZDKSfey/akPPDVbLwc2f0oYebHH5MFWv/rBfGs/bJil0WUy1E6yKM5Kcc evn6yoTNl84E2Cx8smHGqVsXUq+bn32qxFKckWioxVxUnAgAHcWZO5ICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/straw/BIIy2z_igNPycVf7YJS1E7eHnXg Cc: "Richard Barnes \(rlb@ipv.sx\)" , Sean Turner , Stephen Farrell Subject: [straw] 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: Sat, 26 Jul 2014 14:23:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D3D5B73ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (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 lo= ok 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.p= df 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.p= df 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-tax= onomy draft. In case there are conflicts, or other issues are found, the ST= RAW community is requested to provide comments on the grouping-taxonomy dra= ft. It was requested whether the draft should also cover RTP specific issues. I= t was indicated that the scope of the RTCP, and that we should be very care= ful about introducing RTP issues. It was recommended to talk to Colin Perki= ns whether he has any opinions regarding the need to cover RTP. I was asked how the document will relate to the work on multisource optimis= ation 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 disc= ussion (see further down) it was suggested that the RTCP draft should not t= alk about SRTP. Topic: Taxonomy Discussion Presenter: Lorenzo Miniero Slides: http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.p= df 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, w= ith 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.p= df Draft: draft-ram-straw-b2bua-stun It was indicated that B2BUA, due to policy reasons, may strip candidates fr= om SDP. It was indicated that B2BUAs must be very careful to not perform actions th= at will cause ICE mismatch. The chair informed the community that a WG adoption request will be sent ou= t within the upcoming weeks. It was indicated that the group needs to follow the ICE bis work taking pla= ce 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.p= df Draft: draft-ram-straw-b2bua-dtls-srtp The presentation triggered lots of discussions and controversy, as it was s= een as an attempt to standardize MITM (man in the middle procedures). While= people did realize such actions take place in deployments, they claimed th= at 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 problem= s, 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, b= ut 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, e= tc) to involve in such discussions. The chair indicated that the draft impl= ements a charter delivery, but that one possible outcome will be to remove/= re-scope the charter delivery. --_000_7594FB04B1934943A5C02806D1A2204B1D3D5B73ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Co-chair)

 

Hi,

 

Below are the STRAW minutes that the chairs intend t= o 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-SR= TP presentation, as it caused lots of discussion.

 

Note that the minutes do not contain who-said-what i= nformation (that can be found elsewhere), but if you think there are some i= mportant 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/proceeding= s/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/proceeding= s/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 somethi= ng 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 c= areful 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 opti= misation taking place in AVTEXT.

 

It was indicated that the text recommending man in the middle functional= ity for SRTP most likely will cause issues with IESG. After the DTLS-SRTP d= iscussion (see further down) it was suggested that the RTCP draft should not talk about SRTP.

 

 

 

Topic:     Taxonomy Discussion<= /b>

Presenter: Lorenzo Miniero

Slides:       http://www.ietf.org/proceeding= s/90/slides/slides-90-straw-2.pdf

Draft:     All STRAW deliveries

 

 

It was agreed the STRAW shall use the terms in the avtext-grouping-taxon= omy 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/proceeding= s/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/proceeding= s/90/slides/slides-90-straw-4.pdf

Draft:     draft-ram-straw-b2bua-dtls-srtp

 

 

The presentation triggered lots of discussions and controversy, as it wa= s seen as an attempt to standardize MITM (man in the middle procedures). Wh= ile people did realize such actions take place in deployments, they claimed that IETF/STRAW should not standardize such p= rocedures. It was also indicated that it goes against a number of BCP speci= fications, 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 problem= s, which could cause people to not use security to begin with.

 

It was indicated that one possible way forward could be to simply docume= nt, 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 ta= ke 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 possi= ble outcome will be to remove/re-scope the charter delivery.

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D3D5B73ESESSMB209erics_-- From nobody Tue Jul 29 18:34:29 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 6A7971A04B8 for ; Tue, 29 Jul 2014 18:34:27 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riuw0mss60bc for ; Tue, 29 Jul 2014 18:34:17 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4415B1B2A3D for ; Tue, 29 Jul 2014 18:34:16 -0700 (PDT) Received: from userPC (unknown [122.166.176.65]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id AD9B8190811A; Wed, 30 Jul 2014 01:34:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1406684058; bh=Uti2GhLvSsU3bZKepIDXdpjaDI/nze6N0oEN2g8N6eA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=eDOHj/lfyuHO9eDriFZR9VuaWCxzC8MaJMdnSsrHlcMF4ExGUT7wDBxYs2FjGl/E0 DzOyUszS/KfQvposFcnixbz9wl/Xo/0Lur7QAawFa/7B1PuMsdDKKG9VxrgqN+UdDq 9FJH16DfL3j+fc5u0Q+rJbvPSMYbDUTMbbOh/ixA= From: "Parthasarathi R" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> Date: Wed, 30 Jul 2014 07:04:05 +0530 Message-ID: <015701cfab96$5eb380a0$1c1a81e0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0158_01CFABC4.786BBCA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+o3OeZtAp1AN04RPy8c9sDjIscAACtF/nQ Content-Language: en-us X-CTCH-RefID: str=0001.0A020206.53D84B98.005C, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 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.92 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/6VF8UIjJjofYyRLc_vVOPJkpvMo Cc: 'Richard Barnes' , 'Sean Turner' , 'Stephen Farrell' Subject: [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, 30 Jul 2014 01:34:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0158_01CFABC4.786BBCA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. ------=_NextPart_000_0158_01CFABC4.786BBCA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

 

 

------=_NextPart_000_0158_01CFABC4.786BBCA0-- From nobody Wed Jul 30 02:34: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 65BFE1B2A25 for ; Wed, 30 Jul 2014 02:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 WXUCQa_Bdf85 for ; Wed, 30 Jul 2014 02:34:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 61FE21A0AC9 for ; Wed, 30 Jul 2014 02:34:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3D3F1BE12; Wed, 30 Jul 2014 10:34:52 +0100 (IST) 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 9K_cKaXoMfkf; Wed, 30 Jul 2014 10:34:50 +0100 (IST) Received: from [192.168.1.130] (unknown [5.175.75.49]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 17112BE08; Wed, 30 Jul 2014 10:34:43 +0100 (IST) Message-ID: <53D8BC2D.6050408@cs.tcd.ie> Date: Wed, 30 Jul 2014 10:34:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Parthasarathi R , 'Christer Holmberg' , straw@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> In-Reply-To: <015701cfab96$5eb380a0$1c1a81e0$@co.in> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/straw/RyJ8AVBKLoLlnIEPjIOJSZVCii8 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, 30 Jul 2014 09:34:56 -0000 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. > > > > > > From nobody Wed Jul 30 02:50:14 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 747151B2A83 for ; Wed, 30 Jul 2014 02:50:13 -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 nGNOXDZXSsb7 for ; Wed, 30 Jul 2014 02:50:11 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5631B2A3C for ; Wed, 30 Jul 2014 02:50:10 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so7165266wib.14 for ; Wed, 30 Jul 2014 02:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=KW/WQ0mdMvdHmK6OGGNmgviKUZexgSUIzIs9irL4kZU=; b=nb1pbfCIcYHQkp6zyDWqgU4mTzyi2oApBgshOPzGiei1zXBV0BD/+TfNpHqwyB/DnY GNKyNI6dwJxcxiR4emNlw8PtMHo7c+yXbB1qJhRglnOD+duQqEsiijh56jInMFO2Geop t0sl4DpmFvcUFnNaCud/eCpO3K8LF8XRLBveHVTiS37oJ30IgaWEmlv3yVPGKmnZk84H 2zrFwI5kTs/J1qmWMoPyAULyv9GtpmoO68QaBh4atvrQ2AT8jJoMb82Tol9oi0MAAk+0 O8laVkcJIbGCj78jxUe+L2t0pyD6UPMRcRevgWjkahCvq/nt+waj/hGe+8al1j9t0LZf oifQ== X-Received: by 10.194.189.230 with SMTP id gl6mr4521336wjc.118.1406713807144; Wed, 30 Jul 2014 02:50:07 -0700 (PDT) Received: from [192.168.1.37] (228.Red-88-9-161.dynamicIP.rima-tde.net. [88.9.161.228]) by mx.google.com with ESMTPSA id a4sm53489083wie.21.2014.07.30.02.50.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 02:50:06 -0700 (PDT) Message-ID: <53D8BFD9.6010702@gmail.com> Date: Wed, 30 Jul 2014 11:50:17 +0200 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: straw@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> In-Reply-To: <53D8BC2D.6050408@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/straw/3FHi3eptG0fZzD6yM0U891_1fpc 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, 30 Jul 2014 09:50:13 -0000 The sole purpose of a B2BUA is to become and endpoint (well two endpoints in fact) between two other endpoints: Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Best regards Sergio On 30/07/2014 11:34, Stephen Farrell wrote: > 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 From nobody Wed Jul 30 09:58:20 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 09A2A1A026F for ; Wed, 30 Jul 2014 09:58:17 -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 x-i8FGMZKvHL for ; Wed, 30 Jul 2014 09:58:10 -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 64AB41A01D0 for ; Wed, 30 Jul 2014 09:58:09 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-27-53d9241fba4c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 64.BA.03739.F1429D35; Wed, 30 Jul 2014 18:58:07 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Wed, 30 Jul 2014 18:58:07 +0200 From: Christer Holmberg To: Parthasarathi R , "straw@ietf.org" Thread-Topic: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: Draft STRAW minutes] Thread-Index: AQHPq5ZhnPh8EjJl6UG8BttJ7FbyRJu41wFw Date: Wed, 30 Jul 2014 16:58:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3DAC63@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> In-Reply-To: <015701cfab96$5eb380a0$1c1a81e0$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D3DAC63ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM+Jvja68ys1gg2XntCwmf+pjtZjaZ2sx fe81dotbzY9ZLXacm8DiwOqxtvsqm8edOR9YPZYs+cnkMXnjLBaPD/O/sAewRnHZpKTmZJal FunbJXBlLL3/kbng32PGipmHdrE1MN4+xtjFyMEhIWAiceRRdhcjJ5ApJnHh3nq2LkYuDiGB o4wSkx7sZ4ZwFjFKHD/fAdbAJmAh0f1PG6RBRCBUYvOaPjYQm1mgTGLd/GvMILawQJTE0q/d zBA10RLfls9lgbCNJFY9P8UKYrMIqEp0PV3ECGLzCvhKXH4/lR3EFhIol5g79TQryCpOoNse tOSChBmBbvt+ag0TxCpxiVtP5jNB3CwgsWTPeWYIW1Ti5eN/rBC2kkTjkiesEPX5Eo+vL4Ba JShxcuYTlgmMorOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilG0OLW4 ODfdyFgvtSgzubg4P08vL7VkEyMwUg9u+a27g3H1a8dDjAIcjEo8vAmSN4KFWBPLiitzDzFK c7AoifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjrCNDYZdIU2Ls7GhelXktmTmy kUJJS7lmTN4atrVRONxL1Yuv+f/eoLLG1oyJ9paR3z5/mVqQ6qlxONamLfRTqdmR2+ccAgL2 PFxkonN/koNj9ZP7VyJLFq/5euzaMbv3Mv8Mm6KSnZK9k2X73fMKPlsXXcxQn25xeM4qa6+k 9+0dL3/NuqbEUpyRaKjFXFScCAD5vRJvtQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/straw/dUDqSYQH8VQOOAZOI00roqSGHDY Cc: 'Richard Barnes' , 'Sean Turner' , '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, 30 Jul 2014 16:58:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D3DAC63ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Partha, I am glad you are triggering a discussion on this :) However, I would ask you to change the subject. The purpose of my e-mail wa= s simply to request whether people have any issues with the meeting minutes= as such, e.g. whether they think something is missing, and/or whether the = minutes don't reflect what was discussed during the meeting :) Regards, Christer From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: 30 July 2014 04:34 To: Christer Holmberg; straw@ietf.org Cc: 'Richard Barnes'; 'Sean Turner'; 'Stephen Farrell' Subject: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: Draft STRAW = minutes] Hi all, I have different view than the security folks look at this draft. This draf= t intention is not to violate RFC 2804. In case this draft is not standardi= zed, 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 fro= m SIP recording architecture in B2BUA (Fig 1 of RFC 7245) usage perspective= wherein the senders/receiver is informed about the call recording (like ca= ll 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 secu= rity issue. I'm not seeing any major security concerns as B2BUA is yet anot= her UA. Please let me know the list of security concern specific to B2BUA i= n DTLS-SRTP. In reality, B2BUA terminating DTLS-SRTP is not avoidable because of the dif= ferent codec profile between the deployed SIP UAs. Say SIPoWS in browser (W= ebRTC endpoint/SIP UA) uses Opus/G711/VP8 as a codec as of today and SIP Mo= bile 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. Th= e lack of standard leads to proprietary session border controller (SBC) sol= utions 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 Fa= rrell 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 lo= ok 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.p= df 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.p= df 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-tax= onomy draft. In case there are conflicts, or other issues are found, the ST= RAW community is requested to provide comments on the grouping-taxonomy dra= ft. It was requested whether the draft should also cover RTP specific issues. I= t was indicated that the scope of the RTCP, and that we should be very care= ful about introducing RTP issues. It was recommended to talk to Colin Perki= ns whether he has any opinions regarding the need to cover RTP. I was asked how the document will relate to the work on multisource optimis= ation 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 disc= ussion (see further down) it was suggested that the RTCP draft should not t= alk about SRTP. Topic: Taxonomy Discussion Presenter: Lorenzo Miniero Slides: http://www.ietf.org/proceedings/90/slides/slides-90-straw-2.p= df 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, w= ith 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.p= df Draft: draft-ram-straw-b2bua-stun It was indicated that B2BUA, due to policy reasons, may strip candidates fr= om SDP. It was indicated that B2BUAs must be very careful to not perform actions th= at will cause ICE mismatch. The chair informed the community that a WG adoption request will be sent ou= t within the upcoming weeks. It was indicated that the group needs to follow the ICE bis work taking pla= ce 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.p= df Draft: draft-ram-straw-b2bua-dtls-srtp The presentation triggered lots of discussions and controversy, as it was s= een as an attempt to standardize MITM (man in the middle procedures). While= people did realize such actions take place in deployments, they claimed th= at 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 problem= s, 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, b= ut 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, e= tc) to involve in such discussions. The chair indicated that the draft impl= ements a charter delivery, but that one possible outcome will be to remove/= re-scope the charter delivery. --_000_7594FB04B1934943A5C02806D1A2204B1D3DAC63ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Partha,

 

I am glad you are triggering a discussion on this :)=

 

However, I would ask you to change the subject. The purpose of my e-ma= il was simply to request whether people have any issues with the meeting mi= nutes as such, e.g. whether they think something is missing, and/or whether the minutes don’t reflect what = was discussed during the meeting :)

 

Regards,

 

Christer

 

From: Parthasarathi R [mailto:partha@parthasarathi.co.in]
Sent: 30 July 2014 04:34
To: Christer Holmberg; straw@ietf.org
Cc: 'Richard Barnes'; 'Sean Turner'; 'Stephen Farrell'
Subject: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: Draft= STRAW minutes]

 

Hi all,=

&n= bsp;

I have = different view than the security folks look at this draft. This draft inten= tion is not to violate RFC 2804. In case this draft is not standardized, al= l B2BUA handling DTLS-SRTP will end up in violating RFC 2804 due to the lack of guidelines/standards to follow. P= lease look into this draft from SIP recording architecture in B2BUA (Fig 1 = of RFC 7245) usage perspective wherein the senders/receiver is informed abo= ut the call recording (like call centre usage scenario) and no RFC 2804 violation.

&n= bsp;

In IETF= -90 meeting, the security concerns are raised about this draft usage. It wi= ll be good to document as part of this document if it is really security is= sue. I’m not seeing any major security concerns as B2BUA is yet another UA. Please let me know the list of securi= ty concern specific to B2BUA in DTLS-SRTP.

&n= bsp;

In real= ity, B2BUA terminating DTLS-SRTP is not avoidable because of the different = codec profile between the deployed SIP UAs. Say SIPoWS in browser (WebRTC e= ndpoint/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 sess= ion border controller (SBC) solutions which breaks other SIP enhancements as well.

&n= bsp;

Thanks<= o:p>

Partha<= o:p>

&n= bsp;

From: straw [mail= to: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); S= ean Turner; Stephen Farrell
Subject: [straw] IETF#90: Draft STRAW minutes

 

(Co-chair)

 

Hi,

 

Below are the STRAW minutes that the chairs intend t= o 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-SR= TP presentation, as it caused lots of discussion.

 

Note that the minutes do not contain who-said-what i= nformation (that can be found elsewhere), but if you think there are some i= mportant 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 somethi= ng 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 c= areful 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 opti= misation taking place in AVTEXT.

 

It was indicated that the text recommending man in the middle functional= ity for SRTP most likely will cause issues with IESG. After the DTLS-SRTP d= iscussion (see further down) it was suggested that the RTCP draft should not talk about SRTP.

 

 

 

Topic:     Taxonomy Discussion<= /b>

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-taxon= omy 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 wa= s seen as an attempt to standardize MITM (man in the middle procedures). Wh= ile people did realize such actions take place in deployments, they claimed that IETF/STRAW should not standardize such p= rocedures. It was also indicated that it goes against a number of BCP speci= fications, 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 problem= s, which could cause people to not use security to begin with.

 

It was indicated that one possible way forward could be to simply docume= nt, 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 ta= ke 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 possi= ble outcome will be to remove/re-scope the charter delivery.

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D3DAC63ESESSMB209erics_-- From nobody Wed Jul 30 18:23:54 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 A78E61A03AC for ; Wed, 30 Jul 2014 18:23:50 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuKAHNzIQI86 for ; Wed, 30 Jul 2014 18:23:45 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.11]) by ietfa.amsl.com (Postfix) with ESMTP id A37B11A037C for ; Wed, 30 Jul 2014 18:23:45 -0700 (PDT) Received: from userPC (unknown [122.172.204.86]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 17B60190875F; Thu, 31 Jul 2014 01:23:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1406769826; bh=eeD2uWF+oMwtEGN4jiIP2DGm1vZeCMEnlY7ZTpN8uyQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=XT5gK/ptqZVoVTY0VNrNMIZSqbUceHoEObtBYCdO5aNLw1ZWM302YQDPr2VBunCgK gF1XcuZsaOX0ZBw6DOUMES0B9mKFfrynPNSH18O2eSvpx7NPalO+Knc5rSLi76+U55 5LQ9U9CfCSC/5UTOxf0rdRvCe7axp9FQ/w6AeJcc= From: "Parthasarathi R" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <7594FB04B1934943A5C02806D1A2204B1D3DAC63@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3DAC63@ESESSMB209.ericsson.se> Date: Thu, 31 Jul 2014 06:53:31 +0530 Message-ID: <008101cfac5e$0efbccc0$2cf36640$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01CFAC8C.28B408C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPq5ZhnPh8EjJl6UG8BttJ7FbyRJu41wFwgACLnzA= Content-Language: en-us X-CTCH-RefID: str=0001.0A020206.53D99A9F.00E4, 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: 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.92 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/niPsNjR1x5uUofOaFstPj7dAPmA Cc: 'Richard Barnes' , 'Sean Turner' , '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: Thu, 31 Jul 2014 01:23:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0082_01CFAC8C.28B408C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Christer, Sorry, I replied to discuss about adopting this draft as a WG item. Let us keep this mail thread to see the open items which blocks the adoption of this draft J I'll reply separately in the original mail thread to inform some of the missing notes. Thanks Partha From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Wednesday, July 30, 2014 10:28 PM To: Parthasarathi R; straw@ietf.org Cc: 'Richard Barnes'; 'Sean Turner'; 'Stephen Farrell' Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: Draft STRAW minutes] Hi Partha, I am glad you are triggering a discussion on this :) However, I would ask you to change the subject. The purpose of my e-mail was simply to request whether people have any issues with the meeting minutes as such, e.g. whether they think something is missing, and/or whether the minutes don't reflect what was discussed during the meeting :) Regards, Christer From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: 30 July 2014 04:34 To: Christer Holmberg; straw@ietf.org Cc: 'Richard Barnes'; 'Sean Turner'; 'Stephen Farrell' Subject: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: Draft STRAW minutes] 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. ------=_NextPart_000_0082_01CFAC8C.28B408C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Christer,

 

Sorry, I replied to = discuss about adopting this draft as a WG item.

 

Let us keep this mail = thread to see the open items which blocks the adoption of this draft J

 

I’ll reply = separately in the original mail thread to inform some of the missing = notes.

 

Thanks

Partha

 

From:= straw [mailto:straw-bounces@ietf.org] On Behalf Of Christer = Holmberg
Sent: Wednesday, July 30, 2014 10:28 PM
To: Parthasarathi R; straw@ietf.org
Cc: 'Richard Barnes'; 'Sean Turner'; 'Stephen Farrell'
Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: = IETF#90: Draft STRAW minutes]

 

Hi = Partha,

 

I am = glad you are triggering a discussion on this :)

 

However, = I would ask you to change the subject. The purpose of my e-mail was simply to = request whether people have any issues with the meeting minutes as such, e.g. = whether they think something is missing, and/or whether the minutes don’t = reflect what was discussed during the meeting :)

 

Regards,

 

Christer

 

From: Parthasarathi R [mailto:partha@parthasarathi.co.in]
Sent: 30 July 2014 04:34
To: Christer Holmberg; straw@ietf.org
Cc: 'Richard Barnes'; 'Sean Turner'; 'Stephen Farrell'
Subject: B2BUA handling in DTLS-SRTP [was RE: [straw] IETF#90: = Draft STRAW minutes]

 

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<= /o:p>

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.

 

 

------=_NextPart_000_0082_01CFAC8C.28B408C0-- From nobody Wed Jul 30 18:37:51 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 170801A0076 for ; Wed, 30 Jul 2014 18:37:49 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GJVoPFEZ-YX for ; Wed, 30 Jul 2014 18:37:44 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.19]) by ietfa.amsl.com (Postfix) with ESMTP id B68031A017F for ; Wed, 30 Jul 2014 18:37:43 -0700 (PDT) Received: from userPC (unknown [122.172.204.86]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id 99C62639405; Thu, 31 Jul 2014 01:37:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1406770665; bh=ZuQYliZX1iNgZYKy5CORlCbl//ELa8O+oUBgOixnygI=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=QlPPYB5PbIZKMWpvehoiMI7eRnosJNJUfYYdKIVRUXnmkl0NSL70OeVL1T9ZdqLhQ IIx9+MTByM2hPMip1mZI9lwMEXshegBWY/w3Ma+TbYTM8Jaz11Xs0ZDdW193rwGhMY At6tVXtLsVz02a7y0SKRvsEoeudfeYZ4B4qtdkHs= From: "Parthasarathi R" To: "'Christer Holmberg'" , References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> Date: Thu, 31 Jul 2014 07:07:31 +0530 Message-ID: <008c01cfac60$036df750$0a49e5f0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01CFAC8E.1D263350" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac+o3OeZtAp1AN04RPy8c9sDjIscAADgdN9Q Content-Language: en-us X-CTCH-RefID: str=0001.0A020205.53D99DE7.0029, 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: 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.134 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/3vPrc9FLJLI0qyk1yJK9Q2CmliY Cc: 'Richard Barnes' , 'Sean Turner' , 'Stephen Farrell' Subject: Re: [straw] 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, 31 Jul 2014 01:37:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008D_01CFAC8E.1D263350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Christer, The following discussion is missing in the minutes: 1) PSTN interworking - Here, there is no end-to-end DTLS-SRTP and DTLS-SRTP is terminated in the network and not in the actual endpoint. 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. ------=_NextPart_000_008D_01CFAC8E.1D263350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Christer,

 

The following = discussion is missing in the minutes:

 

1)      PSTN = interworking – Here, there is no end-to-end DTLS-SRTP and DTLS-SRTP is terminated in = the network and not in the actual endpoint.

 

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.

 

 

------=_NextPart_000_008D_01CFAC8E.1D263350-- From nobody Wed Jul 30 18:44:35 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 C5EA91A03C5 for ; Wed, 30 Jul 2014 18:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 rn3A-r1VMtGA for ; Wed, 30 Jul 2014 18:44:30 -0700 (PDT) Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7841A016D for ; Wed, 30 Jul 2014 18:44:30 -0700 (PDT) Received: from userPC (unknown [122.172.204.86]) (Authenticated sender: partha@parthasarathi.co.in) by outbound.mailhostbox.com (Postfix) with ESMTPA id A534019087A2; Thu, 31 Jul 2014 01:44:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1406771072; bh=8Ki+HTjq+0EXbFYFsV2ZjqeuJgTUagtoK+vx9mDYHks=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=enfugiQr8PWrtWUkYrWP+S6QuOL9IFrztgkbP8I5QqTQxg8rKft5o6BS0a6DXWZ5i Uhz+R5mv0ej+12GifQMBcWlMfLYcPnKoN7QdxM5bLANfxBqdw3SrPm3Ctl2WhaKJUF DY4qHupr+3aMzA02i8LfwPX93a2ym8goGTcBywHw= From: "Parthasarathi R" To: "'Sergio Garcia Murillo'" , References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> <015701cfab96$5eb380a0$1c1a81e0$@co.in> <53D8BC2D.6050408@cs.tcd.ie> <53D8BFD9.6010702@gmail.com> In-Reply-To: <53D8BFD9.6010702@gmail.com> Date: Thu, 31 Jul 2014 07:14:22 +0530 Message-ID: <009101cfac60$f618c4d0$e24a4e70$@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+r26t4VhRRWx8rRc+a4y3eQEG0BgAhFz+A Content-Language: en-us X-CTCH-RefID: str=0001.0A020207.53D99F7D.00AB, 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: 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.92 Archived-At: http://mailarchive.ietf.org/arch/msg/straw/hl5I33qzx8VfN2yAdBYOwQh3VMk 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, 31 Jul 2014 01:44:32 -0000 I agree with Sergio. Also, Stephen proposal of terminating DTLS-SRTP is weak in security in case of the B2BUA transcoding (one codec to another codec) usecase wherein one of the UA and B2BUA *MUST* communicate using plain RTP. Thanks Partha > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Sergio Garcia > Murillo > Sent: Wednesday, July 30, 2014 3:20 PM > To: straw@ietf.org > Subject: Re: [straw] B2BUA handling in DTLS-SRTP [was RE: IETF#90: > Draft STRAW minutes] > > The sole purpose of a B2BUA is to become and endpoint (well two > endpoints in fact) between two other endpoints: > > Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a > logical entity that receives a request and processes it as a > user agent server (UAS). In order to determine how the > request > should be answered, it acts as a user agent client (UAC) and > generates requests. > > Best regards > Sergio > > On 30/07/2014 11:34, Stephen Farrell wrote: > > 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 > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Thu Jul 31 09:57: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 5E1C71A0180 for ; Thu, 31 Jul 2014 09:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dthDTVzgg08w for ; Thu, 31 Jul 2014 09:57:52 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34251A0166 for ; Thu, 31 Jul 2014 09:57:52 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hq11so4717589vcb.10 for ; Thu, 31 Jul 2014 09:57:51 -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; bh=ljsFbOV1Vuj8BT3GrIWByKXe3KMULbhpxBRnF6QwHjc=; b=tkHXXiil6YYM3lpQg64xtbxs+JodixSlx//OqVX9Tvh0Lrvj5kOQ4nw6dUOWpqp4yY 7EZjO6JYWFOs4Tg357R4+jZMtKPrO9TWbQQSnOWbSHPWbpl3fWW1JRtxAZlvoh2zZ6rp q58uS+SJqHRL3EB/KKOYg0DL6eJQ4Tes5TfT024IeyhVkNhjTcTKYgfkzq36TiW8vSGH /94UvEiFecfe+DPH7jXOz6zwuzuzMBSdAd1QgyTRHIsiWwaiTsTj0/SgNIOsSYRsK+zy 3skYURRl0BUD6XQnaVILnMJiw8OW7+4BZGGJJyOonfGV6USKVwi3DpEWmsmnM5Qxi2PK 4Xbw== MIME-Version: 1.0 X-Received: by 10.220.1.5 with SMTP id 5mr3991724vcd.74.1406825871824; Thu, 31 Jul 2014 09:57:51 -0700 (PDT) Received: by 10.220.39.65 with HTTP; Thu, 31 Jul 2014 09:57:51 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D3D5B73@ESESSMB209.ericsson.se> Date: Thu, 31 Jul 2014 11:57:51 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a11c3106659dc9204ff802c6d Archived-At: http://mailarchive.ietf.org/arch/msg/straw/ojATSwHT6v5wJ4jUmrRxpJLfVkE Cc: "Richard Barnes \(rlb@ipv.sx\)" , Sean Turner , "straw@ietf.org" , Stephen Farrell Subject: Re: [straw] 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, 31 Jul 2014 16:57:56 -0000 --001a11c3106659dc9204ff802c6d Content-Type: text/plain; charset=UTF-8 Hi Christer, I have one point for clarification below wrt our lively discussion around DTLS-SRTP. Mary. On Sat, Jul 26, 2014 at 9:23 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > (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. > [MB] I'm recalling discussion of several options here: 1) Publish as an informational WG deliverable with appropriate caveats/warnings/disclaimers (the doc is currently Standards track) 2) Publish as AD sponsored/information with appropriate caveats/warnings/disclaimers 3) Publish via the Independent Series Editor. This is where the idea of identifying specific vendors came up. This has been done a number of times for a variety of vendors for a variety of unpopular topics. [The responsible AD likely will vehemently oppose this idea, but it is a totally valid and practical route for things of this nature. ] [/MB] > > 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 > > --001a11c3106659dc9204ff802c6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christer,=C2=A0

I have one point for= clarification below wrt our lively discussion around DTLS-SRTP.
=
Mary.


On Sat, Jul 26, 2014 at 9:23 AM, Christer Holmberg <christer.= holmberg@ericsson.com> wrote:

(Co-chair)

=C2=A0

Hi,

=C2=A0

Below are the STRAW minutes that the chairs intend t= o upload.

=C2=A0

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-SR= TP presentation, as it caused lots of discussion.

=C2=A0

Note that the minutes do not contain who-said-what i= nformation (that can be found elsewhere), but if you think there are some i= mportant things missing, or if you think something is wrong, please let the= chairs now.

=C2=A0

Thanks!

=C2=A0

Regards,

=C2=A0

Christer & Victor

=C2=A0

-------------------

=C2=A0

IETF 90 - STRAW

1150-1320 EDT=C2= =A0=C2=A0=C2=A0 Friday Afternoon Session I

=C2=A0=

=C2=A0=

Topic:=C2=A0=C2= =A0=C2=A0=C2=A0 Agenda bashing, IETF Note Well and WG status<= /span>

Presenter: Christ= er Holmberg (co-chair)

Slides: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/proceedings/90= /slides/slides-90-straw-0.pdf

Draft:=C2=A0=C2= =A0=C2=A0=C2=A0 N/A

=C2=A0=

=C2=A0=

No issues were ident= ified.

=C2=A0=

=C2=A0=

=C2=A0=

Topic:=C2=A0=C2= =A0=C2=A0=C2=A0 Guidelines to support RTCP in B2BUAs

Presenter: Lorenz= o Miniero

Slides: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/proceedings/90= /slides/slides-90-straw-1.pdf

Draft:=C2=A0=C2= =A0=C2=A0=C2=A0 draft-ietf-straw-b2bua-rtcp

=C2=A0=

=C2=A0=

It was indicated tha= t XR needs to be looked into, to see whether something needs to be covered = in the draft.

=C2=A0=

It was indicated tha= t the terminology will be aligned with the grouping-taxonomy draft. In case= there are conflicts, or other issues are found, the STRAW community is req= uested to provide comments on the grouping-taxonomy draft.

=C2=A0=

It was requested whe= ther 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 introducin= g RTP issues. It was recommended to talk to Colin Perkins whether he has any opinions regarding the need to= cover RTP.

=C2=A0=

I was asked how the = document will relate to the work on multisource optimisation taking place i= n AVTEXT.

=C2=A0=

It was indicated tha= t the text recommending man in the middle functionality for SRTP most likel= y 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.

=C2=A0=

=C2=A0=

=C2=A0=

Topic:=C2=A0=C2= =A0=C2=A0=C2=A0 Taxonomy Discussion

Presenter: Lorenz= o Miniero

Slides: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/proceedings/90= /slides/slides-90-straw-2.pdf

Draft:=C2=A0=C2= =A0=C2=A0=C2=A0 All STRAW deliveries

=C2=A0=

=C2=A0=

It was agreed the ST= RAW shall use the terms in the avtext-grouping-taxonomy document in prefere= nce to definitions elsewhere is they are appropriate, with a note indicatin= g any differences in other documents that may influence understanding.

=C2=A0=

=C2=A0=

=C2=A0=

Topic:=C2=A0=C2= =A0=C2=A0=C2=A0 STUN handling in B2BUAs

Presenter: Lorenz= o Miniero (on behalf of the draft authors)

Slides: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/proceedings/90= /slides/slides-90-straw-3.pdf

Draft:=C2=A0=C2= =A0=C2=A0=C2=A0 draft-ram-straw-b2bua-stun

=C2=A0=

=C2=A0=

It was indicated tha= t B2BUA, due to policy reasons, may strip candidates from SDP.

=C2=A0=

It was indicated tha= t B2BUAs must be very careful to not perform actions that will cause ICE mi= smatch.

=C2=A0=

The chair informed t= he community that a WG adoption request will be sent out within the upcomin= g weeks.

=C2=A0=

It was indicated tha= t the group needs to follow the ICE bis work taking place in MMUSIC, in cas= e there will be any impacts on the STRAW draft.

=C2=A0=

=C2=A0=

=C2=A0=

Topic:=C2=A0=C2= =A0=C2=A0=C2=A0 DTLS-SRTP handling in B2BUAs

Presenter: Lorenz= o Miniero (on behalf of the draft authors)

Slides: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 http://www.ietf.org/proceedings/90= /slides/slides-90-straw-4.pdf

Draft:=C2=A0=C2= =A0=C2=A0=C2=A0 draft-ram-straw-b2bua-dtls-srtp

=C2=A0=

=C2=A0=

The presentation tri= ggered 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 p= rocedures. It was also indicated that it goes against a number of BCP speci= fications, 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 problem= s, which could cause people to not use security to begin with.

=C2=A0=

It was indicated tha= t one possible way forward could be to simply document, in an informal deli= very, how different vendors do things in the network, but in such case the = vendors should also be listed in the document.

[MB] I'= ;m recalling discussion of several options here:
1) =C2=A0Publish= as an informational WG deliverable with appropriate caveats/warnings/discl= aimers (the doc is currently Standards track)
2) =C2=A0Publish as AD sponsored/information with appropriate caveats/= warnings/disclaimers
3) =C2=A0Publish via the Independent Series = Editor. =C2=A0This is where the idea of identifying specific vendors came u= p. This has been done a number of times for a variety of vendors for a vari= ety of unpopular topics. =C2=A0[The responsible AD likely will vehemently o= ppose this idea, but it is a totally valid and practical route for things o= f this nature. ]
[/MB]=C2=A0

=C2=A0=

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 su= ch discussions. The chair indicated that the draft implements a charter delivery, but that one possi= ble outcome will be to remove/re-scope the charter delivery.<= /span>

=C2=A0=

=C2=A0


_______________________________________________
straw mailing list
straw@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/straw


--001a11c3106659dc9204ff802c6d--