Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?
Christer Holmberg <christer.holmberg@ericsson.com> Tue, 21 January 2014 01:44 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 C2ABF1A0282 for <bfcpbis@ietfa.amsl.com>; Mon, 20 Jan 2014 17:44:35 -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 RdFUEpeHR3f5 for <bfcpbis@ietfa.amsl.com>; Mon, 20 Jan 2014 17:44:33 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCE31A0002 for <bfcpbis@ietf.org>; Mon, 20 Jan 2014 17:44:32 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-0c-52ddd100c070
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 80.6E.03802.001DDD25; Tue, 21 Jan 2014 02:44:32 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.114]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0387.000; Tue, 21 Jan 2014 02:44:23 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
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: <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se>, <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu>
In-Reply-To: <52DDCE70.1090707@alum.mit.edu>
Accept-Language: en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
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-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: Tue, 21 Jan 2014 01:44:36 -0000
Hi, >> 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. Regards, Christer > -----Alkuperäinen viesti----- > Lähettäjä: bfcpbis [mailto:bfcpbis-bounces@ietf.org] Puolesta Christer > Holmberg > Lähetetty: 16. tammikuuta 2014 21:36 > Vastaanottaja: Tom Kristensen > Kopio: bfcpbis@ietf.org > 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@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > _______________________________________________ > bfcpbis mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org https://www.ietf.org/mailman/listinfo/bfcpbis
- [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