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]
