Internet DRAFT - draft-thomson-mux-principles
draft-thomson-mux-principles
Network Working Group M. Thomson
Internet-Draft Mozilla
Updates: 7983 (if approved) December 03, 2017
Intended status: Informational
Expires: June 6, 2018
Principles for Multiplexing of UDP-based Protocols
draft-thomson-mux-principles-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on June 6, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Thomson Expires June 6, 2018 [Page 1]
Internet-Draft UDP Multiplexing Principles December 2017
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
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
[RT-MUX]. This protocol comprises up to 5 different protocols: STUN
[STUN], ZRTP [ZRTP], DTLS [DTLS], TURN channels [TURN], and RTP
[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 [STUN], 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.
2. Multiplexing is Almost Always Possible
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 [TLS]. Other protocols benefit greatly from
being robust against errors in the relatively weak checksum
[CHECKSUM] provided by internet protocols [CHECKSUM-FAIL]. 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.
Note: 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
Thomson Expires June 6, 2018 [Page 2]
Internet-Draft UDP Multiplexing Principles December 2017
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.
3. Multiplexing Considerations
Practical multiplexing schemes rely on simpler and more direct
differences between protocols. For instance, RFC 7983 [RT-MUX]
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 [DTLS13] 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 [RT-MUX].
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 [RTP] might consider setting the
version field to 3. While this space in the multiplexing scheme in
Thomson Expires June 6, 2018 [Page 3]
Internet-Draft UDP Multiplexing Principles December 2017
[RT-MUX] 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.
3.1. Alternative Multiplexing Designs
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 [RT-MUX], 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) [PMTUv4], [PMTUv6] 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.
4. No Expectation of Successful Multiplexing
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 [QUIC-INVARIANTS], in which case a multiplexing
scheme could be designed based on those guarantees.
Thomson Expires June 6, 2018 [Page 4]
Internet-Draft UDP Multiplexing Principles December 2017
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.
5. Security Considerations
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.
6. IANA Considerations
This document has no IANA actions.
7. Informative References
[CHECKSUM]
Braden, R., Borman, D., and C. Partridge, "Computing the
Internet checksum", RFC 1071, DOI 10.17487/RFC1071,
September 1988, <https://www.rfc-editor.org/info/rfc1071>.
[CHECKSUM-FAIL]
Stone, J. and C. Partridge, "When the CRC and TCP checksum
disagree", Proceedings of the conference on Applications,
Technologies, Architectures, and Protocols for Computer
Communication - SIGCOMM '00, DOI 10.1145/347059.347561,
2000.
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[DTLS13] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-02 (work in progress), October
2017.
[PMTUv4] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[PMTUv6] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
Thomson Expires June 6, 2018 [Page 5]
Internet-Draft UDP Multiplexing Principles December 2017
[QUIC-INVARIANTS]
Thomson, M., "Version-Independent Properties of QUIC",
draft-thomson-quic-invariants-00 (work in progress),
November 2017.
[RT-MUX] Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme
Updates for Secure Real-time Transport Protocol (SRTP)
Extension for Datagram Transport Layer Security (DTLS)",
RFC 7983, DOI 10.17487/RFC7983, September 2016,
<https://www.rfc-editor.org/info/rfc7983>.
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[STUN] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[TURN] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<https://www.rfc-editor.org/info/rfc5766>.
[ZRTP] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011,
<https://www.rfc-editor.org/info/rfc6189>.
Author's Address
Martin Thomson
Mozilla
Email: martin.thomson@gmail.com
Thomson Expires June 6, 2018 [Page 6]