Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?
Christer Holmberg <christer.holmberg@ericsson.com> Thu, 16 January 2014 19:36 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7CD1A1F61 for <bfcpbis@ietfa.amsl.com>; Thu, 16 Jan 2014 11:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNdE0u3TqQix for <bfcpbis@ietfa.amsl.com>; Thu, 16 Jan 2014 11:36:22 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2B21A1F54 for <bfcpbis@ietf.org>; Thu, 16 Jan 2014 11:36:22 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-32-52d834a9445a
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3F.12.23787.9A438D25; Thu, 16 Jan 2014 20:36:09 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.120]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0347.000; Thu, 16 Jan 2014 20:36:08 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Tom Kristensen <tomkrist@cisco.com>
Thread-Topic: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?
Thread-Index: Ac8R+ZA84xutttU1TFChlBiOsCWPngAy768AAAq9+j4=
Date: Thu, 16 Jan 2014 19:36:08 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>, <52D7F766.8000402@cisco.com>
In-Reply-To: <52D7F766.8000402@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvje5KkxtBBt8XCVn8W3eUyeLKkV9s DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAlfGsaMX2Qvmy1XcenWUrYGxTaKLkZNDQsBE 4vDCLnYIW0ziwr31bF2MXBxCAocYJToXLINyljBK9C6ey9zFyMHBJmAh0f1PG6RBREBdom/v d7BmZgFNiauHdzGC2MICGRJzlu4CKxcRyJRomKwAYVpJ7F1fBlLBIqAq0dLzHKyCV8BXon2a NEhYSCBLomX7ayYQmxNo4P5vv8EGMgJd9v3UGiaIReISt57MZ4K4WEBiyZ7zzBC2qMTLx/9Y IWwliR8bLrFA1BtIvD83nxnC1pZYtvA1mM0rIChxcuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKs YmTPTczMSS833MQIjI6DW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp2ampBalF8UWlOanF hxiZODilGhjdNf7pXdJi+Ci0NdFM8Ux88yqp30HXnUMSsr0O/VznEbo/f5FVqJencb3r7pta 0j51LNxKKckPhXlCDJRvfO5xmSIy7Vq5gAm7+tXtH46IPZvMzXPWcsGcY283cx18etfoC2tA kMfMDz/cmWYeYEjTjFn6+m3fz+2zn6a41QW1WzB1brZrW6TEUpyRaKjFXFScCABLbCT6XAIA AA==
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 19:36:24 -0000
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] TCP/TLS: Who is TLS server when the con… Christer Holmberg
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Tom Kristensen
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Christer Holmberg
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Christer Holmberg
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Paul Kyzivat
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Christer Holmberg
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Paul Kyzivat
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Tom Kristensen
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Tom Kristensen
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Christer Holmberg
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Tom Kristensen
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… DRAGE, Keith (Keith)
- Re: [bfcpbis] TCP/TLS: Who is TLS server when the… Tom Kristensen