MMUSIC WG R. Mahy Internet-Draft Cisco Systems, Inc. Expires: December 30, 2004 Jul 2004 Setting up Mbus Control Sessions with SIP and SDP draft-mahy-mmusic-mbus-sdp-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Mbus (Message Bus for Local Coordination) was designed for use on individual hosts, subnets, or small multicast networks. This document describes how to setup an mbus control session using SIP and SDP. Using SIP to setup Mbus allows for authentication, negotiation of an Mbus secret key, and facilitates NAT and firewall traversal. Mahy Expires December 30, 2004 [Page 1] Internet-Draft Mbus via SIP and SDP Jul 2004 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. SDP extensions for Mbus . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 4 7.2 Informational References . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . 6 Mahy Expires December 30, 2004 [Page 2] Internet-Draft Mbus via SIP and SDP Jul 2004 1. Conventions 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 [2]. 2. Introduction Mbus (Message Bus for Local Coordination) - RFC 3259 [4], is a lightweight message-oriented coordination protocol designed for inter-application communication. Mbus was designed to run primarily over IP multicast, but also runs over unicast UDP datagrams. Although Mbus contains built-in message integrity and encryption capabilities, it assumes a shared secret key and has no authentication mechanism. In addition, as MBus expects to use either multicast, local service discovery, or manual configuration to find other Mbus devices, it does not function well over NATs [7] (including v4/v6 translators). This document describes how to setup an end-to-end, unicast, Mbus control stream using SIP [1] and SDP [3]. Using SIP allows MBus to be used in settings which are geographically local, but not topologically local. (For example, a mobile phone with IP connectivity could be used as a remote control for a SIP-based video conferencing system which happens to be in the same room, but are in very different networks and addressing realms). 3. Requirements The Mbus profiles likely to be used in conjunction with SIP require strong security. As a result Mbus control streams setup using SIP MUST use Mbus message integrity using SHA1, and SHOULD use Mbus encryption using AES. Because Mbus signaled via SIP is more likely to be used over the Internet at large it is important to include additional restrictions on Mbus implementations in this mode. All Mbus messages sent over SIP-signaled Mbus stream MUST use Mbus message reliability for every message and SHOULD NOT send any messages over the Mbus if there are 4 or more unacknowledged messages. Sending messages larger than 4k over this Mbus is NOT RECOMMENDED. Because of the dynamic nature of many SIP user agents, these frequently need to work behind NATs or Firewalls. Using Mbus with SIP makes it easy for Mbus to be used with the same middlebox traversal solutions that RTP [6] uses--STUN [8], TURN [10], and ICE [9]. Mahy Expires December 30, 2004 [Page 3] Internet-Draft Mbus via SIP and SDP Jul 2004 4. SDP extensions for Mbus Mbus uses the control/mbus MIME type and is signaled in SDP with a media-line of type "control". Mbus in SDP uses the UDP/mbus1.0 transport. Mbus MAY run on any port number, including the default port number. Instead of a codec list after the port number (as with RTP), a media line for Mbus control messages contains a space-separated list of Mbus addresses on which this Mbus implementation is expecting to receive Mbus messages. This document also defines an SDP attribute called mbus-profiles which contains a space separated list of the top-level profiles this implementation is willing to accept. Any of these listed profiles can contain addition hierarchy using a period as a separator. Since message integrity MUST be used, offers and answers for Mbus sessions MUST include a crypto SDP attribute [5] as shown in the example below. (Note that the crypto attribute is on a single line. It is only split onto two lines to accommodate RFC and Internet-Draft formatting requirements). c=192.0.0.5 m=control 47000 UDP/mbus1.0 id:123-45@192.0.0.5 a=mbus-profiles: remote-cc phonectl.volume a=crypto:1 AES_CBC_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|| SIP messages which setup Mbus control sessions SHOULD be sent using the sips: URI scheme to protect the keying information included in SIP offers and answers. 5. Security Considerations To Be Written. 6. IANA Considerations Need to add IANA templates for registering new MIME type, new SDP transport and an SDP attribute. 7. References 7.1 Normative References [1] 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. Mahy Expires December 30, 2004 [Page 4] Internet-Draft Mbus via SIP and SDP Jul 2004 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [4] Ott, J., Perkins, C. and D. Kutscher, "A Message Bus for Local Coordination", RFC 3259, April 2002. [5] Andreasen, F., Baugher, M. and D. Wing, "Session Description Protocol Security Descriptions for Media Streams", draft-ietf-mmusic-sdescriptions-06 (work in progress), July 2004. 7.2 Informational References [6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [7] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [8] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. [9] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols", draft-ietf-mmusic-ice-01 (work in progress), February 2004. [10] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-04 (work in progress), February 2004. Author's Address Rohan Mahy Cisco Systems, Inc. 5617 Scotts Valley Drive, Suite 200 Scotts Valley, CA 95066 USA EMail: rohan@cisco.com Mahy Expires December 30, 2004 [Page 5] Internet-Draft Mbus via SIP and SDP Jul 2004 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mahy Expires December 30, 2004 [Page 6]