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/