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

From: Tom Kristensen <[email-masked]>
Date: Wed, 16 Apr 2014 19:05:04 +0200

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.

-- Tom

On 29 March 2014 12:44, Christer Holmberg <[email-masked]>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 J
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
> *From:* bfcpbis [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 29 March 2014 13:41
> *To:* Charles Eckel (eckelcu)
>
> *Cc:* [email-masked]
> *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:[email-masked]<[email-masked]>]
>
> *Sent:* 27 March 2014 01:11
> *To:* Christer Holmberg
> *Cc:* [email-masked]
> *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 <[email-masked]>
> *Date: *Tuesday, March 25, 2014 at 12:39 PM
> *To: *"[email-masked]" <[email-masked]>
> *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 J
>
>
>
> 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
> [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/

---

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

It would be much clearer and less confusing to have all the SDP
offer/answer related procedures in rfc4583bis. I agree and have started
working on it, i.e. moving content to rfc4583bis and polishing text in
rfc4582bis.

However, what do people on this list think about the concerns and sketch
for solving this issue proposed by Charles?

And specifically: Do we want to (i) update RFC 5018 with UDP / DTLS or do
we think it is even thinkable/doable to (ii) specify UDP / DTLS as a
transport only when offer/answer is used? (Not a clean approach, but very
pragmatic ;) )

-- Tom

On 29 March 2014 12:40, Christer Holmberg <[email-masked]>wrote:

> *From:* Charles Eckel (eckelcu) [mailto:[email-masked]]

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Apr 2014 20:25:51 +0000

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

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 <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:[email-masked]>] On Behalf Of Christer Holmberg
Sent: 29 March 2014 13:41
To: Charles Eckel (eckelcu)

Cc: [email-masked]<mailto:[email-masked]>
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:[email-masked]]
Sent: 27 March 2014 01:11
To: Christer Holmberg
Cc: [email-masked]<mailto:[email-masked]>
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.

  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 <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 25, 2014 at 12:39 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis

Hi,

“7.  Lower-Layer Security

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:

Second, Section 8.1 in 4583bis says:

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
[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/

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 16 Apr 2014 20:36:36 +0000

Hi,

>It would be much clearer and less confusing to have all the SDP offer/answer related >procedures in rfc4583bis. I agree and have started working on it, i.e. moving content to >rfc4583bis and polishing text in rfc4582bis.
>
>However, what do people on this list think about the concerns and sketch for solving this >issue proposed by Charles?
>
>And specifically: Do we want to (i) update RFC 5018 with UDP / DTLS or do we think it is >even thinkable/doable to (ii) specify UDP / DTLS as a transport only when offer/answer is >used? (Not a clean approach, but very pragmatic ;) )

Well, has anyone requested a non-O/A mechanism?

Regards,

Christer

On 29 March 2014 12:40, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Charles,

Regards,

Christer

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

Hi Christer,

Hi,

“7.  Lower-Layer Security

Yes.

Cheers,
Charles

Regards,

Christer

---

From: Tom Kristensen <[email-masked]>
Date: Thu, 17 Apr 2014 18:24:52 +0200

I have never heard of any need for a non-O/A mechanism, UDP/DTLS is
currently used by vendors utilizing offer/answer in a SIP context.

On 16 April 2014 22:36, Christer Holmberg <[email-masked]>wrote:

> offer/answer related >procedures in rfc4583bis. I agree and have started
> working on it, i.e. moving content to >rfc4583bis and polishing text in
> rfc4582bis.
>
> >
>
> for solving this >issue proposed by Charles?
>
> >
>
> >And specifically: Do we want to (i) update RFC 5018 with UDP / DTLS or
> do we think it is >even thinkable/doable to (ii) specify UDP / DTLS as a
> transport only when offer/answer is >used? (Not a clean approach, but
> very pragmatic ;) )
>
>
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 17 Apr 2014 21:35:01 +0000

That no one caught this sooner is another good indication there is no real need for a non offer/answer mechanism when using BFCP UDP/DTLS. I would be willing to sacrifice completeness for simplicity and restrict BFCP over UDP/DTLS to offer/answer usages. Having taken another look at RFC 5763, dealing with connection reestablishment via another offer/answer exchange seems appropriate as well.

Cheers,
Charles

From: Tom Kristensen <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 17, 2014 at 9:24 AM
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Charles Eckel <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Tom Kristensen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bfcpbis] TCP/TLS and UDP/DTLS comments on 4582bis and 4583bis

I have never heard of any need for a non-O/A mechanism, UDP/DTLS is currently used by vendors utilizing offer/answer in a SIP context.

On 16 April 2014 22:36, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,

Christer

Hi Christer,

Hi,

“7.  Lower-Layer Security

Yes.

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

Cheers,
Charles

Regards,

Christer