From nobody Tue Mar 4 07:06:18 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C29D1A008D for ; Tue, 4 Mar 2014 07:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 Dz4GOTwjOlGZ for ; Tue, 4 Mar 2014 07:06:13 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8B21A0085 for ; Tue, 4 Mar 2014 07:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=343; q=dns/txt; s=iport; t=1393945570; x=1395155170; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=aqtidWqri1froPMe0ezVN1Mq9Xs09fm+2mHxGQAAyuY=; b=dW+ruWOKsy6OdYwZOP1heqhn+SFc3u2w7wUY9Ubos2gzR9ZzFjDwBf7q sFCaB7XwtH0cpXuREiXCRXGI7BaB2ODjGDPsySz46qzmimVvZD+9yxhx9 jFddDTmZsMrQeODPTg/3Qj1WCn09ZyN5TkgsH8/gnvPpM4risU2OtTJbz Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAKTqFVOtJV2d/2dsb2JhbABagwY7V8IMFnSCLB0dUQE+QicEiAwNnRWvOReTEASYPIEykHmDLYIq X-IronPort-AV: E=Sophos;i="4.97,585,1389744000"; d="scan'208";a="24811920" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 04 Mar 2014 15:06:10 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s24F6AhW005414 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Mar 2014 15:06:10 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 09:06:10 -0600 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: call for comments on draft-ietf-bfcpbis-rfc4582bis Thread-Index: AQHPN7tGWE6FI4MCBU+PFSXn3STC4w== Date: Tue, 4 Mar 2014 15:06:09 +0000 Message-ID: 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.21.82.236] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A5560D3E1CED0488D9550CBE42FA2D0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/S7Hh84_8sfnFEhke8bcAtwQygaw Subject: [bfcpbis] call for comments on draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:06:15 -0000 As discussed in the session today at IETF 89, this is to officially announce a 2-week call for comments on draft-ietf-bfcpbis-rfc4582bis-11 (http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-11), due by or before March 19, 2014. If the draft is perfect as is, please share that comment on the list as well. Thank you, Charles From nobody Tue Mar 4 07:06:21 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A294A1A014D for ; Tue, 4 Mar 2014 07:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, 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 unP3txIsbEnY for ; Tue, 4 Mar 2014 07:06:15 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id BB8D51A008D for ; Tue, 4 Mar 2014 07:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=343; q=dns/txt; s=iport; t=1393945572; x=1395155172; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=gnyeni0mvYcg3XR9wJTYmychCprZ2YqBmRXw9pIrSPo=; b=HOSxJspW2zhl+9mpIx4lXMGhpp+Z8E3gY4YjkAuwzeCPvCAjZkAxjCTb ZjTuVx2TZJ8rwHl7peS8P9ixPEfZxryd4ayOo1a1ekgba01YLRnpGjRcM JaPCr+7bElhZPmYxdsUh/N8KDMFxM8KfI0WxmU+lxIbYxMc6roaOHqP2M E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAPrqFVOtJV2c/2dsb2JhbABagwY7V8IMFnSCLB0dUQE+QicEiAwNnRWvOReTEASYPIEykHmDLYIq X-IronPort-AV: E=Sophos;i="4.97,585,1389744000"; d="scan'208";a="24802136" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 04 Mar 2014 15:06:12 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s24F6CJe026247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Mar 2014 15:06:12 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 09:06:11 -0600 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: call for comments on draft-ietf-bfcpbis-rfc4583bis Thread-Index: AQHPN7tGLYxS+p5qwUiunNAebDCi+w== Date: Tue, 4 Mar 2014 15:06:10 +0000 Message-ID: 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.21.82.236] Content-Type: text/plain; charset="us-ascii" Content-ID: <12491AF8908324488E3BA0AB4E1EFC83@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/2rhAp-s7Fl3qrdkARjhmPqf05fc Subject: [bfcpbis] call for comments on draft-ietf-bfcpbis-rfc4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:06:18 -0000 As discussed in the session today at IETF 89, this is to officially announce a 2-week call for comments on draft-ietf-bfcpbis-rfc4583bis-09 (http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-09), due by or before March 19, 2014. If the draft is perfect as is, please share that comment on the list as well. Thank you, Charles From nobody Thu Mar 6 08:51:01 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827AD1A0048 for ; Thu, 6 Mar 2014 08:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpCyJrmUca1C for ; Thu, 6 Mar 2014 08:46:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD701A0083 for ; Thu, 6 Mar 2014 08:46:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: bfcpbis@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140306164612.24165.58309.idtracker@ietfa.amsl.com> Date: Thu, 06 Mar 2014 08:46:12 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/gRzDAYCMR2xsNa6Bh4Bc0s2gLj8 X-Mailman-Approved-At: Thu, 06 Mar 2014 08:50:49 -0800 Subject: [bfcpbis] Milestones changed for bfcpbis WG X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:46:15 -0000 Changed milestone "Draft revision of RFC 4582 to IESG", set description to "Draft revision of RFC 4582 to IESG as Proposed Standard", set due date to June 2014 from December 2013. Changed milestone "Draft revision of RFC 4583 to IESG", set description to "Draft revision of RFC 4583 to IESG as Proposed Standard", set due date to June 2014 from December 2013. Added milestone "Draft for BFCP over WebSocket to IESG as Proposed Standard", due November 2014. URL: http://datatracker.ietf.org/wg/bfcpbis/charter/ From nobody Thu Mar 13 12:50:31 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32961A09D8 for ; Thu, 13 Mar 2014 12:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 8tQhR_1imgRe for ; Thu, 13 Mar 2014 12:50:27 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3276C1A0990 for ; Thu, 13 Mar 2014 12:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1071; q=dns/txt; s=iport; t=1394740221; x=1395949821; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=CabpoSsdkFvKrmK8/RR1aMX0TrAGs0fA6QQinM5cWW4=; b=SPcO1QiFShdNKaDRF8BnjH3P3kqDOhsjI3NF0LWQD5V1CDe3GaBQ/N/v Hmp+HLZ8tl+bVBkQJSfJcUHdU/QN7yvzfLbw1arcV9qOGeWs47Pld7dXq skS1w1VBvFhxN60jiDy2v+ZLZjpbJGezYmI+4pABFIbwlycc/CzKnAh6s U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAEkLIlOtJXG9/2dsb2JhbABPCoMGgRLDARZ0giyBCwGBACcEiAyjB7EbF44BhRsEmEWSLYMtgis X-IronPort-AV: E=Sophos;i="4.97,648,1389744000"; d="scan'208";a="310124892" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 13 Mar 2014 19:50:20 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2DJoK65003438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Mar 2014 19:50:20 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 13 Mar 2014 14:50:20 -0500 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: comments on draft-pascual-bfcpbis-bfcp-websocket-00 Thread-Index: AQHPPvV2A075maMM9Ui7mdUSH5LcEQ== Date: Thu, 13 Mar 2014 19:50:19 +0000 Message-ID: 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.21.86.33] Content-Type: text/plain; charset="Windows-1252" Content-ID: <682C589082DA5D4CAC31DE670E140532@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/nQjN2tXKzVnpqhCBuY4fzSlRe7Q Subject: [bfcpbis] comments on draft-pascual-bfcpbis-bfcp-websocket-00 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 19:50:29 -0000 [as an individual] I read the draft and have a few comments/questions I wanted to share. Section 1, Intro As mentioned during the BFCPBIS session last week, it would be helpful to clarify form the start that this draft is concerned with transporting BFCP/TCP only, not BFCP/UDP. Also, where it reads, "a new reliable and message boundary transport for BFCP=B2, I think you meant to write =B3=8A boundary preserving transport = =8A=B2. Section 2.1 Definitions Definitions are provided for BFCP WebSocket Client/Server. BFCP itself defines a BFCP client and BFCP server. My assumption is that these are independent, meaning a BFCP WebSocket Client could be a BFCP client and/or a BFCP server. It would be helpful to clarify this in the draft. Section 4.1 The sample GET and 101 response contain the following to identify the WebSocket payload: Sec-WebSocket-Protocol: bfcp With rfc4582bis we added the definition of a BFCP version. Have you considered if you need to do anything to address this within WebSockets? Cheers, Charles From nobody Fri Mar 14 17:30:18 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4989B1A00FC for ; Fri, 14 Mar 2014 17:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 XaXdHxZpXPnW for ; Fri, 14 Mar 2014 17:30:16 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9851A012A for ; Fri, 14 Mar 2014 17:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=413; q=dns/txt; s=iport; t=1394843409; x=1396053009; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MmFPArD5oCmS4dE4n3XomfIsTIiCX7ep+UHse3hOB3g=; b=c4dMAcIW3WtM/fvd6jx6y7QgntT+Jc1cbt05m4Zg5bakBIG9V3MmSDBg kZ+oXTHMEWMzSQBgpE6CJLl1+5/h/OE3egYHMYCkMeBUJJthVJUC/5gAa i5jdBcxT8+eKhwZXsXpc/KpsWRLdJ0k9M3rgxOf62EiDBfqrIbc9jPw2b o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFANydI1OtJXG9/2dsb2JhbABZgwaBEsMQFnSCLB0dUQE+QicEiAyiObIFF5MmBJhFki6DLYIr X-IronPort-AV: E=Sophos;i="4.97,657,1389744000"; d="scan'208";a="310453040" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 15 Mar 2014 00:30:07 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2F0U77D022967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Mar 2014 00:30:07 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 19:30:07 -0500 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: call for adoption of draft-pascual-bfcpbis-bfcp-websocket-00 Thread-Index: AQHPP+W2HMyDCEuwPkSfetEYLV/n4A== Date: Sat, 15 Mar 2014 00:30:06 +0000 Message-ID: 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.21.86.33] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/AObAlgHcgtRCLY72us7RqvMNQWk Subject: [bfcpbis] call for adoption of draft-pascual-bfcpbis-bfcp-websocket-00 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Mar 2014 00:30:17 -0000 During our session at IETF 89, there was consensus not only to add a new milestone but also to adopt draft-pascual-bfcpbis-bfcp-websocket-00 as a working group draft toward that milestone. The chairs would like to give those not present at the meeting an opportunity to voice any concerns with adopting the draft at this time. Comments supporting adoption are of course welcome as well. Cheers, Charles From nobody Wed Mar 19 15:27:54 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E141A023C for ; Wed, 19 Mar 2014 15:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 cN1cIWjB7JDl for ; Wed, 19 Mar 2014 15:27:48 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 78B9B1A0319 for ; Wed, 19 Mar 2014 15:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2459; q=dns/txt; s=iport; t=1395268060; x=1396477660; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=sQI9i7D6XuZJvVFT53zedhrYC50Ylu+pl8TGh+B2dhM=; b=KVfC/1KYuXfx8MEphD3rc5RvJXgrafQAFeddfkM2iNyBUH1+B9GRe/Bt j3wFeMDLmAklLbIKRvk9Tkm1W3gcpybTs7s9Otp/gAG2oyoCMoZL96hi5 2BQ26zfEqTTzzaEn4EHUERkKUqH99ouqtVXa5Vxra8Uz+GrnmlNlDvVVX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8GAJMYKlOtJXHB/2dsb2JhbABagwY7TAu7FoZjUYEeFnSCJwEEAQEBGlEdAQhtCycEARKHeAEN0DAXjjKEcgSYR4EykH6DLYIr X-IronPort-AV: E=Sophos;i="4.97,689,1389744000"; d="scan'208";a="311310707" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 19 Mar 2014 22:27:39 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2JMRdiH018563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Mar 2014 22:27:39 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 17:27:39 -0500 From: "Charles Eckel (eckelcu)" To: "Charles Eckel (eckelcu)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] call for comments on draft-ietf-bfcpbis-rfc4582bis Thread-Index: AQHPQ8JuxkfRnpJkY0GDUBlVVjTrIQ== Date: Wed, 19 Mar 2014 22:27:38 +0000 Message-ID: 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: [171.68.20.15] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8B8625764AEC754CBD41A6A02CA101D5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/Df8ZpTQTsLC6ByyidEM5izU7qGk Subject: Re: [bfcpbis] call for comments on draft-ietf-bfcpbis-rfc4582bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 22:27:50 -0000 (as an individual) I read through the draft in detail. It addresses all the concerns I raised previously. In addition to the TCP/TLS clarifications requested by Christer, I suggest the following changes. These are mostly editorial. Section 5.3.17: s/should acknowledge/acknowledge I think it is best to drop the =B3should=B2 to avoid confusion with normati= ve statements. This is also more consistent with the rest of the message descriptions in this section. Normative language regarding the sending of request/response messages is specified elsewhere. Section 6: Transport I suggest rewording the information note as follows: OLD: Informational note: In practice products are configured to try one transport initially and use the other one as a fallback. Whether TCP or UDP is chosen as underlying transport depends on type of product and the nature of the environment it is deployed. Here Appendix B are important to consider. NEW: Informational note: In practice, products are configured to try one transport first and use the other transport as a fallback. Whether TCP or UDP is chosen as the underlying transport depends on the type of product and the deployment environment. See Appendix B for additional=20 considerations. Section 6.2 s/Situations =8A is described/Situations =8A are described Section 8 s/all requests will use retransmission timer T1/retransmission timer T1 MUST be used for all requests Section 8.2 s/valuse/values Section 16.2 s/The clarification and bug fixes/Clarifications and bug fixes I=B9m not sure what "Non-functional language clarifications=B2 are, but I don=B9t think we want them in the draft :) Perhaps replace with =B3Non-normative language clarifications=B2? Cheers, Charles On 3/4/14, 3:06 PM, "Charles Eckel (eckelcu)" wrote: >As discussed in the session today at IETF 89, this is to officially >announce a 2-week call for comments on draft-ietf-bfcpbis-rfc4582bis-11 >(http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-11), due by or >before March 19, 2014. >If the draft is perfect as is, please share that comment on the list as >well. > >Thank you, >Charles > > >_______________________________________________ >bfcpbis mailing list >bfcpbis@ietf.org >https://www.ietf.org/mailman/listinfo/bfcpbis From nobody Wed Mar 19 15:28:25 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5651A023C for ; Wed, 19 Mar 2014 15:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.547, 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 jyy5t7hcxRAx for ; Wed, 19 Mar 2014 15:28:13 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 778561A0761 for ; Wed, 19 Mar 2014 15:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1334; q=dns/txt; s=iport; t=1395268084; x=1396477684; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=5M+7ia7ukD7DpKlO8whEOOzUeno3vRmAVBj/LfuuNK4=; b=PiN3EctsBX9kcmnfC3Y+82TSBwLfAsMBxvF5wWVetcrTyMvr+lyNNQg9 Vr6PQnoeKOgK5OqwPwt8EMjMG5fEzAm603VyoRtSwD/RBfkDAEYnPNvS0 LJG9vkU830+w4H4a6sD32pPqn1lKSl9ObF7WlUz4ECmyD2Gz2MH+Zzfr2 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4GALEZKlOtJV2c/2dsb2JhbABagwY7TAu7FoZjgW8WdIInAQQBAQEaUR0BCG0LJwQBEod4AQ3QMBeTJASJGo8tgTKQfoMtgis X-IronPort-AV: E=Sophos;i="4.97,689,1389744000"; d="scan'208";a="311493398" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2014 22:27:44 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2JMRgx0021924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Mar 2014 22:27:42 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 17:27:42 -0500 From: "Charles Eckel (eckelcu)" To: "Charles Eckel (eckelcu)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] call for comments on draft-ietf-bfcpbis-rfc4583bis Thread-Index: AQHPQ8JxVQNELiQ44kaCH6k37ugk+w== Date: Wed, 19 Mar 2014 22:27:42 +0000 Message-ID: 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: [171.68.20.15] 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/bfcpbis/ij3FWQF-Zo5pCv2A57O1WbJrGsQ Subject: Re: [bfcpbis] call for comments on draft-ietf-bfcpbis-rfc4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 22:28:22 -0000 (as an individual) I read through the draft in detail. It addresses all the concerns I raised previously. I would to suggest a few additional changes. These are mostly editorial. Section 1 s/This data include/This data includes Section 7 s/and, when acting as a floor control server to use/and, when acting as a floor control server, to use Section 8 s/will direct the BFCP messages/direct the BFCP messages Section 9 s/How to determine which endpoint to initiate/How to determine which endpoint initiates Section 13 I=B9m not sure what "Non-functional language clarifications=B2 are, but I don=B9t think we want them in the draft :) Perhaps replace with =B3Non-normative language clarifications=B2? Cheers, Charles On 3/4/14, 3:06 PM, "Charles Eckel (eckelcu)" wrote: >As discussed in the session today at IETF 89, this is to officially >announce a 2-week call for comments on draft-ietf-bfcpbis-rfc4583bis-09 >(http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4583bis-09), due by or >before March 19, 2014. >If the draft is perfect as is, please share that comment on the list as >well. > >Thank you, >Charles > > >_______________________________________________ >bfcpbis mailing list >bfcpbis@ietf.org >https://www.ietf.org/mailman/listinfo/bfcpbis From nobody Tue Mar 25 12:39:33 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7F41A01E3 for ; Tue, 25 Mar 2014 12:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4Ba7fDgNlHvb for ; Tue, 25 Mar 2014 12:39:16 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 067321A0144 for ; Tue, 25 Mar 2014 12:39:15 -0700 (PDT) X-AuditID: c1b4fb38-b7f418e000001099-da-5331db620c93 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id B2.C2.04249.26BD1335; Tue, 25 Mar 2014 20:39:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Tue, 25 Mar 2014 20:39:13 +0100 From: Christer Holmberg To: "bfcpbis@ietf.org" Thread-Topic: TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Thread-Index: Ac9IYN6sW5RmxLlBTqekC7NH5gCkoA== Date: Tue, 25 Mar 2014 19:39:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D260FFE@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D260FFEESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+JvjW7SbcNgg/2vRSz+rTvK5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPOPFQueF1fcuN/I1MA4I7WLkZNDQsBE4lNzOyOELSZx4d56 ti5GLg4hgSOMErdOvYNyljBKnGjdC+RwcLAJWEh0/9MGaRAR0JTYvP0uE4gtLGAr0fT+KRNI iYiAk8TDV/4QJXoSX67cZQUJswioSpzf6Qdi8gr4Shx77ARSwQi09fupNWBDmAXEJW49mc8E cY2AxJI955khbFGJl4//sULYShKNS56wQtTnS5xdNZ8FxOYVEJQ4OfMJywRGoVlIRs1CUjYL SRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxchRnFqclJtuZLCJERjwB7f8ttjBePmv zSFGaQ4WJXHej2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwHmfJ+3ehQWeO5ItrYkvs pA8xGRyN+zav7BdLQE5VS/pBIZEODb++vqywu6+3TD21Jt/EbOYM3i1eWVsTe88yPOs84vBi 5jpuP15vweLJ2bLP3csVN4euZDfN5PsYosh1/tWWF43Z3VxqdZWp+gFtr0Xbj2nOeDF7Qf7y nMjCy7NU3pvoLGRXYinOSDTUYi4qTgQAd6p5QkYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/bU5woWfGjCsKD7LQ6T4VNGhGSxM Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 19:39:20 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D260FFEESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 7 in 4582bis, which says: "7. Lower-Layer Security BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS for transport over TCP [6] and MUST support DTLS [7] for transport over UDP. Any BFCP entity MAY support other security mechanisms. BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. Which party, the client or the floor control server, acts as the TLS/ DTLS server depends on how the underlying TLS/DTLS connection is established. For a TCP/TLS connection established using an SDP offer/answer exchange [9], the answerer (which may be the client or the floor control server) always acts as the TLS server. If the TCP connection is lost, the active endpoint, i.e., the current TLS client, is responsible for re-establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. For a UDP/DTLS connection established using the an SDP offer/answer exchange, either party can be the DTLS server depending on the setup attributes exchanged; examples can be found in [23]." First, we already earlier discussed that the active TCP endpoint is respons= ible for re-establishing the TCP connection, and that will be corrected in = the next version of the draft. However, we have discussed a similar topic in CLUE, and we were wondering w= hether it would be good that, whoever detects a connection failure, sends a= new offer in order to re-establish the connection. It does not matter if b= oth endpoints send an offer - the offer/answer race condition rules will ta= ke care of that. Second, Section 8.1 in 4583bis says: "When the existing TCP connection is reset following the rules in [8], the client MUST generate an offer towards the floor control server in order to reestablish the connection. If a TCP connection cannot deliver a BFCP message and times out, the entity that attempted to send the message (i.e., the one that detected the TCP timeout) MUST generate an offer in order to reestablish the TCP connection." I am not sure what is meant by "TCP connection is reset following the rules= in [8]". Which rules are you referring to? Then, the text says that the client always re-established the TCP connectio= n. Is that aligned with the text in 4582bis, saying that the active party d= oes the reestablishment? Is the client always active? I think it is a little confusing that both 4582bis and 4583bis defines SDP = Offer/Answer procedures. Shouldn't they only be in 4583bis? Third, the last paragraph, talking about UDP/DTLS, says that either party c= an be DTLS server depending on the setup attributes exchanged. But, nowhere= is it described how the setup attribute is used to determine the DTLS serv= er role :) I assume it is done in the same way as for TCP/TLS, but that is not written= anywhere. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D260FFEESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 7 in 4582bis, which says:

 

“7.  Lower-Layer Sec= urity

 

   BFCP relies on low= er-layer security mechanisms to provide replay and

   integrity protecti= on and confidentiality.  BFCP floor control servers<= /p>

   and clients (which= include both floor participants and floor chairs)

 

   MUST support TLS f= or transport over TCP [6] and MUST support DTLS [7]

   for transport over= UDP.  Any BFCP entity MAY support other security

   mechanisms.

 

   BFCP entities MUST= support, at a minimum, the

   TLS_RSA_WITH_AES_1= 28_CBC_SHA ciphersuite [6].

 

   Which party, the c= lient or the floor control server, acts as the TLS/

   DTLS server depend= s on how the underlying TLS/DTLS connection is

   established. = For a TCP/TLS connection established using an SDP

   offer/answer excha= nge [9], the answerer (which may be the client or

   the floor control = server) always acts as the TLS server.  If the TCP

   connection is lost= , the active endpoint, i.e., the current TLS

   client, is respons= ible for re-establishing the TCP connection.

   Unless a new TLS s= ession is negotiated, subsequent SDP offers and

   answers will not i= mpact the previously negotiated TLS roles.

 

   For a UDP/DTLS con= nection established using the an SDP offer/answer

   exchange, either p= arty can be the DTLS server depending on the setup

   attributes exchang= ed; examples can be found in [23].”

 

First, we al= ready earlier discussed that the active TCP endpoint is responsible for re-= establishing the TCP connection, and that will be corrected in the next ver= sion of the draft.

 

However, we have discussed a similar topic in CLUE, = and we were wondering whether it would be good that, whoever detects a conn= ection failure, sends a new offer in order to re-establish the connection. = It does not matter if both endpoints send an offer – the offer/answer race condition rules will take care= of that.

 

 

Second, Sect= ion 8.1 in 4583bis says:

 

   “When the existing TCP connection is reset followin=
g the rules in [8],
   the client MUST generate an offer towards the floor contr=
ol server in
   order to reestablish the connection.  If a TCP conne=
ction cannot
   deliver a BFCP message and times out, the entity that att=
empted to
   send the message (i.e., the one that detected the TCP tim=
eout) MUST
   generate an offer in order to reestablish the TCP connect=
ion.”
 
 

I am not sure what is meant by “TCP connection= is reset following the rules in [8]”. Which rules are you referring = to?

 

Then, the text says that the client always re-establ= ished the TCP connection. Is that aligned with the text in 4582bis, saying = that the active party does the reestablishment? Is the client always active= ?

 

I think it is a little confusing that both 4582bis a= nd 4583bis defines SDP Offer/Answer procedures. Shouldn’t they only b= e in 4583bis?

 

 

 

Third, the l= ast paragraph, talking about UDP/DTLS, says that either party can be DTLS s= erver depending on the setup attributes exchanged. But, nowhere is it descr= ibed how the setup attribute is used to determine the DTLS server role J<= /span>

 

I assume it is done in the same way as for TCP/TLS, = but that is not written anywhere.

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1D260FFEESESSMB209erics_-- From nobody Wed Mar 26 14:21:12 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4AE1A03D7 for ; Wed, 26 Mar 2014 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P46XvZPtMF5M for ; Wed, 26 Mar 2014 14:21:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 984251A03D4 for ; Wed, 26 Mar 2014 14:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=988; q=dns/txt; s=iport; t=1395868866; x=1397078466; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=i41pEoW+3Tz+GkacT4m/qcAnyBy0rbhUg+b2vejsRFs=; b=cVfgwFd1/62M1JUNf9qvyhV+Xz1AUrxxrNOd/Hkr/jAOep8LIXcTKriV Ioh4dGQUn2meFPmG50mpYPXXrMAEmYr68+Gi6t2FSUcaFi195FlrHW9ES gQWYL4A2tlDGE4XKRqIY8c+qhiEvT+tzYYTqc9jafLzbmFbE9eRNgOYQQ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYGAE9EM1OtJV2b/2dsb2JhbABZgwY7TAu7PoZkUYEeFnSCJgEBBAEBARodNBsCAQg2ECcLJQIEARKHeQ3RORMEjniEOASYTZIzgy6CKw X-IronPort-AV: E=Sophos;i="4.97,737,1389744000"; d="scan'208";a="313133327" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 26 Mar 2014 21:21:06 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s2QLL5FK028135 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 21:21:05 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 16:21:05 -0500 From: "Charles Eckel (eckelcu)" To: "Charles Eckel (eckelcu)" , "bfcpbis@ietf.org" Thread-Topic: [bfcpbis] call for adoption of draft-pascual-bfcpbis-bfcp-websocket-00 Thread-Index: AQHPP+W2HMyDCEuwPkSfetEYLV/n4Jrz0UMA Date: Wed, 26 Mar 2014 21:21:05 +0000 Message-ID: References: In-Reply-To: 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.21.124.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <072005938CC9504489C259A2F421524A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/72U8WUzPSxJQejaz-KpAjo6yOc8 Subject: Re: [bfcpbis] call for adoption of draft-pascual-bfcpbis-bfcp-websocket-00 X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:21:11 -0000 Having heard no objections or concerns from the list, I ask the draft authors to please submit draft-pascual-bfcpbis-bfcp-websocket-00 as draft-ietf-bfcpbis-bfcp-websocket-00, which will be the working group draft for the following milestone: Nov 2014 - Draft for BFCP over WebSocket to IESG as Proposed Standard Thanks, Charles On 3/14/14, 5:30 PM, "Charles Eckel (eckelcu)" wrote: >During our session at IETF 89, there was consensus not only to add a new >milestone but also to adopt draft-pascual-bfcpbis-bfcp-websocket-00 as a >working group draft toward that milestone. The chairs would like to give >those not present at the meeting an opportunity to voice any concerns with >adopting the draft at this time. Comments supporting adoption are of >course welcome as well. > >Cheers, >Charles > >_______________________________________________ >bfcpbis mailing list >bfcpbis@ietf.org >https://www.ietf.org/mailman/listinfo/bfcpbis From nobody Wed Mar 26 16:10:58 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D481A0401 for ; Wed, 26 Mar 2014 16:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmv6Mv7ygQfn for ; Wed, 26 Mar 2014 16:10:46 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id EAF041A0205 for ; Wed, 26 Mar 2014 16:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30025; q=dns/txt; s=iport; t=1395875444; x=1397085044; h=from:to:cc:subject:date:message-id:mime-version; bh=D6uROMbvK70QKJVmar7LRhFOF1V/aP7EhrR/YrSboXo=; b=VUs2MaFB956tS+mjORYOUxjucp3N1KUK3QIZlrcukU+mQAxKUpdqZrxI Xhp9ydkhSSRXAV8GufK7Y4+4foyYoDqv8fUCXUZZ4C/kJHUYiwyIg59Pe /f3/LQDUz86iAzGK5v1ftVkb1Wx0oU/fSNbXn0nWynJ6dbwpr1EIoVjNo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAN1dM1OtJV2c/2dsb2JhbABZgkJEO1fCeoEbFnSCJQECBC1MEgEIEQMBAiEBBjkUCQoEDgUbh17RWBeOYBEGB4QyBJRhg2ySM4MugWkHOw X-IronPort-AV: E=Sophos; i="4.97,738,1389744000"; d="scan'208,217"; a="30667415" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 26 Mar 2014 23:10:44 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2QNAhve010409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 23:10:43 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 18:10:43 -0500 From: "Charles Eckel (eckelcu)" To: Christer Holmberg Thread-Topic: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Thread-Index: AQHPSUic50RqEV5EM0G8qoAclTNxQg== Date: Wed, 26 Mar 2014 23:10:42 +0000 Message-ID: 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.21.124.61] Content-Type: multipart/alternative; boundary="_000_CF58989923B24eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/OyCiKwICjDgaz1DwTQ-ibCyQRKo Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 23:10:54 -0000 --_000_CF58989923B24eckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Christer, Thanks for your comments. The more I looked into them the more complex and = tangled things became. Let me try to walk through the current state of affa= irs and then propose a potential solutions. RFC 4582 breaks connection establishment into two cases: 1. when SDP offer/answer IS NOT used 2. when SDP offer/answer IS used For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds= a reference to RFC 5239 for XCON. RFC 5018 deals with the connection establishment, reestablishment, and TLS= usage. RFC 5239 points back to RFC 5018 for connection establishment. RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in which= SDP offer/answer is used, we need to update RFC 5018 to deal with DTLS. So= meone please tell me otherwise. Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC= 5018 when dealing with BFCP over UDP or DTLS. I think this should be reloc= ated to an update to RFC 5018, and connection reestablishment should be des= cribed as well. For (2), RFC 4582 provides a teaser but points to RFC 4583 for the normativ= e language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf= -bfcpbis-rfc4583bis-09. Christer comments are in regard to inconsistencies = here. I provided comments on those inline. From: Christer Holmberg > Date: Tuesday, March 25, 2014 at 12:39 PM To: "bfcpbis@ietf.org" > Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Hi, Section 7 in 4582bis, which says: =937. Lower-Layer Security BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS for transport over TCP [6] and MUST support DTLS [7] for transport over UDP. Any BFCP entity MAY support other security mechanisms. BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. Which party, the client or the floor control server, acts as the TLS/ DTLS server depends on how the underlying TLS/DTLS connection is established. For a TCP/TLS connection established using an SDP offer/answer exchange [9], the answerer (which may be the client or the floor control server) always acts as the TLS server. If the TCP connection is lost, the active endpoint, i.e., the current TLS client, is responsible for re-establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. For a UDP/DTLS connection established using the an SDP offer/answer exchange, either party can be the DTLS server depending on the setup attributes exchanged; examples can be found in [23].=94 First, we already earlier discussed that the active TCP endpoint is respons= ible for re-establishing the TCP connection, and that will be corrected in = the next version of the draft. Yes. However, we have discussed a similar topic in CLUE, and we were wondering w= hether it would be good that, whoever detects a connection failure, sends a= new offer in order to re-establish the connection. It does not matter if b= oth endpoints send an offer =96 the offer/answer race condition rules will = take care of that. In CLUE, is this for a TCP/TLS connection, or for a DTLS connection? For DTLS, we specifically chose to alter the behavior, as described in sect= ion 9.1 of 4583bis: "Endpoints that use the offer/answer model to establish a DTLS association MUST support the 'setup' attribute, as defined in [7]. When DTLS is used with UDP, the 'setup' attribute indicates which of the endpoints (client or floor control server) initiates the DTLS association setup. The requirements for the offer/answer exchange specified in [13], Section 5 MUST be followed when using DTLS. Informational note: How to determine which endpoint to initiate the TLS/DTLS association depends on the selected underlying transport. It was decided to keep the original semantics in [15] for TCP to retain backwards compatibility. When using UDP, the procedure above was preferred since it adheres to [13] as used for DTLS-SRTP, it does not overload offer/answer semantics, and it works for offerless INVITE in scenarios with B2BUAs." Second, Section 8.1 in 4583bis says: =93When the existing TCP connection is reset following the rules in [8], the client MUST generate an offer towards the floor control server in order to reestablish the connection. If a TCP connection cannot deliver a BFCP message and times out, the entity that attempted to send the message (i.e., the one that detected the TCP timeout) MUST generate an offer in order to reestablish the TCP connection.=94 I am not sure what is meant by =93TCP connection is reset following the rul= es in [8]=94. Which rules are you referring to? Reset means closed and reestablished. The word =93reset=94 was used in RFC = 4582 and reused in 4582bis. Perhaps we should change it closed and reestabl= ished to avoid confusion? Then, the text says that the client always re-established the TCP connectio= n. Is that aligned with the text in 4582bis, saying that the active party d= oes the reestablishment? Is the client always active? I think it is a little confusing that both 4582bis and 4583bis defines SDP = Offer/Answer procedures. Shouldn=92t they only be in 4583bis? Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its section= on lower layer security, and 4582bis followed suit. It would be better to = have all the details of connection establishment and reestablishment in whe= n using SDP offer/answer in 4583bis. Third, the last paragraph, talking about UDP/DTLS, says that either party c= an be DTLS server depending on the setup attributes exchanged. But, nowhere= is it described how the setup attribute is used to determine the DTLS serv= er role :) I assume it is done in the same way as for TCP/TLS, but that is not written= anywhere. The text I pasted from 4583bis above describes this. If we put all the conn= ection management stuff in 4583bis instead of leaving it split across 4582b= is and 4583bis, this should be clear. Cheers, Charles Regards, Christer --_000_CF58989923B24eckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <84231517C9D33E4EBC143B508E7300D1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Christer,

Thanks for your comments. The more I looked into them the more complex and = tangled things became. Let me try to walk through the current state of affa= irs and then propose a potential solutions.

RFC 4582 breaks connection establishment into two cases:
  1. when SDP offer/answer IS NOT used
  2. when SDP offer/answer IS used=
For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds= a reference to RFC 5239 for XCON.
RFC 5018 deals with the connection establishment, reestablishment,  an= d TLS usage.
RFC 5239 points back to RFC 5018 for connection establishment.
RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in which= SDP offer/answer is used, we need to update RFC 5018 to deal with DTLS. So= meone please tell me otherwise.

Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC= 5018 when dealing with BFCP over UDP or DTLS. I think this should be reloc= ated to an update to RFC 5018, and connection reestablishment should be des= cribed as well.

For (2), RFC 4582 provides a teaser but points to RFC 4583 for the normativ= e language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf= -bfcpbis-rfc4583bis-09. Christer comments are in regard to inconsistencies = here. I provided comments on those inline.

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tuesday, March 25, 2014 at 12= :39 PM
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: [bfcpbis] TCP/TLS and UDP/= DTLS comments on 4582bis and 4583bis

Hi,

 

Section 7 in 4582bis, which says:

 

=937.  Lower-Layer Security

 

   BFCP relies on lower-layer security mechanisms to pro= vide replay and

   integrity protection and confidentiality.  BFCP = floor control servers

   and clients (which include both floor participants an= d floor chairs)

 

   MUST support TLS for transport over TCP [6] and MUST = support DTLS [7]

   for transport over UDP.  Any BFCP entity MAY sup= port other security

   mechanisms.

 

   BFCP entities MUST support, at a minimum, the

   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].

 

   Which party, the client or the floor control server, = acts as the TLS/

   DTLS server depends on how the underlying TLS/DTLS co= nnection is

   established.  For a TCP/TLS connection establish= ed using an SDP

   offer/answer exchange [9], the answerer (which may be= the client or

   the floor control server) always acts as the TLS serv= er.  If the TCP

   connection is lost, the active endpoint, i.e., the cu= rrent TLS

   client, is responsible for re-establishing the TCP co= nnection.

   Unless a new TLS session is negotiated, subsequent SD= P offers and

   answers will not impact the previously negotiated TLS= roles.

 

   For a UDP/DTLS connection established using the an SD= P offer/answer

   exchange, either party can be the DTLS server dependi= ng on the setup

   attributes exchanged; examples can be found in [23].= =94

 

First, we al= ready earlier discussed that the active TCP endpoint is responsible for re-= establishing the TCP connection, and that will be corrected in the next ver= sion of the draft.

Yes.

&nb= sp;

However,= we have discussed a similar topic in CLUE, and we were wondering whether i= t would be good that, whoever detects a connection failure, sends a new off= er in order to re-establish the connection. It does not matter if both endpoints send an offer =96 the offer/answer ra= ce condition rules will take care of that.

In CLUE, is this for a= TCP/TLS connection, or for a DTLS connection?
For DTLS, we specifica= lly chose to alter the behavior, as described in section 9.1 of 4583bis:

  "Endpoints= that use the offer/answer model to establish a DTLS
   association MUST support the 'setup' attribute, as define= d in [7].
   When DTLS is used with UDP, the 'setup' attribute indicat= es which of
   the endpoints (client or floor control server) initiates = the DTLS
   association setup.  The requirements for the offer/a= nswer exchange
   specified in [13], Section 5 MUST be followed when using = DTLS.

      Informational note: How to determine which endpoi= nt to initiate
      the TLS/DTLS association depends on the selected = underlying
      transport.  It was decided to keep the origi= nal semantics in [15]
      for TCP to retain backwards compatibility.  = When using UDP, the
      procedure above was preferred since it adheres to= [13] as used for
      DTLS-SRTP, it does not overload offer/answer sema= ntics, and it
      works for offerless INVITE in scenarios with B2BU= As."


 

&nb= sp;

Second, Section 8.1 in 4583bis says:

&nb= sp;

   =93When the e=
xisting TCP connection is reset following the rules in [8],

   the client MU=
ST generate an offer towards the floor control server in


   order to rees=
tablish the connection.  If a TCP connection cannot


   deliver a BFC=
P message and times out, the entity that attempted to


   send the mess=
age (i.e., the one that detected the TCP timeout) MUST


   generate an o=
ffer in order to reestablish the TCP connection.=94


 


 


I am not=
 sure what is meant by =93TCP connection is reset following the rules in [8=
]=94. Which rules are you referring to?

Reset means closed and= reestablished. The word =93reset=94 was used in RFC 4582 and reused in 458= 2bis. Perhaps we should change it closed and reestablished to avoid confusi= on?

&nb= sp;

Then, th= e text says that the client always re-established the TCP connection. Is th= at aligned with the text in 4582bis, saying that the active party does the = reestablishment? Is the client always active?

&nb= sp;

I think = it is a little confusing that both 4582bis and 4583bis defines SDP Offer/An= swer procedures. Shouldn=92t they only be in 4583bis?

Yes, I think so. RFC 4= 582 mixed some SDP offer/answer text into its section on lower layer securi= ty, and 4582bis followed suit. It would be better to have all the details o= f connection establishment and reestablishment in when using SDP offer/answer in 4583bis. 

&nb= sp;

&nb= sp;

&nb= sp;

Third, the last paragraph, talking about UD= P/DTLS, says that either party can be DTLS server depending on the setup at= tributes exchanged. But, nowhere is it described how the setup attribute is used to determine the DTLS server rol= e J

&nb= sp;

I assume= it is done in the same way as for TCP/TLS, but that is not written anywher= e.

The text I pasted from 4583bis above describes this. If we put all the= connection management stuff in 4583bis instead of leaving it split across = 4582bis and 4583bis, this should be clear.

Cheers,
Charles

&nb= sp;

&nb= sp;

Regards,=

&nb= sp;

Christer=

&nb= sp;

 --_000_CF58989923B24eckelcuciscocom_-- From nobody Wed Mar 26 16:14:53 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7071A0205; Wed, 26 Mar 2014 16:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzWA0e5Pc-jY; Wed, 26 Mar 2014 16:14:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2704C1A0380; Wed, 26 Mar 2014 16:14:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140326231442.19524.43290.idtracker@ietfa.amsl.com> Date: Wed, 26 Mar 2014 16:14:42 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/Rs3XttTWsX6Ftnji6Ax_Mv-VmyM Cc: bfcpbis@ietf.org Subject: [bfcpbis] I-D Action: draft-ietf-bfcpbis-bfcp-websocket-00.txt X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 23:14:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Binary Floor Control Protocol Bis Working Group of the IETF. Title : The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP) Authors : Victor Pascual Anton Roman Stephane Cazeaux Gonzalo Salgueiro Sergio Garcia Murillo Filename : draft-ietf-bfcpbis-bfcp-websocket-00.txt Pages : 11 Date : 2014-03-26 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) entities to enable usage of BFCP in new scenarios. This document normatively updates [I-D.draft-ietf- bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-bfcp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-bfcpbis-bfcp-websocket-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 27 12:28:33 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C04A1A06D8 for ; Thu, 27 Mar 2014 12:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA8M1EdojgUW for ; Thu, 27 Mar 2014 12:28:29 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id AE8941A0333 for ; Thu, 27 Mar 2014 12:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=271; q=dns/txt; s=iport; t=1395948508; x=1397158108; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wQrUY7ZI/TD21EppfJWBekMpM+CUnVdz5CCnMuEtUDA=; b=kdOGJG5M1qMX+zFsbxjZCvC1O9AV63MQpvcdlBxiJb/xGFJXfAT4NROK Q2ZS6jcoE62wkQdHe48SV29w/D1AiKlOL3rbYNKJNHRCvSHbIujzcXBX9 iF7aFc6HHdmQJqlBHvpB+hTmD+to/jO68iWdBMQiHfxugu4CAxdb1dp9r w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAAt7NFOtJXG9/2dsb2JhbABZgwY7GT7CUoEoFnSCLDpRAT5CJwQch28BDZ9AsWEXkzkEmE2SNIMvgis X-IronPort-AV: E=Sophos;i="4.97,744,1389744000"; d="scan'208";a="30929612" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-3.cisco.com with ESMTP; 27 Mar 2014 19:28:27 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2RJSRnn000529 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Mar 2014 19:28:27 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Thu, 27 Mar 2014 14:28:27 -0500 From: "Charles Eckel (eckelcu)" To: "bfcpbis@ietf.org" Thread-Topic: minutes from IETF 89 posted Thread-Index: AQHPSfK6hvKlrKJ14E+Ms1Uag7TksQ== Date: Thu, 27 Mar 2014 19:28:27 +0000 Message-ID: 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: [171.68.20.29] Content-Type: text/plain; charset="us-ascii" Content-ID: <99A346551A80664F9E448835BF1E43D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/ASJnP9o7ax0GxMzxGtWq834QLcM Subject: [bfcpbis] minutes from IETF 89 posted X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 19:28:31 -0000 Sorry for the delay to getting this posted. Thanks to Alan for the excellent note taking. Please have a look and let the chair know about anything that needs to be correct or added. http://www.ietf.org/proceedings/89/minutes/minutes-89-bfcpbis Cheers, Charles From nobody Sat Mar 29 04:41:06 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14AF1A04AB for ; Sat, 29 Mar 2014 04:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, 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 YQexrQH38i-z for ; Sat, 29 Mar 2014 04:40:59 -0700 (PDT) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id E88B71A04A3 for ; Sat, 29 Mar 2014 04:40:58 -0700 (PDT) X-AuditID: c1b4fb32-b7fe98e0000034f3-8d-5336b147c86d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 8F.57.13555.741B6335; Sat, 29 Mar 2014 12:40:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Sat, 29 Mar 2014 12:40:54 +0100 From: Christer Holmberg To: "Charles Eckel (eckelcu)" Thread-Topic: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Thread-Index: AQHPSUic50RqEV5EM0G8qoAclTNxQpr39Bsg Date: Sat, 29 Mar 2014 11:40:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> References: 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.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D26AD25ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+Jvja77RrNgg5PTpC3+rTvKZLFp1hc2 ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugStj2acFrAX3FjNVbOw0aWDsbmTqYuTkkBAw kVi7dCI7hC0mceHeerYuRi4OIYETjBJ3v3xhgnCWMEqs+HmVsYuRg4NNwEKi+582SIOIgKHE oknrWEBsZgFNiauHdzGC2MIC3hIv/q1ihqjxkbh7rYsdpFVEwEjiw8JckDCLgKrE8rPrwW7g FfCV+HO3hQ3EFhLQk3h9qI8VxOYU0JfY0zsfbCQj0G3fT61hglglLnHryXyo+wUkluw5zwxh i0q8fPyPFcJWklix/RLYxcwC+RKff1hBrBKUODnzCcsERtFZSCbNQqiahaQKokRHYsHuT2wQ trbEsoWvmWHsMwceMyGLL2BkX8UoWZxaXJybbmSgl5ueW6KXWpSZXFycn6dXnLqJERhzB7f8 NtrBeHKP/SFGaQ4WJXHe66w1QUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYba6Jvtvw22it 4P7nu0x4yxjawwPKn7069bfK8LWtstfB/hSnnn/Jt2qlf62obDnAtfHltjXdelv/f43UtQy0 Z/i78ltSoHJbiT3XZgGH142lvUKrylr1dv1PZeHkVOO5v4Ar5de3oxLPQ6vXK+ideKZ98sT8 e3sWLynp7DvpOXER1wX228uXKLEUZyQaajEXFScCAFdyL0eHAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/nDVdOmpNmCxYdbx2CWfd9Z0cwOM Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 11:41:04 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D26AD25ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Charles, Without commenting on specifics at this point, I really think we should try= to get the SDP Offer/Answer procedures into one place (4583bis). 4582bis can define actions taken by the DTLS client and server, but should = not define how those roles are determined. 4583bis then defines how the rol= es are determined when using SDP O/A. Regards, Christer From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: 27 March 2014 01:11 To: Christer Holmberg Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Hi Christer, Thanks for your comments. The more I looked into them the more complex and = tangled things became. Let me try to walk through the current state of affa= irs and then propose a potential solutions. RFC 4582 breaks connection establishment into two cases: 1. when SDP offer/answer IS NOT used 2. when SDP offer/answer IS used For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds= a reference to RFC 5239 for XCON. RFC 5018 deals with the connection establishment, reestablishment, and TLS= usage. RFC 5239 points back to RFC 5018 for connection establishment. RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in which= SDP offer/answer is used, we need to update RFC 5018 to deal with DTLS. So= meone please tell me otherwise. Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC= 5018 when dealing with BFCP over UDP or DTLS. I think this should be reloc= ated to an update to RFC 5018, and connection reestablishment should be des= cribed as well. For (2), RFC 4582 provides a teaser but points to RFC 4583 for the normativ= e language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf= -bfcpbis-rfc4583bis-09. Christer comments are in regard to inconsistencies = here. I provided comments on those inline. From: Christer Holmberg > Date: Tuesday, March 25, 2014 at 12:39 PM To: "bfcpbis@ietf.org" > Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Hi, Section 7 in 4582bis, which says: "7. Lower-Layer Security BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS for transport over TCP [6] and MUST support DTLS [7] for transport over UDP. Any BFCP entity MAY support other security mechanisms. BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. Which party, the client or the floor control server, acts as the TLS/ DTLS server depends on how the underlying TLS/DTLS connection is established. For a TCP/TLS connection established using an SDP offer/answer exchange [9], the answerer (which may be the client or the floor control server) always acts as the TLS server. If the TCP connection is lost, the active endpoint, i.e., the current TLS client, is responsible for re-establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. For a UDP/DTLS connection established using the an SDP offer/answer exchange, either party can be the DTLS server depending on the setup attributes exchanged; examples can be found in [23]." First, we already earlier discussed that the active TCP endpoint is respons= ible for re-establishing the TCP connection, and that will be corrected in = the next version of the draft. Yes. However, we have discussed a similar topic in CLUE, and we were wondering w= hether it would be good that, whoever detects a connection failure, sends a= new offer in order to re-establish the connection. It does not matter if b= oth endpoints send an offer - the offer/answer race condition rules will ta= ke care of that. In CLUE, is this for a TCP/TLS connection, or for a DTLS connection? For DTLS, we specifically chose to alter the behavior, as described in sect= ion 9.1 of 4583bis: "Endpoints that use the offer/answer model to establish a DTLS association MUST support the 'setup' attribute, as defined in [7]. When DTLS is used with UDP, the 'setup' attribute indicates which of the endpoints (client or floor control server) initiates the DTLS association setup. The requirements for the offer/answer exchange specified in [13], Section 5 MUST be followed when using DTLS. Informational note: How to determine which endpoint to initiate the TLS/DTLS association depends on the selected underlying transport. It was decided to keep the original semantics in [15] for TCP to retain backwards compatibility. When using UDP, the procedure above was preferred since it adheres to [13] as used for DTLS-SRTP, it does not overload offer/answer semantics, and it works for offerless INVITE in scenarios with B2BUAs." Second, Section 8.1 in 4583bis says: "When the existing TCP connection is reset following the rules in [8], the client MUST generate an offer towards the floor control server in order to reestablish the connection. If a TCP connection cannot deliver a BFCP message and times out, the entity that attempted to send the message (i.e., the one that detected the TCP timeout) MUST generate an offer in order to reestablish the TCP connection." I am not sure what is meant by "TCP connection is reset following the rules= in [8]". Which rules are you referring to? Reset means closed and reestablished. The word "reset" was used in RFC 4582= and reused in 4582bis. Perhaps we should change it closed and reestablishe= d to avoid confusion? Then, the text says that the client always re-established the TCP connectio= n. Is that aligned with the text in 4582bis, saying that the active party d= oes the reestablishment? Is the client always active? I think it is a little confusing that both 4582bis and 4583bis defines SDP = Offer/Answer procedures. Shouldn't they only be in 4583bis? Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its section= on lower layer security, and 4582bis followed suit. It would be better to = have all the details of connection establishment and reestablishment in whe= n using SDP offer/answer in 4583bis. Third, the last paragraph, talking about UDP/DTLS, says that either party c= an be DTLS server depending on the setup attributes exchanged. But, nowhere= is it described how the setup attribute is used to determine the DTLS serv= er role :) I assume it is done in the same way as for TCP/TLS, but that is not written= anywhere. The text I pasted from 4583bis above describes this. If we put all the conn= ection management stuff in 4583bis instead of leaving it split across 4582b= is and 4583bis, this should be clear. Cheers, Charles Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D26AD25ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Charles,=

 

Without commenting on = specifics at this point, I really think we should try to get the SDP Offer/= Answer procedures into one place (4583bis).

 

4582bis can define act= ions taken by the DTLS client and server, but should not define how those r= oles are determined. 4583bis then defines how the roles are determined when= using SDP O/A.

 

Regards,

 

Christer

 

From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
Sent: 27 March 2014 01:11
To: Christer Holmberg
Cc: bfcpbis@ietf.org
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and = 4583bis

 

Hi Chri= ster,

&n= bsp;

Thanks = for your comments. The more I looked into them the more complex and tangled= things became. Let me try to walk through the current state of affairs and= then propose a potential solutions.

&n= bsp;

RFC 458= 2 breaks connection establishment into two cases:

  1. when SDP offer/answer IS NOT used
  2. when SDP offer/answer IS used

For (1)= , RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds a refe= rence to RFC 5239 for XCON.

RFC 501= 8 deals with the connection establishment, reestablishment,  and TLS u= sage.

RFC 523= 9 points back to RFC 5018 for connection establishment.

RFC 501= 8 does not deal with DTLS. Unless we restrict DTLS to cases in which SDP of= fer/answer is used, we need to update RFC 5018 to deal with DTLS. Someone p= lease tell me otherwise.

&n= bsp;

Section= 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC 5018 w= hen dealing with BFCP over UDP or DTLS. I think this should be relocated to= an update to RFC 5018, and connection reestablishment should be described as well.

&n= bsp;

For (2)= , RFC 4582 provides a teaser but points to RFC 4583 for the normative langu= age. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf-bfcpbi= s-rfc4583bis-09. Christer comments are in regard to inconsistencies here. I provided comments on those inline.

&n= bsp;

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tuesday, March 25, 2014 at 12:39 PM
To: "bfcpbis@ietf.org&q= uot; <bfcpbis@ietf.org>
Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583= bis

&n= bsp;

Hi,

 =

Section 7 in 4582bis, wh= ich says:

 =

“7.  Lower-Layer Security

 =

   BFCP relies on lower-layer securi= ty mechanisms to provide replay and=

   integrity protection and confiden= tiality.  BFCP floor control servers

   and clients (which include both f= loor participants and floor chairs)=

 =

   MUST support TLS for transport ov= er TCP [6] and MUST support DTLS [7]

   for transport over UDP.  Any= BFCP entity MAY support other security<= o:p>

   mechanisms.

 =

   BFCP entities MUST support, at a = minimum, the

   TLS_RSA_WITH_AES_128_CBC_SHA ciph= ersuite [6].

 =

   Which party, the client or the fl= oor control server, acts as the TLS/

   DTLS server depends on how the un= derlying TLS/DTLS connection is

   established.  For a TCP/TLS = connection established using an SDP=

   offer/answer exchange [9], the an= swerer (which may be the client or<= /o:p>

   the floor control server) always = acts as the TLS server.  If the TCP=

   connection is lost, the active en= dpoint, i.e., the current TLS=

   client, is responsible for re-est= ablishing the TCP connection.=

   Unless a new TLS session is negot= iated, subsequent SDP offers and

   answers will not impact the previ= ously negotiated TLS roles.

 =

   For a UDP/DTLS connection establi= shed using the an SDP offer/answer<= /o:p>

   exchange, either party can be the= DTLS server depending on the setup=

   attributes exchanged; examples ca= n be found in [23].”

 =

First, we already earlier discussed that the active TCP end= point is responsible for re-establishing the TCP connection, and that will = be corrected in the next version of the draft.

 

Yes.

 

 =

However, we have discuss= ed a similar topic in CLUE, and we were wondering whether it would be good = that, whoever detects a connection failure, sends a new offer in order to r= e-establish the connection. It does not matter if both endpoints send an offer – the offer/answer race c= ondition rules will take care of that.

 

In CLUE, is this for a TCP/TLS connection, or for a DTLS connection?

For DTLS, we specifically chose to alter the behavior, as described in s= ection 9.1 of 4583bis:

 

  "Endpoints that use the offer/answer model to establish a DT= LS

  &n= bsp;association MUST support the 'setup' attribute, as defined in [7].=

  &n= bsp;When DTLS is used with UDP, the 'setup' attribute indicates which of

  &n= bsp;the endpoints (client or floor control server) initiates the DTLS<= /o:p>

  &n= bsp;association setup.  The requirements for the offer/answer exchange=

  &n= bsp;specified in [13], Section 5 MUST be followed when using DTLS.

&nbs= p;

  &n= bsp;   Informational note: How to determine which endpoint to initiate=

  &n= bsp;   the TLS/DTLS association depends on the selected underlying

  &n= bsp;   transport.  It was decided to keep the original semantics = in [15]

  &n= bsp;   for TCP to retain backwards compatibility.  When using UDP= , the

  &n= bsp;   procedure above was preferred since it adheres to [13] as used = for

  &n= bsp;   DTLS-SRTP, it does not overload offer/answer semantics, and it<= o:p>

  &n= bsp;   works for offerless INVITE in scenarios with B2BUAs."=

 

 

 =

 =

Second, Section 8.1 in 4583bis says:

 = 

   “When the existing TCP connection is reset =
following the rules in [8],
   the client MUST generate an offer towards the flo=
or control server in
   order to reestablish the connection.  If a T=
CP connection cannot
   deliver a BFCP message and times out, the entity =
that attempted to
   send the message (i.e., the one that detected the=
 TCP timeout) MUST
   generate an offer in order to reestablish the TCP=
 connection.”
 
 

I am not sure what is me= ant by “TCP connection is reset following the rules in [8]”. Wh= ich rules are you referring to?

 

Reset means closed and reestablished. The word “reset” was u= sed in RFC 4582 and reused in 4582bis. Perhaps we should change it closed and reestablished to avoid confusion?

 

 =

Then, the text says that= the client always re-established the TCP connection. Is that aligned with = the text in 4582bis, saying that the active party does the reestablishment?= Is the client always active?

 =

I think it is a little c= onfusing that both 4582bis and 4583bis defines SDP Offer/Answer procedures.= Shouldn’t they only be in 4583bis?

 

Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its sect= ion on lower layer security, and 4582bis followed suit. It would be better to have all the details of connection establishment and= reestablishment in when using SDP offer/answer in 4583bis. 

 

 =

 =

 =

Third, the last paragraph, talking about UDP/DTLS, says tha= t either party can be DTLS server depending on the setup attributes exchang= ed. But, nowhere is it described how the setup attribute is used to determine the DTLS server role J

 =

I assume it is done in t= he same way as for TCP/TLS, but that is not written anywhere.

&nbs= p;

The text = I pasted from 4583bis above describes this. If we put all the connection ma= nagement stuff in 4583bis instead of leaving it split across 4582bis and 4583bis, this should be clear.

&nbs= p;

Cheers,

Charles

&nbs= p;

 =

 =

Regards,

 =

Christer

 =

--_000_7594FB04B1934943A5C02806D1A2204B1D26AD25ESESSMB209erics_-- From nobody Sat Mar 29 04:44:38 2014 Return-Path: X-Original-To: bfcpbis@ietfa.amsl.com Delivered-To: bfcpbis@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D03B41A04A3 for ; Sat, 29 Mar 2014 04:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, 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 T3lvmA9XO3dT for ; Sat, 29 Mar 2014 04:44:30 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 97E7E1A04AB for ; Sat, 29 Mar 2014 04:44:29 -0700 (PDT) X-AuditID: c1b4fb25-b7f3b8e0000006f1-9b-5336b21a8f55 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 04.B6.01777.A12B6335; Sat, 29 Mar 2014 12:44:26 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.213]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Sat, 29 Mar 2014 12:44:25 +0100 From: Christer Holmberg To: Christer Holmberg , "Charles Eckel (eckelcu)" Thread-Topic: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Thread-Index: AQHPSUic50RqEV5EM0G8qoAclTNxQpr39BsggAABQxA= Date: Sat, 29 Mar 2014 11:44:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D26AD60@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D26AD25@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D26AD25@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_7594FB04B1934943A5C02806D1A2204B1D26AD60ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+Jvja7UJrNggx2fxS3+rTvKZLFp1hc2 ByaPKb83snosWfKTKYApissmJTUnsyy1SN8ugSvj5+edbAULjjFVNLxdx9zA+Hk+UxcjJ4eE gInE4V8XWCBsMYkL99azdTFycQgJHGKUWHf1HiOEs4RR4uT8U0BVHBxsAhYS3f+0QRpEBNIl vkzbwg5iMwtoSlw9vIsRxBYW8JZ48W8VM0SNj8Tda13sELaVxPMbi9lAbBYBVYlX+2eygti8 Ar4Sn2+9BztCSKBI4tS0PWBzOAX8JPZdWQV2KCPQcd9PrWGC2CUucesJzAMCEkv2nGeGsEUl Xj7+xwphK0ms2H6JEaI+X2Lr7f/MELsEJU7OfMIygVF0FpJRs5CUzUJSBhHXkViw+xMbhK0t sWzha2YY+8yBx0zI4gsY2VcxsucmZuaklxttYgTG1cEtv1V3MN45J3KIUZqDRUmc98Nb5yAh gfTEktTs1NSC1KL4otKc1OJDjEwcnFINjJlvGHef9/T5Hsvs+OlqhIV5fLyJtQrbjdlR96NN 4zSmvH7/JPjPrs3pHAx8olXnH7/8UyRuGxWo3h793jN11qFPE0Xv20nlnXuzr0rYtW+762bp sKxZDc/m/HogYK6znyH2O39De6qGc6q0StaL6t3Xn2ktlPmsJb1zoUEfa/vSrJkP27uvKbEU ZyQaajEXFScCAPjCWUp5AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/GSwKwIYkjGNExhCpavrVDNQIdEM Cc: "bfcpbis@ietf.org" Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis X-BeenThere: bfcpbis@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BFCPBIS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 11:44:37 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D26AD60ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Another thing. As part of the WGLC for one of my draft in MMUSIC, I received comments that= the SDP O/A procedures should be structured according to RFC 3264, ie "Sen= ding of initial offer", "Modifying session", "Processing of answer" etc. Eventhough this is not MMUSIC, you may want to consider doing the same :) Regards, Christer From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 29 March 2014 13:41 To: Charles Eckel (eckelcu) Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Hi Charles, Without commenting on specifics at this point, I really think we should try= to get the SDP Offer/Answer procedures into one place (4583bis). 4582bis can define actions taken by the DTLS client and server, but should = not define how those roles are determined. 4583bis then defines how the rol= es are determined when using SDP O/A. Regards, Christer From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: 27 March 2014 01:11 To: Christer Holmberg Cc: bfcpbis@ietf.org Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Hi Christer, Thanks for your comments. The more I looked into them the more complex and = tangled things became. Let me try to walk through the current state of affa= irs and then propose a potential solutions. RFC 4582 breaks connection establishment into two cases: 1. when SDP offer/answer IS NOT used 2. when SDP offer/answer IS used For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds= a reference to RFC 5239 for XCON. RFC 5018 deals with the connection establishment, reestablishment, and TLS= usage. RFC 5239 points back to RFC 5018 for connection establishment. RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in which= SDP offer/answer is used, we need to update RFC 5018 to deal with DTLS. So= meone please tell me otherwise. Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC= 5018 when dealing with BFCP over UDP or DTLS. I think this should be reloc= ated to an update to RFC 5018, and connection reestablishment should be des= cribed as well. For (2), RFC 4582 provides a teaser but points to RFC 4583 for the normativ= e language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf= -bfcpbis-rfc4583bis-09. Christer comments are in regard to inconsistencies = here. I provided comments on those inline. From: Christer Holmberg > Date: Tuesday, March 25, 2014 at 12:39 PM To: "bfcpbis@ietf.org" > Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis Hi, Section 7 in 4582bis, which says: "7. Lower-Layer Security BFCP relies on lower-layer security mechanisms to provide replay and integrity protection and confidentiality. BFCP floor control servers and clients (which include both floor participants and floor chairs) MUST support TLS for transport over TCP [6] and MUST support DTLS [7] for transport over UDP. Any BFCP entity MAY support other security mechanisms. BFCP entities MUST support, at a minimum, the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6]. Which party, the client or the floor control server, acts as the TLS/ DTLS server depends on how the underlying TLS/DTLS connection is established. For a TCP/TLS connection established using an SDP offer/answer exchange [9], the answerer (which may be the client or the floor control server) always acts as the TLS server. If the TCP connection is lost, the active endpoint, i.e., the current TLS client, is responsible for re-establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. For a UDP/DTLS connection established using the an SDP offer/answer exchange, either party can be the DTLS server depending on the setup attributes exchanged; examples can be found in [23]." First, we already earlier discussed that the active TCP endpoint is respons= ible for re-establishing the TCP connection, and that will be corrected in = the next version of the draft. Yes. However, we have discussed a similar topic in CLUE, and we were wondering w= hether it would be good that, whoever detects a connection failure, sends a= new offer in order to re-establish the connection. It does not matter if b= oth endpoints send an offer - the offer/answer race condition rules will ta= ke care of that. In CLUE, is this for a TCP/TLS connection, or for a DTLS connection? For DTLS, we specifically chose to alter the behavior, as described in sect= ion 9.1 of 4583bis: "Endpoints that use the offer/answer model to establish a DTLS association MUST support the 'setup' attribute, as defined in [7]. When DTLS is used with UDP, the 'setup' attribute indicates which of the endpoints (client or floor control server) initiates the DTLS association setup. The requirements for the offer/answer exchange specified in [13], Section 5 MUST be followed when using DTLS. Informational note: How to determine which endpoint to initiate the TLS/DTLS association depends on the selected underlying transport. It was decided to keep the original semantics in [15] for TCP to retain backwards compatibility. When using UDP, the procedure above was preferred since it adheres to [13] as used for DTLS-SRTP, it does not overload offer/answer semantics, and it works for offerless INVITE in scenarios with B2BUAs." Second, Section 8.1 in 4583bis says: "When the existing TCP connection is reset following the rules in [8], the client MUST generate an offer towards the floor control server in order to reestablish the connection. If a TCP connection cannot deliver a BFCP message and times out, the entity that attempted to send the message (i.e., the one that detected the TCP timeout) MUST generate an offer in order to reestablish the TCP connection." I am not sure what is meant by "TCP connection is reset following the rules= in [8]". Which rules are you referring to? Reset means closed and reestablished. The word "reset" was used in RFC 4582= and reused in 4582bis. Perhaps we should change it closed and reestablishe= d to avoid confusion? Then, the text says that the client always re-established the TCP connectio= n. Is that aligned with the text in 4582bis, saying that the active party d= oes the reestablishment? Is the client always active? I think it is a little confusing that both 4582bis and 4583bis defines SDP = Offer/Answer procedures. Shouldn't they only be in 4583bis? Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its section= on lower layer security, and 4582bis followed suit. It would be better to = have all the details of connection establishment and reestablishment in whe= n using SDP offer/answer in 4583bis. Third, the last paragraph, talking about UDP/DTLS, says that either party c= an be DTLS server depending on the setup attributes exchanged. But, nowhere= is it described how the setup attribute is used to determine the DTLS serv= er role :) I assume it is done in the same way as for TCP/TLS, but that is not written= anywhere. The text I pasted from 4583bis above describes this. If we put all the conn= ection management stuff in 4583bis instead of leaving it split across 4582b= is and 4583bis, this should be clear. Cheers, Charles Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D26AD60ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Another thing.

 

As part of the WGLC fo= r one of my draft in MMUSIC, I received comments that the SDP O/A procedure= s should be structured according to RFC 3264, ie “Sending of initial = offer”, “Modifying session”, “Processing of answer” etc.

 

Eventhough this is not= MMUSIC, you may want to consider doing the same J

 

Regards,

 

Christer

 

 

 

 

From: bfcpbis [mailto:bfcpbis-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 29 March 2014 13:41
To: Charles Eckel (eckelcu)
Cc: bfcpbis@ietf.org
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and = 4583bis

 

Hi Charles,=

 

Without commenting on = specifics at this point, I really think we should try to get the SDP Offer/= Answer procedures into one place (4583bis).

 

4582bis can define act= ions taken by the DTLS client and server, but should not define how those r= oles are determined. 4583bis then defines how the roles are determined when= using SDP O/A.

 

Regards,

 

Christer

 

From: Charles Eckel (eckelcu) [mail= to:eckelcu@cisco.com]
Sent: 27 March 2014 01:11
To: Christer Holmberg
Cc: bfcpbis@ietf.org
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and = 4583bis

 

Hi Chri= ster,

&n= bsp;

Thanks = for your comments. The more I looked into them the more complex and tangled= things became. Let me try to walk through the current state of affairs and= then propose a potential solutions.

&n= bsp;

RFC 458= 2 breaks connection establishment into two cases:

  1. when SDP offer/answer IS NOT used
  2. when SDP offer/answer IS used

For (1)= , RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds a refe= rence to RFC 5239 for XCON.

RFC 501= 8 deals with the connection establishment, reestablishment,  and TLS u= sage.

RFC 523= 9 points back to RFC 5018 for connection establishment.

RFC 501= 8 does not deal with DTLS. Unless we restrict DTLS to cases in which SDP of= fer/answer is used, we need to update RFC 5018 to deal with DTLS. Someone p= lease tell me otherwise.

&n= bsp;

Section= 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC 5018 w= hen dealing with BFCP over UDP or DTLS. I think this should be relocated to= an update to RFC 5018, and connection reestablishment should be described as well.

&n= bsp;

For (2)= , RFC 4582 provides a teaser but points to RFC 4583 for the normative langu= age. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf-bfcpbi= s-rfc4583bis-09. Christer comments are in regard to inconsistencies here. I provided comments on those inline.

&n= bsp;

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tuesday, March 25, 2014 at 12:39 PM
To: "bfcpbis@ietf.org&q= uot; <bfcpbis@ietf.org>
Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583= bis

&n= bsp;

Hi,

 =

Section 7 in 4582bis, wh= ich says:

 =

“7.  Lower-Layer Security

 =

   BFCP relies on lower-layer securi= ty mechanisms to provide replay and=

   integrity protection and confiden= tiality.  BFCP floor control servers

   and clients (which include both f= loor participants and floor chairs)=

 =

   MUST support TLS for transport ov= er TCP [6] and MUST support DTLS [7]

   for transport over UDP.  Any= BFCP entity MAY support other security<= o:p>

   mechanisms.

 =

   BFCP entities MUST support, at a = minimum, the

   TLS_RSA_WITH_AES_128_CBC_SHA ciph= ersuite [6].

 =

   Which party, the client or the fl= oor control server, acts as the TLS/

   DTLS server depends on how the un= derlying TLS/DTLS connection is

   established.  For a TCP/TLS = connection established using an SDP=

   offer/answer exchange [9], the an= swerer (which may be the client or<= /o:p>

   the floor control server) always = acts as the TLS server.  If the TCP=

   connection is lost, the active en= dpoint, i.e., the current TLS=

   client, is responsible for re-est= ablishing the TCP connection.=

   Unless a new TLS session is negot= iated, subsequent SDP offers and

   answers will not impact the previ= ously negotiated TLS roles.

 =

   For a UDP/DTLS connection establi= shed using the an SDP offer/answer<= /o:p>

   exchange, either party can be the= DTLS server depending on the setup=

   attributes exchanged; examples ca= n be found in [23].”

 =

First, we already earlier discussed that the active TCP end= point is responsible for re-establishing the TCP connection, and that will = be corrected in the next version of the draft.

 

Yes.

 

 =

However, we have discuss= ed a similar topic in CLUE, and we were wondering whether it would be good = that, whoever detects a connection failure, sends a new offer in order to r= e-establish the connection. It does not matter if both endpoints send an offer – the offer/answer race c= ondition rules will take care of that.

 

In CLUE, is this for a TCP/TLS connection, or for a DTLS connection?

For DTLS, we specifically chose to alter the behavior, as described in s= ection 9.1 of 4583bis:

 

  "Endpoints that use the offer/answer model to establish a DT= LS

  &n= bsp;association MUST support the 'setup' attribute, as defined in [7].=

  &n= bsp;When DTLS is used with UDP, the 'setup' attribute indicates which of

  &n= bsp;the endpoints (client or floor control server) initiates the DTLS<= /o:p>

  &n= bsp;association setup.  The requirements for the offer/answer exchange=

  &n= bsp;specified in [13], Section 5 MUST be followed when using DTLS.

&nbs= p;

  &n= bsp;   Informational note: How to determine which endpoint to initiate=

  &n= bsp;   the TLS/DTLS association depends on the selected underlying

  &n= bsp;   transport.  It was decided to keep the original semantics = in [15]

  &n= bsp;   for TCP to retain backwards compatibility.  When using UDP= , the

  &n= bsp;   procedure above was preferred since it adheres to [13] as used = for

  &n= bsp;   DTLS-SRTP, it does not overload offer/answer semantics, and it<= o:p>

  &n= bsp;   works for offerless INVITE in scenarios with B2BUAs."=

 

 

 =

 =

Second, Section 8.1 in 4583bis says:

 = 

   “When the existing TCP connection is reset =
following the rules in [8],
   the client MUST generate an offer towards the flo=
or control server in
   order to reestablish the connection.  If a T=
CP connection cannot
   deliver a BFCP message and times out, the entity =
that attempted to
   send the message (i.e., the one that detected the=
 TCP timeout) MUST
   generate an offer in order to reestablish the TCP=
 connection.”
 
 

I am not sure what is me= ant by “TCP connection is reset following the rules in [8]”. Wh= ich rules are you referring to?

 

Reset means closed and reestablished. The word “reset” was u= sed in RFC 4582 and reused in 4582bis. Perhaps we should change it closed and reestablished to avoid confusion?

 

 =

Then, the text says that= the client always re-established the TCP connection. Is that aligned with = the text in 4582bis, saying that the active party does the reestablishment?= Is the client always active?

 =

I think it is a little c= onfusing that both 4582bis and 4583bis defines SDP Offer/Answer procedures.= Shouldn’t they only be in 4583bis?

 

Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its sect= ion on lower layer security, and 4582bis followed suit. It would be better to have all the details of connection establishment and= reestablishment in when using SDP offer/answer in 4583bis. 

 

 =

 =

 =

Third, the last paragraph, talking about UDP/DTLS, says tha= t either party can be DTLS server depending on the setup attributes exchang= ed. But, nowhere is it described how the setup attribute is used to determine the DTLS server role J

 =

I assume it is done in t= he same way as for TCP/TLS, but that is not written anywhere.

&nbs= p;

The text = I pasted from 4583bis above describes this. If we put all the connection ma= nagement stuff in 4583bis instead of leaving it split across 4582bis and 4583bis, this should be clear.

&nbs= p;

Cheers,

Charles

&nbs= p;

 =

 =

Regards,

 =

Christer

 =

--_000_7594FB04B1934943A5C02806D1A2204B1D26AD60ESESSMB209erics_--