Re: [bfcpbis] AD evaluation: draft-ietf-bfcpbis-rfc4582bis-12

[Alissa Cooper <[e-mail]>]

Hi Charles,

Thanks, some responses inline.

On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) <[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]>
> Date: Thursday, January 29, 2015 at 10:19 PM
> To: "[e-mail]" <[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