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

["Charles Eckel (eckelcu)" <[e-mail]>]

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

Cheers,
Charles (as an individual)


On 4/15/15, 12:29 AM, "Christer Holmberg" <[e-mail]>
wrote:

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