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

From: Tom Kristensen <[email-masked]>
Date: Fri, 14 Feb 2014 17:22:11 +0100

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/

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 16 Feb 2014 17:22:02 +0000

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):

----

-- Tom

On 23 January 2014 11:48, Tom Kristensen <[email-masked]<mailto:[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]<mailto:[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]<mailto:[email-masked]>] Puolesta Christer
Holmberg
Lähetetty: 16. tammikuuta 2014 21:36
Vastaanottaja: Tom Kristensen
Kopio: [email-masked]<mailto:[email-masked]>
Aihe: Re: [bfcpbis] TCP/TLS: Who is TLS server when the connection goes down and is re-established?

Hi Tom,

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:

Q1:

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).

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.

Regards,

Christer

_______________________________________________
bfcpbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bfcpbis
_______________________________________________
bfcpbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bfcpbis

_______________________________________________
bfcpbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bfcpbis

_______________________________________________
bfcpbis mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bfcpbis

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

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

---

From: Tom Kristensen <[email-masked]>
Date: Wed, 26 Feb 2014 14:41:09 +0100

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
> 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
> 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.
>
> 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.
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 26 Feb 2014 17:17:13 +0000

(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.

-- Tom

On 16 February 2014 18:22, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Tom,

Regards,

Christer

Lähettäjä: Tom Kristensen [mailto:[email-masked]<mailto:[email-masked]>]
Lähetetty: 14. helmikuuta 2014 18:22
Vastaanottaja: Christer Holmberg
Kopio: [email-masked]<mailto:[email-masked]>; Paul Kyzivat; Tom Kristensen

----

-- Tom

-- Tom

WFM.

OK.

Regards,

Christer

-----Alkuperäinen viesti-----

Hi Tom,

Q1:

Q2:

Regards,

Christer