draft-ietf-bfcpbis-rfc4582bis-13.txt   draft-ietf-bfcpbis-rfc4582bis-14.txt 
BFCPbis Working Group G. Camarillo BFCPbis Working Group G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Obsoletes: 4582 (if approved) K. Drage Obsoletes: 4582 (if approved) K. Drage
Intended status: Standards Track Alcatel-Lucent Intended status: Standards Track Alcatel-Lucent
Expires: August 23, 2015 T. Kristensen Expires: March 24, 2016 T. Kristensen
Cisco Cisco
J. Ott J. Ott
Aalto University Aalto University
C. Eckel C. Eckel
Cisco Cisco
February 19, 2015 September 21, 2015
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4582bis-13 draft-ietf-bfcpbis-rfc4582bis-14
Abstract Abstract
Floor control is a means to manage joint or exclusive access to Floor control is a means to manage joint or exclusive access to
shared resources in a (multiparty) conferencing environment. shared resources in a (multiparty) conferencing environment.
Thereby, floor control complements other functions -- such as Thereby, floor control complements other functions -- such as
conference and media session setup, conference policy manipulation, conference and media session setup, conference policy manipulation,
and media control -- that are realized by other protocols. and media control -- that are realized by other protocols.
This document specifies the Binary Floor Control Protocol (BFCP). This document specifies the Binary Floor Control Protocol (BFCP).
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 23, 2015. This Internet-Draft will expire on March 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 17, line 27 skipping to change at page 17, line 27
Figure 5: COMMON-HEADER format Figure 5: COMMON-HEADER format
Ver: This 3-bit field defines the version of BFCP that this message Ver: This 3-bit field defines the version of BFCP that this message
adheres to. This specification defines two versions: 1 and 2. The adheres to. This specification defines two versions: 1 and 2. The
version field MUST be set to 1 when using BFCP over a reliable version field MUST be set to 1 when using BFCP over a reliable
transport. The version field MUST be set to 2 when using BFCP over transport. The version field MUST be set to 2 when using BFCP over
an unreliable transport. If a floor control server receives a an unreliable transport. If a floor control server receives a
message with an unsupported version field value, and the extensions message with an unsupported version field value, and the extensions
in this document is supported, the receiving server MUST send an in this document is supported, the receiving server MUST send an
Error message with parameter value 12 (Unsupported Version) to Error message with parameter value 12 (Unsupported Version) to
indicate this. Note that endpoints supporting only the RFC 4582 indicate this. Note that BFCP entities supporting only the [2]
subset will not support this parameter value. subset will not support this parameter value.
R: The Transaction Responder (R) flag-bit has relevance only for use R: The Transaction Responder (R) flag-bit has relevance only for use
of BFCP over an unreliable transport. When cleared, it indicates of BFCP over an unreliable transport. When cleared, it indicates
that this message is a request initiating a new transaction, and the that this message is a request initiating a new transaction, and the
Transaction ID that follows has been generated for this transaction. Transaction ID that follows has been generated for this transaction.
When set, it indicates that this message is a response to a previous When set, it indicates that this message is a response to a previous
request, and the Transaction ID that follows is the one associated request, and the Transaction ID that follows is the one associated
with that request. When BFCP is used over a reliable transport, the with that request. When BFCP is used over a reliable transport, the
flag has no significance and MUST be cleared by the sender and MUST flag has no significance and MUST be cleared by the sender and MUST
be ignored by the receiver. be ignored by the receiver.
F: The Fragmentation (F) flag-bit has relevance only for use of BFCP F: The Fragmentation (F) flag-bit has relevance only for use of BFCP
over an unreliable transport. When cleared, the message is not over an unreliable transport. When cleared, the message is not
fragmented. When set, it indicates that the message is a fragment of fragmented. When set, it indicates that the message is a fragment of
a large fragmented BFCP message. (The optional fields Fragment a large fragmented BFCP message. (The optional fields Fragment
Offset and Fragment Length described below are present only if the F Offset and Fragment Length described below are present only if the F
flag is set). When BFCP is used over a reliable transport, the flag flag is set). When BFCP is used over a reliable transport, the flag
has no significance and MUST be cleared by the sender and MUST be has no significance and MUST be cleared by the sender and the flag
ignored by the receiver. MUST be ignored by the receiver. In the latter case, the receiver
should also process the COMMON-HEADER as not having the Fragment
Offset and Fragment Length fields present.
Res: At this point, the 3 bits in the reserved field MUST be set to Res: At this point, the 3 bits in the reserved field MUST be set to
zero by the sender of the message and MUST be ignored by the zero by the sender of the message and MUST be ignored by the
receiver. receiver.
Primitive: This 8-bit field identifies the main purpose of the Primitive: This 8-bit field identifies the main purpose of the
message. The following primitive values are defined: message. The following primitive values are defined:
+-------+-----------------------+--------------------+ +-------+-----------------------+--------------------+
| Value | Primitive | Direction | | Value | Primitive | Direction |
skipping to change at page 43, line 7 skipping to change at page 43, line 7
small. By design, the fragmentation scheme does not acknowledge small. By design, the fragmentation scheme does not acknowledge
individual BFCP message fragments. The whole BFCP message is individual BFCP message fragments. The whole BFCP message is
acknowledged if received completely. acknowledged if received completely.
BFCP entities should consider the MTU size available between the BFCP entities should consider the MTU size available between the
sender and the receiver and MAY run MTU discovery, such as sender and the receiver and MAY run MTU discovery, such as
[20][21][22], for this purpose. [20][21][22], for this purpose.
When transmitting a BFCP message with size greater than the path MTU, When transmitting a BFCP message with size greater than the path MTU,
the sender MUST fragment the message into a series of N contiguous the sender MUST fragment the message into a series of N contiguous
data ranges. The value for N is defined as ceil(message size / MTU data ranges. The value for N is defined as ceil(message size -
size), where ceil is the integer ceiling function. The sender then COMMON-HEADER size / MTU size - COMMON-HEADER size), where ceil is
creates N BFCP fragment messages (one for each data range) with the the integer ceiling function and the COMMON-HEADER size includes the
same Transaction ID. The size of each of these N messages MUST be Fragment Offset and Fragment Length fields. The sender then creates
smaller than the path MTU. The F flag in the COMMON-HEADER is set to N BFCP fragment messages (one for each data range) with the same
indicate fragmentation of the BFCP message. Transaction ID. The size of each of these N messages, with the
COMMON-HEADER included, MUST be smaller than the path MTU. The F
flag in the COMMON-HEADER in all the fragments is set to indicate
fragmentation of the BFCP message.
For each of these fragments the Fragment Offset and Fragment Length For each of these fragments the Fragment Offset and Fragment Length
fields are included in the COMMON-HEADER. The Fragment Offset field fields are included in the COMMON-HEADER. The Fragment Offset field
denotes the number of bytes contained in the previous fragments. The denotes the number of bytes contained in the previous fragments. The
Fragment Length contains the length of the fragment itself. Note Fragment Length contains the length of the fragment itself. Note
that the Payload Length field contains the length of the entire, that the Payload Length field contains the length of the entire,
unfragmented message. unfragmented message.
When a BFCP implementation receives a BFCP message fragment, it MUST When a BFCP implementation receives a BFCP message fragment, it MUST
buffer the fragment until either it has received the entire BFCP buffer the fragment until either it has received the entire BFCP
skipping to change at page 47, line 36 skipping to change at page 47, line 36
9. Authentication and Authorization 9. Authentication and Authorization
BFCP clients SHOULD authenticate the floor control server before BFCP clients SHOULD authenticate the floor control server before
sending any BFCP message to it or accepting any BFCP message from it. sending any BFCP message to it or accepting any BFCP message from it.
Similarly, floor control servers SHOULD authenticate a client before Similarly, floor control servers SHOULD authenticate a client before
accepting any BFCP message from it or sending any BFCP message to it. accepting any BFCP message from it or sending any BFCP message to it.
If the signaling or control protocol traffic used to set up the If the signaling or control protocol traffic used to set up the
conference is authenticated and confidentiality and integrity conference is authenticated and confidentiality and integrity
protected, and the extensions in this document is supported, the BFCP protected, and the extensions in this document are supported, the
clients MUST authenticate the floor control server and the floor BFCP clients MUST authenticate the floor control server and the floor
control servers MUST authenticate a client before communicating as control servers MUST authenticate the client before communicating as
described above. Note that endpoints supporting only the RFC 4582 described above. Note that BFCP entities supporting only the [2]
subset may not comply with this mandatory authentication requirement. subset may not comply with this mandatory authentication requirement.
BFCP supports TLS/DTLS mutual authentication between clients and BFCP supports TLS/DTLS mutual authentication between clients and
floor control servers, as specified in Section 9.1. This is the floor control servers, as specified in Section 9.1. This is the
RECOMMENDED authentication mechanism in BFCP. RECOMMENDED authentication mechanism in BFCP.
Note that future extensions may define additional authentication Note that future extensions may define additional authentication
mechanisms. mechanisms.
In addition to authenticating BFCP messages, floor control servers In addition to authenticating BFCP messages, floor control servers
skipping to change at page 70, line 20 skipping to change at page 70, line 20
error, it MUST generate an Error response following the procedures error, it MUST generate an Error response following the procedures
described in Section 13.8. described in Section 13.8.
If the version of BFCP specified in the Version field of the COMMON- If the version of BFCP specified in the Version field of the COMMON-
HEADER is supported by the floor control server, it MUST respond with HEADER is supported by the floor control server, it MUST respond with
the same version number in the HelloAck; this defines the version for the same version number in the HelloAck; this defines the version for
all subsequent BFCP messages within this BFCP Connection. If the all subsequent BFCP messages within this BFCP Connection. If the
version given in the Hello message is not supported, and the version given in the Hello message is not supported, and the
extensions in this document is supported, the receiving server MUST extensions in this document is supported, the receiving server MUST
instead send an Error message with parameter value 12 (Unsupported instead send an Error message with parameter value 12 (Unsupported
Version). Note that endpoints supporting only the RFC 4582 subset Version). Note that BFCP entities supporting only the [2] subset
will not support this parameter value. will not support this parameter value.
When communicating over an unreliable transport and upon receiving a When communicating over an unreliable transport and upon receiving a
Hello from a participant, the floor control server MUST respond with Hello from a participant, the floor control server MUST respond with
a HelloAck message within the transaction failure window to complete a HelloAck message within the transaction failure window to complete
the transaction. the transaction.
The successful processing of a Hello message by a floor control The successful processing of a Hello message by a floor control
server involves generating a HelloAck message, which SHOULD be server involves generating a HelloAck message, which SHOULD be
generated as soon as possible. The floor control server MUST copy generated as soon as possible. The floor control server MUST copy
skipping to change at page 71, line 15 skipping to change at page 71, line 15
The floor control server MUST add an ERROR-CODE attribute to the The floor control server MUST add an ERROR-CODE attribute to the
Error message. The ERROR-CODE attribute contains an Error Code from Error message. The ERROR-CODE attribute contains an Error Code from
Table 5. Additionally, the floor control server may add an ERROR- Table 5. Additionally, the floor control server may add an ERROR-
INFO attribute with extra information about the error. INFO attribute with extra information about the error.
14. Security Considerations 14. Security Considerations
BFCP uses TLS/DTLS to provide mutual authentication between clients BFCP uses TLS/DTLS to provide mutual authentication between clients
and servers. TLS/DTLS also provides replay and integrity protection and servers. TLS/DTLS also provides replay and integrity protection
and confidentiality. It is RECOMMENDED that TLS/DTLS with an and confidentiality. It is RECOMMENDED that TLS/DTLS with an
encryption algorithm according to Section 7 always be used and in encryption algorithm according to Section 7 always be used. In cases
cases where signaling/control traffic is properly protected, as where signaling/control traffic is properly protected, as described
described in Section 9 it is REQUIRED to use a mandated encryption in Section 9 it is REQUIRED to use a mandated encryption algorithm.
algorithm. BFCP entities MAY use other security mechanisms as long BFCP entities MAY use other security mechanisms as long as they
as they provide similar security properties. provide similar security properties.
The remainder of this section analyzes some of the threats against The remainder of this section analyzes some of the threats against
BFCP and how they are addressed. BFCP and how they are addressed.
An attacker may attempt to impersonate a client (a floor participant An attacker may attempt to impersonate a client (a floor participant
or a floor chair) in order to generate forged floor requests or to or a floor chair) in order to generate forged floor requests or to
grant or deny existing floor requests. Client impersonation is grant or deny existing floor requests. Client impersonation is
avoided by having servers only accept BFCP messages over avoided by having servers only accept BFCP messages over
authenticated TLS/DTLS connections. The floor control server assumes authenticated TLS/DTLS connections. The floor control server assumes
that attackers cannot hijack the TLS/DTLS connection and, therefore, that attackers cannot hijack the TLS/DTLS connection and, therefore,
skipping to change at page 79, line 30 skipping to change at page 79, line 30
[6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008. Protocol Version 1.2", RFC 5246, August 2008.
[7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", [8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003. STD 63, RFC 3629, November 2003.
[9] Camarillo, G. and T. Kristensen, "Session Description Protocol [9] Camarillo, G., Kristensen, T., and P. Jones, "Session
(SDP) Format for Binary Floor Control Protocol (BFCP) Streams", Description Protocol (SDP) Format for Binary Floor Control
draft-ietf-bfcpbis-rfc4583bis-11 (work in progress), Protocol (BFCP) Streams", draft-ietf-bfcpbis-rfc4583bis-12
February 2015. (work in progress), Semptember 2015.
[10] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", [10] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)",
BCP 131, RFC 4961, July 2007. BCP 131, RFC 4961, July 2007.
[11] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session [11] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session
Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
18.2. Informational References 18.2. Informational References
[12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with [12] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
 End of changes. 11 change blocks. 
27 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/