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

[Christer Holmberg <[e-mail]>]

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:[e-mail]]
>Sent: 8. huhtikuuta 2015 3:07
>To: Charles Eckel (eckelcu)
>Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist); 
>[e-mail]; 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) 
><[e-mail]>
>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" <[e-mail]> 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) 
>>> <[e-mail]>
>>> 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" <[e-mail]> 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 
>>>>> <[e-mail]> 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 
>>>>>>> <[e-mail] 
>>>>>>> <mailto:[e-mail]>>
>>>>>>> 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 <[e-mail] 
>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>> *Subject: **Re: [bfcpbis] AD evaluation:
>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12*
>>>>>>>>> *Date: *February 9, 2015 at 3:58:52 PM PST
>>>>>>>>> *To: *"Charles Eckel (eckelcu)" <[e-mail] 
>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>> *Cc: *"[e-mail] <mailto:[e-mail]>"
>>>>>>>>> <[e-mail]
>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>> 
>>>>>>>>> Hi Charles,
>>>>>>>>> 
>>>>>>>>> Thanks, some responses inline.
>>>>>>>>> 
>>>>>>>>> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) 
>>>>>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>>> 
>>>>>>>>>> HI Alissa,
>>>>>>>>>> 
>>>>>>>>>> Thank you for the review. Please see my thoughts on your 
>>>>>>>>>> comments and questions inline.
>>>>>>>>>> 
>>>>>>>>>> From: Alissa Cooper <[e-mail] 
>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM
>>>>>>>>>> To: "[e-mail] <mailto:[e-mail]>"
>>>>>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>>>>>> 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
>>>>>>>>> [e-mail] <mailto:[e-mail]> 
>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>