[bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 15 January 2014 14:27 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 C1FD31AE375 for <bfcpbis@ietfa.amsl.com>; Wed, 15 Jan 2014 06:27:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IiwAc8YnaxQC for <bfcpbis@ietfa.amsl.com>; Wed, 15 Jan 2014 06:27:44 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id 8CE5C1AE373 for <bfcpbis@ietf.org>; Wed, 15 Jan 2014 06:27:43 -0800 (PST)
X-AuditID: c1b4fb32-b7f2b8e0000073bf-12-52d69ad2f9fc
Received: from ESESSHC017.ericsson.se (Unknown_Domain []) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 33.AC.29631.2DA96D25; Wed, 15 Jan 2014 15:27:30 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC017.ericsson.se ([]) with mapi id 14.02.0347.000; Wed, 15 Jan 2014 15:27:30 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: TCP/TLS: Who is TLS server when the connection goes down and is re-established?
Thread-Index: Ac8R+ZA84xutttU1TFChlBiOsCWPng==
Date: Wed, 15 Jan 2014 14:27:30 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C5FB1EAESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvje6lWdeCDH6u0bf4t+4okwOjx5Il P5kCGKO4bFJSczLLUov07RK4MuY2cRX0mFa0nHnH3sB4T7eLkZNDQsBE4vzHK2wQtpjEhXvr gWwuDiGBE4wSZ7bfY4VwljBK7FnWCZTh4GATsJDo/qcN0iAioCmxeftdJhBbWCBKYvanA8wg JSIC8RIrWnMhSvQkzhxczw5iswioSiw5OgOsnFfAV2Ly4UuMIDYj0N7vp9aAxZkFxCVuPZnP BHGPgMSSPeeZIWxRiZeP/7GCjJcQUJRY3i8HUZ4vsbdtIiPESEGJkzOfsExgFJqFZNIsJGWz kJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYySxanFxbnpRgZ6uem5JXqpRZnJxcX5 eXrFqZsYgVFxcMtvox2MJ/fYH2KU5mBREue9zloTJCSQnliSmp2aWpBaFF9UmpNafIiRiYNT qoHRpej08hbuF8fO6mmsXCT6/c+lB3uMRW3+VEq8dLm/6vzPmG/aSQ41F2Zq7N2ovZ9pbdrW tu/res/ufOx5o2GfklOeuSC/t2P2S+3fh1UMC/rWpBsceDqJ9/26KaoLuk4Xab3/XvS8q1rc f9r3zTFxfjV8Za+UGJ1mr3R9HD35ad7bG+Kbv3KlKLEUZyQaajEXFScCAGzi7h1YAgAA
Subject: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?
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: Wed, 15 Jan 2014 14:27:47 -0000


I realize the following comes late in the process, and I apologize if it has been discussed, but it is related to something which just has recently popped up in 3GPP, and it's not addressed in the draft.

Section 7 says the following:

"For a TCP/TLS connection established using an SDP
                offer/answer exchange [7], the answerer (which may be the client or
                the floor control server) always acts as the TLS server."


Assume the TCP/TLS connection, for whatever reason, goes down.

Now, I assume that whoever endpoint is "active" will most likely try to re-establish the TCP connection.

But, if the "active" endpoint doesn't send an Offer (i.e. it simply tries to re-establish the TCP connection based on the previously negotiated SDP information), who will act as TLS server? There is no Answerer.

One alternative would be to mandate the sending of an Offer when the TCP/TLS connection is re-established. Then it would be clear who is Offerer, and who is Answerer.

Another alternative would be to say that whoever was previously Answerer will act as TLS server.


Assume there is an Offer/Answer transaction during the session. Now, the TCP/TLS connection is not affected by that, but the TLS roles may change (if whoever was Offerer in the previous O/A transaction is now Answerer).

I think some wording would be needed about that also.

One alternative is to say that the TLS roles may change, but that doesn't affect the TCP/TLS connection.