[bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 25 March 2014 19:39 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5A7F41A01E3 for <bfcpbis@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4Ba7fDgNlHvb for <bfcpbis@ietfa.amsl.com>; Tue, 25 Mar 2014 12:39:16 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id 067321A0144 for <bfcpbis@ietf.org>; Tue, 25 Mar 2014 12:39:15 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-da-5331db620c93
Received: from ESESSHC014.ericsson.se (Unknown_Domain []) 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 ([]) by ESESSHC014.ericsson.se ([]) with mapi id 14.02.0387.000; Tue, 25 Mar 2014 20:39:13 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "bfcpbis@ietf.org" <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-originating-ip: []
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 <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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, 25 Mar 2014 19:39:20 -0000


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

   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 responsible 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 whether 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 both endpoints send an offer - the offer/answer race condition rules will take 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 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 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 can be DTLS server depending on the setup attributes exchanged. But, nowhere is it described how the setup attribute is used to determine the DTLS server role :)

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