[bfcpbis] Eric Rescorla's Discuss on draft-ietf-bfcpbis-rfc4583bis-26: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-bfcpbis-rfc4583bis-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4457



DETAIL
S 9.
>      transport is used for the default candidate, then the 'm' line proto
>      value MUST be 'UDP/TLS/BFCP'.  If TCP transport is used for the
>      default candidate, the 'm' line proto value MUST be 'TCP/DTLS/BFCP'.
>   
>         Note: Usage of ICE with protocols other than UDP/TLS/BFCP and
>         TCP/DTLS/BFCP is outside of scope for this specification.

this is very different from any other use of ICE, and I'm not sure
it's interoperable, unless you require that only TCP or only UDP
candidates be offered (which you do not seem to). The reason is that
with ICE you can flip between different candidates as part of the
negotiation. So what happens if I initially get a UDP candidate and
then via aggressive nomination settle on TCP (or vice versa). DTLS and
TLS aren't really interoperable in that way. It would be far better to
do what WebRTC does and when you do ICE, always do DTLS even if it's
over TCP.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 5.3.
>      The SDP Offer/Answer procedures for the 'confid' attribute are
>      defined in Section 10.
>   
>   5.3.  SDP 'userid' Attribute
>   
>      This section defines the SDP userid' media-level attribute.  The

Are there any security considerations around this attribute?


S 5.5.
>      'bfcpver' attribute in offers and answers.  The attribute value, if
>      present, MUST be in accordance with the definition of the Version
>      field in [I-D.ietf-bfcpbis-rfc4582bis].  If the attribute is not
>      present, endpoints MUST assume a default value in accordance with
>      [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport
>      the default attribute value is "1", and when used over an unreliable

Just for clarity: UDP over TURN-TCP is an unreliable transport, right?


S 7.1.
>      deliver a BFCP message and times out, the endpoint that attempted to
>      send the message (i.e., the one that detected the TCP timeout) MUST
>      send an offer in order to re-establish the TCP connection.
>   
>      Endpoints that use the offer/answer mechanism to negotiate TCP
>      connections MUST support the 'setup' and 'connection' attributes.

You probably need a reference here.


S 10.1.
>   
>      o  MUST associate an SDP 'floorid' attribute (Section 5.4) with the
>         'm' line; and
>   
>      o  MUST associate an SDP 'label' attribute ([RFC4574]) with the 'm'
>         line of each BFCP-controlled media stream.

We managed to mostly purge "associate" from BUNDLE. Can we do it here
too?


S 10.2.
>      o  MUST insert a corresponding 'm' line in the answer, with an
>         identical 'm' line proto value [RFC3264]; and
>   
>      o  MUST associate a 'bfcpver' attribute with the 'm' line.  The
>         answerer only indicates support of BFCP versions also supported by
>         the offerer; and

Is this an odd way of saying you must subset what the offer contained?