idnits 2.17.1 draft-duke-taps-transport-discovery-02.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 (25 October 2021) is 885 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-11 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-13 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 25 October 2021 5 Expires: 28 April 2022 7 TAPS Transport Discovery 8 draft-duke-taps-transport-discovery-02 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 Discussion Venues 27 This note is to be removed before publishing as an RFC. 29 Discussion of this document takes place on the mailing list 30 (taps@ietf.org), which is archived at 31 https://mailarchive.ietf.org/arch/browse/taps/. 33 Source for this draft and an issue tracker can be found at 34 https://github.com/martinduke/draft-duke-taps-transport-discovery. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 28 April 2022. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Entities . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 4. Protocol Implementation . . . . . . . . . . . . . . . . . . . 5 73 4.1. Functions . . . . . . . . . . . . . . . . . . . . . . . . 5 74 4.2. Events . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. Protocol Installer . . . . . . . . . . . . . . . . . . . . . 6 76 6. TAPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 80 10. Informative References . . . . . . . . . . . . . . . . . . . 8 81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 82 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9 83 B.1. since draft-duke-taps-transport-discovery-01 . . . . . . 9 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 The Transport Services architecture [I-D.ietf-taps-arch] enables 89 applications to be protocol-agnostic by presenting an interface where 90 applications can specify their required properties, and the service 91 will select whichever protocol implementation available in the system 92 best meets those requirements. This increases application 93 portability and eases the introduction of new transport innovations 94 by not requiring changes to applications. 96 It is sometimes straightforward for a Transport Services interface to 97 identify the transports available in the host operating system. 98 However, including transports installed by the user greatly expands 99 use cases for the architecture. This document presents 100 considerations for the secure design of a system for discovery of new 101 protocol implementations. 103 Protocol Discovery would ideally have several desirable properties. 105 * The transport services API should not have to recompile when 106 installing new implementations. This would not only disrupt 107 ongoing connections, but also involve ordinary users in the 108 complex business of downloading and building source code. 110 * It should support user-space implementations. Most protocol 111 innovation begins with user space implementations, and many 112 transports (e.g. TLS, HTTP, QUIC) are usually implemented outside 113 the kernel long after reaching maturity. 115 * Protocol Discovery should not subject ordinary users to security 116 vulnerabilities. A new protocol installation is an opportunity to 117 hijack a user's networking stack, and Protocol Discovery requires 118 strong protections against arbitrary code performing operations 119 other than advertised on application data. 121 * Conversely, sophisticated users need a means of discovering 122 implementations that are too new to have fully developed internet 123 trust mechanisms. This is the only means of initially deploying 124 new protocols for existing apps, and is the most plausible model 125 to deploy transport services API shims for existing protocol 126 libraries (e.g., the common TLS implementations) before their 127 proponents deploy native support. 129 * Applications should not have to bring their own implementations. 130 The Transport Services API has the concept of "framers" (see Sec. 131 7.1 of [I-D.ietf-taps-interface]) that provide some ability for 132 applications to provide additional protocol encapsulation around 133 their messages. However, one important advantage of Transport 134 Services is that applications do not have to rely on a third-party 135 implementation that might not offer long term support, or add to 136 their footprint where a functionally equivalent protocol 137 implementation is already present on the system. 139 This document attempts to resolve the tension between some of these 140 properties. 142 2. Conventions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 "TAPS" is an abbreviation for the transport services API. 150 For brevity, this document will use "app" as a shorthand for 151 "application." 153 As in other TAPS documents, the concept of a "transport protocol" is 154 expanded beyond the traditional "transport layer" to include other 155 protocols that encapsulate application data, such as TLS, HTTP, and 156 Websockets. 158 3. Entities 160 The Transport Services API (TAPS) is responsible for matching 161 protocol capabilities with application requirements, and mediating 162 further app communication with the selected protocol implementation. 163 In this document, it actively discovers what implementations are 164 available in the system. 166 The protocol implementation instantiates the transport. In this 167 document, it offers a dynamically linked library that conforms to 168 standard interfaces so that TAPS can interchangeability interact with 169 it. In practice, this may be a shim layer if the underlying 170 implementation does not support TAPS. 172 The protocol installer, aside from installing the implementation 173 library and/or a TAPS shim layer, also is responsible for notifying 174 TAPS that the implementation is present, and what its capabilities 175 are. 177 Finally, the application leverages TAPS to initiate, manage, and 178 terminate communications with other endpoints. This document does 179 not require any changes to application behavior beyond those in the 180 core TAPS design. 182 More detailed requirements for each of these entities is below. 184 4. Protocol Implementation 186 The protocol implementation must offer a dynamically linked library 187 that offers certain APIs. TAPS SHOULD, in its documentation, provide 188 a template for the format of these functions. 190 4.1. Functions 192 The objects below need not follow the semantics of the TAPS 193 application API. In particular, a "message" is unlikely to have all 194 the property information described there, instead being a more 195 primitive buffer in which raw data is stored. 197 ''' Listener := Listen(localEndpoint) ''' 199 Listen opens a socket and listens on the specified address, and 200 returns a handle to the resulting listener. 202 ''' Listener.Stop() ''' 204 Stop causes the listener to stop accepting connections. Subsequent 205 events will return handles to the resulting connection. 207 ''' Connection.Send(Message) Connection.Receive(Message) ''' 209 TAPS will provide a Message object for the protocol to either send, 210 or use to store incoming data. 212 Further APIs are TBD. 214 4.2. Events 216 The protocol needs to throw all the events described in the TAPS 217 Application API, although the return values may not exactly conform 218 to the same semantics. 220 TAPS SHOULD provide an event framework that frees the protocol 221 implementation from running its own thread for a polling loop. TAPS 222 also SHOULD account for the possibility that the implementation may 223 have its own polling architecture. If true, the protocol MUST 224 conform to the API by translating its events into the signals or 225 callbacks that TAPS expects. 227 5. Protocol Installer 229 The installer might use the operating system's package manager or 230 "app store", or be a simple script. Besides installing the 231 implementation, the installer also writes data to a registry that 232 TAPS will access to discover the implementation. 234 This data will include: 236 * the name of the supported protocol(s); 238 * optionally, the versions of those protocols; 240 * the path to the implementations TAPS-compliant library; 242 * the properties that the protocol implementation supports, as 243 described in Section 4.2 of [I-D.ietf-taps-interface]; and 245 * information to authenticate the entry (see Section 7). 247 Of course, a de-installer should remove the appropriate registry 248 entry. 250 A TAPS implementation SHOULD provide a template for this registry 251 information. 253 One potential instantiation of this would have protocol installers 254 write a file to a directory that, in a specified markup language, 255 described the information above. 257 6. TAPS 259 TAPS creates a registry for protocol implementations, which might be 260 a database or a directory. To prevent inadvertent security 261 vulnerabilities, the host system SHOULD, at minimum, require 262 administrative privileges to write to the registry. 264 No later than upon receipt of request for a Preconnection, TAPS MUST 265 access the registry to determine the available protocols and their 266 properties. It is perfectly valid for there to be multiple 267 implementations of a protocol. 269 TAPS SHOULD validate entries in the registry using the provided 270 authentication data. 272 One potential instaniation would start daemon that monitored the 273 status of the registry. Upon any change to the registry, the daemon 274 might: 276 * authenticate any new entry in accordance with security policy; 278 * verify that the required function handles are present; 280 * run tests to verify the installation's claimed properties; 282 * inform the user of the new protocol, requesting permission to 283 trust it; and 285 * write the information into shared memory for the use of 286 Preconnections. 288 7. Security Considerations 290 User-space installation of protocols provides enormous opportunities 291 for attackers to hijack a network stack. While this has always been 292 possible with arbitrary protocol implementations, with TAPS 293 applications completely unaware of the installation can be victims of 294 such an attack. 296 An implementation might advertise properties it does not actually 297 provide to attract more traffic. For example, a "TLS" implementation 298 might not encrypt anything at all. A TAPS implementation MAY run 299 tests on newly installed protocols to verify it provides the 300 advertised properties. 302 Moreover, in principle an implementation could deliver application 303 data anywhere it wanted with little visibility to the application, 304 much less the user. 306 The origin of the protocol installer is important to the trust model. 307 Obviously, transports in the kernel do not introduce vulnerabilities 308 specific to TAPS. A trusted package manager (e.g. the Apple App 309 Store or yum) may imply a minimal level of veracity of the available 310 packages. Protocol implementations directly downloaded from the 311 internet without mediation through these mechanisms require the 312 greatest care. 314 Ongoing work on this document will largely focus on building 315 mechanisms to mitigate this weakness. Some promising approaches 316 include: 318 * administrative privileges to alter the TAPS registry; 320 * a special certificate authority that provides an authentication of 321 the implementation's explicit and implicit claims, as well as the 322 integrity of the installed binary; 324 * each installer generates a private key and provides the 325 corresponding public key, so that only possessors of the private 326 key can modify or delete the registry entry; 328 * confirmation by a human, prominently warned of potential 329 consequences, if the installation is not mediated through a 330 trusted authority. 332 8. IANA Considerations 334 This document has no IANA requirements. 336 9. Implementation Status 338 *RFC Editor's Note:* Please remove this section prior to 339 publication of a final version of this document. 341 The Dynamic TAPS project (https://github.com/f5networks/dynamic-taps) 342 is a preliminary effort to implement the concepts in this document. 344 10. Informative References 346 [I-D.ietf-taps-arch] 347 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 348 Perkins, C., Tiesel, P. S., and C. A. Wood, "An 349 Architecture for Transport Services", Work in Progress, 350 Internet-Draft, draft-ietf-taps-arch-11, 12 July 2021, 351 . 354 [I-D.ietf-taps-interface] 355 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 356 Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A., 357 Pauly, T., and K. Rose, "An Abstract Application Layer 358 Interface to Transport Services", Work in Progress, 359 Internet-Draft, draft-ietf-taps-interface-13, 12 July 360 2021, . 363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 364 Requirement Levels", BCP 14, RFC 2119, 365 DOI 10.17487/RFC2119, March 1997, 366 . 368 Appendix A. Acknowledgments 370 Tim Worsley contributed important ideas to this document. 372 Appendix B. Change Log 374 *RFC Editor's Note:* Please remove this section prior to 375 publication of a final version of this document. 377 B.1. since draft-duke-taps-transport-discovery-01 379 * Added output of initial implementation work 381 Author's Address 383 Martin Duke 384 F5 Networks, Inc. 386 Email: martin.h.duke@gmail.com