IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 21 September 2018 21:21 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 C0ACE12F1AC for <bfcpbis@ietfa.amsl.com>; Fri, 21 Sep 2018 14:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level:
X-Spam-Status: No, score=-4.309 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, 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 w5pHY0DBJYQt for <bfcpbis@ietfa.amsl.com>; Fri, 21 Sep 2018 14:21:36 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 85BB21286E3 for <bfcpbis@ietf.org>; Fri, 21 Sep 2018 14:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537564893; 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=sSb2dkzZUMcPQNz+8lZVEOikOl+ofOIJBjBMRAStstM=; b=HNm1Df5JlVv+s8HWGy6BSPlJnw+4H98AqxaJFSCjmr5ZtWjo/lZOrPw8HOefk3QG auY2qgfxykVbHNAJIojS43IJb6AWXOL7lWdU7Q9uEFHiBwrPBz+JIUJief2Gao+2 IA7yDcoxL3Y7TUVW8PRoCqfEz1lEsifQKBljGWVG5B4=;
X-AuditID: c1b4fb3a-37dff70000003197-2b-5ba560ddd9ae
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E7.C1.12695.DD065AB5; Fri, 21 Sep 2018 23:21:33 +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; Fri, 21 Sep 2018 23:21:33 +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; Fri, 21 Sep 2018 23:21:33 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, Adam Roach <adam@nostrum.com>
CC: "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+My87KoBF4ESReJWIVOiojqTp5O4AgBFqfeA=
Date: Fri, 21 Sep 2018 21:21:33 +0000
Message-ID: <9a74a495fdda41a4892929a6c4da0ba2@ericsson.com>
References: <09534f21-9ccc-91c9-d440-56a9eca86d94@nostrum.com> <CAD5OKxuteVX6o-KgeUrG_O0Bf0czi3r-X+T-4Hd+1uBBEDH-eA@mail.gmail.com>
In-Reply-To: <CAD5OKxuteVX6o-KgeUrG_O0Bf0czi3r-X+T-4Hd+1uBBEDH-eA@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: multipart/alternative; boundary="_000_9a74a495fdda41a4892929a6c4da0ba2ericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsUyM2J7he7dhKXRBnu3KFvs+buI3eLfuqNM FltnHGSzmHFhKrMDi8eSJT+ZPGbtfMLicWtKQQBzFJdNSmpOZllqkb5dAldG44ZupoJnuRWr 569jaWB8kdXFyMkhIWAi8epDH0sXIxeHkMBRRom1ayYyQzjfGCXWn25mhXCWMUp0P3nL1MXI wcEmYCHR/U8bpFtEwEVi8fJPYN3MAh2MEpOO32UDqREGSpz8JgdR4yqxflYPC4RtJbH7yx0m EJtFQFVi7eNTrCA2r4C1RP/FM4wgtpBAK6PEv1nxIDanQKDEq++tYDWMAmIS30+tAetlFhCX uPVkPhPEBwISS/acZ4awRSVePv7HCmErSew9dp0Foj5ZYt3WTWwQuwQlTs58wjKBUXQWklGz kJTNQlI2C+gbZgFNifW79CFKFCWmdD9kh7A1JFrnzGVHFl/AyL6KUbQ4tbg4N93ISC+1KDO5 uDg/Ty8vtWQTIzAWD275bbWD8eBzx0OMAhyMSjy8M8OWRguxJpYVV+YeYpTgYFYS4bV1Bwrx piRWVqUW5ccXleakFh9ilOZgURLndUqziBISSE8sSc1OTS1ILYLJMnFwSjUwtpa93fE9wbJg n0WEW4vYX2nr/23RC8Ikq/qOMFRdm7PSWkNKpvTm/SnXnI/IfFZ9qN3fJpzOq9nw+sW2VF/b OM5nJcKrvq6pVCz2XrM5J1ng4+lJW2efLdn29Hb1SdHszKks0YEtOrPCGyY+ZD/vpznRtvZ9 3HEVljbx8x/TRGOl2OSPf45UYinOSDTUYi4qTgQARHT3KcECAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/IUOGT1an7mh-v_FXrG-HnVXplFo>
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 21:21:38 -0000

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<mailto: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

v2.23.0 | Report a Bug | By Email