idnits 2.17.1 draft-romano-dcon-xdsp-reqs-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 14, 2012) is 4145 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2234' is defined on line 342, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 348, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 4353 == Outdated reference: A later version (-12) exists of draft-romano-dcon-requirements-11 -- Possible downref: Normative reference to a draft: ref. 'I-D.romano-dcon-requirements' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S P. Romano 3 Internet-Draft A. Amirante 4 Expires: June 17, 2013 University of Napoli 5 T. Castaldi 6 L. Miniero 7 Meetecho 8 A. Buono 9 Ansaldo Trasporti e Sistemi 10 Ferroviari 11 December 14, 2012 13 Requirements for the XCON-DCON Synchronization Protocol 14 draft-romano-dcon-xdsp-reqs-12 16 Abstract 18 The Distributed Conferencing (DCON) framework provides the means to 19 distribute Centralized Conference (XCON) information by appropriately 20 orchestrating a number of centralized focus entities (clouds). The 21 mechanism we propose to make each XCON cloud communicate with its 22 related DCON peer is based on the use of some kind of XCON-DCON 23 Synchronization Protocol (XDSP). This document gives the 24 requirements for XDSP. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 17, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. XDSP Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. General Protocol Requirements . . . . . . . . . . . . . . . 4 65 4.2. Requests and responses . . . . . . . . . . . . . . . . . . 5 66 4.3. Updates and asynchronous notifications . . . . . . . . . . 6 67 4.4. Centralized protocols routing and dispatching . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 The Distributed Conferencing framework [I-D.romano-dcon-requirements] 76 describes the requirements for the overall architecture, terminology, 77 and protocol components needed for distribuited conferencing. DCON 78 is based on the idea that a distributed conference can be setup and 79 accessed by appropriately orchestrating the operation of a number of 80 XCON "focus" elements, each in charge of managing a certain number of 81 participants. Each pair composed of a centralized focus entity 82 (XCON) and its related distributed counterpart (namely, a DCON focus) 83 is called "island", or "cloud". These islands are then made part of 84 an overlay network composed of several inter-communicating clouds. 86 Interaction between each participant and the corresponding conference 87 focus is based on the standard XCON framework [RFC5239], whereas 88 inter-focus interaction is based on a peer-to-peer paradigm. The 89 interaction between the centralized conference focus and the 90 distributed conference focus, instead, has requirements that are 91 defined in this document. 93 2. Conventions 95 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 96 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT", 97 "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 98 described in BCP 14, RFC 2119 [RFC2119] and indicate requirement 99 levels for compliant implementations. 101 3. Terminology 103 Distributed conferencing uses, when appropriate, and expands on the 104 terminology introduced in the both the SIPPING [RFC4353] and XCON 105 [RFC5239] conferencing frameworks. The following additional terms 106 are defined for specific use within the distributed conferencing 107 work. 109 Conferencing Cloud: 111 A specific pair composed of a centralized focus entity (XCON) and 112 its associated distributed focus (DCON). We will herein 113 indifferently use both "cloud" and "island" to refer to a 114 conferencing cloud. 116 DCON Focus: 118 A specific entity enabling communication of a centralized 119 conferencing system with the outside world. A DCON focus allows 120 for the construction of a distributed conferencing system as a 121 federation of centralized conferencing components. 123 Focus Discovery: 125 The capability to detect the presence of new focus entities in a 126 distributed conferencing framework. 128 Information Spreading: 130 The spreading of conference related information among the focus 131 entities in a distributed environment. 133 Protocol Dispatching: 135 The capabilty of appropriately forwarding/distributing messages of 136 a natively centralized protocol in order to let them spread across 137 a distributed environment. 139 Label Swapping: 141 The opportune swap of labels assigned to a specific resource, 142 needed to avoid conflicts in the assignment of labels across 143 several point-to-point communications regarding the same resource. 145 4. XDSP Requirements 147 This section describes requirements for the XCON-DCON synchronization 148 protocol (XDSP). 150 4.1. General Protocol Requirements 152 REQ-A1: 154 XDSP protocol MUST be a reliable client-server protocol. 155 Hence, it MUST have a positive response indicating that the 156 request has been received, or an error response in case an 157 error has occurred. 159 REQ-A2: 161 It MUST be possible for the XCON focus entity, the server, 162 to authenticate the related DCON focus entity, the client. 164 REQ-A3: 166 It MUST be possible for the DCON focus entity to be 167 authenticated by the server, the related XCON focus entity. 169 REQ-A4: 171 It MUST be possible to ensure message integrity between each 172 pair of XCON and DCON focus entities. 174 4.2. Requests and responses 176 REQ-B1: 178 It MUST be possible for the involved XCON and DCON entities 179 to communicate on a stateless synchronous request-response 180 based mechanism. 182 REQ-B2: 184 An error message MUST be sent back to the entity placing the 185 request, in case the message couldn't be processed for any 186 reason. 188 REQ-B3: 190 An authentication mechanism SHOULD be made possible on the 191 basis of such stateless synchronous request-response based 192 interaction between the two involved entities. 194 REQ-B4: 196 It SHOULD be possible for the XCON focus entity to request 197 access to remote (e.g. avaliable on different islands) 198 resources by means of an answer sent to the related DCON 199 focus entity. This includes requesting a join to a remote 200 conference for a local user, setting up distributed 201 conferences, actively requesting the list of all the remote 202 conferences and/or the list of all users (remote and local) 203 in a currently running conference, etc.. 205 REQ-B5: 207 The DCON focus entity SHALL forward any request directed to 208 resources available in the related XCON cloud to the related 209 XCON focus entity which will manage it and properly answer 210 the request. 212 4.3. Updates and asynchronous notifications 214 REQ-C1: 216 It SHOULD be possible for the DCON focus entity to subscribe 217 to the related XCON focus entity for events related to the 218 conference system state, in order to receive asynchronous 219 notifications. 221 REQ-C2: 223 The XCON focus entity SHALL generate new asynchronous 224 notifications every time there is any change in the state of 225 any of the conferences it is currently handling. 227 REQ-C3: 229 It SHOULD be possible for the DCON focus entity to receive 230 full state updates from the related XCON focus entity, in 231 case some of the events were missed, to make the known state 232 consistent with the actual conference system internal state. 234 REQ-C4: 236 Both partial notifications and full updates SHOULD be sent 237 through the same authenticated channel used for XDSP 238 communication. In case a separate channel and/or a separate 239 protocol are used (e.g. by means of the XCON event package, 240 when it is available, or of the already available SIPPING 241 conference event package [RFC4575]), the same issues about 242 security and integrity SHOULD be addressed to avoid attacks 243 and exploits by unauthenticated users. 245 REQ-C5: 247 Since state changes might happen in both the involved focus 248 entities (even though related to different situations) the 249 same requirements just described for notifications generated 250 by XCON focus entities should be addressed for their related 251 DCON focus entities. It SHOULD be possible for the XCON 252 focus entity to subscribe to the related DCON focus entity 253 for events related to the conference system state, in order 254 to receive asynchronous notifications. 256 REQ-C6: 258 The DCON focus entity SHALL generate new asynchronous 259 notifications every time there is any change in its internal 260 state, e.g. whenever new remote conferences have been 261 created or become active, etc. 263 REQ-C7: 265 It SHOULD be possible for the XCON focus entity to receive 266 full state updates from the related DCON focus entity, in 267 case some of the events were missed, to make the known state 268 consistent with the actual conference system internal state. 270 4.4. Centralized protocols routing and dispatching 272 REQ-D1: 274 The XCON focus entity MUST forward any centralized protocol 275 message to its related DCON focus entity whenever the 276 message is to be received by a peer who is not a local 277 entity of the centralized system. Natively centralized 278 protocol messages include, but are not limited to, any 279 protocol defined and specified in the XCON framework (e.g. 280 conference control management and floor control) as well as 281 DTMF messages propagation. An example is represented by 282 BFCP messages the local floor control server might need to 283 send to a user who is remotely (i.e. a user who does not 284 belong to the current XCON cloud) participating in the 285 conference. Another example concerns BFCP messages a local 286 user might want to send to the remote floor control server 287 handling the remote, distributed, conference the user is 288 participating in. Any message sent by local entities to 289 local entities has to be treated in the usual centralized 290 way according to the relative protocol specifications (i.e. 291 dispatching shall not be involved). 293 REQ-D2: 295 The DCON focus entity MUST forward any natively centralized 296 protocol message it receives from DCON focus peers in the 297 distributed overlay (routing) to the related XCON focus 298 entity (dispatching), whenever the message is addressed to 299 any of the local entities of the centralized cloud. 301 REQ-D3: 303 The XCON and DCON focus entities MUST establish and mantain 304 opportune labels to correctly address and identify local 305 entities involved in routed and dispatched messages. These 306 labels MUST be appropriately swapped whenever they leave a 307 DCON focus entity and reach a foreign one, so to avoid 308 conflicts upon assigned labels in different islands. 310 REQ-D4: 312 Message dispatching between the two involved focus entities 313 SHOULD occur on an request-response based communication 314 mechanism, and opportune errors should be generated in case 315 any exceptional condition happens while processing the 316 messages. 318 5. Security Considerations 320 The communication between each DCON focus entity and its related XCON 321 entity contains sensitive information, since it envisages the 322 possibility to spread important information that only authorized 323 entities should be aware of (e.g. the full internal state of the 324 centralized conference objects and relevant privacy information about 325 users authenticated by the system). 327 Hence it is very important that protocol messages be protected 328 because otherwise an attacker might spoof the legitimate identity of 329 the DCON focus entity and/or inject messages on his behalf. Many 330 obvious consequences could come out of such an undesirable situation. 332 To mitigate the above threats, both the DCON focus entity and the 333 XCON focus entity SHOULD be authenticated upon initial contact. All 334 protocol messages SHOULD be authenticated and integrity-protected to 335 prevent third-party intervention and MITM (Man-In-The-Middle) 336 attacks. All messages SHOULD be encrypted to prevent eavesdropping. 338 6. Acknowledgements 340 7. References 342 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 343 Specifications: ABNF", RFC 2234, November 1997. 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 349 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 350 October 1998. 352 [RFC4353] Rosenberg, J., "A Framework for Conferencing with the 353 Session Initiation Protocol (SIP)", RFC 4353, 354 February 2006. 356 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 357 Initiation Protocol (SIP) Event Package for Conference 358 State", RFC 4575, August 2006. 360 [I-D.romano-dcon-requirements] 361 Romano, S., Amirante, A., Castaldi, T., Miniero, L., and 362 A. Buono, "Requirements for Distributed Conferencing", 363 draft-romano-dcon-requirements-11 (work in progress), 364 June 2012. 366 [RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for 367 Centralized Conferencing", RFC 5239, June 2008. 369 Authors' Addresses 371 Simon Pietro Romano 372 University of Napoli 373 Via Claudio 21 374 Napoli 80125 375 Italy 377 Email: spromano@unina.it 379 Alessandro Amirante 380 University of Napoli 381 Via Claudio 21 382 Napoli 80125 383 Italy 385 Email: alessandro.amirante@unina.it 386 Tobia Castaldi 387 Meetecho 388 Via Carlo Poerio 89 389 Napoli 80100 390 Italy 392 Email: tcastaldi@meetecho.com 394 Lorenzo Miniero 395 Meetecho 396 Via Carlo Poerio 89 397 Napoli 80100 398 Italy 400 Email: lorenzo@meetecho.com 402 Alfonso Buono 403 Ansaldo Trasporti e Sistemi Ferroviari 404 Via Argine, 425 405 Napoli 80147 406 Italy 408 Email: alfonso.buono@atsf.it