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

[Alissa Cooper <[e-mail]>]

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.


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


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


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


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


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.

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