Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 21 September 2018 22:42 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7854B130E4B for <bfcpbis@ietfa.amsl.com>; Fri, 21 Sep 2018 15:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ye-MlSlxED5m for <bfcpbis@ietfa.amsl.com>; Fri, 21 Sep 2018 15:42:05 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7E1130E4C for <bfcpbis@ietf.org>; Fri, 21 Sep 2018 15:42:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537569722; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0sKh+RIDfgCwrntYJ+nbDO9YnsDvKUlni/mYPb6r1W8=; b=Lb7P29d7EX79wVSfquzeidONiZHsZ1RMqCYdecDk/CAw22iCKqeMBNmDUIXDboJ5 cF0wyg2Qdox+iRnhJ1V9VHCkpOsfT4iTpmiwBvGuStLRb774f3wrxu6Ch1MtSiWe wZCmTn714jF7oFxRPI9UH1NFyKE2OXzgwDSwgfdRkBs=;
X-AuditID: c1b4fb25-8ffff700000013ad-c2-5ba573ba3a03
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F2.88.05037.AB375AB5; Sat, 22 Sep 2018 00:42:02 +0200 (CEST)
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 22 Sep 2018 00:42:02 +0200
Received: from ESESBMB503.ericsson.se ([153.88.183.186]) by ESESBMB503.ericsson.se ([153.88.183.186]) with mapi id 15.01.1466.003; Sat, 22 Sep 2018 00:42:02 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
CC: Adam Roach <adam@nostrum.com>, "draft-ietf-bfcpbis-rfc4583bis.all@ietf.org" <draft-ietf-bfcpbis-rfc4583bis.all@ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24
Thread-Index: AQHUSUa+My87KoBF4ESReJWIVOiojqTp5O4AgBFqfeD//+ZJgIAAKenw
Date: Fri, 21 Sep 2018 22:42:01 +0000
Message-ID: <9ded67e23b174d7ba7757e7a747cfdf1@ericsson.com>
References: <09534f21-9ccc-91c9-d440-56a9eca86d94@nostrum.com> <CAD5OKxuteVX6o-KgeUrG_O0Bf0czi3r-X+T-4Hd+1uBBEDH-eA@mail.gmail.com> <9a74a495fdda41a4892929a6c4da0ba2@ericsson.com> <CAD5OKxts-ATOdSY3zXUFp7=69bD5Ccte6Y8HJEBvB3n4p85jXQ@mail.gmail.com>
In-Reply-To: <CAD5OKxts-ATOdSY3zXUFp7=69bD5Ccte6Y8HJEBvB3n4p85jXQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.153]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2J7he6u4qXRBpOXGlns+buI3eLfuqNM FltnHGSzmHFhKrMDi8eSJT+ZPGbtfMLicWtKQQBzFJdNSmpOZllqkb5dAldGT/995oIplhU3 NvSzNjDeMO9i5OSQEDCRWPPuJ1sXIxeHkMBRRonJDeuYIZxvjBKf9/9ihXCWMUrMW7ISyOHg YBOwkOj+pw3SLSKgKvH3+2QmkBpmgZWMEsualrGB1AgLuEic/CYHUeMqsX5WDwuE7SbRMe8f O4jNAtS7+eQyMJtXwFri1o12JhBbSOAfo8Tx/ioQm1MgUOLNpNtgNYwCYhLfT60Bq2EWEJe4 9WQ+E8QHAhJL9pxnhrBFJV4+/scKYStJ7D12nQXkHGYBTYn1u/QhWhUlpnQ/hForKHFy5hOW CYxis5BMnYXQMQtJxywkHQsYWVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBEbWwS2/VXcw Xn7jeIhRgINRiYc3uWBptBBrYllxZe4hRgkOZiURXlt3oBBvSmJlVWpRfnxRaU5q8SFGaQ4W JXHeh+abo4QE0hNLUrNTUwtSi2CyTBycUg2MjHOE/9kIcXz7ssmcTYthtWyBysu1O3OFv7hY rErZ+f3xBDGNX9OOsfVNtkv8IecezPT+as4DmYAMwYCbSRI175TyvHZzKM3bUvy58/urN19r qh8x8L0U2SZY8tUw6/srExmNk3nS0VtuKbhOz8xeqz97r2CoqbgD+webT+9fljC2fmvzzmBQ YinOSDTUYi4qTgQAu7UOqKgCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/E_swonu01_TZ05V8Wy3oF3QhieA>
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2018 22:42:08 -0000

Hi,

Note that the draft already contains SOME descriptions on when to use what.

For example, the “ICE Considerations” section talks about 'UDP/TLS/BFCP' and 'TCP/DTLS/BFCP'. 

What about the following bullet points?

- 'TCP/BFCP' is used for TCP transport without TLS or DTLS encryption, and is backward interoperability with RFC 4583 endpoints. 
- 'TCP/TLS/BFCP' is used when TCP transport with TLS encryption is used, and is backward interoperability with RFC 4583 endpoints that support. 
- 'UDP/BFCP' is used for UDP transport without DTLS encryption.
- 'UDP/TLS/BFCP' and 'TCP/DTLS/BFCP' are used with ICE (Section 9), and can also be used without ICE for communication between endpoints compliant
with this specification (there is no backward interoperability with RFC 4583 endpoints).
 
Regards,

Christer



From: Roman Shpount [mailto:roman@telurix.com] 
Sent: 22 September 2018 00:49
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Adam Roach <adam@nostrum.com>; draft-ietf-bfcpbis-rfc4583bis.all@ietf.org; bfcpbis@ietf.org
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24

Christer,

Here is the best I can come up with:

The main use case for TCP/TLS/BFCP is legacy interop. This protocol should be used if end point needs to communicate with existing equipment that implements it. This protocol cannot be used with ICE and does not work in NAT environments. This protocol utilizes TCP for reliable in-order delivery and relies on these properties of TCP in its implementation, so that implementation of this protocol is fairly different from  UDP/TLS/BFCP.

The main use case for TCP/DTLS/BFCP is ICE and associated support for NAT environments. This is the protocol which will be used on the wire and specified in the m= line when an ICE TCP candidate is used. It is recommended to use this protocol for new implementations or when endpoints deployed in NAT environments need to be supported. From implementation point of view, TCP/DTLS/BFCP protocol compliments UDP/TLS/BFCP since it allows seamless switch-over between TCP/DTLS/BFCP and UDP/TLS/BFCP within the same communication session, which is required for ICE support. Both protocols use the same encryption (DTLS), and the same mechanisms to insure reliable message delivery. Essentially, TCP/DTLS/BFCP is UDP/TLS/BFCP with DTLS packets sent over the TCP connection using framing defined in RFC 4571 instead of UDP, so that most of the transport implementation code can be shared.

Regards,


_____________
Roman Shpount

On Fri, Sep 21, 2018 at 5:21 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi Roman,
 
Could you help providing explanation?
 
Perhaps a bullet list with each protocol value, and when to use it.
 
Regards,
 
Christer
 
From: Roman Shpount [mailto:roman@telurix.com] 
Sent: 11 September 2018 00:23
To: Adam Roach <adam@nostrum.com>
Cc: draft-ietf-bfcpbis-rfc4583bis.all@ietf.org; bfcpbis@ietf.org
Subject: Re: [bfcpbis] AD Review of draft-ietf-bfcpbis-rfc4583bis-24
 
Hi Adam,
 
On Mon, Sep 10, 2018 at 4:41 PM, Adam Roach <adam@nostrum.com> wrote:

§4 (BLOCKING):

>  This document defines five values for the proto field: TCP/BFCP,
>  TCP/DTLS/BFCP, TCP/TLS/BFCP, UDP/BFCP, and UDP/TLS/BFCP.

Generally, having more ways to do the same things in a protocol leads to less
interoperability rather than more. While the rationale for the four-way split
caused by TLS-versus-plaintext and UDP-versus-TCP is pretty self evident, there
appears to be no rationale in this document for having both TCP/DLTS/BFCP and
TCP/TLS/BFCP; more importantly, the document offers no guidance to implementors
regarding which to use. This is likely to lead to some implementations choosing
one encoding and others choosing the other somewhat arbitrarily. This decreases
the chances of the protocol interoperating.

Minimally, please include guidance regarding which of these two variations
implementations should use, and under which conditions. On a first glance, it
would appear that the guidance might be that non-ICE uses should use
TCP/TLS/BFCP for maximal compatibility with RFC 4583 implementations, and that
ICE uses need to use TCP/DTLS/BFCP, as outlined in section 9.
 
You are correct, the reason there are two protocols is that TCP/TLS/BFCP needs to be supported for legacy interop with RFC4583 but it does not work with ICE. Since  ICE is designed as being able to switch between ICE candidates, including UDP and TCP based candidates, without disrupting the higher level protocol, any ICE transport, including ICE-TCP, should be treated as packet-based unreliable transport. As a result, ICE can only work with UDP/TLS/DTLS/BFC for UDP candidates or TCP/DTLS/BFCP for TCP candidates. Both of these protocols treat underlying transport as unreliable with DTLS responsible for packet re-transmission. On the other hand,  TCP/TLS/BFCP relies on the underlying transport for reliable in-order delivery, which is not provided by ICE. Furthermore, ICE is not supported by plain UDP/BFC either, or you will end up with TCP/UDP/BFCP (different from TCP/BFCP) which everyone found to be even more confusing. I think some explanation of this would be helpful.
 
Regards,
_____________
Roman Shpount