Subject: [bfcpbis] TSVDIR LC review: <draft-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary Floor Control Protocol (BFCP)) to Proposed Standard>

From: Allison Mankin <[email-masked]>
Date: Mon, 2 Mar 2015 12:06:13 -0500

[Put into template form and forwarded for the TSVDIR reviewer, Gorry
Fairhurst, to expedite while he is traveling]

Please resolve these comments along with any other Last Call comments you
may receive.

Document:  draft-ietf-6man-resilient-rs-04.txt
Reviewer: Gorry Fairhurst
Review Date: 2015-03-01
IETF LC End Date: 2015-03-05
IESG Telechat date: ---

Summary: This draft is not ready for publication as a standards track RFC.

This document defines a control protocol that may be used over TCP or UDP.
The major change between this document and its predecessor RFC4528 is
stated to be:

   Main purpose of this work was to revise the specification to support
   BFCP over an unreliable transport (Section 16.1)

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 RFC 5405 as normative (rather than informational) may be
good, and some of the guidance from this BCP suggests protocol issues that
should be examined and justified or amended. Notable concerns are the lack
of
support for RTT estimation, and the way in which fragmentation is handled.

There is mention of potential support for SCTP, however the statement on
SCTP appears to need updating.

The intro states:
"BFCP has been designed so that it can be used in low-
bandwidth environments" - there are specific low-bandwidth
concerns when UDP is used. See below.

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? Note 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.

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?

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 4 Mar 2015 00:58:05 +0000

Forwarding to list because I do not believe it made it through originally.
Note, the document name in the email text should have read draft-ietf-bfcpbis-rfc4582bis-13.txt, not draft-ietf-6man-resilient-rs-04.txt

Cheers,
Charles

From: Allison Mankin <[email-masked]<mailto:[email-masked]>>
Date: Monday, March 2, 2015 at 11:06 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Transport Directorate <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: TSVDIR LC review: <draft-ietf-bfcpbis-rfc4582bis-13.txt> (The Binary Floor Control Protocol (BFCP)) to Proposed Standard>

[Put into template form and forwarded for the TSVDIR reviewer, Gorry Fairhurst, to expedite while he is traveling]

Please resolve these comments along with any other Last Call comments you may receive.

This document defines a control protocol that may be used over TCP or UDP.
The major change between this document and its predecessor RFC4528 is stated to be:

should be examined and justified or amended. Notable concerns are the lack of

The intro states:

Section 5: Protocol:

Section 5:

Primitive
- Please specify here what a receiver should do with an undefined primitive value!

Payload Length:

Conference ID:

Fragment Length:

Section 6.1: CC:
"if a TCP

Section 6.2.2:

Section 6.2.2:

Section 6.2.3:

Congestion Control:

B.1.1.6.  SCTP