RFC 4376

Requirements for Floor Control Protocols

📅 published February 2006, from ietf

RFC 4376: Requirements for Floor Control Protocols 🎀

Okay bestie, here's the whole vibe of this one. RFC 4376 is titled Requirements for Floor Control Protocols 💖

  • Authors: P. Koskelainen (Nokia), J. Ott (Helsinki University of Technology), H. Schulzrinne (Columbia University), and X. Wu (Columbia University) 🧚
  • Category: Informational, so it's giving "here's some info," not a binding standard 📚
  • Date: February 2006 📅
  • Obsoletes/Updates: The header doesn't list any RFCs it obsoletes or updates, so there's nothing to report there ✨

Status of This Memo 📝

This memo is here to share info with the Internet community. It is not a standard of any kind. You can distribute it as much as you want, no restrictions 🦋

Copyright (C) The Internet Society (2006). 💜

Abstract 🌸

Okay so, floor control is how you manage joint or exclusive access to shared resources in a (multiparty) conferencing setup. It's the main character of the group call, deciding who gets to talk or use the shared thing 👑 It works alongside other stuff like conference and media session setup, conference policy changes, and media control, which are handled by other protocols. This document lays out the requirements for a floor control protocol for multiparty conferences, within an existing framework. Iconic 💅

Table of Contents 🗂️

1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Model ...........................................................4
5. Integration with Conferencing ...................................5
6. Assumptions about a Conference Policy ...........................6
7. Floor Control Protocol Requirements .............................7
   7.1. Communication between Participant and Server ...............7
   7.2. Communication between Chair and Server .....................9
   7.3. General Protocol Requirements ..............................9
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................12
   10.1. Normative References .....................................12
   10.2. Informative References ...................................12

1. Introduction ✨

Okay so conference apps have shared stuff, right? Like the right to talk, input access to a limited-bandwidth video channel, or a pointer or input focus in a shared app 🎤

A lot of the time, you want to control who gets to provide input (send, write, or control, depending on the app) to that shared resource 🫶

Floor control is what lets apps or users get safe, mutually exclusive or non-exclusive input access to the shared object or resource. The floor is a temporary access or manipulation permission for a specific shared resource (or group of resources) [6]. Iconic, honestly 🔥

Floor control is optional for conferencing apps. SIP [2] conferencing apps can also just skip it completely 🙈 Two-party apps can use floor control outside of conferencing, though it's not super useful in that case. Floor control can be used together with the conference policy control protocol (CPCP) [7], or it can be a stand-alone protocol, for example with SIP but without CPCP 🦋

People have studied floor control for years (see [8], [6], and [5]), so we can build on earlier work. Smart, right? 🧠

This document describes the requirements for a floor control protocol. Since it's a requirements spec, it doesn't assume anything about how those requirements get implemented later, whether that's in one protocol or several, or about which entities do the work and what roles they have 💅

This document can be used alongside other docs, like the conferencing framework document [3]. When it talks about a floor control server, that server might be the same as the focus or a conference policy server from the framework document, or be located with one of them. The participants and floor chairs mentioned here can just be regular participants from the framework document 🧚 In this spec, "floor control protocol" is an abstract idea. It might eventually map onto any of the existing conference control or other signaling protocols (including CPCP and SIP). Defining those connections is left to a concrete floor control protocol spec 💖

2. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. These are the words that carry the actual weight, so pay attention to them 👀

3. Terminology 📚

This document uses the definitions from [3].

Here are some more definitions that also apply:

  • Floor: A permission to access or manipulate a specific shared resource, or a set of resources, temporarily 🌈
  • Conference owner: A privileged user who controls the conference, creates floors, and assigns and deassigns floor chairs. The conference owner doesn't have to be a member of the conference 👑
  • Floor chair: A user (or an entity) who manages one floor by granting, denying, or revoking it. The floor chair doesn't have to be a member of the conference either 🧚
  • Floor control: A mechanism that lets apps or users get safe, mutually exclusive or non-exclusive input access to the shared object or resource 🫶
  • Floor control server: A logical entity that keeps track of the state of the floor(s), including which floors exist, who the floor chairs are, who holds a floor, and so on. Requests to manipulate a floor get sent to the floor control server 🍓
  • Floor request set: A logical data structure holding all the requests for a particular floor at a given point in time 🌸
  • Floor holder set: A logical data structure identifying all the participants who currently hold the floor 💜

4. Model 🧩

The floor control model has three logical entities: one floor control server, one or more floor chairs (moderators), and any number of regular conference participants 🎀

A floor control protocol carries floor control messages between the floor chairs (moderators) of the conference, the floor control server, and the conference participants. The architecture is centralized, meaning all messages go through one point, the floor control server 🦋 Granting or rejecting floor control requests is handled by one or more floor chairs, or by the server itself, depending on the policy 👑

Requests from participants get received by the floor control server and stored (at the floor control protocol level) in a floor request set. There's no particular order to them. The current floor holders are reflected in a current floor holder set. Floor chairs can change both sets to grant, revoke, reject, and pass the floor, for example 💅

The order in which requests get processed, whether they're granted or rejected, and how many participants get a floor at the same time are decided by a higher-layer application that works on these sets. The floor control protocol doesn't limit any of that 🧚

A floor is tied to one or more media sessions. The centralized conference server manages the floors, so it controls access to those media sessions. This has two sides. 1) The server keeps and shares consistent state info about who holds a given floor at any moment, and it follows some set of rules while doing that. This tells everyone who's allowed to speak (for example), but it depends on everyone cooperating 🫶 2) To stop people from ignoring the "hints" from the floor control server, the server can enforce compliance with floor status. It might do this with other functional entities, for example by blocking media streams from participants who aren't allowed to speak 🔥 The floor control server controls floors at least at the signaling level. Actively controlling the actual (physical) media resources is highly recommended, but that's beyond this document's scope 💀

As the intro mentioned, a real protocol spec that meets the requirements in this memo might map the parts of this model onto the conferencing components defined in the conferencing framework document. Section 5 covers a few of those aspects briefly 🌈

5. Integration with Conferencing 🔗

Floor control doesn't handle privileges like creating floors, appointing floor chairs, or handing chair privileges to other users (or taking them away). Some external mechanism does that instead, such as conference management (for example, CPCP or a web interface for policy changes) 🎀

The conference policy (and therefore the conference owner or creator) decides whether floor control is used at all. Actually enforcing conference media distribution to match each medium's floor status (for example, controlling an audio bridge) is beyond this document's scope. Floor control by itself doesn't define media enforcement. It's up to the conference and media policies to decide which media streams can be used in a conference and which ones are floor controlled 💜

Usually, the conference owner creates the floor(s) using the conference policy control protocol (or some other mechanism) and appoints the floor chair. The conference owner can remove the floor at any time, so a media session stops being floor-controlled, or change the floor chair or floor parameters 👑

The floor chair just controls access to the floor(s), according to the conference policy 🧚

A floor control server is its own logical entity, usually located with the focus and/or conference policy server. That means the floor control server can interact with the focus, the conference policy server, and media servers as needed. How the floor control server communicates with other central conferencing entities is outside the scope of the floor control protocol requirements in this document 🦋

Conferences can be cascaded, so one participant in one conference might represent a second conference (called a subconference). From a floor control perspective, there's no difference between a participant (identified by its URI) that represents one person and a participant that represents a set of subconference(s) 🌸

Note: In the second case, it's the subconference's job to negotiate floor requests internally before passing a request on to the conference, and to assign a floor internally after receiving a floor grant. This can be done recursively by using the floor control protocol with a different floor control server in the subconference 🍓

6. Assumptions about a Conference Policy ✨

okay so the floor control protocol is supposed to manage access to shared resources during a conference 🎀 but the rules for how that works come from the conference policy [4]. the conference's policy decides the rules, and a conference policy control protocol [4] can also define mechanisms that change those rules mid-conference 🦋 this section just lays out what a floor control protocol assumes about the conference policy and how it gets modified 💅

the conference policy is expected to define the rules for floor control. so it isn't the floor control protocol's job to set up or share those rules 🫶

in general, it's assumed that the conference policy also decides who can create, change, and remove a floor in a conference 👑

conference participants and floor chairs should be able to get and set floor-related parameters 💖 the conference policy may restrict who can access or change which parameters 🌸 not every parameter kept for a floor is interpreted by the floor control protocol, though. for example, floor policy descriptions can be stored with a floor but a higher-layer application might be the one that interprets them 🧚 also, changes to the floor control policy are outside the scope of the floor control protocol. they're handled by something like a conference policy control protocol 😭

(for example, it's useful to see who the floor chair is, what kind of policy is in use, the time limits, how many people can hold the floor at once, and who the current floor holder is 💜)

these requirements on a conference policy related to floor control are identified in [4]:

REQ-F1: It MUST be possible to define whether floor control is in use or not.

REQ-F2: It MUST be possible to define the algorithm to be used in granting the floor. (Note: Examples of algorithms are moderator-controlled, FCFS, or random.)

Note: It must be possible to use an automated floor policy where the floor control server decides autonomously about granting and rejecting floor requests as well as revoking the floor. It must also be possible to use a chair-controlled floor policy in which the floor control server notifies the floor chair and waits for the chair to make a decision. This enables the chair to fully control who has the floor. The server MAY forward all requests immediately to the floor chair, or it may do filtering and send only occasional notifications to the chair. 🔥

REQ-F3: It MUST be possible to define how many users can have the floor at the same time.

REQ-F4: It MUST be possible to have one floor for one or more media types.

REQ-F5: It MUST be possible to have multiple floors in a conference.

REQ-F6: It MUST be possible to define whether a floor is moderator-controlled or not.

REQ-F7: If the floor is moderator-controlled, it MUST be possible to assign and replace the floor moderator.

7. Floor Control Protocol Requirements 🦋

this section is all about the requirements for a floor control protocol 🌈 they're grouped like this: 1) floor control protocol between participant and server; 2) floor control protocol between floor chairs and server; 3) floor control server management; and 4) general protocol requirements.

7.1. Communication between Participant and Server 🍓

REQ-PS-1: Participants MUST be able to request (claim) a floor.

REQ-PS-2: It SHOULD be possible for a participant requesting a floor to give additional information about the request, such as the topic of the question for an audio floor. Note: In some scenarios, the floor control server or the floor chair may use this information when granting the floor to the user, or when manipulating the floor sets at the server. ✨

REQ-PS-3: It MUST be possible for a participant to modify (e.g., cancel) a previously placed floor request.

REQ-PS-4: It SHOULD be possible for a participant to initiate a floor control operation (e.g., floor request, release) on behalf of another participant (third-party floor control) provided that he is authorized to do so.

REQ-PS-5: A participant MUST be informed that she has been granted the floor. 🎉

REQ-PS-6: A participant MUST be informed that his floor request has been rejected.

REQ-PS-7: A participant MUST be informed that the floor was revoked from her.

REQ-PS-8: A participant SHOULD be informed that her floor request is pending and will be processed later. ⭐

REQ-PS-9: A floor holder MUST be able to release a floor.

REQ-PS-10: It MUST be possible to notify conference participants of (changes to) the floor holder(s).

REQ-PS-11: It MUST be possible to notify conference participants when a new floor request is being made.

REQ-PS-12: It MUST be possible for a floor requester to request privacy for claiming the floor. there are three flavours of privacy here 🙈

  • anonymous: The participants (including the floor chair) cannot see the floor requester's identity. The floor chairs grant the floor based on the claim id and the topic of the claim.
  • known to the floor chair: Only the floor chair is able to see the floor requester's identity; all other participants do not obtain this information.
  • public: All the participants can see the floor requester's identity.

REQ-PS-13: It MUST be possible for a participant to request privacy for holding the floor along with a floor request. Note that identity information about the participant may become available to others through different means (e.g., application/media protocols or the media itself such as the voice). 💀

7.2. Communication between Chair and Server 👑

REQ-CS-1: It MUST be possible to inform the floor chairs, if present, about a participant's floor request.

It SHOULD be possible to convey additional information the participant may have provided along with her request.

It MUST be possible to hide the requesting participant's identity from the chair, i.e., not to include this identity information in the floor request. 🫣

REQ-CS-2: It MUST be possible to grant a floor to a participant.

REQ-CS-3: It MUST be possible to reject a participant's floor request.

REQ-CS-4: The floor chair MUST be able to revoke a floor from (one of) its current holder(s). Note that the floor chair may also remove pending floor requests from the request set (by rejecting them). 🙅‍♀️

REQ-CS-5: It MUST be possible to notify floor chairs about changes to the floor holder(s).

REQ-CS-6: There SHOULD be operations to manipulate the request set available for floor chair(s). Such a request set SHOULD at least include creating, maintaining, and re-ordering floor requests in a queue and clearing the floor control queue. 🧹

REQ-CS-7: It MUST be possible to hide the identity of a floor chair from a subset or all participants of a conference.

REQ-CS-8: It MUST be possible for a newly assigned floor chair to learn (e.g., inquire) about the existing floor request set. 🌟

7.3. General Protocol Requirements 🔥

REQ-GEN-1: Bandwidth and terminal limitations SHOULD be taken into account in order to ensure that floor control can be efficiently used in mobile environments.

Note that efficient communication by means of minimal-sized messages may contradict the desire to express reasons for requesting a floor along with other information. Therefore, a floor control protocol SHOULD be designed in a way that it allows for expressive as well as minimal messaging, as a (negotiable) configuration option and/or selectable on a per-message basis. 📱

REQ-GEN-2: The floor control MUST be a reliable client-server protocol. Hence, it MUST provide a positive response indicating that a request has been received or an error response if an error has occurred. 💯

REQ-GEN-3: It MUST be possible for the floor control server to authenticate participants and chairs.

REQ-GEN-4: It MUST be possible for the participants and chairs to authenticate the server.

REQ-GEN-5: It MUST be possible to ensure message integrity between participants and chairs and the floor control server.

REQ-GEN-6: It MUST be possible to ensure the privacy of messages exchanged between participants and chairs and the floor control server. 🔐

8. Security Considerations 🔐💖

okay bestie, this section is SERIOUS and I'm not gonna pretend it isn't 😭. floor control messages go back and forth between regular participants and the floor control server, AND between the floor control server and the floor chair(s). 🫶

so like, floor control is the thing that decides who gets to contribute to a conference, and it can do that in all kinds of ways: speaking, being seen, writing, whatever the conferencing apps support. 🎀 which means if the floor control messages aren't protected, an attacker could stop people from being "heard" 🙊 (think: in a setup where silence is treated as consent, that's a whole mess). or they could make people be heard when they DON'T know it, like eavesdropping on someone's mic 😳. this gets extra spicy when floor control works with one or more central entities, like a media mixer, that the floor control server uses to enforce its decisions. an attacker could basically mute someone completely 💀.

now the participant side. communications between a participant and the floor control server are open to all kinds of masquerading attacks, and it's giving chaos:

  • if an attacker can spoof the participant's identity or inject messages as them, they can send floor requests (like a floor release) and keep the participant from participating properly. 🙅‍♀️
  • if an attacker can inject messages to the participant, they can make up responses and false status info. 🤥
  • if an attacker can impersonate the floor control server, the participant's requests may never reach the real one. 😱
  • if an attacker can intercept messages from either side (a man in the middle, or MITM 🕵️‍♀️), they can suppress, alter, or inject messages, which means they can mess with the participant's view of the conference floor status AND the server's view of the participant. 🌀

the chair side is similar vibes. 💅

  • if an attacker can intercept messages from either side, they might defer or prevent responses to floor control requests from a particular floor chair. 🙄
  • if they can inject messages (especially going from the floor chair to the floor control server), they can steer who gets which conference floor. 👑
  • if interception AND injection are both possible (MITM again), the attacker can create an arbitrary picture of the conference for the floor chair. 🖼️
  • if an attacker can impersonate a floor chair, then with a single chair they can rule the floor assignments 👑, and with multiple chairs they can wreck the conference with arbitrary and potentially conflicting requests, responses, and assignments 💥. in that second case, how much damage one attacker can do depends on the floor control policy. 📋

and finally, attackers can eavesdrop on floor control communications and learn who's present, how active they are, who the floor chairs are, and more. 👀

so how do we stop all this? 🛡️✨

  • conference participants, floor control servers, and floor chairs SHOULD be authenticated upon initial contact. 🪪
  • all floor control messages SHOULD be authenticated and integrity-protected, to stop third-party intervention and MITM attacks. 🔒
  • floor control messages SHOULD be encrypted to prevent eavesdropping. 🤐
bestie, these SHOULDs are doing a LOT of work. 💀 if you skip them you're basically leaving the door wide open. 🚪

9. Acknowledgements 🫶🌸

the authors wanna give a huge shoutout to the IETF conferencing design team, plus Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen, and Nermeen Ismail for their feedback. 💕 literally the squad ✨

10. References 📚

10.1. Normative References 💜

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCD 14, March 1997.
  • [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

10.2. Informative References 🦋

  • [3] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
  • [4] Koskelainen, P. and H. Khartabil, "Additional Requirements to Conferencing", Work in Progress, August 2004.
  • [5] Koskelainen, P., Schulzrinne, H., and X. Wu, "A SIP-based conference control framework", NOSSDAV 2002, Miami Beach, May 2002.
  • [6] Dommel, H. and J. Garcia-Luna-Aceves, "Floor control for activity coordination in networked multimedia applications", Proc. of 2nd Asian-pacific Conference on Communications APPC, Osaka Japan, June 1995.
  • [7] Koskelainen, P., Khartabil, H., and A. Niemi, "The Conference Policy Control Protocol (CPCP)", Work in Progress, October 2004.
  • [8] Borman, C., Kutscher, D., Ott, J., and D. Trossen, "Simple conference control protocol service specification", Work in Progress, March 2001.

Authors' Addresses 🏡

Petri Koskelainen 🌟 Nokia 102 Corporate Park Drive White Plains, NY 10604 USA EMail: petri.koskelainen@nokia.com

Joerg Ott 🌈 Helsinki University of Technology Networking Laboratory Otakaari 5A 02150 Espoo Finland EMail: jo@netlab.hut.fi

Henning Schulzrinne 🧚 Columbia University 1214 Amsterdam Avenue New York 10027 USA EMail: hgs@cs.columbia.edu

Xiaotao Wu 💜 Columbia University 1214 Amsterdam Avenue New York 10027 USA EMail: xiaotaow@cs.columbia.edu

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🧠

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🙏

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

📦 where this page comes from