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

From: Tom Kristensen <[email-masked]>
Date: Wed, 16 Apr 2014 18:20:55 +0200

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) <
[email-masked]> 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:[email-masked]] *On Behalf Of *Tom
> Kristensen
> *Sent:* 26 February 2014 13:41
> *To:* Christer Holmberg
> *Cc:* [email-masked]; 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 <
> [email-masked]> 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:[email-masked]]
>> *Lähetetty:* 14. helmikuuta 2014 18:22
>> *Vastaanottaja:* Christer Holmberg
>> *Kopio:* [email-masked]; 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 <[email-masked]> 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 <[email-masked]> 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:[email-masked]] Puolesta Christer
>> Holmberg
>> Lähetetty: 16. tammikuuta 2014 21:36
>> Vastaanottaja: Tom Kristensen
>> Kopio: [email-masked]
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>> _______________________________________________
>> bfcpbis mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>
>>
>> _______________________________________________
>> bfcpbis mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>
>>
>> _______________________________________________
>> bfcpbis mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>
>>
>>
>>
>>
>> --
>> # Cisco                         |  http://www.cisco.com/telepresence/
>> ## [email-masked]  |  http://www.tandberg.com
>> ###                               |  http://folk.uio.no/tomkri/
>>
>>
>>
>>
>>
>> --
>> # Cisco                         |  http://www.cisco.com/telepresence/
>> ## [email-masked]  |  http://www.tandberg.com
>> ###                               |  http://folk.uio.no/tomkri/
>>
>
>
>
>  --
> # Cisco                         |  http://www.cisco.com/telepresence/
> ## [email-masked]  |  http://www.tandberg.com
> ###                               |  http://folk.uio.no/tomkri/
>
>

-- 
# Cisco                         |  http://www.cisco.com/telepresence/
## [email-masked]  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/