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

[Tom Kristensen <[e-mail]>]

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 <[e-mail]
> 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:[e-mail]]
> *Lähetetty:* 14. helmikuuta 2014 18:22
> *Vastaanottaja:* Christer Holmberg
> *Kopio:* [e-mail]; 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 <[e-mail]> 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 <[e-mail]> 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:[e-mail]] Puolesta Christer
> Holmberg
> Lähetetty: 16. tammikuuta 2014 21:36
> Vastaanottaja: Tom Kristensen
> Kopio: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>
>
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>
>
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>
>
>
>
>
> --
> # Cisco                         |  http://www.cisco.com/telepresence/
> ## [e-mail]  |  http://www.tandberg.com
> ###                               |  http://folk.uio.no/tomkri/
>
>
>
>
>
> --
> # Cisco                         |  http://www.cisco.com/telepresence/
> ## [e-mail]  |  http://www.tandberg.com
> ###                               |  http://folk.uio.no/tomkri/
>



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