Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?
Tom Kristensen <2mkristensen@gmail.com> Thu, 23 January 2014 10:48 UTC
Return-Path: <2mkristensen@gmail.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 1725F1A0435 for <bfcpbis@ietfa.amsl.com>; Thu, 23 Jan 2014 02:48:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 KqRUtu8KJV-5 for <bfcpbis@ietfa.amsl.com>; Thu, 23 Jan 2014 02:48:46 -0800 (PST)
Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id D3D881A03F0 for <bfcpbis@ietf.org>; Thu, 23 Jan 2014 02:48:45 -0800 (PST)
Received: by mail-qc0-f177.google.com with SMTP id i8so2169274qcq.22 for <bfcpbis@ietf.org>; Thu, 23 Jan 2014 02:48:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HI2Ox6TWL0Ccn2gM0q6rAoeFgLIvLlPZLFQBLiylbFk=; b=qyB+RTtgZ3mCudaWyo0Ps5KI8x41X3SBJFdDnqFVQozYG8mYIvasu7UfrBH/NXWjBV FlYH3B7QJFhXP+GmNdrTFRB2/dxmyOwxTl4EM3KUQRRd72kGrF1azHvrZxVXTGykC83q yZpXTYP6cqhRSFQn5mVW4M4Ox29Wf5us8t53sUagJzYS+j3WOM2YO4LnbaX3yDBtokAE PsC3NNdGRaG87Y6r0OEK1Y3gJjR3ULteg2l/4n9lRwddl2ZGCDk2W4RUZhE5RHMvnJE+ KGRrWDsT5bPOA77lopBH5083qDs3dgES3i5imF/yaOjm2cjCB/FYIFNXAbZIL7en2m+S HYXA==
MIME-Version: 1.0
X-Received: by 10.140.31.247 with SMTP id f110mr9695850qgf.58.1390474124792; Thu, 23 Jan 2014 02:48:44 -0800 (PST)
Received: by 10.229.2.69 with HTTP; Thu, 23 Jan 2014 02:48:44 -0800 (PST)
In-Reply-To: <52DE7FE6.3000203@alum.mit.edu>
References: <7594FB04B1934943A5C02806D1A2204B1C5FB1EA@ESESSMB209.ericsson.se> <52D7F766.8000402@cisco.com> <7594FB04B1934943A5C02806D1A2204B1C642F14@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D10FE85@ESESSMB209.ericsson.se> <52DDCE70.1090707@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se> <52DE7FE6.3000203@alum.mit.edu>
Date: Thu, 23 Jan 2014 11:48:44 +0100
Message-ID: <CAFHv=r9hKoTsFJAeLTZ+fWZSvFncn1-==WPYdV8dR6EHtCki4A@mail.gmail.com>
From: Tom Kristensen <2mkristensen@gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="001a113a9c024716f304f0a0fc42"
Cc: "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, Tom Kristensen <tomkrist@cisco.com>
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, 23 Jan 2014 10:48:49 -0000
Thanks Christer, not only did you discover the issue - you also provided the fix (and text for it). That solves what is currently missing in the draft and in RFC 4582. I will add your text, or at least a very similar version, to the upcoming version of the draft. -- Tom On 21 January 2014 15:10, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote: > On 1/20/14 8:44 PM, Christer Holmberg wrote: > >> 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. >> > > WFM. > > > 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. >> > > OK. > > > 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 mailing list > bfcpbis@ietf.org > https://www.ietf.org/mailman/listinfo/bfcpbis > -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.com ### | http://folk.uio.no/tomkri/
- [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