Subject: [Tsv-art] Fwd: Fwd: TSV Triage - Review needed for Last Call: <draft-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary Floor Control Protocol (BFCP)) to Proposed Standard

From: Allison Mankin <[email-masked]>
Date: Sun, 1 Mar 2015 19:16:05 -0500

Thank you so much. The template doesn't matter so best if you send the
review to ietf
On Mar 1, 2015 4:57 PM, <[email-masked]> wrote:

> Hi Allison,
>
> I've read this - I'm travelling so I didn't have a chance to put this into
> a template, but hope the review is useful. Feel free to edit or adapt,
>
> Gorry
>
> ----
>
> This document defines a control protocol that may be used over TCP or UDP.
> There is mention of potential support for SCTP - although the statement on
> SCTP appears to need updating.
>
> The use of UDP raises a number of issues that need to be considered when
> used in environments that may experience congestion, long delay, or
> limited capacity. Further work appears to be needed to address these
> concerns. Citing RFC5405 as normative (rather than informational) may be
> good, but some of the guidance from this BCP suggests protocol issues that
> should be examined and justified or amended. Notable is the lack of
> support for RTT estimation, and the way in which fragmentation is handled.
>
> The intro states:
> "BFCP has been designed so that it can be used in low-
> bandwidth environments"
> - however there are concerns when UDP is used. See below.
>
> Section 3.2: Encoding?
> "This data includes the transport address
> of the server, the conference identifier, and a user identifier."
> - This suggests the numerical address is encoded in the exchange, i.e. a
> numerical IPv4 or IPv6 address, given that these messages may be exchanged
> via NAPT or other middleboxes. Should it say the identity be exchanged in
> the form of a DNS NAME?
>
> Section 3.4: Congestion Control
> I do not understand how congestion-control is performed on the media flow.
> Is it the responsibility of each audio stream to independently react to
> congestion? If it is, it would be useful to state this here.
>
> Section 5: Protocol:
> "If a floor control server receives a
> message with an unsupported version field value, and the extensions
> in this document is supported, the receiving server MUST send an
> Error message with parameter value 12 (Unsupported Version) to
> indicate this. "
> - What happens in the case where the receiving server does not support the
> extensions in this document? Does it silently discard?
>
> Section 5:
>
> What is the security model when TLS/DTLS is not used? - has the protocol
> protection from off-path attacks, and how is this provided?
>
> What is the privacy model when TLS/DTLS is not used?  - Does the protocol
> expose the identity of participants to others on the network?
>
> "Res: At this point, the 3 bits"
> - This may be better written as perhaps: Res: In version 1 and 2 of the
> protocol, the 3 bits".
>
> Primitive
> - Please specify here what a receiver should do with an undefined
> primitive value!
>
> Payload Length:
> - What happens when using a datagram format if the datagram length (e.g.
> UDP-Length) is less or more than the value specified within the BFCP?
>
> Conference ID:
> - Is the Conference ID randomised to provide protection to mitigate the
> chance of off-path data insertion attacks? Norte that in section 6.2.4,
> symmetric port numbers (src,dst) are recommended, and hence the a random
> ephemeral port does not offer protection from off-path attacks in the case
> where TLS/DTLS is not used.
>
> Fragment Length:
> - What happens if the datagram length (e.g. UDP-Length) is less or more
> than the value specified within the BFCP?
>
> Section 6.1: CC:
> "if a TCP
> connection cannot deliver a BFCP message and times out or receives an
> ICMP port unreachable message mid-connection, the TCP connection
> SHOULD be reestablished."
> - I think this needs more specification. How many times will the TCP
> connection be retried in succession? While it seems OK for a session to be
> restarted because of a delivery failure, this seems like a
> congestion-control problem if it is unconditionally resumed with no
> control of the number of attempts, and no requirement to back-off after
> repeated failures.
>
> Section 6.2.1: Retransmission interval:
> "The default initial interval MUST be set to 500ms "
> - The protocol appears to fail systematically  when the actual path RTT is
> greater than 500ms. The sender needs not only to expand the timer each
> retransmission, but needs to avoid the possibility that every message is
> duplicated when the path RTT is greater than 500mS. A simple solution is
> for the sender learn the actual RTT and increase the default timer when
> this is greater than 500 mS? This seems like a protocol flaw. See RFC 5405
> on the need to back-off timers, based on RTT.
>
> Section 6.2.2:
> How does the receiving endpoint verify that the ICMP message was from the
> corresponding endpoint, is there any field in the protocol header that
> could be used to reduce the chance of off-path attacks?
>
> Section 6.2.2:
> This section could usefully also refer to RFC 5405.
>
> Section 6.2.3:
> "BFCP entities should consider the MTU size"
> - This isn't capitalised as "SHOULD", was that intended? I'm unclear what
> the intention is here, especially when discussing PMTU-D.
>
> "and MAY run MTU discovery, such as [20][21][22], for this purpose."
> - Presumably this is "Path" MTU Discovery.
> - The ID does not explain how this is done. Could it be done using dummy
> messages (e.g. padded out with unused options?) or some other method to
> probe the path? The current text simply does not explain how PMTUD  or
> PLPMTUD is implemented, It needs to specify how to generate a "big" packet
> and how to handle retransmission.
>
> Congestion Control:
> The protocol appears to say it sends a single datagram per RTT, but
> actually fragmentation may result in multiple fragments per RTT. This
> amplifies the congestion control risk. There appears to be no limit set to
> the number of fragments that may be created, and each are presumably sent
> as a burst - and all retransmitted if there is a single loss. This could
> introduce a significant risk of congestion collapse, if this happens for
> multiple consecutive messages.
>
> Timers T1 and T2 are set to a static value by configuration. While the
> values suggested may be reasonable default minimum values, these two
> values should be increased when a path has a larger RTT to avoid the
> protocol replicating all data (see RFC 5405). The current specification
> can increase congestion for long RTT paths, and needs to be updated to
> reflect paths discovered to have a larger RTT.
>
> Section 9:
> "BFCP clients SHOULD authenticate the floor control server before sending
> any BFCP message"
> - The use of SHOULD implies there could be reasonable cases where this is
> not the case, what are these cases? Why is this not a MUST? It seems to
> conflict a little with the SHOULD use DTLS/TLS that is stated later? I am
> unsure of the intended security functions requirements.
>
> B.1.1.6.  SCTP
> "It would be quite straight forward to specify a BFCP binding for SCTP
> [28], and then tunnel SCTP over UDP in the use case described in
> Appendix B.1.  SCTP is gaining some momentum currently.  There is ongoing
> discussion in the RTCWeb WG regarding this approach. However, this
> approach for tunneling over UDP was not mature enough  when considered and
> not even fully specified."
> - it seems this dismisses SCTP support, yet this text appears out of date
> and needs  to be updated to reflect RFC 6951, and possibly
> https://tools.ietf.org/html/draft-ietf-tsvwg-dtls-for-sctp?
>
> ----
>
>
> > Hi, Gorry,
> >
> >
> > I hope you are very well :-)
> >
> > Would you consider writing this TSV-DIR LC review, due on or before 3/5?
> > I
> > think it's quite up your alley, especially as I notice that they have not
> > referenced RFC 5405 / BCP 145!
> >
> > I am not sure the ADs let the directorate know that Wes and I have taken
> > up
> > duty as hunters of reviews for them...
> >
> > See you in Dallas, I hope,
> >
> > Allison and Wes
> >
> >
> > ---------- Forwarded message ----------
> > From: Allison Mankin <[email-masked]>
> > Date: 23 February 2015 at 12:41
> > Subject: TSV Triage - Review needed for Last Call:
> > <draft-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary Floor Control Protocol
> > (BFCP)) to Proposed Standard
> > To: Transport Directorate <[email-masked]>, [email-masked]
> >
> >
> >
> > This draft is a bis of RFC 4582.  The primary change is to add capability
> > for the protocol to run over unreliable transport.  This should have a
> TSV
> > review before the Last Call is over on March 5.  Who would like to take
> > this review for our ADs?
> >
> >
> > Wes Eddy and Allison Mankin
> > TSV Triage Team
> >
> >
> > ---------- Forwarded message ----------
> > From: The IESG <[email-masked]>
> > Date: 19 February 2015 at 12:42
> > Subject: Last Call: <draft-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary
> > Floor Control Protocol (BFCP)) to Proposed Standard
> > To: IETF-Announce <[email-masked]>
> > Cc: [email-masked]
> >
> >
> >
> > The IESG has received a request from the Binary Floor Control Protocol
> > Bis  WG (bfcpbis) to consider the following document:
> > - 'The Binary Floor Control Protocol (BFCP)'
> >   <draft-ietf-bfcpbis-rfc4582bis-13.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action. Please send substantive comments to the
> > [email-masked] mailing lists by 2015-03-05. Exceptionally, comments may
> be
> > sent to [email-masked] instead. In either case, please retain the
> > beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >    Floor control is a means to manage joint or exclusive access to
> >    shared resources in a (multiparty) conferencing environment.
> >    Thereby, floor control complements other functions -- such as
> >    conference and media session setup, conference policy manipulation,
> >    and media control -- that are realized by other protocols.
> >
> >    This document specifies the Binary Floor Control Protocol (BFCP).
> >    BFCP is used between floor participants and floor control servers,
> >    and between floor chairs (i.e., moderators) and floor control
> >    servers.
> >
> >    This document obsoletes RFC 4582.  Changes from RFC 4582 are
> >    summarized in Section 16.
> >
> >
> >
> >
> > The file can be obtained via
> > http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/
> >
> > IESG discussion can be tracked via
> > http://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4582bis/ballot/
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
>
>
>

---

From: Allison Mankin <[email-masked]>
Date: Sun, 1 Mar 2015 19:17:04 -0500

Oops, forwarded my draft to Gorry rather than the review without the note
at the top.

Anyway, one more for the ADs.