Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis

[Christer Holmberg <[e-mail]>]

Hi,

>I'm starting with addressing this last issue first: RFC 4583 has lived fine for some years and >do have a number of interoperable implementations out there. This happened without >structuring the O/A procedures using RFC 3264 as a blueprint as was suggested for Christer's >draft in MMUSIC.
>
>Additinally, this issue never raised during SDP directorate review.
>
>I propose we do not restructure rfc4583bis this way.

Note that I am not asking for any technical changes.

But, the structure below does make things easier to read. But, if you think you can do it in another way, fine. The important thing is to get everything covered.

Regards,

Christer


On 29 March 2014 12:44, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

Another thing.

As part of the WGLC for one of my draft in MMUSIC, I received comments that the SDP O/A procedures should be structured according to RFC 3264, ie “Sending of initial offer”, “Modifying session”, “Processing of answer” etc.

Eventhough this is not MMUSIC, you may want to consider doing the same ☺

Regards,

Christer




From: bfcpbis [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Christer Holmberg
Sent: 29 March 2014 13:41
To: Charles Eckel (eckelcu)

Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis

Hi Charles,

Without commenting on specifics at this point, I really think we should try to get the SDP Offer/Answer procedures into one place (4583bis).

4582bis can define actions taken by the DTLS client and server, but should not define how those roles are determined. 4583bis then defines how the roles are determined when using SDP O/A.

Regards,

Christer

From: Charles Eckel (eckelcu) [mailto:[e-mail]]
Sent: 27 March 2014 01:11
To: Christer Holmberg
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis

Hi Christer,

Thanks for your comments. The more I looked into them the more complex and tangled things became. Let me try to walk through the current state of affairs and then propose a potential solutions.

RFC 4582 breaks connection establishment into two cases:

  1.  when SDP offer/answer IS NOT used
  2.  when SDP offer/answer IS used
For (1), RFC 4582 points to RFC 5018. draft-ietf-bfcpbis-rfc4582bis-11 adds a reference to RFC 5239 for XCON.
RFC 5018 deals with the connection establishment, reestablishment,  and TLS usage.
RFC 5239 points back to RFC 5018 for connection establishment.
RFC 5018 does not deal with DTLS. Unless we restrict DTLS to cases in which SDP offer/answer is used, we need to update RFC 5018 to deal with DTLS. Someone please tell me otherwise.

Section 6.2 of draft-ietf-bfcpbis-rfc4582bis-11 describes how to extend RFC 5018 when dealing with BFCP over UDP or DTLS. I think this should be relocated to an update to RFC 5018, and connection reestablishment should be described as well.

For (2), RFC 4582 provides a teaser but points to RFC 4583 for the normative language. draft-ietf-bfcpbis-rfc4582bis-11 similarly points to draft-ietf-bfcpbis-rfc4583bis-09. Christer comments are in regard to inconsistencies here. I provided comments on those inline.

From: Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, March 25, 2014 at 12:39 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis

Hi,

Section 7 in 4582bis, which says:

“7.  Lower-Layer Security

   BFCP relies on lower-layer security mechanisms to provide replay and
   integrity protection and confidentiality.  BFCP floor control servers
   and clients (which include both floor participants and floor chairs)

   MUST support TLS for transport over TCP [6] and MUST support DTLS [7]
   for transport over UDP.  Any BFCP entity MAY support other security
   mechanisms.

   BFCP entities MUST support, at a minimum, the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].

   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 [9], 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 [23].”

First, we already earlier discussed that the active TCP endpoint is responsible for re-establishing the TCP connection, and that will be corrected in the next version of the draft.

Yes.


However, we have discussed a similar topic in CLUE, and we were wondering whether it would be good that, whoever detects a connection failure, sends a new offer in order to re-establish the connection. It does not matter if both endpoints send an offer – the offer/answer race condition rules will take care of that.

In CLUE, is this for a TCP/TLS connection, or for a DTLS connection?
For DTLS, we specifically chose to alter the behavior, as described in section 9.1 of 4583bis:

  "Endpoints that use the offer/answer model to establish a DTLS
   association MUST support the 'setup' attribute, as defined in [7].
   When DTLS is used with UDP, the 'setup' attribute indicates which of
   the endpoints (client or floor control server) initiates the DTLS
   association setup.  The requirements for the offer/answer exchange
   specified in [13], Section 5 MUST be followed when using DTLS.

      Informational note: How to determine which endpoint to initiate
      the TLS/DTLS association depends on the selected underlying
      transport.  It was decided to keep the original semantics in [15]
      for TCP to retain backwards compatibility.  When using UDP, the
      procedure above was preferred since it adheres to [13] as used for
      DTLS-SRTP, it does not overload offer/answer semantics, and it
      works for offerless INVITE in scenarios with B2BUAs."




Second, Section 8.1 in 4583bis says:


   “When the existing TCP connection is reset following the rules in [8],

   the client MUST generate an offer towards the floor control server in

   order to reestablish the connection.  If a TCP connection cannot

   deliver a BFCP message and times out, the entity that attempted to

   send the message (i.e., the one that detected the TCP timeout) MUST

   generate an offer in order to reestablish the TCP connection.”




I am not sure what is meant by “TCP connection is reset following the rules in [8]”. Which rules are you referring to?

Reset means closed and reestablished. The word “reset” was used in RFC 4582 and reused in 4582bis. Perhaps we should change it closed and reestablished to avoid confusion?


Then, the text says that the client always re-established the TCP connection. Is that aligned with the text in 4582bis, saying that the active party does the reestablishment? Is the client always active?

I think it is a little confusing that both 4582bis and 4583bis defines SDP Offer/Answer procedures. Shouldn’t they only be in 4583bis?

Yes, I think so. RFC 4582 mixed some SDP offer/answer text into its section on lower layer security, and 4582bis followed suit. It would be better to have all the details of connection establishment and reestablishment in when using SDP offer/answer in 4583bis.




Third, the last paragraph, talking about UDP/DTLS, says that either party can be DTLS server depending on the setup attributes exchanged. But, nowhere is it described how the setup attribute is used to determine the DTLS server role ☺

I assume it is done in the same way as for TCP/TLS, but that is not written anywhere.

The text I pasted from 4583bis above describes this. If we put all the connection management stuff in 4583bis instead of leaving it split across 4582bis and 4583bis, this should be clear.

Cheers,
Charles



Regards,

Christer


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



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