Requirements for the XCON-DCON Synchronization Protocol
draft-romano-dcon-xdsp-reqs-08

Abstract

The Distributed Conferencing (DCON) framework provides the means to distribute Centralized Conference (XCON) information by appropriately orchestrating a number of centralized focus entities (clouds). The mechanism we propose to make each XCON cloud communicate with its related DCON peer is based on the use of some kind of XCON-DCON Synchronization Protocol (XDSP). This document gives the requirements for XDSP.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on June 23, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  Conventions
3.  Terminology
4.  XDSP Requirements
    4.1.  General Protocol Requirements
    4.2.  Requests and responses
    4.3.  Updates and asynchronous notifications
    4.4.  Centralized protocols routing and dispatching
5.  Security Considerations
6.  Acknowledgements
7.  References
§  Authors' Addresses

1.  Introduction

The Distributed Conferencing framework [I‑D.romano‑dcon‑requirements] (Romano, S., Amirante, A., Castaldi, T., Miniero, L., and A. Buono, “Requirements for Distributed Conferencing,” June 2010.) describes the requirements for the overall architecture, terminology, and protocol components needed for distribuited conferencing. DCON is based on the idea that a distributed conference can be setup and accessed by appropriately orchestrating the operation of a number of XCON "focus" elements, each in charge of managing a certain number of participants. Each pair composed of a centralized focus entity (XCON) and its related distributed counterpart (namely, a DCON focus) is called "island", or "cloud". These islands are then made part of an overlay network composed of several inter-communicating clouds.

Interaction between each participant and the corresponding conference focus is based on the standard XCON framework [RFC5239] (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” June 2008.), whereas inter-focus interaction is based on a peer-to-peer paradigm. The interaction between the centralized conference focus and the distributed conference focus, instead, has requirements that are defined in this document.

2.  Conventions

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) and indicate requirement levels for compliant implementations.

3.  Terminology

Distributed conferencing uses, when appropriate, and expands on the terminology introduced in the both the SIPPING [RFC4353] (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.) and XCON [RFC5239] (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” June 2008.) conferencing frameworks. The following additional terms are defined for specific use within the distributed conferencing work.

Conferencing Cloud:

A specific pair composed of a centralized focus entity (XCON) and its associated distributed focus (DCON). We will herein indifferently use both "cloud" and "island" to refer to a conferencing cloud.

DCON Focus:

A specific entity enabling communication of a centralized conferencing system with the outside world. A DCON focus allows for the construction of a distributed conferencing system as a federation of centralized conferencing components.

Focus Discovery:

The capability to detect the presence of new focus entities in a distributed conferencing framework.

Information Spreading:

The spreading of conference related information among the focus entities in a distributed environment.

Protocol Dispatching:

The capabilty of appropriately forwarding/distributing messages of a natively centralized protocol in order to let them spread across a distributed environment.

Label Swapping:

The opportune swap of labels assigned to a specific resource, needed to avoid conflicts in the assignment of labels across several point-to-point communications regarding the same resource.

4.  XDSP Requirements

This section describes requirements for the XCON-DCON synchronization protocol (XDSP).

4.1.  General Protocol Requirements

REQ-A1:

XDSP protocol MUST be a reliable client-server protocol. Hence, it MUST have a positive response indicating that the request has been received, or an error response in case an error has occurred.

REQ-A2:

It MUST be possible for the XCON focus entity, the server, to authenticate the related DCON focus entity, the client.

REQ-A3:

It MUST be possible for the DCON focus entity to be authenticated by the server, the related XCON focus entity.

REQ-A4:

It MUST be possible to ensure message integrity between each pair of XCON and DCON focus entities.

4.2.  Requests and responses

REQ-B1:

It MUST be possible for the involved XCON and DCON entities to communicate on a stateless synchronous request-response based mechanism.

REQ-B2:

An error message MUST be sent back to the entity placing the request, in case the message couldn't be processed for any reason.

REQ-B3:

An authentication mechanism SHOULD be made possible on the basis of such stateless synchronous request-response based interaction between the two involved entities.

REQ-B4:

It SHOULD be possible for the XCON focus entity to request access to remote (e.g. avaliable on different islands) resources by means of an answer sent to the related DCON focus entity. This includes requesting a join to a remote conference for a local user, setting up distributed conferences, actively requesting the list of all the remote conferences and/or the list of all users (remote and local) in a currently running conference, etc..

REQ-B5:

The DCON focus entity SHALL forward any request directed to resources available in the related XCON cloud to the related XCON focus entity which will manage it and properly answer the request.

4.3.  Updates and asynchronous notifications

REQ-C1:

It SHOULD be possible for the DCON focus entity to subscribe to the related XCON focus entity for events related to the conference system state, in order to receive asynchronous notifications.

REQ-C2:

The XCON focus entity SHALL generate new asynchronous notifications every time there is any change in the state of any of the conferences it is currently handling.

REQ-C3:

It SHOULD be possible for the DCON focus entity to receive full state updates from the related XCON focus entity, in case some of the events were missed, to make the known state consistent with the actual conference system internal state.

REQ-C4:

Both partial notifications and full updates SHOULD be sent through the same authenticated channel used for XDSP communication. In case a separate channel and/or a separate protocol are used (e.g. by means of the XCON event package, when it is available, or of the already available SIPPING conference event package [RFC4575] (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.)), the same issues about security and integrity SHOULD be addressed to avoid attacks and exploits by unauthenticated users.

REQ-C5:

Since state changes might happen in both the involved focus entities (even though related to different situations) the same requirements just described for notifications generated by XCON focus entities should be addressed for their related DCON focus entities. It SHOULD be possible for the XCON focus entity to subscribe to the related DCON focus entity for events related to the conference system state, in order to receive asynchronous notifications.

REQ-C6:

The DCON focus entity SHALL generate new asynchronous notifications every time there is any change in its internal state, e.g. whenever new remote conferences have been created or become active, etc.

REQ-C7:

It SHOULD be possible for the XCON focus entity to receive full state updates from the related DCON focus entity, in case some of the events were missed, to make the known state consistent with the actual conference system internal state.

4.4.  Centralized protocols routing and dispatching

REQ-D1:

The XCON focus entity MUST forward any centralized protocol message to its related DCON focus entity whenever the message is to be received by a peer who is not a local entity of the centralized system. Natively centralized protocol messages include, but are not limited to, any protocol defined and specified in the XCON framework (e.g. conference control management and floor control) as well as DTMF messages propagation. An example is represented by BFCP messages the local floor control server might need to send to a user who is remotely (i.e. a user who does not belong to the current XCON cloud) participating in the conference. Another example concerns BFCP messages a local user might want to send to the remote floor control server handling the remote, distributed, conference the user is participating in. Any message sent by local entities to local entities has to be treated in the usual centralized way according to the relative protocol specifications (i.e. dispatching shall not be involved).

REQ-D2:

The DCON focus entity MUST forward any natively centralized protocol message it receives from DCON focus peers in the distributed overlay (routing) to the related XCON focus entity (dispatching), whenever the message is addressed to any of the local entities of the centralized cloud.

REQ-D3:

The XCON and DCON focus entities MUST establish and mantain opportune labels to correctly address and identify local entities involved in routed and dispatched messages. These labels MUST be appropriately swapped whenever they leave a DCON focus entity and reach a foreign one, so to avoid conflicts upon assigned labels in different islands.

REQ-D4:

Message dispatching between the two involved focus entities SHOULD occur on an request-response based communication mechanism, and opportune errors should be generated in case any exceptional condition happens while processing the messages.

5.  Security Considerations

The communication between each DCON focus entity and its related XCON entity contains sensitive information, since it envisages the possibility to spread important information that only authorized entities should be aware of (e.g. the full internal state of the centralized conference objects and relevant privacy information about users authenticated by the system).

Hence it is very important that protocol messages be protected because otherwise an attacker might spoof the legitimate identity of the DCON focus entity and/or inject messages on his behalf. Many obvious consequences could come out of such an undesirable situation.

To mitigate the above threats, both the DCON focus entity and the XCON focus entity SHOULD be authenticated upon initial contact. All protocol messages SHOULD be authenticated and integrity-protected to prevent third-party intervention and MITM (Man-In-The-Middle) attacks. All messages SHOULD be encrypted to prevent eavesdropping.

6.  Acknowledgements

7. References

Authors' Addresses