Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 8 Sep 2015 17:48:44 +0000

Picking up on this old thread regarding draft-ietf-bfcpbis-rfc4583bis. I
think this is the only outstanding item with respect to the current
version of the draft. Unless anyone has an issue with the proposed
resolution, I request we update the draft accordingly and then use it as
the basis for Mary, the document shepherd, to provide a proto writeup.

Cheers,
Charles

On 4/20/15, 10:39 AM, "Charles Eckel (eckelcu)" <[email-masked]> wrote:

>Hi Christer,
>
>I reread the current draft and went through the following MMUSIC thread on
>this subject:
>http://www.ietf.org/mail-archive/web/mmusic/current/msg14631.html
>
>As a result, I better understand the issue you are addressing. I suggest
>the following changes to be consistent with what is being proposed in
>MMUSIC:
>
>------------
>Section 9:
>
>OLD: 
>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 of [13] MUST be followed when using DTLS.
>Offer/answer considerations are described in Section 10.5.
>
>NEW: 
>When DTLS is used with UDP, the requirements specified in Section 5
>of [13] MUST be followed.
>
>
>Section 10.5
>
>OLD
>   If the transport parameters or the key fingerprints change, the
>   endpoints MUST establish a new DTLS connection.  In such case the
>   'active/passive' status of the endpoints will again be determined
>   following the procedures in [7], and the new status will be used to
>   determine the TLS roles associated with the new DTLS connection.
>
>      Informational note: The procedure above is identical to the one
>      defined for DTLS-SRTP in [13].
>
>      Note: A new DTLS connection needs to be established if the
>      transport parameters or the key fingerprints change.
>
>
>
>NEW: 
>The conditions under which endpoints MUST establish a new DTLS
>connection are as the same defined for DTLS-SRTP in [13].
>————————
>
>This way we avoid any potential conflicts with the intent of RFC 5763, and
>when clarifications to RFC 5763 are made, they will be picked up by the
>BFCP spec.
>
>Cheers,
>Charles
>
>
>
>
>On 4/18/15, 2:01 PM, "Christer Holmberg" <[email-masked]>
>wrote:
>
>>Hi Charles,
>>
>>> [adding bfcppbis list]
>>>
>>> Hi Christer,
>>>
>>> Thanks for your review and comments. In the BFCP usage, the DTLS
>>>connection is dedicated to the BFCP
>>> stream it contains. As I understand it, the complications around DTLS
>>>re-establishement discussed in MMUSIC
>>> result from use of a single DTLS connection for multiple RTP and/or
>>>SCTP streams. Those complications do
>>> not exist with the BFCP usage, so I think it is sufficient to continue
>>>to reference RFC 5763 and not use the
>>> SDP connection attribute.
>>
>>The complications do not result from use of a single DTLS connection for
>>multiple streams - it mainly results from the usage of ICE. And, as far
>>as I know, ICE can be used also for BFCP.
>>
>>And, even without ICE we intend to add text saying that a DTLS connection
>>is only re-established if the underlying transport changes.
>>
>>Regards,
>>
>>Christer
>>
>>
>>
>>>Hi,
>>>
>>>First, I want to apologize for not providing my review earlier.
>>>
>>>As far as the BFCP specifics are concerned, I am ok with the latest
>>>version of the draft.
>>>
>>>However, there is an issue regarding the DTLS considerations (section
>>>10.5).
>>>
>>>The text says:
>>>
>>>	"Once a DTLS connection has been established, if the 'active/passive'
>>>   	status of the endpoints change during a session, a new DTLS
>>>   	connection MUST be established."
>>>
>>>There is currently an ongoing discussion in MMUSIC about when a DTLS
>>>connection is to be re-established.
>>>
>>>The discussion is still ongoing, but the outcome will most likely NOT
>>>be aligned with the text above.
>>>
>>>For example, there has been a suggestion (by myself) to use the SDP
>>>connection attribute to explicitly indicate that a new DTLS connection
>>>needs to be established.
>>>
>>>
>>>The draft also says:
>>>
>>>	"If the transport parameters or the key fingerprints change, the
>>>   	endpoints MUST establish a new DTLS connection."
>>>
>>>This is related to the earlier issue. There is the discussion about ICE
>>>"virtual connections", and that a single DTLS connection would apply to
>>>all ICE candidates associated with an m- line. So, even if a candidate
>>>changes (read: transport parameter changes), it would not automatically
>>>trigger a new DTLS connection.
>>>
>>>
>>>The issues above are also holding up the SCTP-SDP draft, so it doesn't
>>>only affect BFCPbis :)
>>>
>>>
>>>Regards,
>>>
>>>Christer
>>>
>>>
>>>-----Original Message-----
>>>From: Alissa Cooper [mailto:[email-masked]]
>>>Sent: 8. huhtikuuta 2015 3:07
>>>To: Charles Eckel (eckelcu)
>>>Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist);
>>>[email-masked]; Ben Campbell; Christer
>>>Holmberg
>>>Subject: Re: draft-ietf-bfcpbis-rfc4583bis
>>>
>>>Adding Christer to this thread.
>>>
>>>On Apr 7, 2015, at 12:44 PM, Charles Eckel (eckelcu)
>>><[email-masked]>
>>>wrote:
>>>
>>>> Christer (cc’d) and I discussed some of the changes offlist in
>>>> Dallas, and he is to come back to the list with comments after Dallas
>>>> - which is now :)
>>>> 
>>>> Cheers,
>>>> Charles
>>>> 
>>>> On 4/7/15, 10:26 AM, "Alissa Cooper" <[email-masked]> wrote:
>>>> 
>>>>> Checking in on this — has Christer been prompted to review the
>>>>> latest rev of draft-ietf-bfcpbis-rfc4583bis?
>>>>> 
>>>>> Thanks,
>>>>> Alissa
>>>>> 
>>>>> On Feb 25, 2015, at 9:14 AM, Charles Eckel (eckelcu)
>>>>> <[email-masked]>
>>>>> wrote:
>>>>> 
>>>>>> Most of the changes I this recent update to rfc4583bis were
>>>>>> inspired by comments and suggested text provided by Christer. He is
>>>>>> in the process of reviewing. If all goes well with that, we are
>>>>>> ready to proceed with proto writeup (Mary) and AD review.
>>>>>> 
>>>>>> Cheers,
>>>>>> Charles
>>>>>> 
>>>>>> On 2/25/15, 7:01 AM, "Alissa Cooper" <[email-masked]> wrote:
>>>>>> 
>>>>>>> rfc4583 has not had an AD review yet. Richard can hopefully take
>>>>>>> care of that while I¹m on leave (starting today, actually).
>>>>>>> 
>>>>>>> On Feb 25, 2015, at 2:56 AM, Gonzalo Camarillo
>>>>>>> <[email-masked]> wrote:
>>>>>>> 
>>>>>>>> Hi Alissa,
>>>>>>>> 
>>>>>>>> I have noted that while rfc4582bis in on the agenda of the March
>>>>>>>> 5th telechat (thanks for handling that!), rfc4583bis isn't. Tom
>>>>>>>> revised rfc4583bis on February 20th. Should rfc4583bis be on the
>>>>>>>> agenda of the telechat as well or there is still something left
>>>>>>>> for Tom to take care of?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Gonzalo
>>>>>>>> 
>>>>>>>> On 18/02/2015 9:28 PM, Alissa Cooper wrote:
>>>>>>>>> Pinging on this.
>>>>>>>>> 
>>>>>>>>> March 5 will likely be my last telechat before going on leave,
>>>>>>>>>so  it would be great to get this scheduled on that one. To do
>>>>>>>>>that,  the rev needs to be posted today. The updates are pretty
>>>>>>>>>minimal  and are all basically written up in Charles¹ response to
>>>>>>>>>my AD review.
>>>>>>>>> 
>>>>>>>>> Alissa
>>>>>>>>> 
>>>>>>>>> On Feb 15, 2015, at 9:13 AM, Gonzalo Camarillo
>>>>>>>>> <[email-masked]
>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I have talked offline with the other authors and Tom is holding
>>>>>>>>>> the pen. Tom, do you think you can meet the time frame below?
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> 
>>>>>>>>>> Gonzalo
>>>>>>>>>> 
>>>>>>>>>> Sent from my mobile
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> ---- Alissa Cooper wrote ----
>>>>>>>>>> 
>>>>>>>>>> Just wanted to see if this rev might get done in the next
>>>>>>>>>>couple  of days. If so, we could get it on the next telechat
>>>>>>>>>>agenda (March 5).
>>>>>>>>>> 
>>>>>>>>>> Alissa
>>>>>>>>>> 
>>>>>>>>>> Begin forwarded message:
>>>>>>>>>> 
>>>>>>>>>>> *From: *Alissa Cooper <[email-masked]
>>>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>>>> *Subject: **Re: [bfcpbis] AD evaluation:
>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12*
>>>>>>>>>>> *Date: *February 9, 2015 at 3:58:52 PM PST
>>>>>>>>>>> *To: *"Charles Eckel (eckelcu)" <[email-masked]
>>>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>>>> *Cc: *"[email-masked] <mailto:[email-masked]>"
>>>>>>>>>>> <[email-masked]
>>>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>>>> 
>>>>>>>>>>> Hi Charles,
>>>>>>>>>>> 
>>>>>>>>>>> Thanks, some responses inline.
>>>>>>>>>>> 
>>>>>>>>>>> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu)
>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> HI Alissa,
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you for the review. Please see my thoughts on your
>>>>>>>>>>>> comments and questions inline.
>>>>>>>>>>>> 
>>>>>>>>>>>> From: Alissa Cooper <[email-masked]
>>>>>>>>>>>> <mailto:[email-masked]>>
>>>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM
>>>>>>>>>>>> To: "[email-masked] <mailto:[email-masked]>"
>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>>>>>>>>> Subject: [bfcpbis] AD evaluation:
>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12
>>>>>>>>>>>> 
>>>>>>>>>>>>> I have reviewed this draft in preparation for IETF LC.
>>>>>>>>>>>>> Overall the document appears in good shape. I have a few
>>>>>>>>>>>>> questions and comments I¹d like to discuss before issuing
>>>>>>>>>>>>> the IETF last call. I¹ve also included some editorial nits
>>>>>>>>>>>>> that should be addressed together with any last call
>>>>>>>>>>>>>comments.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Comments and questions:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Section 5.1 =
>>>>>>>>>>>>> "If an endpoint receives a message with an  unsupported
>>>>>>>>>>>>> version field value, the receiving server MUST send an
>>>>>>>>>>>>> Error message with parameter value 12 (Unsupported Version)
>>>>>>>>>>>>> to indicate this.²
>>>>>>>>>>>>> 
>>>>>>>>>>>>> This seems a little misleading since RFC 4582 didn¹t specify
>>>>>>>>>>>>>what to do upon receipt of a message with a version other
>>>>>>>>>>>>>than 1.
>>>>>>>>>>>>> Implementations that do not get upgraded to be compliant
>>>>>>>>>>>>>with  4582bis (which could certainly account for some of
>>>>>>>>>>>>>those that  will not support version 2) will therefore never
>>>>>>>>>>>>>send the  error specified here. This seems like it should at
>>>>>>>>>>>>>least be  noted given the MUST-level requirement. The same
>>>>>>>>>>>>>applies in  Section 13.7.
>>>>>>>>>>>> 
>>>>>>>>>>>> Good point. I believe we made this a MUST because we were
>>>>>>>>>>>>thinking in terms of implementations compliant with this bis
>>>>>>>>>>>>version.
>>>>>>>>>>>> Adding
>>>>>>>>>>>> your suggested note about rfc 4582 implementations here and
>>>>>>>>>>>>in  section 13.7 seems useful to me.
>>>>>>>>>>> 
>>>>>>>>>>> Ok
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Section 7 =
>>>>>>>>>>>>> "BFCP entities MUST support, at a minimum, the
>>>>>>>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].²
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I realize this requirement comes from RFC 4582, but I¹d like
>>>>>>>>>>>>> to understand why it has not been updated to be consistent
>>>>>>>>>>>>> with more current guidance on cipher suite selection (e.g.,
>>>>>>>>>>>>> 
>>>>>>>>>>>>>https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#section
>>>>>>>>>>>>>-4)
>>>>>>>>>>>>>.
>>>>>>>>>>>> 
>>>>>>>>>>>> How about we keep this minimum requirement, and add a
>>>>>>>>>>>>reference to draft-ietf-uta-tls-bcp along with a
>>>>>>>>>>>>recommendation to adhere to the best practices it outlines in
>>>>>>>>>>>>section 4?
>>>>>>>>>>> 
>>>>>>>>>>> I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA for
>>>>>>>>>>> backwards compatibility and SHOULD support the ones listed in
>>>>>>>>>>> the UTA drafts would be ok.
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Sections 8, 8.1, 8.2 =
>>>>>>>>>>>>> It seems like the transaction ID requirements regarding
>>>>>>>>>>>>> non-reuse/monotonically increasing IDs are re-stated
>>>>>>>>>>>>> multiple times across these three sections, in slightly
>>>>>>>>>>>>> different ways, to the point where it¹s not clear exactly
>>>>>>>>>>>>> what they are. It seems like they are:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> (1) Reliable transport, server-initiated transaction: ID is
>>>>>>>>>>>>> 0
>>>>>>>>>>>>> (2) Unreliable transport, server-initiated transaction: ID
>>>>>>>>>>>>> MUST be monotonically increasing (except for wrap-around)
>>>>>>>>>>>>> (3) Reliable transport, client-initiated transaction: ID
>>>>>>>>>>>>> MUST NOT be 0 and MUST NOT be reused in another message from
>>>>>>>>>>>>> the client until a response from the server is received for
>>>>>>>>>>>>> the transaction, but need not be monotonically increasing
>>>>>>>>>>>>> (e.g., a lower, recently used ID could be re-used once a
>>>>>>>>>>>>> response is
>>>>>>>>>>>>> received)
>>>>>>>>>>>>> (4) Unreliable transport, client-initiated transaction: ID
>>>>>>>>>>>>> MUST be monotonically increasing (except for wrap-around)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Is (3) the correct interpretation of the text in 8.1? If so,
>>>>>>>>>>>>> why not just require IDs in all client-initiated
>>>>>>>>>>>>> transactions to be monotonically increasing?
>>>>>>>>>>>> 
>>>>>>>>>>>> Agree we can and should simplify this. Sections 8.1 and 8.2
>>>>>>>>>>>> cover the client behavior and server behavior in detail. As
>>>>>>>>>>>> such, the transaction ID related information at the start of
>>>>>>>>>>>> Section 8 is superfluous. I recommend reducing the text in
>>>>>>>>>>>> Section 8 to the
>>>>>>>>>>>> follow:
>>>>>>>>>>>> 
>>>>>>>>>>>> 8. Protocol Transactions
>>>>>>>>>>>> 
>>>>>>>>>>>> In BFCP, there are two types of transactions:
>>>>>>>>>>>> client-initiated transactions and server-initiated
>>>>>>>>>>>>transactions.
>>>>>>>>>>>> 
>>>>>>>>>>>> Client-initiated transactions consist of a request from a
>>>>>>>>>>>> client to a floor control server and a response from the
>>>>>>>>>>>> floor control server to the client.
>>>>>>>>>>>> 
>>>>>>>>>>>> Server-initiated transactions have different behavior
>>>>>>>>>>>> depending on underlying transport:
>>>>>>>>>>>> 
>>>>>>>>>>>>    When using a reliable transport, server-initiated
>>>>>>>>>>>>transactions
>>>>>>>>>>>>    consist of a single message from a floor control server to
>>>>>>>>>>>>a
>>>>>>>>>>>>    client (notifications).  They do not trigger any response.
>>>>>>>>>>>> 
>>>>>>>>>>>>    When using an unreliable transport, server-initiated
>>>>>>>>>>>> transactions
>>>>>>>>>>>>    consist of a request from a floor control server to a
>>>>>>>>>>>> client and a
>>>>>>>>>>>>    response from the client to the floor control server.
>>>>>>>>>>>> 
>>>>>>>>>>>> When using BFCP over an unreliable transport, retransmission
>>>>>>>>>>>> timer T1 (see Section 8.3) MUST be used for all requests
>>>>>>>>>>>> until the transaction is completed.
>>>>>>>>>>>> 
>>>>>>>>>>>> Then in section 8.1, we add the important details removed
>>>>>>>>>>>> from section 8.
>>>>>>>>>>>> 
>>>>>>>>>>>> 8.1.1 Client Behavior
>>>>>>>>>>>> 
>>>>>>>>>>>> A client starting a client-initiated transaction MUST set the
>>>>>>>>>>>> Conference ID in the common header of the message to the
>>>>>>>>>>>> Conference ID for the conference that the client obtained
>>>>>>>>>>>> previously.
>>>>>>>>>>>> 
>>>>>>>>>>>> The client MUST set the Transaction ID value in the common
>>>>>>>>>>>> header to a number that is different from 0 and that MUST NOT
>>>>>>>>>>>> be reused in another message from the client until a response
>>>>>>>>>>>> from the server is received for the transaction.  The client
>>>>>>>>>>>> uses the Transaction ID value to match this message with the
>>>>>>>>>>>> response from the floor control server. When using BFCP over
>>>>>>>>>>>> an unreliable transport, it is important to choose a
>>>>>>>>>>>> Transaction ID value that lets the receiver distinguish the
>>>>>>>>>>>> reception of the next message in a sequence of BFCP messages
>>>>>>>>>>>> from a retransmission of a previous message.  Therefore, BFCP
>>>>>>>>>>>> entities using an unreliable transport MUST use monotonically
>>>>>>>>>>>> increasing Transaction ID values (except for wrap-around).
>>>>>>>>>>>> 
>>>>>>>>>>>> A client receiving a server-initiated transaction over an
>>>>>>>>>>>> unreliable transport MUST copy the Transaction ID from the
>>>>>>>>>>>> request received from the server into the response.
>>>>>>>>>>>> [Question: is there a need to copy the Conference ID and User
>>>>>>>>>>>> ID, if present?]
>>>>>>>>>>>> 
>>>>>>>>>>>> 8.2. Server Behavior
>>>>>>>>>>>> 
>>>>>>>>>>>> A floor control server sending a response within a
>>>>>>>>>>>> client-initiated transaction MUST copy the Conference ID, the
>>>>>>>>>>>> Transaction ID, and the User ID from the request received
>>>>>>>>>>>> from the client into the response.
>>>>>>>>>>>> 
>>>>>>>>>>>> Server-initiated transactions MUST contain a Transaction ID
>>>>>>>>>>>> equal to
>>>>>>>>>>>> 0 when BFCP is used over a reliable transport.  Over an
>>>>>>>>>>>> unreliable transport, the Transaction ID shall have the same
>>>>>>>>>>>> properties as for client-initiated transactions. The server
>>>>>>>>>>>> uses the Transaction ID value to match this message with the
>>>>>>>>>>>> response from the floor participant or floor chair.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Thanks, this is better.
>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Section 9 (impacts Section 14 as well) = "BFCP clients
>>>>>>>>>>>>> SHOULD authenticate the floor control server before sending
>>>>>>>>>>>>> any BFCP message to it or accepting any BFCP message from it.
>>>>>>>>>>>>> Similarly, floor control servers SHOULD authenticate a
>>>>>>>>>>>>> client before accepting any BFCP message from it or sending
>>>>>>>>>>>>> any BFCP message to it.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> BFCP supports TLS/DTLS mutual authentication between clients
>>>>>>>>>>>>> and floor control servers, as specified in Section 9.1.
>>>>>>>>>>>>> This is the RECOMMENDED authentication mechanism in BFCP.²
>>>>>>>>>>>>> 
>>>>>>>>>>>>> What are the cases where clients and servers do not need to
>>>>>>>>>>>>> be authenticating each other? I know this requirement and
>>>>>>>>>>>>> the other SHOULD-level requirements around use of TLS/DTLS
>>>>>>>>>>>>> are carried over from RFC 4582, but I¹m concerned that they
>>>>>>>>>>>>> aren¹t as strong as they should be. For a conference where
>>>>>>>>>>>>> the signaling traffic is authenticated and confidentiality
>>>>>>>>>>>>> and integrity protected, why is it ok for the floor control
>>>>>>>>>>>>> traffic not to be? Could these requirements be adjusted to
>>>>>>>>>>>>> require use of TLS/DTLS at least in cases where the
>>>>>>>>>>>>> signaling is also protected?
>>>>>>>>>>>> 
>>>>>>>>>>>> Yes, but again, this would be at the expense of adding a non
>>>>>>>>>>>> backward compatible change from rfc 4582. How about saying
>>>>>>>>>>>> TLS/DTLS MUST be used for BFCP in such cases, while pointing
>>>>>>>>>>>> out the rfc
>>>>>>>>>>>> 4582
>>>>>>>>>>>> based implementations may not comply (similar to what we did
>>>>>>>>>>>> with the version field).
>>>>>>>>>>> 
>>>>>>>>>>> Works for me.
>>>>>>>>>>> 
>>>>>>>>>>> Feel free to make all of these changes and submit a rev and
>>>>>>>>>>> I¹ll issue the IETF LC.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Alissa
>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Section 14 =
>>>>>>>>>>>>> See the point above about ciphersuites. ³Non-null
>>>>>>>>>>>>> encryption² is not a sufficient minimum baseline, and if the
>>>>>>>>>>>>> requirements change in Section 7 they should be reflected
>>>>>>>>>>>>>here as well.
>>>>>>>>>>>> 
>>>>>>>>>>>> Yep.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Editorial nits to be resolved with LC comments:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Section 5.1 =
>>>>>>>>>>>>> ³The version field MUST be set to 1 when using BFCP over a
>>>>>>>>>>>>> reliable transport, i.e. as in [2].²
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I find it a little odd to reference the spec you¹re
>>>>>>>>>>>>> obsoleting in this sentence, especially since BFCP over a
>>>>>>>>>>>>> reliable transport is completely specified in this bis
>>>>>>>>>>>>> document. I would suggest dropping the i.e. clause.
>>>>>>>>>>>> 
>>>>>>>>>>>> Good catch. This is a carry over from before this draft was
>>>>>>>>>>>> adopted as a bis version of rfc4582.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> "The version field MUST be set to 2 when using BFCP over an
>>>>>>>>>>>>> unreliable transport with the extensions specified in this
>>>>>>>>>>>>> document.²
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The bit about ³with the extensions specified in this
>>>>>>>>>>>>> document² is extraneous and should be removed.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> "If an endpoint receives a message with an unsupported
>>>>>>>>>>>>> version field value, the receiving server MUST send an Error
>>>>>>>>>>>>> message with parameter value 12 (Unsupported Version) to
>>>>>>>>>>>>> indicate this.²
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Use of the word ³server² here makes it sound as if only
>>>>>>>>>>>>> servers could receive headers with unsupported versions.
>>>>>>>>>>>>> Should this be ³the receiving endpoint²?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Section 6.2.4 =
>>>>>>>>>>>>> "[23], Section 6.7 provides useful recommendations Š²
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The links in the references are not quite right.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Section 8.3.2 =
>>>>>>>>>>>>> s/when fires/when fired/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Section 14 =
>>>>>>>>>>>>> s/high-jack/hijack/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> = Section B.1 =
>>>>>>>>>>>>> "situation where multiple different and non-interoperable
>>>>>>>>>>>>> would
>>>>>>>>>>>>> co-
>>>>>>>>>>>>> exist in the market.²
>>>>>>>>>>>>> 
>>>>>>>>>>>>> There is a word missing after ³non-interoperable."
>>>>>>>>>>>> 
>>>>>>>>>>>> This should read ³non-interoperable implementations². Earlier
>>>>>>>>>>>> in that same sentence, ³BFCP over UDP were already used²
>>>>>>>>>>>> should read ³BFCP over UDP is already being used².
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Charles
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> bfcpbis mailing list
>>>>>>>>>>> [email-masked] <mailto:[email-masked]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>
>>

---

From: Tom Kristensen <[email-masked]>
Date: Fri, 11 Sep 2015 12:24:40 +0200

Pointing to the DTLS-SRTP (and by that any updates of it) is a simple, 
safe and straigt-forward solution.

The only change in the new version of rfc4583bis just submitted. And as 
Charles says, this should be the last missing fix for this draft until 
next stages in the process at least.

-- Tom

On 09/08/2015 07:48 PM, Charles Eckel (eckelcu) wrote:
> On 4/20/15, 10:39 AM, "Charles Eckel (eckelcu)"<[email-masked]>  wrote:
>
>    
>> Hi Christer,
>>
>> On 4/18/15, 2:01 PM, "Christer Holmberg"<[email-masked]>
>> wrote:
>>
>>      
>>> Hi Charles,
>>>
>>>        
>>>> [adding bfcppbis list]
>>>>
>>>> Hi Christer,
>>>>
>>>>> On 4/7/15, 10:26 AM, "Alissa Cooper"<[email-masked]>  wrote:
>>>>>
>>>>>            
>>>>>>> On 2/25/15, 7:01 AM, "Alissa Cooper"<[email-masked]>  wrote:
>>>>>>>
>>>>>>>                
>>>>>>>>>>>> *From: *Alissa Cooper<[email-masked]
>>>>>>>>>>>> *To: *"Charles Eckel (eckelcu)"<[email-masked]
>>>>>>>>>>>> *Cc: *"[email-masked]<mailto:[email-masked]>"
>>>>>>>>>>>> <[email-masked]
>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>>  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>                          
>>>>>>>>>>>>> HI Alissa,
>>>>>>>>>>>>>
>>>>>>>>>>>>> From: Alissa Cooper<[email-masked]
>>>>>>>>>>>>> To: "[email-masked]<mailto:[email-masked]>"
>>>>>>>>>>>>> <[email-masked]<mailto:[email-masked]>>
>>>>>>>>>>>> [email-masked]<mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Sep 2015 11:25:58 +0000

Hi,

My suggestion would actually be to refer to the new draft-ietf-mmusic-dtls-sdp, which is going to clarify the DTLS-SRTP rules regarding when a new DTLS association must be established.

Regards,

Christer

-----Original Message-----
From: Tom Kristensen [mailto:[email-masked]] 
Sent: 11. syyskuuta 2015 13:25
To: Charles Eckel (eckelcu)
Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo; [email-masked]; Ben Campbell; [email-masked]
Subject: Re: draft-ietf-bfcpbis-rfc4583bis

Pointing to the DTLS-SRTP (and by that any updates of it) is a simple, safe and straigt-forward solution.

The only change in the new version of rfc4583bis just submitted. And as Charles says, this should be the last missing fix for this draft until next stages in the process at least.

-- Tom

On 09/08/2015 07:48 PM, Charles Eckel (eckelcu) wrote:
> Picking up on this old thread regarding draft-ietf-bfcpbis-rfc4583bis. 
> I think this is the only outstanding item with respect to the current 
> resolution, I request we update the draft accordingly and then use it 
> as the basis for Mary, the document shepherd, to provide a proto writeup.
>
> Cheers,
> Charles
>
>
>> I reread the current draft and went through the following MMUSIC 
>> thread on this subject:
>> As a result, I better understand the issue you are addressing. I 
>> suggest the following changes to be consistent with what is being 
>> proposed in
>> MMUSIC:
>>
>> ------------
>> Section 9:
>>
>> OLD:
>> This way we avoid any potential conflicts with the intent of RFC 
>> 5763, and when clarifications to RFC 5763 are made, they will be 
>> picked up by the BFCP spec.
>>
>> Cheers,
>> Charles
>>
>>
>>
>>
>> On 4/18/15, 2:01 PM, "Christer 
>> Holmberg"<[email-masked]>
>> wrote:
>>
>>      
>>> Hi Charles,
>>>
>>>        
>>>> [adding bfcppbis list]
>>>>
>>>> Hi Christer,
>>>>
>>>> connection is dedicated to the BFCP stream it contains. As I 
>>>> understand it, the complications around DTLS re-establishement 
>>>> discussed in MMUSIC result from use of a single DTLS connection for 
>>>> multiple RTP and/or SCTP streams. Those complications do not exist 
>>>> with the BFCP usage, so I think it is sufficient to continue to 
>>>> reference RFC 5763 and not use the SDP connection attribute.
>>>>          
>>> The complications do not result from use of a single DTLS connection 
>>> for multiple streams - it mainly results from the usage of ICE. And, 
>>> as far as I know, ICE can be used also for BFCP.
>>>
>>> And, even without ICE we intend to add text saying that a DTLS 
>>> connection is only re-established if the underlying transport changes.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>>
>>>        
>>>> Hi,
>>>>
>>>> However, there is an issue regarding the DTLS considerations 
>>>> (section 10.5).
>>>>
>>>> The text says:
>>>>
>>>> There is currently an ongoing discussion in MMUSIC about when a 
>>>> DTLS connection is to be re-established.
>>>>
>>>> The discussion is still ongoing, but the outcome will most likely 
>>>> NOT be aligned with the text above.
>>>>
>>>> connection attribute to explicitly indicate that a new DTLS 
>>>> connection needs to be established.
>>>>
>>>>
>>>> The draft also says:
>>>>
>>>> This is related to the earlier issue. There is the discussion about 
>>>> ICE "virtual connections", and that a single DTLS connection would 
>>>> apply to all ICE candidates associated with an m- line. So, even if 
>>>> a candidate changes (read: transport parameter changes), it would 
>>>> not automatically trigger a new DTLS connection.
>>>>
>>>>
>>>> The issues above are also holding up the SCTP-SDP draft, so it 
>>>> doesn't only affect BFCPbis :)
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>> [email-masked]; Ben Campbell; 
>>>> Christer Holmberg
>>>>>>> inspired by comments and suggested text provided by Christer. He 
>>>>>>> is in the process of reviewing. If all goes well with that, we 
>>>>>>> are ready to proceed with proto writeup (Mary) and AD review.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Charles
>>>>>>>
>>>>>>>> rfc4583 has not had an AD review yet. Richard can hopefully 
>>>>>>>> take care of that while I¹m on leave (starting today, actually).
>>>>>>>>
>>>>>>>>> I have noted that while rfc4582bis in on the agenda of the 
>>>>>>>>> March 5th telechat (thanks for handling that!), rfc4583bis 
>>>>>>>>> isn't. Tom revised rfc4583bis on February 20th. Should 
>>>>>>>>> rfc4583bis be on the agenda of the telechat as well or there 
>>>>>>>>> is still something left for Tom to take care of?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Gonzalo
>>>>>>>>>
>>>>>>>>>> March 5 will likely be my last telechat before going on 
>>>>>>>>>> leave, so  it would be great to get this scheduled on that 
>>>>>>>>>> one. To do that,  the rev needs to be posted today. The 
>>>>>>>>>> updates are pretty minimal  and are all basically written up 
>>>>>>>>>> in Charles¹ response to my AD review.
>>>>>>>>>>
>>>>>>>>>> Alissa
>>>>>>>>>>
>>>>>>>>>>> I have talked offline with the other authors and Tom is 
>>>>>>>>>>> holding the pen. Tom, do you think you can meet the time frame below?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>>
>>>>>>>>>>> Gonzalo
>>>>>>>>>>>
>>>>>>>>>>> Sent from my mobile
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> the IETF last call. I¹ve also included some editorial 
>>>>>>>>>>>>>> nits that should be addressed together with any last call 
>>>>>>>>>>>>>> comments.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Comments and questions:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> = Section 5.1 =
>>>>>>>>>>>>>> Error message with parameter value 12 (Unsupported 
>>>>>>>>>>>>>> Version) to indicate this.²
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This seems a little misleading since RFC 4582 didn¹t 
>>>>>>>>>>>>>> specify what to do upon receipt of a message with a 
>>>>>>>>>>>>>> version other than 1.
>>>>>>>>>>>>>> those that  will not support version 2) will therefore 
>>>>>>>>>>>>>> never send the  error specified here. This seems like it 
>>>>>>>>>>>>>> should at least be  noted given the MUST-level 
>>>>>>>>>>>>>> requirement. The same applies in  Section 13.7.
>>>>>>>>>>>>>>                              
>>>>>>>>>>>>> thinking in terms of implementations compliant with this 
>>>>>>>>>>>>> bis version.
>>>>>>>>>>>>> Adding
>>>>>>>>>>>>> your suggested note about rfc 4582 implementations here 
>>>>>>>>>>>>> and in  section 13.7 seems useful to me.
>>>>>>>>>>>>>                            
>>>>>>>>>>>> Ok
>>>>>>>>>>>>
>>>>>>>>>>>>                          
>>>>>>>>>>>>>                            
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> = Section 7 =
>>>>>>>>>>>>>> I realize this requirement comes from RFC 4582, but I¹d 
>>>>>>>>>>>>>> like to understand why it has not been updated to be 
>>>>>>>>>>>>>> consistent with more current guidance on cipher suite 
>>>>>>>>>>>>>> selection (e.g.,
>>>>>>>>>>>>>>
>>>>>>>>>>>>> recommendation to adhere to the best practices it outlines 
>>>>>>>>>>>>> in section 4?
>>>>>>>>>>>>>                            
>>>>>>>>>>>> backwards compatibility and SHOULD support the ones listed 
>>>>>>>>>>>> in the UTA drafts would be ok.
>>>>>>>>>>>>
>>>>>>>>>>>>                          
>>>>>>>>>>>>>                            
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> = Sections 8, 8.1, 8.2 =
>>>>>>>>>>>>>> (2) Unreliable transport, server-initiated transaction: 
>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for 
>>>>>>>>>>>>>> wrap-around)
>>>>>>>>>>>>>> MUST NOT be 0 and MUST NOT be reused in another message 
>>>>>>>>>>>>>> from the client until a response from the server is 
>>>>>>>>>>>>>> received for the transaction, but need not be 
>>>>>>>>>>>>>> monotonically increasing (e.g., a lower, recently used ID 
>>>>>>>>>>>>>> could be re-used once a response is
>>>>>>>>>>>>>> received)
>>>>>>>>>>>>>> (4) Unreliable transport, client-initiated transaction: 
>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for 
>>>>>>>>>>>>>> wrap-around)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is (3) the correct interpretation of the text in 8.1? If 
>>>>>>>>>>>>>> so, why not just require IDs in all client-initiated 
>>>>>>>>>>>>> Agree we can and should simplify this. Sections 8.1 and 
>>>>>>>>>>>>> 8.2 cover the client behavior and server behavior in 
>>>>>>>>>>>>> detail. As such, the transaction ID related information at 
>>>>>>>>>>>>> the start of Section 8 is superfluous. I recommend 
>>>>>>>>>>>>> reducing the text in Section 8 to the
>>>>>>>>>>>>> follow:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 8. Protocol Transactions
>>>>>>>>>>>>>
>>>>>>>>>>>>>     consist of a single message from a floor control 
>>>>>>>>>>>>> server to a
>>>>>>>>>>>>> When using BFCP over an unreliable transport, 
>>>>>>>>>>>>> retransmission timer T1 (see Section 8.3) MUST be used for 
>>>>>>>>>>>>> all requests until the transaction is completed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A client starting a client-initiated transaction MUST set 
>>>>>>>>>>>>> the Conference ID in the common header of the message to 
>>>>>>>>>>>>> the Conference ID for the conference that the client 
>>>>>>>>>>>>> obtained previously.
>>>>>>>>>>>>>
>>>>>>>>>>>>> header to a number that is different from 0 and that MUST 
>>>>>>>>>>>>> NOT be reused in another message from the client until a 
>>>>>>>>>>>>> response from the server is received for the transaction.  
>>>>>>>>>>>>> The client uses the Transaction ID value to match this 
>>>>>>>>>>>>> message with the response from the floor control server. 
>>>>>>>>>>>>> When using BFCP over an unreliable transport, it is 
>>>>>>>>>>>>> important to choose a Transaction ID value that lets the 
>>>>>>>>>>>>> receiver distinguish the reception of the next message in 
>>>>>>>>>>>>> a sequence of BFCP messages from a retransmission of a 
>>>>>>>>>>>>> previous message.  Therefore, BFCP entities using an 
>>>>>>>>>>>>> unreliable transport MUST use monotonically increasing Transaction ID values (except for wrap-around).
>>>>>>>>>>>>>
>>>>>>>>>>>>> [Question: is there a need to copy the Conference ID and 
>>>>>>>>>>>>> User ID, if present?]
>>>>>>>>>>>>>
>>>>>>>>>>>>> 8.2. Server Behavior
>>>>>>>>>>>>>
>>>>>>>>>>>>> client-initiated transaction MUST copy the Conference ID, 
>>>>>>>>>>>>> the Transaction ID, and the User ID from the request 
>>>>>>>>>>>>> received from the client into the response.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Server-initiated transactions MUST contain a Transaction 
>>>>>>>>>>>>> ID equal to
>>>>>>>>>>>>> unreliable transport, the Transaction ID shall have the 
>>>>>>>>>>>>> same properties as for client-initiated transactions. The 
>>>>>>>>>>>>> server uses the Transaction ID value to match this message 
>>>>>>>>>>>>> with the response from the floor participant or floor chair.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                            
>>>>>>>>>>>> Thanks, this is better.
>>>>>>>>>>>>
>>>>>>>>>>>>                          
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> SHOULD authenticate the floor control server before 
>>>>>>>>>>>>>> sending any BFCP message to it or accepting any BFCP message from it.
>>>>>>>>>>>>>> client before accepting any BFCP message from it or 
>>>>>>>>>>>>>> sending any BFCP message to it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> BFCP supports TLS/DTLS mutual authentication between 
>>>>>>>>>>>>>> clients and floor control servers, as specified in Section 9.1.
>>>>>>>>>>>>>> What are the cases where clients and servers do not need 
>>>>>>>>>>>>>> to be authenticating each other? I know this requirement 
>>>>>>>>>>>>>> and the other SHOULD-level requirements around use of 
>>>>>>>>>>>>>> TLS/DTLS are carried over from RFC 4582, but I¹m 
>>>>>>>>>>>>>> concerned that they aren¹t as strong as they should be. 
>>>>>>>>>>>>>> For a conference where the signaling traffic is 
>>>>>>>>>>>>>> authenticated and confidentiality and integrity 
>>>>>>>>>>>>>> protected, why is it ok for the floor control traffic not 
>>>>>>>>>>>>>> to be? Could these requirements be adjusted to require 
>>>>>>>>>>>>>> use of TLS/DTLS at least in cases where the signaling is also protected?
>>>>>>>>>>>>>>                              
>>>>>>>>>>>>> Yes, but again, this would be at the expense of adding a 
>>>>>>>>>>>>> non backward compatible change from rfc 4582. How about 
>>>>>>>>>>>>> saying TLS/DTLS MUST be used for BFCP in such cases, while 
>>>>>>>>>>>>> pointing out the rfc
>>>>>>>>>>>>> 4582
>>>>>>>>>>>>> based implementations may not comply (similar to what we 
>>>>>>>>>>>>> did with the version field).
>>>>>>>>>>>>>                            
>>>>>>>>>>>> Works for me.
>>>>>>>>>>>>
>>>>>>>>>>>>>> encryption² is not a sufficient minimum baseline, and if 
>>>>>>>>>>>>>> the requirements change in Section 7 they should be 
>>>>>>>>>>>>>> reflected here as well.
>>>>>>>>>>>>>>                              
>>>>>>>>>>>>> Yep.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                            
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ³The version field MUST be set to 1 when using BFCP over 
>>>>>>>>>>>>>> a reliable transport, i.e. as in [2].²
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Good catch. This is a carry over from before this draft 
>>>>>>>>>>>>> was adopted as a bis version of rfc4582.
>>>>>>>>>>>>>
>>>>>>>>>>>>>                            
>>>>>>>>>>>>>> "The version field MUST be set to 2 when using BFCP over 
>>>>>>>>>>>>>> an unreliable transport with the extensions specified in 
>>>>>>>>>>>>>> this document.²
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Error message with parameter value 12 (Unsupported 
>>>>>>>>>>>>>> Version) to indicate this.²
>>>>>>>>>>>>>>
>>>>>>>>>>>>> This should read ³non-interoperable implementations². 
>>>>>>>>>>>>> Earlier in that same sentence, ³BFCP over UDP were already 
>>>>>>>>>>>>> used² should read ³BFCP over UDP is already being used².
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Charles
>>>>>>>>>>>>>

---

From: Tom Kristensen <[email-masked]>
Date: Fri, 11 Sep 2015 13:42:21 +0200

Hmm, yes maybe an idea if it's fine proceeding with referring a 
work-in-progress draft here.
What if we keep the text and adds this as an additional reference in the 
two new text passages proposed by Charles: "... [13], and the 
clarifications defined in [draft-ietf-mmusic-dtls-sdp], ...".

Where [13] is a reference to RFC 5763.

Anyway, I'd still prefer to keep the text in 
draft-ietf-bfcpbis-rfc4583bis-12 and redirect the readers to the 
rfc5763bis, that eventually then will obsolete (or extend?) RFC 5763.

-- Tom

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Sep 2015 20:11:02 +0000

Hi,

>Hmm, yes maybe an idea if it's fine proceeding with referring a work-in-progress draft here.
>What if we keep the text and adds this as an additional reference in the two new text passages proposed by Charles: "... [13], and the clarifications defined in [draft-ietf-mmusic-dtls-sdp], ...".
>

My suggestion is to *only* refer the new dtls-sdp draft. Because, one of the ideas with the new draft is to also update RFC 5763 to reference the new dtls-sdp draft.

>draft-ietf-bfcpbis-rfc4583bis-12 and redirect the readers to the rfc5763bis, that eventually then will obsolete (or extend?) RFC 5763.

The new dtls-sdp draft will not become 5763bis (eventhough it MAY update some parts of 5763). It's a generic document, which *any* DTLS usage can then reference.

Regards,

Christer

On 09/11/2015 01:25 PM, Christer Holmberg wrote:
> Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo; 
> [email-masked]
>>>>> discussed in MMUSIC result from use of a single DTLS connection 
>>>>> for multiple RTP and/or SCTP streams. Those complications do not 
>>>>> exist with the BFCP usage, so I think it is sufficient to continue 
>>>>> to reference RFC 5763 and not use the SDP connection attribute.
>>>>>
>>>>>            
>>>> The complications do not result from use of a single DTLS 
>>>> connection for multiple streams - it mainly results from the usage 
>>>> of ICE. And, as far as I know, ICE can be used also for BFCP.
>>>>
>>>>> As far as the BFCP specifics are concerned, I am ok with the 
>>>>> latest version of the draft.
>>>>>
>>>>> For example, there has been a suggestion (by myself) to use the 
>>>>> SDP connection attribute to explicitly indicate that a new DTLS 
>>>>> This is related to the earlier issue. There is the discussion 
>>>>> about ICE "virtual connections", and that a single DTLS connection 
>>>>> would apply to all ICE candidates associated with an m- line. So, 
>>>>> even if a candidate changes (read: transport parameter changes), 
>>>>> it would not automatically trigger a new DTLS connection.
>>>>>
>>>>>
>>>>>>>> inspired by comments and suggested text provided by Christer. 
>>>>>>>> He is in the process of reviewing. If all goes well with that, 
>>>>>>>> we are ready to proceed with proto writeup (Mary) and AD review.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Charles
>>>>>>>>
>>>>>>>>>>>> couple  of days. If so, we could get it on the next 
>>>>>>>>>>>> telechat agenda (March 5).
>>>>>>>>>>>>
>>>>>>>>>>>> Alissa
>>>>>>>>>>>>
>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>                          
>>>>>>>>>>>>>>> questions and comments I¹d like to discuss before 
>>>>>>>>>>>>>>> issuing the IETF last call. I¹ve also included some 
>>>>>>>>>>>>>>> editorial nits that should be addressed together with 
>>>>>>>>>>>>>>> any last call comments.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Comments and questions:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> = Section 5.1 =
>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-08#se
>>>>>>>>>>>>>>> c
>>>>>>>>>>>>>>> tion
>>>>>>>>>>>>>>> -4)
>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                                
>>>>>>>>>>>>>> recommendation to adhere to the best practices it 
>>>>>>>>>>>>>> outlines in section 4?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                              
>>>>>>>>>>>>>>> = Sections 8, 8.1, 8.2 = It seems like the transaction 
>>>>>>>>>>>>>>> ID requirements regarding non-reuse/monotonically 
>>>>>>>>>>>>>>> increasing IDs are re-stated multiple times across these 
>>>>>>>>>>>>>>> three sections, in slightly different ways, to the point 
>>>>>>>>>>>>>>> where it¹s not clear exactly what they are. It seems 
>>>>>>>>>>>>>>> like they are:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> monotonically increasing (e.g., a lower, recently used 
>>>>>>>>>>>>>>> ID could be re-used once a response is
>>>>>>>>>>>>>>> received)
>>>>>>>>>>>>>> detail. As such, the transaction ID related information 
>>>>>>>>>>>>>> at the start of Section 8 is superfluous. I recommend 
>>>>>>>>>>>>>>      consist of a request from a floor control server to 
>>>>>>>>>>>>>> a client and a
>>>>>>>>>>>>>> retransmission timer T1 (see Section 8.3) MUST be used 
>>>>>>>>>>>>>> for all requests until the transaction is completed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The client MUST set the Transaction ID value in the 
>>>>>>>>>>>>>> common header to a number that is different from 0 and 
>>>>>>>>>>>>>> that MUST NOT be reused in another message from the 
>>>>>>>>>>>>>> client until a response from the server is received for the transaction.
>>>>>>>>>>>>>> unreliable transport MUST copy the Transaction ID from 
>>>>>>>>>>>>>> the request received from the server into the response.
>>>>>>>>>>>>>> server uses the Transaction ID value to match this 
>>>>>>>>>>>>>> message with the response from the floor participant or floor chair.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                              
>>>>>>>>>>>>> Thanks, this is better.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                            
>>>>>>>>>>>>>>> protected, why is it ok for the floor control traffic 
>>>>>>>>>>>>>>> not to be? Could these requirements be adjusted to 
>>>>>>>>>>>>>>> require use of TLS/DTLS at least in cases where the signaling is also protected?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                                
>>>>>>>>>>>>>> saying TLS/DTLS MUST be used for BFCP in such cases, 
>>>>>>>>>>>>>> while pointing out the rfc
>>>>>>>>>>>>>> 4582
>>>>>>>>>>>>> Feel free to make all of these changes and submit a rev 
>>>>>>>>>>>>> and I¹ll issue the IETF LC.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Alissa
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>                            
>>>>>>>>>>>>>>> = Section 14 =
>>>>>>>>>>>>>>> obsoleting in this sentence, especially since BFCP over 
>>>>>>>>>>>>>>> a reliable transport is completely specified in this bis 
>>>>>>>>>>>>>>> "situation where multiple different and 
>>>>>>>>>>>>>>> non-interoperable would
>>>>>>>>>>>>>>> co-
>>>>>>>>>>>>>>> exist in the market.²
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Earlier in that same sentence, ³BFCP over UDP were 
>>>>>>>>>>>>>> already used² should read ³BFCP over UDP is already being used².
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Charles
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 21 Sep 2015 16:25:59 +0000

Hi Christer,

The problem I see with this is that it is not just a matter of changing
the reference, it is also a matter of changing the normative behavior. For
DTLS with BFCP, we never required the use of the “connection” attribute.
If we are to start requiring it, we would need add text to describe how to
address backward compatibility in cases in which the connection attribute
is not specified. Are there plans for this within RFC 5763bis draft? If
so, Tom’s recommendation of continuing to point to RFC 5763 for now may be
the best approach. 

Cheers,
Charles

On 9/11/15, 1:11 PM, "Christer Holmberg" <[email-masked]>
wrote:

>My suggestion is to *only* refer the new dtls-sdp draft. Because, one of
>the ideas with the new draft is to also update RFC 5763 to reference the
>new dtls-sdp draft.
>
>The new dtls-sdp draft will not become 5763bis (eventhough it MAY update
>some parts of 5763). It's a generic document, which *any* DTLS usage can
>then reference.
>
>Regards,
>
>Christer
>
>
>
>> My suggestion would actually be to refer to the new
>>draft-ietf-mmusic-dtls-sdp, which is going to clarify the DTLS-SRTP
>>rules regarding when a new DTLS association must be established.
>>
>> Regards,
>>
>> Christer
>>
>>>>>>>>>>>>>>> unreliable transport MUST use monotonically increasing
>>>>>>>>>>>>>>>Transaction ID values (except for wrap-around).
>>>>>>>>>>>>>>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Sep 2015 16:32:41 +0000

Hi Charles,

>The problem I see with this is that it is not just a matter of changing the reference, it is also a matter of changing the normative behavior. For DTLS with BFCP, we never required the use of the >“connection” attribute.
>If we are to start requiring it, we would need add text to describe how to address backward compatibility in cases in which the connection attribute is not specified. 

The intention is to cover backward compatibility in the draft.

>Are there plans for this within RFC 5763bis draft? If so, Tom’s recommendation of continuing to point to RFC 5763 for now may be the best approach.

I am not familiar with the 5763bis draft. But, even if the DTLS-SDP draft makes updates to 5763, it won't become a 5763bis draft.

Regards,

Christer

On 9/11/15, 1:11 PM, "Christer Holmberg" <[email-masked]>
wrote:

>>What if we keep the text and adds this as an additional reference in 
>>the two new text passages proposed by Charles: "... [13], and the 
>My suggestion is to *only* refer the new dtls-sdp draft. Because, one 
>of the ideas with the new draft is to also update RFC 5763 to reference 
>the new dtls-sdp draft.
>
>The new dtls-sdp draft will not become 5763bis (eventhough it MAY 
>update some parts of 5763). It's a generic document, which *any* DTLS 
>usage can then reference.
>
>Regards,
>
>Christer
>
>
>
>> Pointing to the DTLS-SRTP (and by that any updates of it) is a 
>>simple, safe and straigt-forward solution.
>>
>> The only change in the new version of rfc4583bis just submitted. And 
>>as Charles says, this should be the last missing fix for this draft 
>>until next stages in the process at least.
>>
>> -- Tom
>>
>>> I think this is the only outstanding item with respect to the 
>>>current  version of the draft. Unless anyone has an issue with the 
>>>proposed  resolution, I request we update the draft accordingly and 
>>>then use it  as the basis for Mary, the document shepherd, to provide 
>>>a proto writeup.
>>>
>>> Cheers,
>>> Charles
>>>
>>>
>>>> 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 of [13] MUST be followed when using DTLS.
>>>>>> exist with the BFCP usage, so I think it is sufficient to 
>>>>>> continue to reference RFC 5763 and not use the SDP connection attribute.
>>>>>>
>>>>>>            
>>>>>> about ICE "virtual connections", and that a single DTLS 
>>>>>> connection would apply to all ICE candidates associated with an 
>>>>>> m- line. So, even if a candidate changes (read: transport 
>>>>>> parameter changes), it would not automatically trigger a new DTLS connection.
>>>>>>
>>>>>>
>>>>>>>>>>>> updates are pretty minimal  and are all basically written 
>>>>>>>>>>>> up in Charles¹ response to my AD review.
>>>>>>>>>>>>
>>>>>>>>>>>> Alissa
>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Overall the document appears in good shape. I have a 
>>>>>>>>>>>>>>>> few questions and comments I¹d like to discuss before 
>>>>>>>>>>>>>>>> Implementations that do not get upgraded to be 
>>>>>>>>>>>>>>>> compliant with  4582bis (which could certainly account 
>>>>>>>>>>>>>>>> for some of those that  will not support version 2) 
>>>>>>>>>>>>>>>> will therefore never send the  error specified here. 
>>>>>>>>>>>>>>>> This seems like it should at least be  noted given the 
>>>>>>>>>>>>>>>> MUST-level requirement. The same applies in  Section 13.7.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>> Good point. I believe we made this a MUST because we 
>>>>>>>>>>>>>>> were thinking in terms of implementations compliant with 
>>>>>>>>>>>>>>> this bis version.
>>>>>>>>>>>>>>> Adding
>>>>>>>>>>>>>> backwards compatibility and SHOULD support the ones 
>>>>>>>>>>>>>> listed in the UTA drafts would be ok.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>>> increasing IDs are re-stated multiple times across 
>>>>>>>>>>>>>>>> these three sections, in slightly different ways, to 
>>>>>>>>>>>>>>>> the point where it¹s not clear exactly what they are. 
>>>>>>>>>>>>>>>> It seems like they are:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> (3) Reliable transport, client-initiated transaction: 
>>>>>>>>>>>>>>>> ID MUST NOT be 0 and MUST NOT be reused in another 
>>>>>>>>>>>>>>>> message from the client until a response from the 
>>>>>>>>>>>>>>>> server is received for the transaction, but need not be 
>>>>>>>>>>>>>>>> Is (3) the correct interpretation of the text in 8.1? 
>>>>>>>>>>>>>>>> If so, why not just require IDs in all client-initiated 
>>>>>>>>>>>>>>> Client-initiated transactions consist of a request from 
>>>>>>>>>>>>>>> a client to a floor control server and a response from 
>>>>>>>>>>>>>>> the floor control server to the client.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>      When using an unreliable transport, 
>>>>>>>>>>>>>>> server-initiated transactions
>>>>>>>>>>>>>>> Then in section 8.1, we add the important details 
>>>>>>>>>>>>>>> removed from section 8.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 8.1.1 Client Behavior
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A client starting a client-initiated transaction MUST 
>>>>>>>>>>>>>>> set the Conference ID in the common header of the 
>>>>>>>>>>>>>>> message to the Conference ID for the conference that the 
>>>>>>>>>>>>>>> client obtained previously.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> A client receiving a server-initiated transaction over 
>>>>>>>>>>>>>>> an unreliable transport MUST copy the Transaction ID 
>>>>>>>>>>>>>>> from the request received from the server into the response.
>>>>>>>>>>>>>>> client-initiated transaction MUST copy the Conference 
>>>>>>>>>>>>>>> ID, the Transaction ID, and the User ID from the request 
>>>>>>>>>>>>>>>> = Section 9 (impacts Section 14 as well) = "BFCP 
>>>>>>>>>>>>>>>>clients  SHOULD authenticate the floor control server 
>>>>>>>>>>>>>>>>before  sending any BFCP message to it or accepting any 
>>>>>>>>>>>>>>>>BFCP message from it.
>>>>>>>>>>>>>>>> What are the cases where clients and servers do not 
>>>>>>>>>>>>>>>>need  to be authenticating each other? I know this 
>>>>>>>>>>>>>>>>requirement  and the other SHOULD-level requirements 
>>>>>>>>>>>>>>>>around use of  TLS/DTLS are carried over from RFC 4582, 
>>>>>>>>>>>>>>>>but I¹m  concerned that they aren¹t as strong as they should be.
>>>>>>>>>>>>>>>> encryption² is not a sufficient minimum baseline, and 
>>>>>>>>>>>>>>>> if the requirements change in Section 7 they should be 
>>>>>>>>>>>>>>>> reflected here as well.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>> Yep.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>>> ³The version field MUST be set to 1 when using BFCP 
>>>>>>>>>>>>>>>> over a reliable transport, i.e. as in [2].²
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> a reliable transport is completely specified in this 
>>>>>>>>>>>>>>>> bis document. I would suggest dropping the i.e. clause.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>> "The version field MUST be set to 2 when using BFCP 
>>>>>>>>>>>>>>>> over an unreliable transport with the extensions 
>>>>>>>>>>>>>>>> specified in this document.²
>>>>>>>>>>>>>>>>