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

Christer Holmberg <> Tue, 21 January 2014 01:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C2ABF1A0282 for <>; Mon, 20 Jan 2014 17:44:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RdFUEpeHR3f5 for <>; Mon, 20 Jan 2014 17:44:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2CCE31A0002 for <>; Mon, 20 Jan 2014 17:44:32 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-0c-52ddd100c070
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 80.6E.03802.001DDD25; Tue, 21 Jan 2014 02:44:32 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0387.000; Tue, 21 Jan 2014 02:44:23 +0100
From: Christer Holmberg <>
To: Paul Kyzivat <>, "" <>
Thread-Topic: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?
Thread-Index: Ac8R+ZA84xutttU1TFChlBiOsCWPngAy768AAAq9+j4A1NzWIP//+WMA///tb0A=
Date: Tue, 21 Jan 2014 01:44:23 +0000
Message-ID: <>
References: <>, <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: fi-FI
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+JvjS7DxbtBBsv3y1j8W3eUyWLFhgOs Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfGlbWTmAp2GFRsfP2QuYGxVb2LkYNDQsBE 4vuyyi5GTiBTTOLCvfVsXYxcHEIChxglTt7/zg6SEBJYwijR+EwJpJ5NwEKi+582SFhEIFDi 0L5pTCC2sECGxJJ/J9hASkQEMiUaJitAlPhJLDxyDGwKi4CqxL31h8DKeQV8JeYvP8gEsWo6 k8S/qVNYQBKcAjoSb5+2soLYjED3fD+1BqyBWUBc4sPB68wQdwpILNlzHsoWlXj5+B8rhK0k sWL7JUaIej2JG1OnsEHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiZM9N zMxJLzfaxAiMg4NbfqvuYLxzTuQQozQHi5I474e3zkFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGNUlJmc+6fdiKrzG7RP8R4x32vUN3Hzv/l9atOSoko6A7GYVg87ZS0oL/whPlHSc9MCA r6ljlbOd2Zy4m6kOmq8XJs0QWbC3S32j+dJjv9lOzuDtTBJ2fMCrbVJRf1fa1aR889adm+av C2pr+jUv1Lp3F9fDJSoFIcF3ZkxUuutcsn7VtLkVdkosxRmJhlrMRcWJAGMKa5xRAgAA
Subject: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BFCPBIS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Jan 2014 01:44:36 -0000


>> Some initial text proposal:
>> "If the TCP connection is lost, the "active" endpoint 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."
> Is the passive endpoint expected to listen for the connection attempt at all times, or when it has noticed that the old connection is lost, or only when 
> there has been a new O/A? (It is kind of a waste to maintain a listener when you have an active connection and aren't expecting more. 
> And it is asking for trouble, since you might get a new connection when you think the old one is still functional.)

If a TCP connection has been established, I think it is enough to listen for the connection when it has noticed that the old connection is lost. I assume both endpoints would detect that more or less at the same time, or?

If a TCP connection has NOT been established, one would listen only when there has been a O/A used to negotiate the TCP connection.

> I realize this is old stuff, but I'm surprised that it didn't follow comedia about all of this, including who is active.

I am not sure I understand. Comedia IS used to indicate who is active. However, comedia is NOT used to indicate who is TLS client/server.



> -----Alkuperäinen viesti-----
> Lähettäjä: bfcpbis [] Puolesta Christer 
> Holmberg
> Lähetetty: 16. tammikuuta 2014 21:36
> Vastaanottaja: Tom Kristensen
> Kopio:
> Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?
> Hi Tom,
>>> 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.
>> Not too late, since we are still not finished! Anyway, the TCP/TLS 
>> connection reuse is not altered while extending BFCP to support 
>> unreliable transport. Any fixes now must be backwards compatible in 
>> some way.
>> That said and based on what I have seen from different vendors, most 
>> of them still use TCP (without TLS) :)
>> So, at least if we are changing anything to solve these issues, we 
>> should add an informational note indicating this is a change where 
>> legacy, pure RFC 4582 implementations might differ in behaviour...
> I am not suggesting to change anything - I am suggesting to specify 
> something which is currently unspecified :)
>> By the way: How these issues was solved in 3GPP are along the lines of what you propose below?
> We have had some discussions in 3GPP, and there are some text suggestions for the upcoming meeting next week.
> However, the discussions so far have been mostly about Q2. Q1 came up on a mailing list just this week, and whill be discussed at the 3GPP meeting next week.
>>> 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."
>>> Q1:
>>> 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.
>> I'm not too fond of yet another re-INVITE being mandated, so if we 
>> will fix this issue mandating the previous answerer to be the TLS 
>> server would be my preference.
> Assuming that, then my follow-up question is:
> When you say "previous answerer", do you refer to the answerer in the latest Offer/Answer transaction, OR the answerer in the last Offer/Answer transaction that established/re-established the TCP/TLS connection (those Offer/Answer transactions may, or may not, be the same).
>>> Q2:
>>> 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.
>> A healthy TCP/TLS connection shouldn't be affected at all, should it?
> Correct. The question is whether such Offer/Answer can affect the TCP/TLS roles - even if the TCP/TLS connection itself if not affected. That could have impact on the case in Q1, where the TCP/TLC connection goes down, and it needs to be determined who is TLS server.
>> However, any potential connection re-establishment will need to 
>> monitor who was the last answerer to do the TLS initiation correctly.
>> Hopefully I did understand the issue here, and added my 2 zlotys or 
>> pence or whatever,
> I think you did understand the issue :)
> Regards,
> Christer
> _______________________________________________
> bfcpbis mailing list
> _______________________________________________
> bfcpbis mailing list

bfcpbis mailing list