Section 8.1.1 specifies how to obtain hello_d. Section 10 defines
values for the constants c_hello_dead and c_hello_dither_max.
9. Messages
This section defines some basic application-independent messages that
MUST be understood by all implementations; these messages are
required for proper operation of the Mbus. This specification does
not contain application-specific messages. These are to be defined
outside of the basic Mbus protocol specification in separate Mbus
profiles.
9.1 mbus.hello
Syntax:
mbus.hello()
Parameters: - none -
mbus.hello messages MUST be sent unreliably to all Mbus entities.
Each Mbus entity learns about other Mbus entities by observing their
mbus.hello messages and tracking the sender address of each message
and can thus calculate the current number of entities.
mbus.hello messages MUST be sent periodically in dynamically
calculated intervals as specified in Section 8.
Upon startup the first mbus.hello message MUST be sent after a delay
hello_delay, where hello_delay be a randomly chosen number between 0
and c_hello_min (see Section 10).
9.2 mbus.bye
Syntax: mbus.bye()
Parameters: - none -
An Mbus entity that is about to terminate (or "detach" from the Mbus)
SHOULD announce this by transmitting an mbus.bye message. The
mbus.bye message MUST be sent unreliably to all entities.
9.3 mbus.ping
Syntax: mbus.ping()
Parameters: - none -
mbus.ping can be used to solicit other entities to signal their
existence by replying with an mbus.hello message. Each protocol
implementation MUST understand mbus.ping and reply with an mbus.hello
message. The reply hello message MUST be delayed for hello_delay
milliseconds, where hello_delay be a randomly chosen number between 0
and c_hello_min (see Section 10). Several mbus.ping messages MAY be
answered by a single mbus.hello: if one or more further mbus.ping
messages are received while the entity is waiting hello_delay time
units before transmitting the mbus.hello message, no extra mbus.hello
message need be scheduled for those additional mbus.ping messages.
As specified in Section 9.1 hello messages MUST be sent unreliably to
all Mbus entities. This is also the case for replies to ping
messages. An entity that replies to mbus.ping with mbus.hello SHOULD
stop any outstanding timers for hello messages after sending the
hello message and schedule a new timer event for the subsequent hello
message. (Note that using the variables and the algorithms of
Section 8.1.1 this can be achieved by setting hello_p to hello_now.)
mbus.ping allows a new entity to quickly check for other entities
without having to wait for the regular individual hello messages. By
specifying a target address the new entity can restrict the
solicitation for hello messages to a subset of entities it is
interested in.
9.4 mbus.quit
Syntax:
mbus.quit()
Parameters: - none -
The mbus.quit message is used to request other entities to terminate
themselves (and detach from the Mbus). Whether this request is
honoured by receiving entities or not is application specific and
not defined in this document.
The mbus.quit message can be multicast or sent reliably via unicast
to a single Mbus entity or a group of entities.
9.5 mbus.waiting
Syntax:
mbus.waiting(condition)
Parameters:
symbol condition
The condition parameter is used to indicate that the entity
transmitting this message is waiting for a particular event to
occur.
An Mbus entity SHOULD be able to indicate that it is waiting for a
certain event to happen (similar to a P() operation on a semaphore
but without creating external state somewhere else). In conjunction
with this, an Mbus entity SHOULD be capable of indicating to another
entity that this condition is now satisfied (similar to a semaphore's
V() operation).
The mbus.waiting message MAY be broadcast to all Mbus entities, MAY
be multicast to an arbitrary subgroup, or MAY be unicast to a
particular peer. Transmission of the mbus.waiting message MUST be
unreliable and hence MUST be repeated at an application-defined
interval (until the condition is satisfied).
If an application wants to indicate that it is waiting for several
conditions to be met, several mbus.waiting messages are sent
(possibly included in the same Mbus payload). Note that mbus.hello
and mbus.waiting messages may also be transmitted in a single Mbus
payload.
9.6 mbus.go
Syntax:
mbus.go(condition)
Parameters:
symbol condition
This parameter specifies which condition is met.
The mbus.go message is sent by an Mbus entity to "unblock" another
Mbus entity -- which has indicated that it is waiting for a certain
condition to be met. Only a single condition can be specified per
mbus.go message. If several conditions are satisfied simultaneously
multiple mbus.go messages MAY be combined in a single Mbus payload.
The mbus.go message MUST be sent reliably via unicast to the Mbus
entity to unblock.
10. Constants
The following values for timers and counters mentioned in this
document SHOULD be used by implementations:
+-------------------+------------------------+--------------+
|Timer / Counter | Value | Unit |
+-------------------+------------------------+--------------+
|c_hello_factor | 200 | - |
|c_hello_min | 1000 | milliseconds |
|c_hello_dither_min | 0.9 | - |
|c_hello_dither_max | 1.1 | - |
|c_hello_dead | 5 | - |
+-------------------+------------------------+--------------+
T_r=100ms
N_r=3
T_c=70ms
T_k=((N_r)*(N_r+1)/2)*T_r
11. Mbus Security
11.1 Security Model
In order to prevent accidental or malicious disturbance of Mbus
communications through messages originated by applications from other
users, message authentication is deployed (Section 11.3). For each
message, a digest MUST be calculated based on the value of a shared
secret key value. Receivers of messages MUST check if the sender
belongs to the same Mbus security domain by re-calculating the digest
and comparing it to the received value. The messages MUST only be
processed further if both values are equal. In order to allow
different simultaneous Mbus sessions at a given scope and to
compensate defective implementations of host local multicast, message
authentication MUST be provided by conforming implementations.
Privacy of Mbus message transport can be achieved by optionally using
symmetric encryption methods (Section 11.2). Each message MAY be
encrypted using an additional shared secret key and a symmetric
encryption algorithm. Encryption is OPTIONAL for applications, i.e.,
it is allowed to configure an Mbus domain not to use encryption. But
conforming implementations MUST provide the possibility to use
message encryption (see below).
Message authentication and encryption can be parameterized: the
algorithms to apply, the keys to use, etc. These and other
parameters are defined in an Mbus configuration object that is
accessible by all Mbus entities that participate in an Mbus session.
In order to achieve interoperability conforming implementations
SHOULD use the values provided by such an Mbus configuration.
Section 12 defines the mandatory and optional parameters as well as
storage procedures for different platforms. Only in cases where none
of the options mentioned in Section 12 is applicable alternative
methods of configuring Mbus protocol entities MAY be deployed.
The algorithms and procedures for applying encryption and
authentication techniques are specified in the following sections.
11.2 Encryption
Encryption of messages is OPTIONAL, that means, an Mbus MAY be
configured not to use encryption.
Implementations can choose between different encryption algorithms.
Every conforming implementation MUST provide the AES [18] algorithm.
In addition, the following algorithms SHOULD be supported: DES [16],
3DES (triple DES) [16] and IDEA [20].
For algorithms requiring en/decryption data to be padded to certain
boundaries octets with a value of 0 SHOULD be used for padding
characters.
The length of the encryption keys is determined by the currently used
encryption algorithm. This means, the configured encryption key MUST
NOT be shorter than the native key length for the currently
configured algorithm.
DES implementations MUST use the DES Cipher Block Chaining (CBC)
mode. DES keys (56 bits) MUST be encoded as 8 octets as described in
RFC1423 [12], resulting in 12 Base64-encoded characters. IDEA uses
128-bit keys (24 Base64-encoded characters). AES can use either
128-bit, 192-bit or 256-bit keys. For Mbus encryption using AES only
128-bit keys (24 Base64-encoded characters) MUST be used.
11.3 Message Authentication
For authentication of messages, hashed message authentication codes
(HMACs) as described in RFC2104 [5] are deployed. In general,
implementations can choose between a number of digest algorithms.
For Mbus authentication, the HMAC algorithm MUST be applied in the
following way:
The keyed hash value is calculated using the HMAC algorithm
specified in RFC2104 [5]. The specific hash algorithm and the
secret hash key MUST be obtained from the Mbus configuration (see
Section 12).
The keyed hash values (see RFC2104 [5]) MUST be truncated to 96
bits (12 octets).
Subsequently, the resulting 12 octets MUST be Base64-encoded,
resulting in 16 Base64-encoded characters (see RFC1521 [7]).
Either MD5 [15] or SHA-1 [17] SHOULD be used for message
authentication codes (MACs). An implementation MAY provide MD5,
whereas SHA-1 MUST be implemented.
The length of the hash keys is determined by the selected hashing
algorithm. This means, the configured hash key MUST NOT be shorter
than the native key length for the currently configured algorithm.
11.4 Procedures for Senders and Receivers
The algorithms that MUST be provided by implementations are AES and
SHA-1.
See Section 12 for a specification of notations for Base64-strings.
A sender MUST apply the following operations to a message that is to
be sent:
1. If encryption is enabled, the message MUST be encrypted using the
configured algorithm and the configured encryption key. Padding
(adding extra-characters) for block-ciphers MUST be applied as
specified in Section 11.2. If encryption is not enabled, the
message is left unchanged.
2. Subsequently, a message authentication code (MAC) for the
(encrypted) message MUST be calculated using the configured HMAC-
algorithm and the configured hash key.
3. The MAC MUST then be converted to Base64 encoding, resulting in 16
Base64-characters as specified in Section 11.3.
4. At last, the sender MUST construct the final message by placing
the (encrypted) message after the base64-encoded MAC and a CRLF.
The ABNF definition for the final message is as follows:
final_msg = MsgDigest CRLF encr_msg
MsgDigest = base64
encr_msg = *OCTET
A receiver MUST apply the following operations to a message that it
has received:
1. Separate the base64-encoded MAC from the (encrypted) message and
decode the MAC.
2. Re-calculate the MAC for the message using the configured HMAC-
algorithm and the configured hash key.
3. Compare the original MAC with re-calculated MAC. If they differ,
the message MUST be discarded without further processing.
4. If encryption is enabled, the message MUST be decrypted using the
configured algorithm and the configured encryption key. Trailing
octets with a value of 0 MUST be deleted. If the message does not
start with the string "mbus/" the message MUST be discarded
without further processing.
12. Mbus Configuration
An implementation MUST be configurable by the following parameters:
Configuration version
The version number of the given configuration entity. Version
numbers allow implementations to check if they can process the
entries of a given configuration entity. Version number are
integer values. The version number for the version specified
here is 1.
Encryption key
The secret key used for message encryption.
Hash key
The hash key used for message authentication.
Scope
The multicast scope to be used for sent messages.
The above parameters are mandatory and MUST be present in every Mbus
configuration entity.
The following parameters are optional. When they are present they
MUST be honored. When they are not present implementations SHOULD
fall back to the predefined default values (as defined in Transport
(Section 6)):
Address
The non-standard multicast address to use for message
transport.
Use of Broadcast
It can be specified whether broadcast should be used. If
broadcast has been configured implementations SHOULD use the
network broadcast address (as specified in Section 6.1.3)
instead of the standard multicast address.
Port Number
The non-standard UDP port number to use for message transport.
Two distinct facilities for parameter storage are considered: For
Unix-like systems a per-user configuration file SHOULD be used and
for Windows-95/98/NT/2000/XP systems a set of registry entries is
defined that SHOULD be used. For other systems it is RECOMMENDED
that the file-based configuration mechanism is used.
The syntax of the values for the respective parameter entries remains
the same for both configuration facilities. The following defines a
set of ABNF (see RFC2234 [13]) productions that are later re-used
for the definitions for the configuration file syntax and registry
entries:
algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" /
"HMAC-MD5-96" / "HMAC-SHA1-96"
scope = "HOSTLOCAL" / "LINKLOCAL"
key = base64
version_number = 1*10DIGIT
key_value = "(" algo-id "," key ")"
address = IPv4address / IPv6address / "BROADCAST"
port = 1*5DIGIT ; values from 0 through 65535
Given the definition above, a key entry MUST be specified using this
notation:
"("algo-id","base64string")"
algo-id is one of the character strings specified above. For algo-
id=="NOENCR" the other fields are ignored. The delimiting commas
MUST always be present though.
A Base64 string consists of the characters defined in the Base64
char-set (see RFC1521 [7]) including all possible padding
characters, i.e., the length of a Base64-string is always a multiple
of 4.
The scope parameter is used to configure an IP-Multicast scope and
may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations
SHOULD choose an appropriate IP-Multicast scope depending on the
value of this parameter and construct an effective IP-Address
considering the specifications of Section 6.1.
The use of broadcast is configured by providing the value "BROADCAST"
for the address field. If broadcast has been configured,
implementations SHOULD use the network broadcast address for the used
IP version instead of the standard multicast address.
The version_number parameter specifies a version number for the used
configuration entity.
12.1 File based parameter storage
The file name for an Mbus configuration file is ".mbus" in the user's
home-directory. If an environment variable called MBUS is defined
implementations SHOULD interpret the value of this variable as a
fully qualified file name that is to be used for the configuration
file. Implementations MUST ensure that this file has appropriate
file permissions that prevent other users to read or write it. The
file MUST exist before a conference is initiated. Its contents MUST
be UTF-8 encoded and MUST comply to the following syntax definition:
mbus-file = mbus-topic LF *(entry LF)
mbus-topic = "[MBUS]"
entry = 1*(version_info / hashkey_info
/ encryptionkey_info / scope_info
/ port_info / address_info)
version_info = "CONFIG_VERSION=" version_number
hashkey_info = "HASHKEY=" key_value
encrkey_info = "ENCRYPTIONKEY=" key_value
scope_info = "SCOPE=" scope
port_info = "PORT=" port
address_info = "ADDRESS=" address
The following entries are defined: CONFIG_VERSION, HASHKEY,
ENCRYPTIONKEY, SCOPE, PORT, ADDRESS.
The entries CONFIG_VERSION, HASHKEY and ENCRYPTIONKEY are mandatory,
they MUST be present in every Mbus configuration file. The order of
entries is not significant.
An example for an Mbus configuration file:
[MBUS]
CONFIG_VERSION=1
HASHKEY=(HMAC-MD5-96,MTIzMTU2MTg5MTEy)
ENCRYPTIONKEY=(DES,MTIzMTU2MQ==)
SCOPE=HOSTLOCAL
ADDRESS=224.255.222.239
PORT=47000
12.2 Registry-based parameter storage
For systems lacking the concept of a user's home-directory as a place
for configuration files the suggested database for configuration
settings (e.g., the Windows9x, Windows NT, Windows 2000, Windows XP
registry) SHOULD be used. The hierarchy for Mbus related registry
entries is as follows:
HKEY_CURRENT_USER\Software\Mbus
The entries in this hierarchy section are:
+---------------+--------+----------------+
|Name | Type | ABNF production|
+---------------+--------+----------------|
|CONFIG_VERSION | DWORD | version_number |
|HASHKEY | String | key_value |
|ENCRYPTIONKEY | String | key_value |
|SCOPE | String | scope |
|ADDRESS | String | address |
|PORT | DWORD | port |
+---------------+--------+----------------+
The same syntax for key values as for the file based configuration
facility MUST be used.
13. Security Considerations
The Mbus security mechanisms are specified in Section 11.1.
It should be noted that the Mbus transport specification defines a
mandatory baseline set of algorithms that have to be supported by
implementations. This baseline set is intended to provide reasonable
security by mandating algorithms and key lengths that are considered
to be cryptographically strong enough at the time of writing.
However, in order to allow for efficiency it is allowable to use
cryptographically weaker algorithms, for example HMAC-MD5 instead of
HMAC-SHA1. Furthermore, encryption can be turned off completely if
privacy is provided by other means or not considered important for a
certain application.
Users of the Mbus should therefore be aware of the selected security
configuration and should check if it meets the security demands for a
given application. Since every implementation MUST provide the
cryptographically strong algorithm it should always be possible to
configure an Mbus in a way that secure communication with
authentication and privacy is ensured.
In any way, application developers should be aware of incorrect IP
implementations that do not conform to RFC1122 [2] and do send
datagrams with TTL values of zero, resulting in Mbus messages sent to
the local network link although a user might have selected host local
scope in the Mbus configuration. When using administratively scoped
multicast, users cannot always assume the presence of correctly
configured boundary routers. In these cases the use of encryption
SHOULD be considered if privacy is desired.
14. IANA Considerations
The IANA has assigned a scope-relative multicast address with an
offset of 8 for Mbus/IPv4. The IPv6 permanent multicast address is
FF0X:0:0:0:0:0:0:300.
The registered Mbus UDP port number is 47000.
15. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[2] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC1122, October 1989.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC2373, July 1998.
[4] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC2375, July 1998.
[5] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC2104, February 1997.
[6] Resnick, P., Editor, "Internet Message Format", RFC2822, April
2001.
[7] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC1521, September
1993.
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC2543, March 1999.
[10] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC2327, April 1998.
[11] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[12] Balenson, D., "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers", RFC1423,
February 1993.
[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
[14] Myers, J., "SMTP Service Extension for Authentication", RFC
2554, March 1999.
[15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC1321, April
1992.
[16] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and
Technology, "Data Encryption Standard (DES)", FIPS PUB 46-3,
Category Computer Security, Subcategory Cryptography, October
1999.
[17] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and
Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995.
[18] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March
1999.
[19] IANA, "Internet Multicast Addresses", URL
http://www.iana.org/assignments/multicast-addresses, May 2001.
[20] Schneier, B., "Applied Cryptography", Edition 2, Publisher John
Wiley & Sons, Inc., status: non-normative, 1996.
Appendix A. About References
Please note that the list of references contains normative as well as
non-normative references. Each Non-normative references is marked as
"status: non-normative". All unmarked references are normative.
Appendix B. Limitations and Future Work
The Mbus is a light-weight local coordination mechanism and
deliberately not designed for larger scope coordination. It is
expected to be used on a single node or -- at most -- on a single
network link.
Therefore the Mbus protocol does not contain features that would be
required to qualify it for the use over the global Internet:
There are no mechanisms to provide congestion control. The issue
of congestion control is a general problem for multicast
protocols. The Mbus allows for un-acknowledged messages that are
sent unreliably, for example as event notifications, from one
entity to another. Since negative acknowledgements are not
defined there is no way the sender could realize that it is
flooding another entity or congesting a low bandwidth network
segment.
The reliability mechanism, i.e., the retransmission timers, are
designed to provide effective, responsive message transport on
local links but are not suited to cope with larger delays that
could be introduced from router queues etc.
Some experiments are currently underway to test the applicability of
bridges between different distributed Mbus domains without changing
the basic protocol semantics. Since the use of such bridges should
be orthogonal to the basic Mbus protocol definitions and since these
experiments are still work in progress there is no mention of this
concept in this specification.
Authors' Addresses
Joerg Ott
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.201-7028
Fax: +49.421.218-7000
EMail: jo@tzi.uni-bremen.de
Colin Perkins
USC Information Sciences Institute
3811 N. Fairfax Drive #200
Arlington VA 22203
USA
EMail: csp@isi.edu
Dirk Kutscher
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.218-7595
Fax: +49.421.218-7000
EMail: dku@tzi.uni-bremen.de
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.