Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 21 January 2014 14:10 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 C36B51A00D3 for <bfcpbis@ietfa.amsl.com>; Tue, 21 Jan 2014 06:10:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 es9eGtKJF8bt for <bfcpbis@ietfa.amsl.com>; Tue, 21 Jan 2014 06:10:47 -0800 (PST)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 997621A00D2 for <bfcpbis@ietf.org>; Tue, 21 Jan 2014 06:10:47 -0800 (PST)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta13.westchester.pa.mail.comcast.net with comcast id GdtN1n0010ldTLk5DeAnZZ; Tue, 21 Jan 2014 14:10:47 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id GeAn1n0043ZTu2S01eAnEa; Tue, 21 Jan 2014 14:10:47 +0000
Message-ID: <52DE7FE6.3000203@alum.mit.edu>
Date: Tue, 21 Jan 2014 09:10:46 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
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>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D110ECA@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1390313447; bh=QXDKBiIl0KLYX2NCUrEvNTAMhuCHFFCrwZiCTexx9qM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JxYc2dXzlB2IHPiRde5zBZDMm8sDbYseufCJR2M61+cW81XN4+Jhbbn/TE8qrq58J AoWgjLXBLcJ1HAcMYMPGn4uuJyZ/2EF0IbF8Fz4jdylvOwQhlHYr2TgObsawM3xAUw UJ9VzMUWIl/ji+qU7mBhpCDD7TDzj9+IeXt8vHgBo/bOvX3UCJqVZrL9/b/P1CVuA+ k7Mri+zd1RKAAEx1Scqz2dX+h8Mm9rW52IOJXPEoBABNydGPqb+CerRgpEbWxPhfhu jo02OXIKQNAhWDvPeMVAtIFsY/itB7FsLZPQIRKqbTlT8fXmd5d4NYMpFAtITa+st5 MO0FaSzhTOdYQ==
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 14:10:50 -0000

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
>