[bfcpbis] Comments on draft-ietf-bfcpbis-rfc4582bis-06

[Gonzalo Camarillo <[e-mail]>]

Folks,

here you have some comments on the following draft:

http://tools.ietf.org/html/draft-ietf-bfcpbis-rfc4582bis-06

Cheers,

Gonzalo


Comments on draft-ietf-bfcpbis-rfc4582bis-06

In the whole document: when referring to a reliable or to an unreliable
transport, the indefinite article (i.e., "a" or "an") needs to be
used. For example:

OLD:

When communicating over unreliable transport...

NEW:

When communicating over an unreliable transport...


Abstract:

OLD:

Changes from RFC 4582 are summarized in section 16.

NEW:

Changes from RFC 4582 are summarized in Section 16.

Sections 3.1 and 3.3

The document needs to reference the XCON documents (which were
published after RFC 4582) that deal with floor creation, termination,
and floor-resource association (e.g., RFC 6503). Roberta wrote the
following text. You can use it as a base, edit it as you wish, and add
a paragraph to each of the sections (3.1 and 3.3).

"As to the XCON framework, floor settings such as floor identifiers,
associated resources, moderator identifier, etc., are held in the
<floor-information> section of conference objects. Conference control
clients using CCMP (RFC 6505) can specify such floor-related settings
by editing the floor-information section of the to-be created
conference object provided in the body of a CCMP confRequest/create
message issued to the conference control server. According to the
conferencing system policies, conference control clients can modify
the floor settings of a conference by issuing CCMP confRequest/update
messages providing the specific updates to the <floor-information>
section of the target conference object. More information about CCMP
and BFCP interaction can be found in RFC6504."


Section 3.2:

Add a reference to RFC 5018.


Section 4:

OLD:

There are two types of transactions in BFCP: client-initiated
transactions and server-initiated transactions (notifications),
further details in Section 8.

NEW:

There are two types of transactions in BFCP: client-initiated
transactions and server-initiated transactions
(notifications). Section 8 describes both types of transactions in
detail.



Section 4.1:

OLD:

Figures 2 and 3 below show call flows for two sample BFCP interactions
when used over reliable transport.  Appendix A shows the same sample
interactions but over an unreliable transport.

NEW:

Figures 2 and 3 below show examples of call flows where BFCP is used
over a reliable transport.  Appendix A shows the same call flow
examples using an unreliable transport instead.


Sections 5.3.14 and 5.3.15 talk about acknowledging a "subsequent"
message. Why is it a subsequent message? Maybe we can delete that
word.


Section 5.3.14.

OLD:

FloorRequestStatus message from the floor control server by sending an
FloorRequestStatusAck.

NEW:

FloorRequestStatus message from the floor control server by sending a
FloorRequestStatusAck message.


Do a similar fix to the above across the document so that it is
consistent. For example, the same issue appears in Sections 5.3.15 and
5.3.16.


Section 6 says:

"(e.g., using an SDP offer/answer exchange [7])"

We should also add a reference to RFC 5018. Additionally, the document
could discuss at some point what happens when the mechanism in RFC
5018 is used.


Section 6:

OLD:

TCP, appropriate where entities can be sure that their connectivity is
not impeded by NAT devices, media relays or firewalls;

NEW:

TCP, appropriate where connectivity is not impeded by network elements
such as NAT devices or media relays;

Section 6.1

OLD:

Consequently, message framing is implemented in the application
layer.

NEW:

Consequently, message framing needs to be implemented in the
application layer.

Section 6.2

OLD:

To avoid BFCP messages being fragmented at the IP layer, in the event
the size of a BFCP message exceeds the MTU size, the fragmentation
will be handled by the BFCP protocol.

NEW:

To keep large BFCP messages from being fragmented at the IP layer, the
fragmentation of BFCP messages that exceeding the MTU size is
performed at the BFCP level.


OLD:

The message format for exchange of BFCP in UDP datagrams is the same
as for a TCP stream above.

NEW:

The message format for BFCP messages is the same regardless of whether
the messages are sent in UDP datagrams or over a TCP stream.


In the following paragraph, I have removed the MUST because the floor
control server could respond with, for example, an error message
instead.

OLD:

Clients MUST announce their presence to the floor control server by
transmission of a Hello message.  This Hello message MUST be responded
to with a HelloAck message and only upon receipt of HelloAck can the
client consider the floor control service as present and available.

NEW:

Clients MUST announce their presence to the floor control server by
sending a Hello message. The floor control server responds to the
Hello message with a HelloAck message. The client considers the floor
control service as present and available only upon receiving the
HelloAck message.


The following paragraph (the second sentence in particular) needs to
be clarified. The paragraph starts talking about a floor control
server receiving a message and then talks about a client discarding
the message. Also, why would an entity discard a message only to
receive a retransmission of the *same* message later? It is not clear
what the paragraph means.

"If a Floor Control Server receives data that cannot be parsed, the
receiving server SHOULD send an Error message with parameter value 10
(Unable to parse message) indicating receipt of a malformed message.
If the message can be parsed to the extent that it is able to discern
that it was a response to an outstanding request transaction, the
client MAY discard the message as the client will retransmit the
message when the retransmit timer T1 specified in Section 8.3.1
fires."


The document says: " Transaction ID values are non-sequential and
entities are at liberty to select values at random."

The document needs to make it clear what is the requirement and the
level of randomness required. For example, what happens if the same
transaction ID is reused and a retransmission of the message that
first used that transaction ID arrives?


What is a "delinquent" response?


Section 6.2.2 deals with ICMP errors for UDP. We should also specify
how to handle ICMP errors for TCP, for consistency.

Also in Section 6.2.2, the following sentences talk about a
"conversation" and a "connection" in the context of UDP. What do those
terms mean?

"The entity MAY attempt to re-establish the conversation afresh.  The
new connection will appear as a wholly new floor participant, chair or
floor control server with all state previously held about that
participant lost."


Section 6.2.2 also says:

"Note: This is because the peer entities cannot rely on IP and port
tuple to uniquely identify the participant, nor would extending Hello
to include an attribute that advertised what the entity previously was
assigned as a User ID be acceptable due to session hijacking."

This paragraph in unclear as well... it needs to be clarified together
with the previous one so that both are easier to understand.


Also in Section 6.2.2, per one of my comments above, remove the
reference to firewalls. In general, remove references to firewalls
across the document (e.g., they also appear in Appendix A).

Section 6.2.3 says: "The size of a BFCP message is limited by the
16-bit Payload Length field of the COMMON-HEADER." This is applicable
to BFCP messages in general whether they are sent over TCP or
UDP. However, Section 6.2.3 is under Section 6.2, which deals with
unreliable transports. The document needs to make it clear that this
is also applicable to TCP. Also, what is the implication of that
limit? What happens if a message would need to be larger than that?
What does the floor control server do in that case?


Also in Section 6.2.3:

"When using UDP, a single BFCP message may be fragmented at the IP
layer if its overall size exceeds the MTU threshold of the network."

Use "path MTU" instead of "MTU threshold". Also, the sentence should
be clear that we are simply talking hypothetically, since BFCP
entities will not send such large messages; they will fragment them
instead following the steps that are described right after that
sentence.


Across the document, always use "path MTU". Not "MTU" on any other
term.


Also in Section 6.2.3:

"When transmitting a BFCP message with size greater than the MTU, the
sender should fragment the message into a series of N contiguous data
ranges."

We need to add a normative word. A MUST probably.


Where does the document talk about path MTU discovery? How do BFCP
entities discover what is the path MTU?


Also in Section 6.2.3:

"When a BFCP implementation receives a BFCP message fragment, it MUST
buffer the fragment until it has received the entire BFCP message."

When dealing with fragmentation and especially with the buffering of
unauthenticated fragments one always thinks about DoS attacks. Could a
client perform a resource attack on a server by using this
fragmentation mechanism?  We should probably discuss this somewhere in
the document, explaining that the time this state is kept is limited
by a timer and what role DTLS plays into this.


Also in Section 6.2.3:

"The receiver MUST then retransmit the ACK.  The receiver can discard
an incomplete buffer utilizing the Response Retransmission Timer,
starting the timer after the receipt of the first fragment."

The first sentence should not contain a normative statement, since
sending an ACK on receiving a message is specified somewhere
else. Also, the term "ACK" has not been defined in the document. It
should if we want to use it in this section.

The second sentence should have a normative statement.


Section 6.2.3 needs to briefly discuss (at the beginning of the
section) that BFCP acknowledges the reception of whole messages, not
of fragments. That is why the loss of a fragment implies the
retransmission of the whole message. The document can talk about how
inefficient that is and why we have decided to do it anyway (e.g.,
for simplicity reasons).


Section 6.2.3 needs to talk about the interactions of using DTLS and
fragmentation.


Section 6.2.4 talks (in a couple of places) about BFCP over UDP
entities. However, the rest of the document talks about entities using
unreliable transports. The terminology needs to be consistent.


Section 8:

"Server-initiated transactions consist of a single message from a
floor control server to a client.  Since they do not trigger any
response, their Transaction ID is set to 0 when used over reliable
transports, but must be non-zero and unique in the context of
outstanding transactions over unreliable transports."

This paragraph needs to be rephrased so that it is clear how this
works for TCP and for UDP. For example, with UDP the transaction will
not be a single message.


Also in Section 8:

"When using BFCP over unreliable transports, all requests will use
retransmit timer T1 (see Section 8.3) until the transaction is
completed."

Use "retransmission timer" instead.


Section 8.1

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

See my comment above about reusing transaction ID values and the risk
of receiving retransmissions of the original message.

Section 8.3.1

We probably want to remove the following statement:

"Alternatively, they MAY continue without BFCP and therefore not be
participant in any floor control actions."


Section 8.3.2

"T2 shall be set such that it encompasses all legal retransmissions
per T1 plus a factor to accommodate network latency between BFCP
entities."

This sentence probably belongs to Section 8.3.3, together with a
discussion on the default value that has been chosen for T2. Note that
whole Section 8.3.3 contains such a discussion for T1, it does not
contain one for T2.