Principles for Multiplexing of UDP-based Protocols
Mozilla
martin.thomson@gmail.com
IAB
Internet-Draft
The existence of protocols that rely on multiplexing of different protocols
could be used to justify the imposition of constraints on the operation of
other protocols. The existence of a multiplexed protocol does not inherently
justify constraints on protocols that participate or might participate in the
protocol.
The use of multiple protocols that share a 5-tuple is possible in unordered
transport like UDP. Multiplexing in this fashion creates a meta-protocol that
is comprised of the set of protocols that are multiplexed.
A specific example of such a meta-protocol is documented in RFC 7983
. This protocol comprises up to 5 different protocols: STUN
, ZRTP , DTLS , TURN
channels , and RTP . The meta-protocol that
is composed from this set of protocols is commonly deployed for use in
real-time communications. Of particular note is the STUN protocol ,
which is specifically designed to be multiplexed with another protocol.
The existence of a multiplexed meta-protocol can be used to justify constraints
on the definition of new protocols, or the addition of changes to protocols that
participate. These constraints should be considered in the context of the
protocol in use. A protocol design for use outside of a multiplexed context
should not be unduly constrained by the limitations of a chosen multiplexing
scheme.
Any protocol that includes integrity checks can be multiplexed with any other
protocol. A sufficiently strong checksum or cryptographic authentication tag
allows arriving datagrams to be rejected by any protocol that the datagram was
not intended for with high probability.
New protocols often require confidentiality and integrity and so use a solution
like TLS . Other protocols benefit greatly from being robust
against errors in the relatively weak checksum provided by
internet protocols . Thus, the
inclusion of strong integrity checks is beneficial for any internet protocol,
which makes the protocol highly likely to be classified by a recipient as
intended.
This does not mean that protocols are distinguishable to intermediaries.
Protocols that include use keyed integrity checks will not be identifiable to
entities that do not have access to keys.
Relying on an integrity check also probabilistic, meaning that shorter integrity
checks increase the chance that a datagram could be incorrectly classified by a
recipient. While the probability of collision is negligible for a protocol that
uses an integrity check with 128 bits or more of redundancy, a shorter integrity
check could be vulnerable to collisions and mis-classification.
As long as no more than one participating protocol lacks an integrity check of
sufficient strength, protocols can be demultiplexed with high reliability.
However, this form of demultiplexing can be grossly inefficient, as every
datagram needs to be validated once for each potential protocol that is in use.
Practical multiplexing schemes rely on simpler and more direct differences
between protocols. For instance, RFC 7983 separates protocols based
on the value of the first octet. While this scheme is cheap and effective, it
has the drawback of using a limited space of potential values. Of the 256
possible values for the first octet, RFC 7983 consumes 132 values. Adding more
protocols to the set that can be multiplexed would reduce the available space
further.
The design in RFC 7983 was initially opportunistic in nature. The original set
of protocols that were selected included only DTLS, SRTP, and STUN. Since then,
compatibility with that scheme has constrained the design of other protocols so
that they fit within this scheme. This is not an indefinitely sustainable
posture.
The need to multiplex can create unwanted constraints on the designs of
protocols, particularly as protocols evolve. For a protocol that is used
exclusively or predominantly in a multiplexed meta-protocol, this does not
present a significant burden, but protocols that have uses in other contexts are
different.
For instance, DTLS 1.3 defines a record layout
that uses the first octet in a very different fashion to earlier versions; this
design is constrained by the need to remain compatible with the scheme in RFC
7983 .
Multiplexing should not be a primary consideration in design of new protocols
that might be multiplexed. Similary, the design of extensions or revisions to
protocols should not be constrained by the potential for multiplexing.
Multiplexing considerations might be paid greater attention depending on how
likely it is that the protocol will be used together with other protocols.
For example, a new version of RTP might consider setting the version
field to 3. While this space in the multiplexing scheme in is
currently unallocated, changing the RTP version greatly reduces the space
available for other protocols. Because RTP is frequently used in a multiplexed
context, changing the RTP header is best avoided.
Protocol multiplexing works most efficiently when the protocol in use for any
given packet can be identified using only the contents of the packet. Stateful
multiplexing - where multiplexing rules change based on protocol state - is
possible, but is best avoided.
A protocol that intends to multiplex several protocols can avoid this sort of
pressure by adding an explicit multiplexing protocol layer. The simplest
multiplexing protocol is a shim of a small number of octets that is added to the
start or end of every datagram. The value of these octets is then used to
identify the protocol.
For a scheme like that in , it is possible to use a shim for only
some protocols, whether other protocols are multiplexed based on their inherent
observable properties.
Expanding the size of datagrams can have implications for protocol operation.
Trivially, it reduces the space in the path maximum transfer unit (PMTU)
, available to the multiplexed
meta-protocol.
More substantially, the addition of octets to a protocol datagram - especially
at the start - can also mean that the apparent format of datagrams changes. If
a multiplexed meta-protocol adds octets to the start of payloads, this reduces
the degree to which the multiplexed meta-protocol can be identified correctly.
Some middleboxes have been shown to observe and discriminate based on the
content of flows, even when large parts of a flow is encrypted and therefore
inaccessible to the middlebox. Octets added to the start of a datagram could
cause middleboxes to apply different treatment to a protocol when it is
multiplexed than when it is not.
A multiplexing scheme that relies on certain properties of a protocol cannot
expect those properties to remain fixed as that protocol changes.
It’s possible that the designers of a protocol will explicitly guarantee that
certain properties won’t change over time, such as the invariants defined in
, in which case a multiplexing
scheme could be designed based on those guarantees.
Choosing a multiplexing scheme that relies on properties of a protocol remaining
constant can either impose unwanted constraints on the design of a protocol that
is selected for multiplexing, or it can cause some or all features of that
protocol to be unusable in the multiplexed context when that protocol changes.
The ability to use new protocol features can have a material impact on security
if access to updated or added security-related features is prevented by an
incompatibility with a chosen multiplexing scheme.
This document has no IANA actions.
Multiplexing Scheme Updates for Secure Real-time Transport Protocol (SRTP) Extension for Datagram Transport Layer Security (DTLS)
This document defines how Datagram Transport Layer Security (DTLS), Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP), Session Traversal Utilities for NAT (STUN), Traversal Using Relays around NAT (TURN), and ZRTP packets are multiplexed on a single receiving socket. It overrides the guidance from RFC 5764 ("SRTP Extension for DTLS"), which suffered from four issues described and fixed in this document.This document updates RFC 5764.
Session Traversal Utilities for NAT (STUN)
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.This document obsoletes RFC 3489. [STANDARDS-TRACK]
ZRTP: Media Path Key Agreement for Unicast Secure RTP
This document defines ZRTP, a protocol for media path Diffie-Hellman exchange to agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications. The ZRTP protocol is media path keying because it is multiplexed on the same port as RTP and does not require support in the signaling protocol. ZRTP does not assume a Public Key Infrastructure (PKI) or require the complexity of certificates in end devices. For the media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the signaling protocol provides end-to-end integrity protection, authentication. ZRTP can utilize a Session Description Protocol (SDP) attribute to provide discovery and authentication through the signaling channel. To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media sessions that include a voice media stream and can also secure media sessions that do not include voice by using an optional digital signature. This document is not an Internet Standards Track specification; it is published for informational purposes.
Datagram Transport Layer Security Version 1.2
This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers). In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from some other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. [STANDARDS-TRACK]
RTP: A Transport Protocol for Real-Time Applications
This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. Most of the text in this memorandum is identical to RFC 1889 which it obsoletes. There are no changes in the packet formats on the wire, only changes to the rules and algorithms governing how the protocol is used. The biggest change is an enhancement to the scalable timer algorithm for calculating when to send RTCP packets in order to minimize transmission in excess of the intended rate when many participants join a session simultaneously. [STANDARDS-TRACK]
The Transport Layer Security (TLS) Protocol Version 1.2
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]
Computing the Internet checksum
This RFC summarizes techniques and algorithms for efficiently computing the Internet checksum. It is not a standard, but a set of useful implementation techniques.
When the CRC and TCP checksum disagree
The Datagram Transport Layer Security (DTLS) Protocol Version 1.3
This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol.
Path MTU discovery
This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK]
Path MTU Discovery for IP version 6
This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981.
Version-Independent Properties of QUIC
This document defines the properties of the QUIC transport protocol that are expected to remain unchanged over time as new versions of the protocol are developed. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-invariants [3].