draft-ietf-bfcpbis-rfc4582bis-12.txt   draft-ietf-bfcpbis-rfc4582bis-13.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 30, 2015 T. Kristensen Expires: August 23, 2015 T. Kristensen
Cisco Cisco
J. Ott J. Ott
Aalto University Aalto University
C. Eckel C. Eckel
Cisco Cisco
October 27, 2014 February 19, 2015
The Binary Floor Control Protocol (BFCP) The Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-rfc4582bis-12 draft-ietf-bfcpbis-rfc4582bis-13
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 30, 2015. This Internet-Draft will expire on August 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 32 skipping to change at page 3, line 32
5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.16. Goodbye . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38 5.3.17. GoodbyeAck . . . . . . . . . . . . . . . . . . . . . . 38
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39 6.1. Reliable Transport . . . . . . . . . . . . . . . . . . . . 39
6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40 6.2. Unreliable Transport . . . . . . . . . . . . . . . . . . . 40
6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 41 6.2.1. Congestion Control . . . . . . . . . . . . . . . . . . 41
6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42 6.2.2. ICMP Error Handling . . . . . . . . . . . . . . . . . 42
6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 42 6.2.3. Fragmentation Handling . . . . . . . . . . . . . . . . 42
6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 44 6.2.4. NAT Traversal . . . . . . . . . . . . . . . . . . . . 44
7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 44 7. Lower-Layer Security . . . . . . . . . . . . . . . . . . . . . 44
8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 44 8. Protocol Transactions . . . . . . . . . . . . . . . . . . . . 45
8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 45 8.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 45
8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46 8.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 46
8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 46 8.3.1. Request Retransmission Timer, T1 . . . . . . . . . . . 46
8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 46 8.3.2. Response Retransmission Timer, T2 . . . . . . . . . . 46
8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 47 8.3.3. Timer Values . . . . . . . . . . . . . . . . . . . . . 46
9. Authentication and Authorization . . . . . . . . . . . . . . . 47 9. Authentication and Authorization . . . . . . . . . . . . . . . 47
9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 48 9.1. TLS/DTLS Based Mutual Authentication . . . . . . . . . . . 48
10. Floor Participant Operations . . . . . . . . . . . . . . . . . 48 10. Floor Participant Operations . . . . . . . . . . . . . . . . . 48
10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 49 10.1. Requesting a Floor . . . . . . . . . . . . . . . . . . . . 49
10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 49 10.1.1. Sending a FloorRequest Message . . . . . . . . . . . . 49
10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 49 10.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 50
10.1.3. Reception of a Subsequent FloorRequestStatus 10.1.3. Reception of a Subsequent FloorRequestStatus
Message . . . . . . . . . . . . . . . . . . . . . . . 51 Message . . . . . . . . . . . . . . . . . . . . . . . 51
10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 51 10.2. Cancelling a Floor Request and Releasing a Floor . . . . . 51
10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 51 10.2.1. Sending a FloorRelease Message . . . . . . . . . . . . 51
10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 52 10.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 52
11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 52 11. Chair Operations . . . . . . . . . . . . . . . . . . . . . . . 52
11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 52 11.1. Sending a ChairAction Message . . . . . . . . . . . . . . 52
11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 54 11.2. Receiving a Response . . . . . . . . . . . . . . . . . . . 54
12. General Client Operations . . . . . . . . . . . . . . . . . . 54 12. General Client Operations . . . . . . . . . . . . . . . . . . 54
12.1. Requesting Information about Floors . . . . . . . . . . . 54 12.1. Requesting Information about Floors . . . . . . . . . . . 54
12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 54 12.1.1. Sending a FloorQuery Message . . . . . . . . . . . . . 54
12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 55 12.1.2. Receiving a Response . . . . . . . . . . . . . . . . . 55
12.1.3. Reception of a Subsequent FloorStatus Message . . . . 55 12.1.3. Reception of a Subsequent FloorStatus Message . . . . 56
12.2. Requesting Information about Floor Requests . . . . . . . 56 12.2. Requesting Information about Floor Requests . . . . . . . 56
12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 56 12.2.1. Sending a FloorRequestQuery Message . . . . . . . . . 56
12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 56 12.2.2. Receiving a Response . . . . . . . . . . . . . . . . . 56
12.3. Requesting Information about a User . . . . . . . . . . . 57 12.3. Requesting Information about a User . . . . . . . . . . . 57
12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 57 12.3.1. Sending a UserQuery Message . . . . . . . . . . . . . 57
12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 57 12.3.2. Receiving a Response . . . . . . . . . . . . . . . . . 58
12.4. Obtaining the Capabilities of a Floor Control Server . . . 58 12.4. Obtaining the Capabilities of a Floor Control Server . . . 58
12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 58 12.4.1. Sending a Hello Message . . . . . . . . . . . . . . . 58
12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 58 12.4.2. Receiving Responses . . . . . . . . . . . . . . . . . 58
13. Floor Control Server Operations . . . . . . . . . . . . . . . 59 13. Floor Control Server Operations . . . . . . . . . . . . . . . 59
13.1. Reception of a FloorRequest Message . . . . . . . . . . . 59 13.1. Reception of a FloorRequest Message . . . . . . . . . . . 59
13.1.1. Generating the First FloorRequestStatus Message . . . 60 13.1.1. Generating the First FloorRequestStatus Message . . . 60
13.1.2. Generation of Subsequent FloorRequestStatus 13.1.2. Generation of Subsequent FloorRequestStatus
Messages . . . . . . . . . . . . . . . . . . . . . . . 61 Messages . . . . . . . . . . . . . . . . . . . . . . . 61
13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 62 13.2. Reception of a FloorRequestQuery Message . . . . . . . . . 62
13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 63 13.3. Reception of a UserQuery Message . . . . . . . . . . . . . 64
13.4. Reception of a FloorRelease Message . . . . . . . . . . . 65 13.4. Reception of a FloorRelease Message . . . . . . . . . . . 65
13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 66 13.5. Reception of a FloorQuery Message . . . . . . . . . . . . 66
13.5.1. Generation of the First FloorStatus Message . . . . . 67 13.5.1. Generation of the First FloorStatus Message . . . . . 67
13.5.2. Generation of Subsequent FloorStatus Messages . . . . 68 13.5.2. Generation of Subsequent FloorStatus Messages . . . . 68
13.6. Reception of a ChairAction Message . . . . . . . . . . . . 68 13.6. Reception of a ChairAction Message . . . . . . . . . . . . 69
13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 69 13.7. Reception of a Hello Message . . . . . . . . . . . . . . . 70
13.8. Error Message Generation . . . . . . . . . . . . . . . . . 70 13.8. Error Message Generation . . . . . . . . . . . . . . . . . 70
14. Security Considerations . . . . . . . . . . . . . . . . . . . 70 14. Security Considerations . . . . . . . . . . . . . . . . . . . 71
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72
15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 72 15.1. Attribute Subregistry . . . . . . . . . . . . . . . . . . 72
15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 73 15.2. Primitive Subregistry . . . . . . . . . . . . . . . . . . 73
15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 73 15.3. Request Status Subregistry . . . . . . . . . . . . . . . . 74
15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 74 15.4. Error Code Subregistry . . . . . . . . . . . . . . . . . . 75
16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 75 16. Changes from RFC 4582 . . . . . . . . . . . . . . . . . . . . 76
16.1. Extensions for an unreliable transport . . . . . . . . . . 75 16.1. Extensions for an unreliable transport . . . . . . . . . . 76
16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 76 16.2. Other changes . . . . . . . . . . . . . . . . . . . . . . 77
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 77 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79
18.1. Normative References . . . . . . . . . . . . . . . . . . . 78 18.1. Normative References . . . . . . . . . . . . . . . . . . . 79
18.2. Informational References . . . . . . . . . . . . . . . . . 78 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 . . . . . . . . . . . . . . . . . . . . . . 80 Transport . . . . . . . . . . . . . . . . . . . . . . 81
Appendix B. Motivation for Supporting an Unreliable Transport . . 83 Appendix B. Motivation for Supporting an Unreliable Transport . . 85
B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 84 B.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 85
B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 85 B.1.1. Alternatives Considered . . . . . . . . . . . . . . . 86
B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 85 B.1.1.1. ICE TCP . . . . . . . . . . . . . . . . . . . . . 86
B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 86 B.1.1.2. Teredo . . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 86 B.1.1.3. GUT . . . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 86 B.1.1.4. UPnP IGD . . . . . . . . . . . . . . . . . . . . . 87
B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.5. NAT PMP . . . . . . . . . . . . . . . . . . . . . 88
B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 87 B.1.1.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . 88
B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 87 B.1.1.7. BFCP over UDP transport . . . . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 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.
The Requirements for Floor Control Protocol [13] list a set of The Requirements for Floor Control Protocol [13] list a set of
skipping to change at page 17, line 22 skipping to change at page 17, line 22
| Transaction ID | User ID | | Transaction ID | User ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Offset (if F is set) | Fragment Length (if F is set) | | Fragment Offset (if F is set) | Fragment Length (if F is set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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, i.e. as in [2]. The version field MUST be set to 2 when transport. The version field MUST be set to 2 when using BFCP over
using BFCP over an unreliable transport with the extensions specified an unreliable transport. If a floor control server receives a
in this document. If an endpoint receives a message with an message with an unsupported version field value, and the extensions
unsupported version field value, 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. indicate this. Note that endpoints supporting only the RFC 4582
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 25, line 5 skipping to change at page 25, line 5
| 9 | Use TLS | | 9 | Use TLS |
| 10 | Unable to Parse Message | | 10 | Unable to Parse Message |
| 11 | Use DTLS | | 11 | Use DTLS |
| 12 | Unsupported Version | | 12 | Unsupported Version |
| 13 | Incorrect Message Length | | 13 | Incorrect Message Length |
| 14 | Generic Error | | 14 | Generic Error |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Table 5: Error Code meaning Table 5: Error Code meaning
Note: The Generic Error error code is intended to be used by a Note: The Generic Error error code is intended to be used when an
BFCP entity when an error occurs and the other specific error error occurs and the other specific error codes do not apply.
codes do not apply.
Error Specific Details: Present only for certain Error Codes. In Error Specific Details: Present only for certain Error Codes. In
this document, only for Error Code 4 (Unknown Mandatory Attribute). this document, only for Error Code 4 (Unknown Mandatory Attribute).
See Section 5.2.6.1 for its definition. See Section 5.2.6.1 for its definition.
Padding: One, two, or three octets of padding added so that the Padding: One, two, or three octets of padding added so that the
contents of the ERROR-CODE attribute is 32-bit aligned. If the contents of the ERROR-CODE attribute is 32-bit aligned. If the
attribute is already 32-bit aligned, no padding is needed. attribute is already 32-bit aligned, no padding is needed.
The Padding bits MUST be set to zero by the sender and MUST be The Padding bits MUST be set to zero by the sender and MUST be
skipping to change at page 41, line 44 skipping to change at page 41, line 44
server, it is REQUIRED that the client send a Goodbye message to server, it is REQUIRED that the client send a Goodbye message to
dissociate itself from any allocated resources. If a floor control dissociate itself from any allocated resources. If a floor control
server wishes to end its BFCP connection with a client (e.g., the server wishes to end its BFCP connection with a client (e.g., the
Focus of the conference informs the floor control server that the Focus of the conference informs the floor control server that the
client has been kicked out from the conference), it is REQUIRED that client has been kicked out from the conference), it is REQUIRED that
the floor control server send a Goodbye message towards the client. the floor control server send a Goodbye message towards the client.
6.2.1. Congestion Control 6.2.1. Congestion Control
BFCP may be characterized to generate "low data-volume" traffic, per BFCP may be characterized to generate "low data-volume" traffic, per
the classification in [25]. Nevertheless is it necessary to ensure the classification in [26]. Nevertheless is it necessary to ensure
suitable and necessary congestion control mechanisms are used for suitable and necessary congestion control mechanisms are used for
BFCP over UDP. As described in Section 6.2, within the same BFCP BFCP over UDP. As described in Section 6.2, within the same BFCP
connection, every entity - client or server - is only allowed to send connection, every entity - client or server - is only allowed to send
one request at a time, and await the acknowledging response. This one request at a time, and await the acknowledging response. This
way at most one datagram is sent per RTT given the message is not way at most one datagram is sent per RTT given the message is not
lost during transmission. In case the message is lost, the request lost during transmission. In case the message is lost, the request
retransmission timer T1 specified in Section 8.3.1 will fire and the retransmission timer T1 specified in Section 8.3.1 will fire and the
message is retransmitted up to three times, in addition to the message is retransmitted up to three times, in addition to the
original transmission of the message. The default initial interval original transmission of the message. The default initial interval
MUST be set to 500ms and the interval MUST be doubled after each MUST be set to 500ms and the interval MUST be doubled after each
skipping to change at page 44, line 17 skipping to change at page 44, line 17
One of the key benefits when using UDP for BFCP communication is the One of the key benefits when using UDP for BFCP communication is the
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
[15]. [15].
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 [11] Binding unreliable transport are RECOMMENDED to use STUN [11] Binding
Indication for keep-alives, as described for ICE [15]. [23], Section Indication for keep-alives, as described for ICE [15]. Section 6.7
6.7 provides useful recommendations for middlebox interaction when of [23] provides useful recommendations for middlebox interaction
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 [11]. and BFCP packets even without checking the STUN magic cookie [11].
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
recommended for RTP/RTCP [10]. recommended for RTP/RTCP [10].
skipping to change at page 44, line 41 skipping to change at page 44, line 41
7. Lower-Layer Security 7. Lower-Layer Security
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 [6] and MUST support DTLS [7] MUST support TLS for transport over TCP [6] and MUST support DTLS [7]
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 ciphersuite [6]. TLS_RSA_WITH_AES_128_CBC_SHA cipher suite [6] for backwards
compatibility with existing implementations of RFC 4582. In
accordance with the recommendations and guidelines in [24], BFCP
entities SHOULD support the following cipher suites:
o TLS_DHE_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_ECDHE_RSA_WITH_AES_256_GCM_SHA384
8. Protocol Transactions 8. Protocol Transactions
In BFCP, there are two types of transactions: client-initiated In BFCP, there are two types of transactions: client-initiated
transactions and server-initiated transactions. transactions and server-initiated transactions.
Client-initiated transactions consist of a request from a client to a Client-initiated transactions consist of a request from a client to a
floor control server and a response from the floor control server to floor control server and a response from the floor control server to
the client. The request carries a Transaction ID in its common the client.
header, which the floor control server copies into the response.
Clients use Transaction ID values to match responses with previously
issued requests.
Server-initiated transactions have different requirements and Server-initiated transactions have different requirements and
behavior depending on underlying transport: behavior depending on underlying transport:
When using a reliable transport, server-initiated transactions When using a reliable transport, server-initiated transactions
consist of a single message from a floor control server to a consist of a single message from a floor control server to a
client (notifications). Since they do not trigger any response, client (notifications). They do not trigger any response.
their Transaction ID is set to 0.
When using an unreliable transport, server-initiated transactions When using an unreliable transport, server-initiated transactions
consist of a request from a floor control server to a client and a consist of a request from a floor control server to a client and a
response from the client to the floor control server. The response from the client to the floor control server.
Transaction ID MUST be non-zero and unique in the context of
outstanding transactions over an unreliable transport. The
request carries a Transaction ID in its common header, which the
client copies into the response. Floor control servers use
Transaction ID values to match responses with previously issued
requests.
When using BFCP over an unreliable transport, it is important that
the initiator of a transaction choose a Transaction ID value that
lets the receiver distinguish the reception of the next message in a
sequence of BFCP messages from a retransmission of a previous
message. Therefore, BFCP entities using an unreliable transport MUST
use monotonically increasing Transaction ID values (except for wrap-
around).
When using BFCP over an unreliable transport, retransmission timer T1 When using BFCP over an unreliable transport, retransmission timer T1
(see Section 8.3) MUST be used for all requests until the transaction (see Section 8.3) MUST be used for all requests until the transaction
is completed. is completed.
8.1. Client Behavior 8.1. Client Behavior
A client starting a client-initiated transaction MUST set the A client starting a client-initiated transaction MUST set the
Conference ID in the common header of the message to the Conference Conference ID in the common header of the message to the Conference
ID for the conference that the client obtained previously. ID for the conference that the client obtained previously.
The client MUST set the Transaction ID value in the common header to 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 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 another message from the client until a response from the server is
received for the transaction. The client uses the Transaction ID received for the transaction. The client uses the Transaction ID
value to match this message with the response from the floor control value to match this message with the response from the floor control
server. server. When using BFCP over an unreliable transport, it is
important to choose a Transaction ID value that lets the receiver
distinguish the reception of the next message in a sequence of BFCP
messages from a retransmission of a previous message. Therefore,
BFCP entities using an unreliable transport MUST use monotonically
increasing Transaction ID values (except for wrap-around).
A client receiving a server-initiated transaction over an unreliable
transport MUST copy the Transaction ID from the request received from
the server into the response.
8.2. Server Behavior 8.2. Server Behavior
A floor control server sending a response within a client-initiated A floor control server sending a response within a client-initiated
transaction MUST copy the Conference ID, the Transaction ID, and the transaction MUST copy the Conference ID, the Transaction ID, and the
User ID from the request received from the client into the response. User ID from the request received from the client into the response.
Server-initiated transactions MUST contain a Transaction ID equal to Server-initiated transactions MUST contain a Transaction ID equal to
0 when BFCP is used over a reliable transport. Over an unreliable 0 when BFCP is used over a reliable transport. Over an unreliable
transport, the Transaction ID shall have the same properties as for transport, the Transaction ID shall have the same properties as for
client-initiated transactions: the server MUST set the Transaction ID client-initiated transactions. The server uses the Transaction ID
value in the common header to a number that is different from 0 and value to match this message with the response from the floor
that MUST NOT be reused, i.e. monotonically increasing values as participant or floor chair.
defined in Section 8. The server uses the Transaction ID value to
match this message with the response from the floor participant or
floor chair.
8.3. Timers 8.3. Timers
When BFCP entities are communicating over an unreliable transport, When BFCP entities are communicating over an unreliable transport,
two retransmission timers are employed to help mitigate against loss two retransmission timers are employed to help mitigate against loss
of datagrams. Retransmission and response caching are not required of datagrams. Retransmission and response caching are not required
when BFCP entities communicate over a reliable transport. when BFCP entities communicate over a reliable transport.
8.3.1. Request Retransmission Timer, T1 8.3.1. Request Retransmission Timer, T1
skipping to change at page 46, line 42 skipping to change at page 46, line 39
retransmissions have occurred. The timer doubles on each re- retransmissions have occurred. The timer doubles on each re-
transmit, failing after three unacknowledged retransmission attempts. transmit, failing after three unacknowledged retransmission attempts.
If a valid response is not received for a client- or server-initiated If a valid response is not received for a client- or server-initiated
transaction, the implementation MUST consider the BFCP connection as transaction, the implementation MUST consider the BFCP connection as
failed. Implementations SHOULD follow the reestablishment procedure failed. Implementations SHOULD follow the reestablishment procedure
described in section 6. described in section 6.
8.3.2. Response Retransmission Timer, T2 8.3.2. Response Retransmission Timer, T2
T2 is a timer that, when fires, signals that the BFCP entity can T2 is a timer that, when fired, signals that the BFCP entity can
release knowledge of the transaction against which it is running. It release knowledge of the transaction against which it is running. It
is started upon the first transmission of the response to a request is started upon the first transmission of the response to a request
and is the only mechanism by which that response is released by the and is the only mechanism by which that response is released by the
BFCP entity. Any subsequent retransmissions of the same request can BFCP entity. Any subsequent retransmissions of the same request can
be responded to by replaying the cached response, whilst that value be responded to by replaying the cached response, whilst that value
is retained until the timer has fired. Refer to Section 6.2.3 for is retained until the timer has fired. Refer to Section 6.2.3 for
the role this timer has in the fragmentation handling scheme. the role this timer has in the fragmentation handling scheme.
8.3.3. Timer Values 8.3.3. Timer Values
skipping to change at page 47, line 39 skipping to change at page 47, line 34
extra 2.5s is added to take into account potential messages in extra 2.5s is added to take into account potential messages in
transit due to latency. transit due to latency.
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
conference is authenticated and confidentiality and integrity
protected, and the extensions in this document is supported, the BFCP
clients MUST authenticate the floor control server and the floor
control servers MUST authenticate a client before communicating as
described above. Note that endpoints supporting only the RFC 4582
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
need to authorize them. On receiving an authenticated BFCP message, need to authorize them. On receiving an authenticated BFCP message,
the floor control server checks whether the client sending the the floor control server checks whether the client sending the
skipping to change at page 70, line 9 skipping to change at page 70, line 17
On reception of a Hello message, the floor control server follows the On reception of a Hello message, the floor control server follows the
rules in Section 9 that relate to client authentication. If while rules in Section 9 that relate to client authentication. If while
processing the Hello message, the floor control server encounters an processing the Hello message, the floor control server encounters an
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, the receiving version given in the Hello message is not supported, and the
server MUST instead send an Error message with parameter value 12 extensions in this document is supported, the receiving server MUST
(Unsupported Version). instead send an Error message with parameter value 12 (Unsupported
Version). Note that endpoints supporting only the RFC 4582 subset
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
the Conference ID, the Transaction ID, and the User ID from the Hello the Conference ID, the Transaction ID, and the User ID from the Hello
skipping to change at page 71, line 5 skipping to change at page 71, line 14
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 non-null and confidentiality. It is RECOMMENDED that TLS/DTLS with an
encryption always be used. BFCP entities MAY use other security encryption algorithm according to Section 7 always be used and in
mechanisms as long as they provide similar security properties. cases where signaling/control traffic is properly protected, as
described in Section 9 it is REQUIRED to use a mandated encryption
algorithm. BFCP entities MAY use other security mechanisms as long
as they 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 high-jack the TLS/DTLS connection and, that attackers cannot hijack the TLS/DTLS connection and, therefore,
therefore, that messages over the TLS/DTLS connection come from the that messages over the TLS/DTLS connection come from the client that
client that was initially authenticated. was initially authenticated.
An attacker may attempt to impersonate a floor control server. A An attacker may attempt to impersonate a floor control server. A
successful attacker would be able to make clients think that they successful attacker would be able to make clients think that they
hold a particular floor so that they would try to access a resource hold a particular floor so that they would try to access a resource
(e.g., sending media) without having legitimate rights to access it. (e.g., sending media) without having legitimate rights to access it.
Floor control server impersonation is avoided by having servers only Floor control server impersonation is avoided by having servers only
accept BFCP messages over authenticated TLS/DTLS connections, as well accept BFCP messages over authenticated TLS/DTLS connections, as well
as ensuring clients only send and accept messages over authenticated as ensuring clients only send and accept messages over authenticated
TLS/DTLS connections. TLS/DTLS connections.
skipping to change at page 71, line 45 skipping to change at page 72, line 9
a floor control server and replay it over a connection between the a floor control server and replay it over a connection between the
attacker and the floor control server. This attack is prevented by attacker and the floor control server. This attack is prevented by
having floor control servers check that messages arriving over a having floor control servers check that messages arriving over a
given authenticated TLS/DTLS connection use an authorized user ID given authenticated TLS/DTLS connection use an authorized user ID
(i.e., a user ID that the user that established the authenticated (i.e., a user ID that the user that established the authenticated
TLS/DTLS connection is allowed to use). TLS/DTLS connection is allowed to use).
Attackers may attempt to pick messages from the network to get access Attackers may attempt to pick messages from the network to get access
to confidential information between the floor control server and a to confidential information between the floor control server and a
client (e.g., why a floor request was denied). TLS/DTLS client (e.g., why a floor request was denied). TLS/DTLS
confidentiality prevents this attack. Therefore, it is RECOMMENDED confidentiality prevents this attack. Therefore, it is REQUIRED that
that TLS/DTLS be used with a non-null encryption algorithm. TLS/DTLS be used with an encryption algorithm according to Section 7.
15. IANA Considerations 15. IANA Considerations
[Editorial note: This section instructs the IANA to register new [Editorial note: 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
skipping to change at page 78, line 32 skipping to change at page 79, line 32
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. and T. Kristensen, "Session Description Protocol
(SDP) Format for Binary Floor Control Protocol (BFCP) Streams", (SDP) Format for Binary Floor Control Protocol (BFCP) Streams",
draft-ietf-bfcpbis-rfc4583bis-10 (work in progress), draft-ietf-bfcpbis-rfc4583bis-11 (work in progress),
October 2014. February 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
skipping to change at page 79, line 39 skipping to change at page 80, line 39
IP version 6", RFC 1981, August 1996. IP version 6", RFC 1981, August 1996.
[22] Mathis, M. and J. Heffner, "Packetization Layer Path MTU [22] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[23] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for [23] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for
Establishing a Secure Real-time Transport Protocol (SRTP) Establishing a Secure Real-time Transport Protocol (SRTP)
Security Context Using Datagram Transport Layer Security Security Context Using Datagram Transport Layer Security
(DTLS)", RFC 5763, May 2010. (DTLS)", RFC 5763, May 2010.
[24] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network [24] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for
Secure Use of TLS and DTLS", draft-ietf-uta-tls-bcp-09 (work in
progress), February 2015.
[25] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
Address Translations (NATs)", RFC 4380, February 2006. Address Translations (NATs)", RFC 4380, February 2006.
[25] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for [26] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
Application Designers", BCP 145, RFC 5405, November 2008. Application Designers", BCP 145, RFC 5405, November 2008.
[26] Thaler, D., "Teredo Extensions", RFC 6081, January 2011. [27] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
[27] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, [28] Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
September 2007. September 2007.
[28] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP [29] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP
Candidates with Interactive Connectivity Establishment (ICE)", Candidates with Interactive Connectivity Establishment (ICE)",
RFC 6544, March 2012. RFC 6544, March 2012.
[29] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling [30] Manner, J., Varis, N., and B. Briscoe, "Generic UDP Tunnelling
(GUT)", draft-manner-tsvwg-gut-02 (work in progress), (GUT)", draft-manner-tsvwg-gut-02 (work in progress),
July 2010. July 2010.
[30] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of [31] Stucker, B., Tschofenig, H., and G. Salgueiro, "Analysis of
Middlebox Interactions for Signaling Protocol Communication Middlebox Interactions for Signaling Protocol Communication
along the Media Path", along the Media Path",
draft-ietf-mmusic-media-path-middleboxes-05 (work in progress), draft-ietf-mmusic-media-path-middleboxes-05 (work in progress),
July 2012. July 2012.
[31] Guha, S. and P. Francis, "Characterization and Measurement of [32] Guha, S. and P. Francis, "Characterization and Measurement of
TCP Traversal through NATs and Firewalls", 2005, TCP Traversal through NATs and Firewalls", 2005,
<http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>. <http://saikat.guha.cc/pub/imc05-tcpnat.pdf/>.
[32] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer [33] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
Communication Across Network Address Translators", April 2005, Communication Across Network Address Translators", April 2005,
<http://www.brynosaurus.com/pub/net/p2pnat.pdf/>. <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 84, line 36 skipping to change at page 85, line 41
+----+ +----+ +----+ +----+
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
[30]. [31].
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
[28]. A broad study of NAT behavior and peer-to-peer TCP [29]. 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 [31]. The possible to establish a TCP connection in 11% of the cases [32]. 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 [32]. UDP than when using TCP [33].
It is worth noticing that BFCP over UDP were already 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 would co- situation where multiple different and non-interoperable
exist in the market. The purpose of this draft is to formalize and implementations would co-exist in the market. The purpose of this
publish the extension from the standard specification to facilitate draft is to formalize and publish the extension from the standard
complete interoperability between implementations. specification to facilitate complete interoperability between
implementations.
B.1.1. Alternatives Considered B.1.1. Alternatives Considered
In selecting the approach of defining UDP as an alternate transport In selecting the approach of defining UDP as an alternate transport
for BFCP, several alternatives were considered and explored to some for BFCP, several alternatives were considered and explored to some
degree. Each of these is discussed briefly in the following degree. Each of these is discussed briefly in the following
subsections. In summary, while the not chosen alternatives work in a subsections. In summary, while the not chosen alternatives work in a
number of scenarios, they are not sufficient, in and of themselves, number of scenarios, they are not sufficient, in and of themselves,
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 [28] extends ICE to TCP based media, including the ability to ICE TCP [29] 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 [28]) than enabling UDP connectivity in the same (see Appendix A of [29]) 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 [28] should increase the advocated for candidate collection in [29] 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 [24] enables nodes located behind one or more IPv4 NATs to Teredo [25] 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 [26] provide additional capabilities to Teredo, including extensions [27] 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"
[24]. These servers and relays generally do not exist in the [25]. 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 [29] attempts to facilitate tunneling over UDP by encapsulating GUT [30] 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 87, line 28 skipping to change at page 88, line 33
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
[27], and then tunnel SCTP over UDP in the use case described in [28], and then tunnel SCTP over UDP in the use case described in
Appendix B.1. SCTP is gaining some momentum currently. There is Appendix B.1. SCTP is gaining some momentum currently. There is
ongoing discussion in the RTCWeb WG regarding this approach. ongoing discussion in the RTCWeb WG regarding this approach.
However, this approach for tunneling over UDP was not mature enough However, this approach for tunneling over UDP was not mature enough
when considered and not even fully specified. 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
[25]. [26].
Minor changes to the transaction model are introduced in that all Minor changes to the transaction model are introduced in that all
requests now have an appropriate response to complete the requests now have an appropriate response to complete the
transaction. The requests are sent with a retransmit timer transaction. The requests are sent with a retransmit timer
associated with the response to achieve reliability. This associated with the response to achieve reliability. This
alternative does not change the semantics of BFCP. It permits UDP as alternative does not change the semantics of BFCP. It permits UDP as
an alternate transport. an alternate transport.
Existing implementations, in the spirit of the approach detailed in Existing implementations, in the spirit of the approach detailed in
earlier versions of this draft, have demonstrated this approach to be earlier versions of this draft, have demonstrated this approach to be
skipping to change at page 88, line 15 skipping to change at page 89, line 19
achieved at previous interoperability events. The authors view this achieved at previous interoperability events. The authors view this
extension as a pragmatic solution to an existing deployment extension as a pragmatic solution to an existing deployment
challenge. This is the chosen approach, and the extensions is challenge. This is the chosen approach, and the extensions is
specified in this document. specified in this document.
Authors' Addresses Authors' Addresses
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 FI-02420 Jorvas
Finland Finland
Email: gonzalo.camarillo@ericsson.com Email: gonzalo.camarillo@ericsson.com
Keith Drage Keith Drage
Alcatel-Lucent Alcatel-Lucent
Quadrant, StoneHill Green, Westlea Quadrant, StoneHill Green, Westlea
Swindon, Wilts Swindon, Wilts
UK UK
Email: drage@alcatel-lucent.com Email: drage@alcatel-lucent.com
Tom Kristensen Tom Kristensen
Cisco Cisco
Philip Pedersens vei 1 Philip Pedersens vei 1
N-1366 Lysaker NO-1366 Lysaker
Norway Norway
Email: tomkrist@cisco.com, tomkri@ifi.uio.no Email: tomkrist@cisco.com, tomkri@ifi.uio.no
Joerg Ott Joerg Ott
Aalto University Aalto University
Otakaari 5 A Otakaari 5 A
Espoo, FIN 02150 FI-02150 Espoo
Finland Finland
Email: jo@comnet.tkk.fi Email: jo@comnet.tkk.fi
Charles Eckel Charles Eckel
Cisco Cisco
707 Tasman Drive 707 Tasman Drive
California, CA 95035 California, CA 95035
United States United States
Email: eckelcu@cisco.com Email: eckelcu@cisco.com
 End of changes. 60 change blocks. 
121 lines changed or deleted 137 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/