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

Tom Kristensen <> Thu, 16 January 2014 15:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DA1731AE4D5 for <>; Thu, 16 Jan 2014 07:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hH3tyN-3bV-I for <>; Thu, 16 Jan 2014 07:14:59 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 27CD71AE4D3 for <>; Thu, 16 Jan 2014 07:14:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2741; q=dns/txt; s=iport; t=1389885287; x=1391094887; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=vh3w92iiIoWX399UVpj9hlxnEUZharoVPSQ4gtxyOaw=; b=jNRgE7XjG+r4KNvMTnUrFvMoI5OcBdLWpsj3tlqghCzmim5nz4/JLqQO zd8kGsmn9U+mec31m6Hzuy1PQx6MCddiMgMl/SgADvKjnMoBbQjzsQhSI Q6kmiWY1Q5+mUl6dINf6mdZgdSYZNqYStlNSEsG7ulmBkqvyTxDAqaxWy 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjAFAJX211KQ/khR/2dsb2JhbABZgwu5EYMIgQsWdIIlAQEBAwEyAQVAAQULCxgJFg8JAwIBAgFFBg0BBwEBh3gIxE0Xjn8HhDgBA5ghhkaLUYFvgT87
X-IronPort-AV: E=Sophos;i="4.95,668,1384300800"; d="scan'208";a="3722938"
Received: from ([]) by with ESMTP; 16 Jan 2014 15:14:46 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id s0GFEkbY025154; Thu, 16 Jan 2014 15:14:46 GMT
Message-ID: <>
Date: Thu, 16 Jan 2014 16:14:46 +0100
From: Tom Kristensen <>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10
MIME-Version: 1.0
To: Christer Holmberg <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "" <>
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: Thu, 16 Jan 2014 15:15:01 -0000

On 01/15/2014 03:27 PM, Christer Holmberg wrote:
> Hi,
> 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...

By the way: How these issues was solved in 3GPP are along the lines of 
what you propose below?

> 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.

> 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? 
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,
-- Tom