[bfcpbis] BFCPbis: UDP- and TCP candidates and proto value

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 27 September 2016 05:51 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1B87412B3FD for <bfcpbis@ietfa.amsl.com>; Mon, 26 Sep 2016 22:51:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CBMfp1W9oXW8 for <bfcpbis@ietfa.amsl.com>; Mon, 26 Sep 2016 22:51:49 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net []) (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 E84F712B3F9 for <bfcpbis@ietf.org>; Mon, 26 Sep 2016 22:51:48 -0700 (PDT)
X-AuditID: c1b4fb25-5405a9800000793b-d6-57ea08f25a1f
Received: from ESESSHC009.ericsson.se (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 71.6A.31035.2F80AE75; Tue, 27 Sep 2016 07:51:47 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC009.ericsson.se ([]) with mapi id 14.03.0301.000; Tue, 27 Sep 2016 07:51:37 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: BFCPbis: UDP- and TCP candidates and proto value
Thread-Index: AQHSGIM1ppZO5vN2Zk+0kXRTwh8WBQ==
Date: Tue, 27 Sep 2016 05:51:37 +0000
Message-ID: <D40FE4FA.FE39%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D40FE4FAFE39christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ru5njlfhBh0vuS3+rTvK5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLbO08wFK40q1rftZ2lgvK7VxcjJISFgIrF2Wi9rFyMXh5DA ekaJN1vWMEE4ixklzl57DeRwcLAJWEh0/9MGaRAR0JTYvP0uE4gtLGApsX3zAiaIuJ1E/+5L 7BC2nsSc5eeYQWwWAVWJ5rbzbCA2r4CVxJ0d68FqGAXEJL6fWgPWyywgLnHryXwmiIMEJJbs Oc8MYYtKvHz8jxXEFgWa+f3rbKi4osTV6cvBTmMWiJe4stQGYrygxMmZT1gmMArNQjJ1FkLV LCRVECUGEu/PzWeGsLUlli18DWXrS2z8cpYRwraW6PryAEXNAkaOVYyixanFSbnpRsZ6qUWZ ycXF+Xl6eaklmxiBcXJwy2/VHYyX3zgeYhTgYFTi4U2Y9TJciDWxrLgy9xCjBAezkgjvPLZX 4UK8KYmVValF+fFFpTmpxYcYpTlYlMR5zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwmiwzctmw z6Lx7GzPMz6ePdeezXDae0dYVWCt/fk1UU5yDod8H+3RNwzlnssuYyZcwKXfZHNXyeL8iUXl E9W1I/Qf7lmc+Gu3ytU61Z06N/w+59onqSXM3KPmqRJnzltX89lG62WU/nsG+QZjPk7dyaLV 72WNXOV/FCreeXrph++iY/INLpuVWIozEg21mIuKEwF2Oj0ajwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/e1_MmI_TyORtNC076YhBlN9syc8>
Subject: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 27 Sep 2016 05:51:51 -0000


An issue came up during the review of draft-sctp-sdp, which I believe also applies to BFCPbis.


The document defines TCP/TLS/BFCP and UDP/TLS/BFCP. If ICE is used, and there can be both TCP- and UDP-based candidates, which value shall be used? Also, if there is a
candidate switch from TCP to UDP (or vice verse), is an updated offer required? Is it even possible to switch between candidates, since in the case of BCFP one uses DTLS and the other TLS (for RTP and SCTP DTLS is always used – also for TCP).
The same applies to UDP/BFCP and TCP/BFCP.

In the following pull request you can see how we suggest to address it in draft-sctp-sdp (look at the changes in the ICE Considerations sections):



In case of TCP/TLS/BFCP and UDP/TLS/BFCP, if you have both UDP- and TCP-based candidates, it also means you are going to have both a TLS connection and an DTLS association. If the TLS roles (client/server) change etc, it will affect both the TLS connection and the DTLS association. I think this needs to be described in the draft, as it is not covered e.g. by referencing draft-dtls-sdp.