Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?
Tom Kristensen <2mkristensen@gmail.com> Wed, 16 April 2014 16:21 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 B73C31A0243 for <bfcpbis@ietfa.amsl.com>; Wed, 16 Apr 2014 09:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.5
X-Spam-Level:
X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=no
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 jR7FLAHz1yKW for <bfcpbis@ietfa.amsl.com>; Wed, 16 Apr 2014 09:21:00 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8A53E1A0249 for <bfcpbis@ietf.org>; Wed, 16 Apr 2014 09:20:59 -0700 (PDT)
Received: by mail-qg0-f51.google.com with SMTP id q108so11372002qgd.38 for <bfcpbis@ietf.org>; Wed, 16 Apr 2014 09:20:56 -0700 (PDT)
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=XYg7JNvqfptcj19n78yg/zPIcxv/f4C0NLJJoa2HgpI=; b=SjwcYYZCcpLGRzVv1fszlErFFLTnacdG5aUeB3WcgCsb6tGaE4N+MgBTTTot3BGjwx PZJd135JF86GbnIwI8aqoEyUMu3UV5b4phMZv39yBte0BTR3lIVt3iRhDzee6GY5iDkr WTa8y8Ru4DNBtmQg/Obo6canlBEhn+j28ehZ4/rxs4V7s0nhHKei1Lu8S8rD8X0dflGA euDesLRN2fhtuhIUV3IMio/hnGkl90g0lBI5ti/up53s9n4cWtASO3jO/OYUKI1jMttG tbpPAbvDilGDYX3dAoa3Ctp90CyHcUrB34O6xoCLlDC/VhaTEfm33saAHt3Sl7yGmfiO TwaQ==
MIME-Version: 1.0
X-Received: by 10.224.67.131 with SMTP id r3mr4302146qai.75.1397665256091; Wed, 16 Apr 2014 09:20:56 -0700 (PDT)
Received: by 10.229.2.66 with HTTP; Wed, 16 Apr 2014 09:20:55 -0700 (PDT)
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B13A243@FR712WXCHMBA11.zeu.alcatel-lucent.com>
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> <CAFHv=r9hKoTsFJAeLTZ+fWZSvFncn1-==WPYdV8dR6EHtCki4A@mail.gmail.com> <CAFHv=r9fm3RsxbZ9+vRYnd-gCheK8iKo95xO_gkrqeFg7akJYw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D193AE1@ESESSMB209.ericsson.se> <CAFHv=r-ot4bDJ9MyC0eGst41oCFVxgpzxLgpySJP2wPxP_Ca4g@mail.gmail.com> <949EF20990823C4C85C18D59AA11AD8B13A243@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Date: Wed, 16 Apr 2014 18:20:55 +0200
Message-ID: <CAFHv=r8VTW_he7O+7W+yEvDHr=gioinxSAzODexDSG2_HcahLw@mail.gmail.com>
From: Tom Kristensen <2mkristensen@gmail.com>
To: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="001a11c3cefc1adf3704f72b4de0"
Archived-At: http://mailarchive.ietf.org/arch/msg/bfcpbis/sdQ6PUvQer0ppA9XBKpKoRJoEsg
Cc: Tom Kristensen <tomkrist@cisco.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>, Christer Holmberg <christer.holmberg@ericsson.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: Wed, 16 Apr 2014 16:21:05 -0000
Fixed. Adopted Christer's initial text suggestion for this issue. Will appear in the upcoming version of the draft. -- Tom On 26 February 2014 18:17, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > (As WG cochair) > > I would rather not have a new draft on the table immediately before the > face to face meeting. > > I would suggest you briefly list it in the identified changes in your > presentation to the WG, and then produce the new draft immediately > following the face to face meeting. > > Keith > > ------------------------------ > *From:* bfcpbis [mailto:bfcpbis-bounces@ietf.org] *On Behalf Of *Tom > Kristensen > *Sent:* 26 February 2014 13:41 > *To:* Christer Holmberg > *Cc:* bfcpbis@ietf.org; Paul Kyzivat; Tom Kristensen > *Subject:* Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection > goes down and is re-established? > > Right. An internal short-circuit there... > I'll fix the wording as soon as the submission gate has opened, it is the > active TCP endpoint that is responsible for re-establishing. > > And yes this is the TCP layer and should not rely on roles on the TLS > level. > > -- Tom > > > On 16 February 2014 18:22, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi Tom, >> >> >> >> You say that, if the *TCP connection* is lost, then the TLS client is >> responsible for re-establishing it. Isn’t it the *active TCP endpoint*that is responsible for re-establishing the *TCP >> connection*? >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> *Lähettäjä:* Tom Kristensen [mailto:2mkristensen@gmail.com] >> *Lähetetty:* 14. helmikuuta 2014 18:22 >> *Vastaanottaja:* Christer Holmberg >> *Kopio:* bfcpbis@ietf.org; Paul Kyzivat; Tom Kristensen >> >> *Aihe:* Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection >> goes down and is re-established? >> >> >> >> FYI. The text included in the next version will be (Section 7, 3rd and >> 4th paragraphs): >> >> >> >> ---- >> >> Which party, the client or the floor control server, acts as the TLS/ >> >> DTLS server depends on how the underlying TLS/DTLS connection is >> >> established. 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. If the TCP >> >> connection is lost, the active endpoint, i.e., the current TLS >> >> client, 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. >> >> >> >> For a UDP/DTLS connection established using the an SDP offer/answer >> >> exchange, either party can be the DTLS server depending on the setup >> >> attributes exchanged; examples can be found in [22]. >> >> ---- >> >> >> >> I do hope that defines it correctly. >> >> >> >> -- Tom >> >> >> >> >> >> On 23 January 2014 11:48, Tom Kristensen <2mkristensen@gmail.com> wrote: >> >> 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/ >> >> >> >> >> >> -- >> # Cisco | http://www.cisco.com/telepresence/ >> ## tomkrist@cisco.com | http://www.tandberg.com >> ### | http://folk.uio.no/tomkri/ >> > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > > -- # 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