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

Roman Shpount <roman@telurix.com> Mon, 10 September 2018 21:23 UTC

Return-Path: <roman@telurix.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 E0529130FB5 for <bfcpbis@ietfa.amsl.com>; Mon, 10 Sep 2018 14:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 vAIcyKFo3jR0 for <bfcpbis@ietfa.amsl.com>; Mon, 10 Sep 2018 14:23:26 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4702E130DD7 for <bfcpbis@ietf.org>; Mon, 10 Sep 2018 14:23:26 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id d19-v6so11122573pgv.1 for <bfcpbis@ietf.org>; Mon, 10 Sep 2018 14:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kLIwpp6QDub38ozDWa6hOaVfSURqTieGdw5mGAcFyQM=; b=CDBnsb9zaGzdQ4UHpLZKh0Zr8nKWmlG4HWwgtREjmCXmuGfthxooC0y+pBIgYJBQd4 obVndDXTutRvBCYSngB+t/SO/j1e0ahk5GcVIwQsU8jfyV4JnTF5h2GFT5WlSUVOIsqV w8N9ctI99GeBwVh5F8XEYXV+wsQfONELjzLApO+CRp29MoKd55XBTnGfSd5RNr6c8Qps Dvtcq6doemb6aNtnDksKF0RtrlwblJcZjUxh/Innm8yjUdYH9DkNlRKQAjWUpwA56gR0 0qJzaprXsRAmc2ea9EIYZekp2pwQ3RtRgHPcqElHw1OI2JahcA18Ebi1fHssJqrqlYQ0 6BUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kLIwpp6QDub38ozDWa6hOaVfSURqTieGdw5mGAcFyQM=; b=ncXzgLnvvmkmNbuCX0XYDQHtGoMh9PZBJvI4ETQJHqzHxEs75WrtHeJrTXexFgqc2P B+be2GM0jwGHKLgBwCgZ2N/sSDzCU565/mSVodgSWRyttCkwtqFUCmJ3nAf+jMesEgQY sn3mVzbXtK3VVarXzpAhII12+x2f93HLJVXlmPC47262pSJ3KIETE/6Ff5qoxbFdKpL5 alBMfe7yZ7T8Al1l3jH8hjDDJxdcrfv7hcAnmQr59E86WnkaJOqBHfayR7iRAmuo8D2Y KPa0/WzN3G5cPXazf8OP4y37pKeJutZKqxDiTmm1bSb0tSQxVPMaga8ifzH0luNlR0kl asOQ==
X-Gm-Message-State: APzg51Ako8tcOp+E7lyXPJBcRMMFXxf5yulHNU83gWtZEspzbbnt2RZM ugcb3jYawe2y2LH8pJeIW/J+VE10xGA=
X-Google-Smtp-Source: ANB0VdZygV/zSiOvs9CSxNWIyOSlKyYR6SzAhZ/WpQGjJKvs2LnFY0yMQGS/WbEHSUvgfY5gboydZA==
X-Received: by 2002:a63:a54f:: with SMTP id r15-v6mr24646794pgu.336.1536614605887; Mon, 10 Sep 2018 14:23:25 -0700 (PDT)
Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com. [209.85.214.173]) by smtp.gmail.com with ESMTPSA id 6-v6sm27637944pfr.115.2018.09.10.14.23.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Sep 2018 14:23:25 -0700 (PDT)
Received: by mail-pl1-f173.google.com with SMTP id f6-v6so10329809plo.1; Mon, 10 Sep 2018 14:23:25 -0700 (PDT)
X-Received: by 2002:a17:902:1ab:: with SMTP id b40-v6mr24525233plb.55.1536614605054; Mon, 10 Sep 2018 14:23:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:d588:0:0:0:0 with HTTP; Mon, 10 Sep 2018 14:23:24 -0700 (PDT)
In-Reply-To: <09534f21-9ccc-91c9-d440-56a9eca86d94@nostrum.com>
References: <09534f21-9ccc-91c9-d440-56a9eca86d94@nostrum.com>
From: Roman Shpount <roman@telurix.com>
Date: Mon, 10 Sep 2018 17:23:24 -0400
X-Gmail-Original-Message-ID: <CAD5OKxuteVX6o-KgeUrG_O0Bf0czi3r-X+T-4Hd+1uBBEDH-eA@mail.gmail.com>
Message-ID: <CAD5OKxuteVX6o-KgeUrG_O0Bf0czi3r-X+T-4Hd+1uBBEDH-eA@mail.gmail.com>
To: 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>
Content-Type: multipart/alternative; boundary="000000000000b0e7f205758af712"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/Jeq0Cc54wQTHJEl7Gk1Pim1u5Fs>
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: Mon, 10 Sep 2018 21:23:28 -0000

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