draft-ietf-bfcpbis-rfc4582bis-15.txt   draft-ietf-bfcpbis-rfc4582bis-16.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: April 16, 2016 T. Kristensen Expires: May 16, 2016 T. Kristensen
Cisco Cisco
J. Ott J. Ott
Aalto University Aalto University
C. Eckel C. Eckel
Cisco Cisco
October 14, 2015 November 13, 2015
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4582bis-15 draft-ietf-bfcpbis-rfc4582bis-16
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 April 16, 2016. This Internet-Draft will expire on May 16, 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 4, line 47 skipping to change at page 4, line 47
16.1. Extensions for an unreliable transport . . . . . . . . . 75 16.1. Extensions for an unreliable transport . . . . . . . . . 75
16.2. Other changes . . . . . . . . . . . . . . . . . . . . . 76 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . 76
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 77
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 77
18.1. Normative References . . . . . . . . . . . . . . . . . . 78 18.1. Normative References . . . . . . . . . . . . . . . . . . 78
18.2. Informational References . . . . . . . . . . . . . . . . 79 18.2. Informational References . . . . . . . . . . . . . . . . 79
Appendix A. Example Call Flows for BFCP over an Unreliable Appendix A. Example Call Flows for BFCP over an Unreliable
Transport . . . . . . . . . . . . . . . . . . . . . 81 Transport . . . . . . . . . . . . . . . . . . . . . 81
Appendix B. Motivation for Supporting an Unreliable Transport . 85 Appendix B. Motivation for Supporting an Unreliable Transport . 85
B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 85 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 85
B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 86 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 87
B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 88
B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . 88 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . 88
B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88
B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . 88 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . 89
B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 89 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89
1. Introduction 1. Introduction
Within a conference, some applications need to manage the access to a Within a conference, some applications need to manage the access to a
set of shared resources, such as the right to send media to a set of shared resources, such as the right to send media to a
particular media session. Floor control enables such applications to particular media session. Floor control enables such applications to
provide users with coordinated (shared or exclusive) access to these provide users with coordinated (shared or exclusive) access to these
resources. resources.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
3.1. Floor Creation 3.1. Floor Creation
The association of a given floor with a resource or a set of The association of a given floor with a resource or a set of
resources (e.g., media streams) is out of the scope of BFCP as resources (e.g., media streams) is out of the scope of BFCP as
described in [16]. Floor creation and termination are also outside described in [16]. Floor creation and termination are also outside
the scope of BFCP; these aspects are handled using the conference the scope of BFCP; these aspects are handled using the conference
control protocol for manipulating the conference object. control protocol for manipulating the conference object.
Consequently, the floor control server needs to stay up to date on Consequently, the floor control server needs to stay up to date on
changes to the conference object (e.g., when a new floor is created). changes to the conference object (e.g., when a new floor is created).
Conference control clients using CCMP [20] can specify such floor- Conference control clients using CCMP [21] can specify such floor-
related settings in the <floor-information> element [19] of the to-be related settings in the <floor-information> element [20] of the to-be
created conference object provided in the body of a CCMP confRequest/ created conference object provided in the body of a CCMP confRequest/
create message issued to the conference control server. create message issued to the conference control server.
3.2. Obtaining Information to Contact a Floor Control Server 3.2. Obtaining Information to Contact a Floor Control Server
A client needs a set of data in order to establish a BFCP connection A client needs a set of data in order to establish a BFCP connection
to a floor control server. This data includes the transport address to a floor control server. This data includes the transport address
of the server, the conference identifier, and a user identifier. of the server, the conference identifier, and a user identifier.
Clients can obtain this information in different ways. One is to use Clients can obtain this information in different ways. One is to use
skipping to change at page 9, line 22 skipping to change at page 9, line 22
with the conference focus of the conference. So, the conference with the conference focus of the conference. So, the conference
focus needs to obtain information about associations between focus needs to obtain information about associations between
floors and resources in order to be able to provide this floors and resources in order to be able to provide this
information to a floor participant in an SDP offer/answer information to a floor participant in an SDP offer/answer
exchange. exchange.
Other mechanisms for obtaining this information, including discussion Other mechanisms for obtaining this information, including discussion
of how the information is made available to a (SIP) Focus, are of how the information is made available to a (SIP) Focus, are
described in the XCON framework [16] (and other related documents). described in the XCON framework [16] (and other related documents).
According to the conferencing system policies, conference control According to the conferencing system policies, conference control
clients using CCMP [20] can modify the floor settings of a conference clients using CCMP [21] can modify the floor settings of a conference
by issuing CCMP confRequest/update messages providing the specific by issuing CCMP confRequest/update messages providing the specific
updates to the <floor-information> element of the target conference updates to the <floor-information> element of the target conference
object. More information about CCMP and BFCP interaction can be object. More information about CCMP and BFCP interaction can be
found in [21]. found in [22].
3.4. Privileges of Floor Control 3.4. Privileges of Floor Control
A participant whose floor request is granted has the right to use the A participant whose floor request is granted has the right to use the
resource or resources associated with the floor that was requested. resource or resources associated with the floor that was requested.
For example, the participant may have the right to send media over a For example, the participant may have the right to send media over a
particular audio stream. particular audio stream.
Nevertheless, holding a floor does not imply that others will not be Nevertheless, holding a floor does not imply that others will not be
able to use its associated resources at the same time, even if they able to use its associated resources at the same time, even if they
skipping to change at page 16, line 27 skipping to change at page 16, line 27
+---- These fragment fields are never present +---- These fragment fields are never present
when using reliable transports when using reliable transports
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, the server MUST message with an unsupported version field value or a message with a
indicate it does not support the protocol version by sending an Error version number that is not permitted with the transport over which it
message with parameter value 12 (Unsupported Version). Note that was received, the server MUST indicate it does not support the
BFCP entities supporting only the [3] subset will not support this protocol version by sending an Error message with parameter value 12
parameter value. (Unsupported Version). Note that BFCP entities supporting only the
[3] 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.
skipping to change at page 18, line 6 skipping to change at page 18, line 9
length MUST discard the message. length MUST discard the message.
Note: BFCP is designed to achieve small message size, as explained Note: BFCP is designed to achieve small message size, as explained
in Section 1, and BFCP entities are required to keep the BFCP in Section 1, and BFCP entities are required to keep the BFCP
message size smaller than the size limited by the 16-bit Payload message size smaller than the size limited by the 16-bit Payload
Length field. To convey information not strictly related to floor Length field. To convey information not strictly related to floor
control, other protocols should be used such as the XCON framework control, other protocols should be used such as the XCON framework
(cf. Section 3). (cf. Section 3).
Conference ID: This 32-bit unsigned integer field identifies the Conference ID: This 32-bit unsigned integer field identifies the
conference to which the message belongs. (Note that the use of conference to which the message belongs. It is RECOMMENDED that the
conference identifier be randomly chosen. (Note that the use of
predictable conference identifiers in conjunction with a non-secure predictable conference identifiers in conjunction with a non-secure
transport protocol makes BFCP more susceptible to forged request and transport protocol makes BFCP susceptible to off-path data injection
response messages. See the Security Considerations section regarding attacks, where an attacker can forge a request or response message.)
the recommendation to use a secure transport.)
Transaction ID: This field contains a 16-bit value that allows users Transaction ID: This field contains a 16-bit value that allows users
to match a given message with its response (see Section 8). to match a given message with its response (see Section 8).
User ID: This field contains a 16-bit unsigned integer that uniquely User ID: This field contains a 16-bit unsigned integer that uniquely
identifies a participant within a conference. identifies a participant within a conference.
The identity used by a participant in BFCP, which is carried in The identity used by a participant in BFCP, which is carried in
the User ID field, is generally mapped to the identity used by the the User ID field, is generally mapped to the identity used by the
same participant in the session establishment protocol (e.g., in same participant in the session establishment protocol (e.g., in
skipping to change at page 41, line 16 skipping to change at page 41, line 16
original transmission of the message. The default initial interval original transmission of the message. The default initial interval
MUST be set to 500ms, but is adjusted dynamically as described in MUST be set to 500ms, but is adjusted dynamically as described in
Section 8.3.1. The interval MUST be doubled after each Section 8.3.1. The interval MUST be doubled after each
retransmission attempt. This is similar to the specification of the retransmission attempt. This is similar to the specification of the
timer A and its initial value T1 in SIP as described in timer A and its initial value T1 in SIP as described in
Section 17.1.1.2 of [18], except that the value of T1 in this Section 17.1.1.2 of [18], except that the value of T1 in this
protocol is not fixed from one transaction to another. protocol is not fixed from one transaction to another.
6.2.2. ICMP Error Handling 6.2.2. ICMP Error Handling
ICMP is not used with unreliable transports due to risks asociated ICMP is not usable when BFCP is running over an unreliable transport
with off-path attacks. Any ICMP messages received over an unreliable due to risks associated with off-path attacks. Any ICMP messages
transport MUST be ignored. associated with BFCP running over an unreliable transport MUST be
ignored.
6.2.3. Fragmentation Handling 6.2.3. Fragmentation Handling
When using UDP, a single BFCP message could be fragmented at the IP When using UDP, a single BFCP message could be fragmented at the IP
layer if its overall size exceeds the path MTU of the network. To layer if its overall size exceeds the path MTU of the network. To
avoid this happening at the IP layer, a fragmentation scheme for BFCP avoid this happening at the IP layer, a fragmentation scheme for BFCP
is defined below. is defined below.
BFCP is designed for achieving small message size, due to the binary BFCP is designed for achieving small message size, due to the binary
encoding as described in Section 1. The fragmentation scheme is encoding as described in Section 1. The fragmentation scheme is
therefore deliberately kept simple and straightforward, since the therefore deliberately kept simple and straightforward, since the
probability of fragmentation of BFCP messages being required is probability of fragmentation of BFCP messages being required is
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 path MTU size available between the BFCP entities SHOULD consider the path 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
[22][23][24], for this purpose. [23][24][25], 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 size of each of these N messages MUST be smaller data ranges. The size of each of these N messages MUST be smaller
than the path MTU to help prevent fragmentation overlap attacks. The than the path MTU to help prevent fragmentation overlap attacks. The
value for N is defined as ceil((message size - COMMON-HEADER size) / value for N is defined as ceil((message size - COMMON-HEADER size) /
(path MTU size - COMMON-HEADER size)), where ceil is the integer (path MTU size - COMMON-HEADER size)), where ceil is the integer
ceiling function and the COMMON-HEADER size includes the Fragment ceiling function and the COMMON-HEADER size includes the Fragment
Offset and Fragment Length fields. The sender then creates N BFCP Offset and Fragment Length fields. The sender then creates N BFCP
fragment messages (one for each data range) with the same Transaction fragment messages (one for each data range) with the same Transaction
skipping to change at page 43, line 6 skipping to change at page 43, line 9
ability to leverage the existing NAT traversal infrastructure and ability to leverage the existing NAT traversal infrastructure and
strategies deployed to facilitate transport of the media associated strategies deployed to facilitate transport of the media associated
with the video conferencing sessions. Depending on the given with the video conferencing sessions. Depending on the given
deployment, this infrastructure typically includes some subset of ICE deployment, this infrastructure typically includes some subset of ICE
[17]. [17].
In order to facilitate the initial establishment of NAT bindings, and In order to facilitate the initial establishment of NAT bindings, and
to maintain those bindings once established, BFCP entities using an to maintain those bindings once established, BFCP entities using an
unreliable transport are RECOMMENDED to use STUN [12] Binding unreliable transport are RECOMMENDED to use STUN [12] Binding
Indication for keep-alives, as described for ICE [17]. Section 6.7 Indication for keep-alives, as described for ICE [17]. Section 6.7
of [25] provides useful recommendations for middlebox interaction of [26] provides useful recommendations for middlebox interaction
when DTLS is used. when DTLS is used.
Informational note: Since the version number is set to 2 when BFCP Informational note: Since the version number is set to 2 when BFCP
is used over an unreliable transport, cf. the Ver field in is used over an unreliable transport, cf. the Ver field in
Section 5.1, it is straight forward to distinguish between STUN Section 5.1, it is straight forward to distinguish between STUN
and BFCP packets even without checking the STUN magic cookie [12]. and BFCP packets even without checking the STUN magic cookie [12].
In order to facilitate traversal of BFCP packets through NATs, BFCP In order to facilitate traversal of BFCP packets through NATs, BFCP
entities using an unreliable transport are RECOMMENDED to use entities using an unreliable transport are RECOMMENDED to use
symmetric ports for sending and receiving BFCP packets, as symmetric ports for sending and receiving BFCP packets, as
skipping to change at page 43, line 31 skipping to change at page 43, line 34
BFCP relies on lower-layer security mechanisms to provide replay and BFCP relies on lower-layer security mechanisms to provide replay and
integrity protection and confidentiality. BFCP floor control servers integrity protection and confidentiality. BFCP floor control servers
and clients (which include both floor participants and floor chairs) and clients (which include both floor participants and floor chairs)
MUST support TLS for transport over TCP [7] and MUST support DTLS [8] MUST support TLS for transport over TCP [7] and MUST support DTLS [8]
for transport over UDP. Any BFCP entity MAY support other security for transport over UDP. Any BFCP entity MAY support other security
mechanisms. mechanisms.
BFCP entities MUST support, at a minimum, the BFCP entities MUST support, at a minimum, the
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [7] for backwards TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [7] for backwards
compatibility with existing implementations of RFC 4582. In compatibility with existing implementations of RFC 4582. In
accordance with the recommendations and guidelines in [27], BFCP accordance with the recommendations and guidelines in [28], BFCP
entities SHOULD support the following cipher suites: entities SHOULD support the following cipher suites:
o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 o TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 o TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
skipping to change at page 70, line 13 skipping to change at page 70, line 13
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. In cases encryption algorithm according to Section 7 always be used. In cases
where signaling/control traffic is properly protected, as described where signaling/control traffic is properly protected, as described
in Section 9 it is REQUIRED to use a mandated encryption algorithm. in Section 9 it is REQUIRED to use a mandated encryption algorithm.
BFCP entities MAY use other security mechanisms as long as they BFCP entities MAY use other security mechanisms to interwork with
provide similar security properties. legacy implementation that do not use TLS/DTLS as long as these
mechanisms provide similar security properties. An example of other
mechanisms is IPSec [19] to effectively secure a non-secure BFCP
connection.
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 71, line 16 skipping to change at page 71, line 20
15. IANA Considerations 15. IANA Considerations
[Note to IANA: Much of this text exists from the previous version [Note to IANA: Much of this text exists from the previous version
of this document. While the old and new additions to the of this document. While the old and new additions to the
registries are presented here, the items for which IANA needs to registries are presented here, the items for which IANA needs to
take action with respect to this draft are highlighted with "Note take action with respect to this draft are highlighted with "Note
to IANA", as with this note and the one immediately following. to IANA", as with this note and the one immediately following.
Throughout this document, though, RFC XXXX needs to be replaced Throughout this document, though, RFC XXXX needs to be replaced
with this RFC and the IANA registries for BFCP should to refer with this RFC and the IANA registries for BFCP should to refer
only to this RFC. only to this RFC.]
[Note to IANA: This section instructs the IANA to register new [Note to IANA: This section instructs the IANA to register new
entries in the BFCP Primitive subregistry in Section 15.2 and for entries in the BFCP Primitive subregistry in Section 15.2 and for
the BFCP Error Code subregistry in Section 15.4.] the BFCP Error Code subregistry in Section 15.4.]
The IANA has created a registry for BFCP parameters called "Binary The IANA has created a registry for BFCP parameters called "Binary
Floor Control Protocol (BFCP) Parameters". This registry has a Floor Control Protocol (BFCP) Parameters". This registry has a
number of subregistries, which are described in the following number of subregistries, which are described in the following
sections. sections.
skipping to change at page 79, line 47 skipping to change at page 79, line 47
Traversal for Offer/Answer Protocols", RFC 5245, DOI Traversal for Offer/Answer Protocols", RFC 5245, DOI
10.17487/RFC5245, April 2010, 10.17487/RFC5245, April 2010,
<http://www.rfc-editor.org/info/rfc5245>. <http://www.rfc-editor.org/info/rfc5245>.
[18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [18] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
[19] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, [19] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[20] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen,
"Conference Information Data Model for Centralized "Conference Information Data Model for Centralized
Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501,
March 2012, <http://www.rfc-editor.org/info/rfc6501>. March 2012, <http://www.rfc-editor.org/info/rfc6501>.
[20] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne, [21] Barnes, M., Boulton, C., Romano, S., and H. Schulzrinne,
"Centralized Conferencing Manipulation Protocol", RFC "Centralized Conferencing Manipulation Protocol", RFC
6503, DOI 10.17487/RFC6503, March 2012, 6503, DOI 10.17487/RFC6503, March 2012,
<http://www.rfc-editor.org/info/rfc6503>. <http://www.rfc-editor.org/info/rfc6503>.
[21] Barnes, M., Miniero, L., Presta, R., and S. Romano, [22] Barnes, M., Miniero, L., Presta, R., and S. Romano,
"Centralized Conferencing Manipulation Protocol (CCMP) "Centralized Conferencing Manipulation Protocol (CCMP)
Call Flow Examples", RFC 6504, DOI 10.17487/RFC6504, March Call Flow Examples", RFC 6504, DOI 10.17487/RFC6504, March
2012, <http://www.rfc-editor.org/info/rfc6504>. 2012, <http://www.rfc-editor.org/info/rfc6504>.
[22] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, [23] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990, DOI 10.17487/RFC1191, November 1990,
<http://www.rfc-editor.org/info/rfc1191>. <http://www.rfc-editor.org/info/rfc1191>.
[23] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [24] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
1996, <http://www.rfc-editor.org/info/rfc1981>. 1996, <http://www.rfc-editor.org/info/rfc1981>.
[24] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [25] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
<http://www.rfc-editor.org/info/rfc4821>. <http://www.rfc-editor.org/info/rfc4821>.
[25] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework [26] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing a Secure Real-time Transport Protocol for Establishing a Secure Real-time Transport Protocol
(SRTP) Security Context Using Datagram Transport Layer (SRTP) Security Context Using Datagram Transport Layer
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May
2010, <http://www.rfc-editor.org/info/rfc5763>. 2010, <http://www.rfc-editor.org/info/rfc5763>.
[26] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream [27] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Control Transmission Protocol (SCTP) Packets for End-Host Control Transmission Protocol (SCTP) Packets for End-Host
to End-Host Communication", RFC 6951, DOI 10.17487/ to End-Host Communication", RFC 6951, DOI 10.17487/
RFC6951, May 2013, RFC6951, May 2013,
<http://www.rfc-editor.org/info/rfc6951>. <http://www.rfc-editor.org/info/rfc6951>.
[27] Sheffer, Y., Holz, R., and P. Saint-Andre, [28] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <http://www.rfc-editor.org/info/rfc7525>.
[28] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [29] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, DOI Network Address Translations (NATs)", RFC 4380, DOI
10.17487/RFC4380, February 2006, 10.17487/RFC4380, February 2006,
<http://www.rfc-editor.org/info/rfc4380>. <http://www.rfc-editor.org/info/rfc4380>.
[29] Thaler, D., "Teredo Extensions", RFC 6081, DOI 10.17487/ [30] Thaler, D., "Teredo Extensions", RFC 6081, DOI 10.17487/
RFC6081, January 2011, RFC6081, January 2011,
<http://www.rfc-editor.org/info/rfc6081>. <http://www.rfc-editor.org/info/rfc6081>.
[30] Stewart, R., Ed., "Stream Control Transmission Protocol", [31] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>. <http://www.rfc-editor.org/info/rfc4960>.
[31] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [32] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>. March 2012, <http://www.rfc-editor.org/info/rfc6544>.
[32] Manner, J., Varis, N., and B. Briscoe, "Generic UDP [33] Manner, J., Varis, N., and B. Briscoe, "Generic UDP
Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in Tunnelling (GUT)", draft-manner-tsvwg-gut-02 (work in
progress), July 2010. progress), July 2010.
[33] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis [34] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis
of Middlebox Interactions for Signaling Protocol of Middlebox Interactions for Signaling Protocol
Communication along the Media Path", draft-ietf-mmusic- Communication along the Media Path", draft-ietf-mmusic-
media-path-middleboxes-07 (work in progress), May 2013. media-path-middleboxes-07 (work in progress), May 2013.
[34] Guha, S. and P. Francis, "Characterization and Measurement [35] Guha, S. and P. Francis, "Characterization and Measurement
of TCP Traversal through NATs and Firewalls", 2005, of TCP Traversal through NATs and Firewalls", 2005,
<http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>. <http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>.
[35] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer [36] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
Communication Across Network Address Translators", April Communication Across Network Address Translators", April
2005, <http://www.brynosaurus.com/pub/net/p2pnat.pdf/>. 2005, <http://www.brynosaurus.com/pub/net/p2pnat.pdf/>.
Appendix A. Example Call Flows for BFCP over an Unreliable Transport Appendix A. Example Call Flows for BFCP over an Unreliable Transport
With reference to Section 4.1, the following figures show With reference to Section 4.1, the following figures show
representative call-flows for requesting and releasing a floor, and representative call-flows for requesting and releasing a floor, and
obtaining status information about a floor when BFCP is deployed over obtaining status information about a floor when BFCP is deployed over
an unreliable transport. The figures here show a loss-less an unreliable transport. The figures here show a loss-less
interaction. interaction.
skipping to change at page 86, line 7 skipping to change at page 86, line 24
+----+ +----+ +----+ +----+
Figure 50: Use Case Figure 50: Use Case
The communication session between the video conferencing endpoints The communication session between the video conferencing endpoints
typically consists of a number of RTP over UDP media streams, for typically consists of a number of RTP over UDP media streams, for
audio and video, and a BFCP connection for floor control. Existing audio and video, and a BFCP connection for floor control. Existing
deployments are most common in, but not limited to, enterprise deployments are most common in, but not limited to, enterprise
networks. In existing deployments, NAT traversal for the RTP streams networks. In existing deployments, NAT traversal for the RTP streams
works using ICE and/or other methods, including those described in works using ICE and/or other methods, including those described in
[33]. [34].
When enhancing an existing SIP based video conferencing deployment When enhancing an existing SIP based video conferencing deployment
with support for content sharing, the BFCP connection often poses a with support for content sharing, the BFCP connection often poses a
problem. The reasons for this fall into two general classes. First, problem. The reasons for this fall into two general classes. First,
there may be a strong preference for UDP based signaling in general. there may be a strong preference for UDP based signaling in general.
On high capacity endpoints (e.g., PSTN gateways or SIP/H.323 inter- On high capacity endpoints (e.g., PSTN gateways or SIP/H.323 inter-
working gateways), TCP can suffer from head of line blocking, and it working gateways), TCP can suffer from head of line blocking, and it
uses many kernel buffers. Network operators view UDP as a way to uses many kernel buffers. Network operators view UDP as a way to
avoid both of these. Second, establishment and traversal of the TCP avoid both of these. Second, establishment and traversal of the TCP
connection involving ephemeral ports, as is typically the case with connection involving ephemeral ports, as is typically the case with
BFCP over TCP, can be problematic, as described in Appendix A of BFCP over TCP, can be problematic, as described in Appendix A of
[31]. A broad study of NAT behavior and peer-to-peer TCP [32]. A broad study of NAT behavior and peer-to-peer TCP
establishment for a comprehensive set of TCP NAT traversal techniques establishment for a comprehensive set of TCP NAT traversal techniques
over a wide range of commercial NAT products concluded it was not over a wide range of commercial NAT products concluded it was not
possible to establish a TCP connection in 11% of the cases [34]. The possible to establish a TCP connection in 11% of the cases [35]. The
results are worse when focusing on enterprise NATs. A study of hole results are worse when focusing on enterprise NATs. A study of hole
punching as a NAT traversal technique across a wide variety of punching as a NAT traversal technique across a wide variety of
deployed NATs reported consistently higher success rates when using deployed NATs reported consistently higher success rates when using
UDP than when using TCP [35]. UDP than when using TCP [36].
It is worth noticing that BFCP over UDP is already being used in real It is worth noticing that BFCP over UDP is already being used in real
deployments, underlining the necessity to specify a common way to deployments, underlining the necessity to specify a common way to
exchange BFCP messages where TCP is not appropriate, to avoid a exchange BFCP messages where TCP is not appropriate, to avoid a
situation where multiple different and non-interoperable situation where multiple different and non-interoperable
implementations would co-exist in the market. The purpose of this implementations would co-exist in the market. The purpose of this
draft is to formalize and publish the extension from the standard draft is to formalize and publish the extension from the standard
specification to facilitate complete interoperability between specification to facilitate complete interoperability between
implementations. implementations.
skipping to change at page 87, line 7 skipping to change at page 87, line 22
to address the use case targeted by this draft. The last to address the use case targeted by this draft. The last
alternative, presented in Appendix B.1.1.7, is the selected one and alternative, presented in Appendix B.1.1.7, is the selected one and
is specified in this draft. is specified in this draft.
It is also worth noting that the IETF Transport Area were asked for a It is also worth noting that the IETF Transport Area were asked for a
way to tunnel TCP over UDP, but at that point there was no consensus way to tunnel TCP over UDP, but at that point there was no consensus
on how to achieve that. on how to achieve that.
B.1.1.1. ICE TCP B.1.1.1. ICE TCP
ICE TCP [31] extends ICE to TCP based media, including the ability to ICE TCP [32] extends ICE to TCP based media, including the ability to
offer a mix of TCP and UDP based candidates for a single stream. ICE offer a mix of TCP and UDP based candidates for a single stream. ICE
TCP has, in general, a lower success probability for enabling TCP TCP has, in general, a lower success probability for enabling TCP
connectivity without a relay if both of the hosts are behind a NAT connectivity without a relay if both of the hosts are behind a NAT
(see Appendix A of [31]) than enabling UDP connectivity in the same (see Appendix A of [32]) than enabling UDP connectivity in the same
scenarios. The happens because many of the currently deployed NATs scenarios. The happens because many of the currently deployed NATs
in video conferencing networks do not support the flow of TCP hand in video conferencing networks do not support the flow of TCP hand
shake packets seen in case of TCP simultaneous-open, either because shake packets seen in case of TCP simultaneous-open, either because
they do not allow incoming TCP SYN packets from an address to which a they do not allow incoming TCP SYN packets from an address to which a
SYN packet has been sent to recently, or because they do not properly SYN packet has been sent to recently, or because they do not properly
process the subsequent SYNACK. Implementing various techniques process the subsequent SYNACK. Implementing various techniques
advocated for candidate collection in [31] should increase the advocated for candidate collection in [32] should increase the
success probability, but many of these techniques require support success probability, but many of these techniques require support
from some network elements (e.g., from the NATs). Such support is from some network elements (e.g., from the NATs). Such support is
not common in enterprise NATs. not common in enterprise NATs.
B.1.1.2. Teredo B.1.1.2. Teredo
Teredo [28] enables nodes located behind one or more IPv4 NATs to Teredo [29] enables nodes located behind one or more IPv4 NATs to
obtain IPv6 connectivity by tunneling packets over UDP. Teredo obtain IPv6 connectivity by tunneling packets over UDP. Teredo
extensions [29] provide additional capabilities to Teredo, including extensions [30] provide additional capabilities to Teredo, including
support for more types of NATs and support for more efficient support for more types of NATs and support for more efficient
communication. communication.
As defined, Teredo could be used to make BFCP work for the video As defined, Teredo could be used to make BFCP work for the video
conferencing use cases addressed in this draft. However, running the conferencing use cases addressed in this draft. However, running the
service requires the help of "Teredo servers" and "Teredo relays" service requires the help of "Teredo servers" and "Teredo relays"
[28]. These servers and relays generally do not exist in the [29]. These servers and relays generally do not exist in the
existing video conferencing deployments. It also requires IPv6 existing video conferencing deployments. It also requires IPv6
awareness on the endpoints. It should also be noted that ICMP6, as awareness on the endpoints. It should also be noted that ICMP6, as
used with Teredo to complete an initial protocol exchange and confirm used with Teredo to complete an initial protocol exchange and confirm
that the appropriate NAT bindings have been set up, is not a that the appropriate NAT bindings have been set up, is not a
conventional feature of IPv4 or even IPv6, and some currently conventional feature of IPv4 or even IPv6, and some currently
deployed IPv6 firewalls discard ICMP messages. As these networks deployed IPv6 firewalls discard ICMP messages. As these networks
continue to evolve and tackle the transaction to IPv6, Teredo servers continue to evolve and tackle the transaction to IPv6, Teredo servers
and relays may be deployed, making Teredo available as a suitable and relays may be deployed, making Teredo available as a suitable
alternative to BFCP over UDP. alternative to BFCP over UDP.
B.1.1.3. GUT B.1.1.3. GUT
GUT [32] attempts to facilitate tunneling over UDP by encapsulating GUT [33] attempts to facilitate tunneling over UDP by encapsulating
the native transport protocol and its payload (in general the whole the native transport protocol and its payload (in general the whole
IP payload) within a UDP packet destined to the well-known port IP payload) within a UDP packet destined to the well-known port
GUT_P. Unfortunately, it requires user-space TCP, for which there is GUT_P. Unfortunately, it requires user-space TCP, for which there is
not a readily available implementation, and creating one is a large not a readily available implementation, and creating one is a large
project in itself. This draft has expired and its future is still project in itself. This draft has expired and its future is still
not clear as it has not yet been adopted by a working group. not clear as it has not yet been adopted by a working group.
B.1.1.4. UPnP IGD B.1.1.4. UPnP IGD
Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on Universal Plug and Play Internet Gateway Devices (UPnP IGD) sit on
skipping to change at page 88, line 47 skipping to change at page 89, line 13
to communicate with it. to communicate with it.
Many NATs do not support PMP. In those that do support it, it has Many NATs do not support PMP. In those that do support it, it has
similar issues with negotiation of multilayer NATs as UPnP. Video similar issues with negotiation of multilayer NATs as UPnP. Video
conferencing is used extensively in enterprise networks, and NAT PMP conferencing is used extensively in enterprise networks, and NAT PMP
is not generally available in enterprise-class routers. is not generally available in enterprise-class routers.
B.1.1.6. SCTP B.1.1.6. SCTP
It would be quite straight forward to specify a BFCP binding for SCTP It would be quite straight forward to specify a BFCP binding for SCTP
[30], and then tunnel SCTP over UDP in the use case described in [31], and then tunnel SCTP over UDP in the use case described in
Appendix B.1. SCTP is gaining some momentum currently. There was Appendix B.1. SCTP is gaining some momentum currently. There was
ongoing discussion in the RTCWeb WG regarding this approach, which ongoing discussion in the RTCWeb WG regarding this approach, which
resulted in [26]. However, this approach for tunneling over UDP was resulted in [27]. However, this approach for tunneling over UDP was
not mature enough when considered and not even fully specified. not mature enough when considered and not even fully specified.
B.1.1.7. BFCP over UDP transport B.1.1.7. BFCP over UDP transport
To overcome the problems with establishing TCP flows between BFCP To overcome the problems with establishing TCP flows between BFCP
entities, an alternative is to define UDP as an alternate transport entities, an alternative is to define UDP as an alternate transport
for BFCP, leveraging the same mechanisms in place for the RTP over for BFCP, leveraging the same mechanisms in place for the RTP over
UDP media streams for the BFCP communication. When using UDP as the UDP media streams for the BFCP communication. When using UDP as the
transport, it is recommended to follow the guidelines provided in transport, it is recommended to follow the guidelines provided in
[13]. [13].
 End of changes. 49 change blocks. 
59 lines changed or deleted 68 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/