idnits 2.17.1 draft-duke-taps-transport-discovery-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (9 April 2021) is 1113 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-09 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-10 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 taps M. Duke 3 Internet-Draft F5 Networks, Inc. 4 Intended status: Informational 9 April 2021 5 Expires: 11 October 2021 7 TAPS Transport Discovery 8 draft-duke-taps-transport-discovery-00 10 Abstract 12 The Transport Services architecture decouples applications from the 13 protocol implementations that transport their data. While it is 14 often straightforward to connect applications with transports that 15 are present in the host operating system, providing a means of 16 discovering user-installed implementations dramatically enlarges the 17 use cases. This document discusses considerations for the design of 18 a discovery mechanism and an example of such a design. 20 Discussion of this work is encouraged to happen on the TAPS IETF 21 mailing list taps@ietf.org or on the GitHub repository which contains 22 the draft: https://github.com/martinduke/draft-duke-taps-transport- 23 discovery. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 11 October 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Entities . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Protocol Implementation . . . . . . . . . . . . . . . . . . . 4 62 5. Protocol Installer . . . . . . . . . . . . . . . . . . . . . 4 63 6. TAPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 9. Informative References . . . . . . . . . . . . . . . . . . . 6 67 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The Transport Services architecture [I-D.ietf-taps-arch] enables 73 applications to be protocol-agnostic by presenting an interface where 74 applications can specify their required properties, and the service 75 will select whichever protocol implementation available in the system 76 best meets those requirements. This increases application 77 portability and eases the introduction of new transport innovations 78 by not requiring changes to applications. 80 It is sometimes straightforward for a Transport Services interface to 81 identify the transports available in the host operating system. 82 However, including transports installed by the user greatly expands 83 use cases for the architecture. This document presents 84 considerations for the secure design of a system for discovery of new 85 protocol implementations. 87 Protocol Discovery would ideally have several desirable properties. 89 * The transport services API should not have to recompile when 90 installing new implementations. This would not only disrupt 91 ongoing connections, but also involve ordinary users in the 92 complex business of downloading and building source code. 94 * It should support user-space implementations. Most protocol 95 innovation begins with user space implementations, and many 96 transports (e.g. TLS, HTTP, QUIC) are usually implemented outside 97 the kernel long after reaching maturity. 99 * Protocol Discovery should not subject ordinary users to security 100 vulnerabilities. A new protocol installation is an opportunity to 101 hijack a user's networking stack, and Protocol Discovery requires 102 strong protections against arbitrary code performing operations 103 other than advertised on application data. 105 * Conversely, sophisticated users need a means of discovering 106 implementations that are too new to have fully developed internet 107 trust mechanisms. This is the only means of initially deploying 108 new protocols for existing apps, and is the most plausible model 109 to deploy transport services API shims for existing protocol 110 libraries (e.g., the common TLS implementations) before their 111 proponents deploy native support. 113 * Applications should not have to bring their own implementations. 114 The Transport Services API has the concept of "framers" (see Sec. 115 7.1 of [I-D.ietf-taps-interface]) that provide some ability for 116 applications to provide additional protocol encapsulation around 117 their messages. However, one important advantage of Transport 118 Services is that applications do not have to rely on a third-party 119 implementation that might not offer long term support, or add to 120 their footprint where a functionally equivalent protocol 121 implementation is already present on the system. 123 This document attempts to resolve the tension between some of these 124 properties. 126 2. Conventions 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 "TAPS" is an abbreviation for the transport services API. 134 For brevity, this document will use "app" as a shorthand for 135 "application." 137 As in other TAPS documents, the concept of a "transport protocol" is 138 expanded beyond the traditional "transport layer" to include other 139 protocols that encapsulate application data, such as TLS, HTTP, and 140 Websockets. 142 3. Entities 144 The Transport Services API (TAPS) is responsible for matching 145 protocol capabilities with application requirements, and mediating 146 further app communication with the selected protocol implementation. 147 In this document, it actively discovers what implementations are 148 available in the system. 150 The protocol implementation instantiates the transport. In this 151 document, it offers a dynamically linked library that conforms to 152 standard interfaces so that TAPS can interchangeability interact with 153 it. In practice, this may be a shim layer if the underlying 154 implementation does not support TAPS. 156 The protocol installer, aside from installing the implementation 157 library and/or a TAPS shim layer, also is responsible for notifying 158 TAPS that the implementation is present, and what its capabilities 159 are. 161 Finally, the application leverages TAPS to initiate, manage, and 162 terminate communications with other endpoints. This document does 163 not require any changes to application behavior beyond those in the 164 core TAPS design. 166 More detailed requirements for each of these entities is below. 168 4. Protocol Implementation 170 The protocol implementation must offer a dynamically linked library 171 that offers certain APIs. 173 These APIs are TBD. 175 5. Protocol Installer 177 The installer might use the operating system's package manager or 178 "app store", or be a simple script. Besides installing the 179 implementation, the installer also writes data to a registry that 180 TAPS will access to discover the implementation. 182 This data will include: 184 * the name of the supported protocol(s); 186 * optionally, the versions of those protocols; 188 * the path to the implementations TAPS-compliant library; 189 * the properties that the protocol implementation supports, as 190 described in Section 4.2 of [I-D.ietf-taps-interface]; and 192 * information to authenticate the entry (see Section 7). 194 Of course, a de-installer should remove the appropriate registry 195 entry. 197 6. TAPS 199 TAPS creates a registry for protocol implementations, which might be 200 a database or a directory. To prevent inadvertent security 201 vulnerabilities, the host system SHOULD, at minimum, require 202 administrative privileges to write to the registry. 204 No later than upon receipt of request for a Preconnection, TAPS MUST 205 access the registry to determine the available protocols and their 206 properties. It is perfectly valid for there to be multiple 207 implementations of a protocol. 209 TAPS SHOULD validate entries in the registry using the provided 210 authentication data. 212 7. Security Considerations 214 User-space installation of protocols provides enormous opportunities 215 for attackers to hijack a network stack. While this has always been 216 possible with arbitrary protocol implementations, with TAPS 217 applications completely unaware of the installation can be victims of 218 such an attack. 220 An implementation might advertise properties it does not actually 221 provide to attract more traffic. For example, a "TLS" implementation 222 might not encrypt anything at all. 224 Moreover, in principle an implementation could deliver application 225 data anywhere it wanted with little visibility to the application, 226 much less the user. 228 The origin of the protocol installer is important to the trust model. 229 Obviously, transports in the kernel do not introduce vulnerabilities 230 specific to TAPS. A trusted package manager (e.g. the Apple App 231 Store or yum) may imply a minimal level of veracity of the available 232 packages. Protocol implementations directly downloaded from the 233 internet without mediation throught these mechanisms require the 234 greatest care. 236 Ongoing work on this document will largely focus on building 237 mechanisms to mitigate this weakness. Some promising approaches 238 include: 240 * administrative privileges to alter the TAPS registry; 242 * a special certificate authority that provides an authentication of 243 the implementation's explicit and implicit claims, as well as the 244 integrity of the installed binary; 246 * each installer generates a private key and provides the 247 corresponding public key, so that only possessors of the private 248 key can modify or delete the registry entry; 250 * confirmation by a human, prominently warned of potential 251 consequences, if the installation is not mediated through a 252 trusted authority. 254 8. IANA Considerations 256 This document has no IANA requirements. 258 9. Informative References 260 [I-D.ietf-taps-arch] 261 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 262 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 263 Transport Services", Work in Progress, Internet-Draft, 264 draft-ietf-taps-arch-09, 2 November 2020, 265 . 268 [I-D.ietf-taps-interface] 269 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 270 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 271 Pauly, "An Abstract Application Layer Interface to 272 Transport Services", Work in Progress, Internet-Draft, 273 draft-ietf-taps-interface-10, 2 November 2020, 274 . 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 Appendix A. Acknowledgments 284 Tim Worsley contributed important ideas to this document. 286 Author's Address 288 Martin Duke 289 F5 Networks, Inc. 291 Email: martin.h.duke@gmail.com