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

Tom Kristensen <tomkrist@cisco.com> Thu, 16 January 2014 15:15 UTC

Return-Path: <tomkrist@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1731AE4D5 for <bfcpbis@ietfa.amsl.com>; Thu, 16 Jan 2014 07:15:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hH3tyN-3bV-I for <bfcpbis@ietfa.amsl.com>; Thu, 16 Jan 2014 07:14:59 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 27CD71AE4D3 for <bfcpbis@ietf.org>; Thu, 16 Jan 2014 07:14:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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 ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 16 Jan 2014 15:14:46 +0000
Received: from [10.61.86.87] (ams3-vpn-dhcp5720.cisco.com [10.61.86.87]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0GFEkbY025154; Thu, 16 Jan 2014 15:14:46 GMT
Message-ID: <52D7F766.8000402@cisco.com>
Date: Thu, 16 Jan 2014 16:14:46 +0100
From: Tom Kristensen <tomkrist@cisco.com>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: Re: [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: 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