Internet-Draft transport-discovery April 2021
Duke Expires 11 October 2021 [Page]
Intended Status:
M. Duke
F5 Networks, Inc.

TAPS Transport Discovery


The Transport Services architecture decouples applications from the protocol implementations that transport their data. While it is often straightforward to connect applications with transports that are present in the host operating system, providing a means of discovering user-installed implementations dramatically enlarges the use cases. This document discusses considerations for the design of a discovery mechanism and an example of such a design.

Discussion of this work is encouraged to happen on the TAPS IETF mailing list or on the GitHub repository which contains the draft:

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

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 11 October 2021.

Table of Contents

1. Introduction

The Transport Services architecture [I-D.ietf-taps-arch] enables applications to be protocol-agnostic by presenting an interface where applications can specify their required properties, and the service will select whichever protocol implementation available in the system best meets those requirements. This increases application portability and eases the introduction of new transport innovations by not requiring changes to applications.

It is sometimes straightforward for a Transport Services interface to identify the transports available in the host operating system. However, including transports installed by the user greatly expands use cases for the architecture. This document presents considerations for the secure design of a system for discovery of new protocol implementations.

Protocol Discovery would ideally have several desirable properties.

This document attempts to resolve the tension between some of these properties.

2. 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 [RFC2119].

"TAPS" is an abbreviation for the transport services API.

For brevity, this document will use "app" as a shorthand for "application."

As in other TAPS documents, the concept of a "transport protocol" is expanded beyond the traditional "transport layer" to include other protocols that encapsulate application data, such as TLS, HTTP, and Websockets.

3. Entities

The Transport Services API (TAPS) is responsible for matching protocol capabilities with application requirements, and mediating further app communication with the selected protocol implementation. In this document, it actively discovers what implementations are available in the system.

The protocol implementation instantiates the transport. In this document, it offers a dynamically linked library that conforms to standard interfaces so that TAPS can interchangeability interact with it. In practice, this may be a shim layer if the underlying implementation does not support TAPS.

The protocol installer, aside from installing the implementation library and/or a TAPS shim layer, also is responsible for notifying TAPS that the implementation is present, and what its capabilities are.

Finally, the application leverages TAPS to initiate, manage, and terminate communications with other endpoints. This document does not require any changes to application behavior beyond those in the core TAPS design.

More detailed requirements for each of these entities is below.

4. Protocol Implementation

The protocol implementation must offer a dynamically linked library that offers certain APIs.

These APIs are TBD.

5. Protocol Installer

The installer might use the operating system's package manager or "app store", or be a simple script. Besides installing the implementation, the installer also writes data to a registry that TAPS will access to discover the implementation.

This data will include:

Of course, a de-installer should remove the appropriate registry entry.


TAPS creates a registry for protocol implementations, which might be a database or a directory. To prevent inadvertent security vulnerabilities, the host system SHOULD, at minimum, require administrative privileges to write to the registry.

No later than upon receipt of request for a Preconnection, TAPS MUST access the registry to determine the available protocols and their properties. It is perfectly valid for there to be multiple implementations of a protocol.

TAPS SHOULD validate entries in the registry using the provided authentication data.

7. Security Considerations

User-space installation of protocols provides enormous opportunities for attackers to hijack a network stack. While this has always been possible with arbitrary protocol implementations, with TAPS applications completely unaware of the installation can be victims of such an attack.

An implementation might advertise properties it does not actually provide to attract more traffic. For example, a "TLS" implementation might not encrypt anything at all.

Moreover, in principle an implementation could deliver application data anywhere it wanted with little visibility to the application, much less the user.

The origin of the protocol installer is important to the trust model. Obviously, transports in the kernel do not introduce vulnerabilities specific to TAPS. A trusted package manager (e.g. the Apple App Store or yum) may imply a minimal level of veracity of the available packages. Protocol implementations directly downloaded from the internet without mediation throught these mechanisms require the greatest care.

Ongoing work on this document will largely focus on building mechanisms to mitigate this weakness. Some promising approaches include:

8. IANA Considerations

This document has no IANA requirements.

9. Informative References

Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Perkins, C., Tiesel, P., and C. Wood, "An Architecture for Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-arch-09, , <>.
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. Pauly, "An Abstract Application Layer Interface to Transport Services", Work in Progress, Internet-Draft, draft-ietf-taps-interface-10, , <>.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.

Appendix A. Acknowledgments

Tim Worsley contributed important ideas to this document.

Author's Address

Martin Duke
F5 Networks, Inc.