Internet DRAFT - draft-mahy-mmusic-mbus-sdp

draft-mahy-mmusic-mbus-sdp






MMUSIC WG                                                        R. Mahy
Internet-Draft                                              SIP Edge LLC
Expires: January 16, 2006                                  July 15, 2005


           Setting up Mbus Control Sessions with SIP and SDP
                   draft-mahy-mmusic-mbus-sdp-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 January 16, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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 January 16, 2006                [Page 1]

Internet-Draft            Mbus via SIP and SDP                 July 2005


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 . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
     7.2   Informational References . . . . . . . . . . . . . . . . .  5
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
       Intellectual Property and Copyright Statements . . . . . . . .  7






































Mahy                    Expires January 16, 2006                [Page 2]

Internet-Draft            Mbus via SIP and SDP                 July 2005


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 [12], and ICE
   [10].




Mahy                    Expires January 16, 2006                [Page 3]

Internet-Draft            Mbus via SIP and SDP                 July 2005


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 single zero.

   This document also defines two SDP attributes.  The first attribute,
   called  mbus-addr is a space-separated list of Mbus addresses on
   which this Mbus implementation is expecting to receive Mbus messages.
   The second SDP attribute, called mbus-profiles, 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).  [TODO: The ciphersuites in sdescriptions
   are currently specific to SRTP [9].  Either define a new
   sdescriptions ciphersuite, or define the SDP exchange to use Datagram
   TLS [11].]

   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






Mahy                    Expires January 16, 2006                [Page 4]

Internet-Draft            Mbus via SIP and SDP                 July 2005


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.

   [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., "Session Description Protocol Security
        Descriptions for Media Streams",
        draft-ietf-mmusic-sdescriptions-11 (work in progress),
        June 2005.

7.2  Informational References

   [6]   Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
         "RTP: A Transport Protocol for Real-Time Applications", STD 64,
         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]   Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
         Norrman, "The Secure Real-time Transport Protocol (SRTP)",
         RFC 3711, March 2004.

   [10]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Methodology for Network  Address Translator (NAT) Traversal for
         Multimedia Session Establishment Protocols",
         draft-ietf-mmusic-ice-04 (work in progress), February 2005.

   [11]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
         Security", draft-rescorla-dtls-05 (work in progress),
         June 2005.

   [12]  Rosenberg, J., "Traversal Using Relay NAT (TURN)",
         draft-rosenberg-midcom-turn-07 (work in progress),



Mahy                    Expires January 16, 2006                [Page 5]

Internet-Draft            Mbus via SIP and SDP                 July 2005


         February 2005.


Author's Address

   Rohan Mahy
   SIP Edge LLC

   Email: rohan@cisco.com










































Mahy                    Expires January 16, 2006                [Page 6]

Internet-Draft            Mbus via SIP and SDP                 July 2005


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 (2005).  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 January 16, 2006                [Page 7]