diff options
Diffstat (limited to 'doc/rfc/rfc9419.txt')
| -rw-r--r-- | doc/rfc/rfc9419.txt | 815 |
1 files changed, 815 insertions, 0 deletions
diff --git a/doc/rfc/rfc9419.txt b/doc/rfc/rfc9419.txt new file mode 100644 index 0000000..a4e7f53 --- /dev/null +++ b/doc/rfc/rfc9419.txt @@ -0,0 +1,815 @@ + + + + +Internet Architecture Board (IAB) J. Arkko +Request for Comments: 9419 Ericsson +Category: Informational T. Hardie +ISSN: 2070-1721 Cisco + T. Pauly + Apple + M. Kühlewind + Ericsson + July 2023 + + +Considerations on Application - Network Collaboration Using Path Signals + +Abstract + + This document discusses principles for designing mechanisms that use + or provide path signals and calls for standards action in specific + valuable cases. RFC 8558 describes path signals as messages to or + from on-path elements and points out that visible information will be + used whether or not it is intended as a signal. The principles in + this document are intended as guidance for the design of explicit + path signals, which are encouraged to be authenticated and include a + minimal set of parties to minimize information sharing. These + principles can be achieved through mechanisms like encryption of + information and establishing trust relationships between entities on + a path. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board (IAB) + and represents information that the IAB has deemed valuable to + provide for permanent record. It represents the consensus of the + Internet Architecture Board (IAB). Documents approved for + publication by the IAB are not candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9419. + +Copyright Notice + + Copyright (c) 2023 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. + +Table of Contents + + 1. Introduction + 2. Principles + 2.1. Intentional Distribution + 2.2. Control of the Distribution of Information + 2.3. Protecting Information and Authentication + 2.4. Minimize Information + 2.5. Limiting Impact of Information + 2.6. Minimum Set of Entities + 2.7. Carrying Information + 3. Further Work + 4. IANA Considerations + 5. Security Considerations + 6. Informative References + IAB Members at the Time of Approval + Acknowledgments + Authors' Addresses + +1. Introduction + + [RFC8558] defines the term "path signals" as signals to or from on- + path elements. Today, path signals are often implicit; for example, + they are derived from cleartext end-to-end information by, e.g., + examining transport protocols. For instance, on-path elements use + various fields of the TCP header [RFC9293] to derive information + about end-to-end latency as well as congestion. These techniques + have evolved because the information was available and its use + required no coordination with anyone. This made such techniques more + easily deployable than alternative, potentially more explicit or + cooperative, approaches. + + However, this also means that applications and networks have often + evolved their interaction without comprehensive design for how this + interaction should happen or which (minimal) information would be + needed for a certain function. This has led to a situation where + information that happens to be easily available is used instead of + the information that is actually needed. As such, that information + may be incomplete, incorrect, or only indirectly representative of + the information that is actually needed. In addition, dependencies + on information and mechanisms that were designed for a different + function limit the evolvability of the protocols in question. + + In summary, such unplanned interactions end up having several + negative effects: + + * Ossifying protocols by introducing dependencies to unintended + parties that may not be updating, such as how middleboxes have + limited the use of TCP options + + * Creating systemic incentives against deploying more secure or + otherwise updated versions of protocols + + * Basing network behavior on information that may be incomplete or + incorrect + + * Creating a model where network entities expect to be able to use + rich information about sessions passing through + + For instance, features such as DNS resolution or TLS setup have been + used beyond their original intent, such as in name-based filtering. + Media Access Control (MAC) addresses have been used for access + control, captive portals have been used to take over cleartext HTTP + sessions, and so on. (This document is not about whether those + practices are good or bad; it is simply stating a fact that the + features were used beyond their original intent.) + + Many protocol mechanisms throughout the stack fall into one of two + categories: authenticated private communication that is only visible + to a very limited set of parties, often one on each "end", and + unauthenticated public communication that is visible to all network + elements on a path. + + Exposed information encourages pervasive monitoring, which is + described in [RFC7258]. It may also be used for commercial purposes + or to form a basis for filtering that the applications or users do + not desire. However, a lack of all path signaling, on the other + hand, may limit network management, debugging, or the ability for + networks to optimize their services. There are many cases where + elements on the network path can provide beneficial services, but + only if they can coordinate with the endpoints. It also affects the + ability of service providers and others to observe why problems occur + [RFC9075]. + + As such, this situation is sometimes cast as an adversarial trade-off + between privacy and the ability for the network path to provide + intended functions. However, this is perhaps an unnecessarily + polarized characterization as a zero-sum situation. Not all + information passing implies loss of privacy. For instance, + performance information or preferences do not require disclosing the + content being accessed, the user identity, or the application in use. + Similarly, network congestion status information does not have to + reveal network topology, the status of other users, and so on. + + Increased deployment of encryption is changing this situation. + Encryption provides tools for controlling information access and + protects against ossification by avoiding unintended dependencies and + requiring active maintenance. The increased deployment of encryption + provides an opportunity to reconsider parts of Internet architecture + that have used implicit derivation of input signals for on-path + functions rather than explicit signaling, as recommended by + [RFC8558]. + + For instance, QUIC replaces TCP for various applications and protects + end-to-end signals so that they are only accessible by the endpoints, + ensuring evolvability [RFC9000]. QUIC does expose information + dedicated for on-path elements to consume by using explicit signals + for specific use cases, such as the Spin Bit for latency measurements + or connection ID that can be used by load balancers [RFC9312]. This + information is accessible by all on-path devices, but information is + limited to only those use cases. Each new use case requires + additional action. This points to one way to resolve the adversity: + the careful design of what information is passed. + + Another extreme is to employ explicit trust and coordination between + specific entities, endpoints, and network path elements. VPNs are a + good example of a case where there is an explicit authentication and + negotiation with a network path element that is used to gain access + to specific resources. Authentication and trust must be considered + in both directions: how endpoints trust and authenticate signals from + network path elements and how network path elements trust and + authenticate signals from endpoints. + + The goal of improving privacy and trust on the Internet does not + necessarily need to remove the ability for network elements to + perform beneficial functions. We should instead improve the way that + these functions are achieved and design new ways to support explicit + collaboration where it is seen as beneficial. As such, our goals + should be to: + + * ensure that information is distributed intentionally, not + accidentally; + + * understand the privacy and other implications of any distributed + information; + + * ensure that the information distribution is limited to the + intended parties; and + + * gate the distribution of information on the participation of the + relevant parties. + + These goals for exposure and distribution apply equally to senders, + receivers, and path elements. + + Going forward, new standards work in the IETF needs to focus on + addressing this gap by providing better alternatives and mechanisms + for building functions that require some collaboration between + endpoints and path elements. + + We can establish some basic questions that any new network function + should consider: + + * Which entities must consent to the information exchange? + + * What is the minimum information each entity in this set needs? + + * What is the effect that new signals should have? + + * What is the minimum set of entities that need to be involved? + + * What are the right mechanism and needed level of trust to convey + this kind of information? + + If we look at ways network functions are achieved today, we find that + many, if not most of them, fall short of the standard set up by the + questions above. Too often, they send unnecessary information, fail + to limit the scope of distribution, or fail to provide any + negotiation or consent. + + Designing explicit signals between applications and network elements, + and ensuring that all information is appropriately protected, enables + information exchange in both directions that is important for + improving the quality of experience and network management. The + clean separation provided by explicit signals is also more conducive + to protocol evolvability. + + Beyond the recommendation in [RFC8558], the IAB has provided further + guidance on protocol design. Among other documents, [RFC5218] + provides general advice on incremental deployability based on an + analysis of successes and failures, and [RFC6709] discusses protocol + extensibility. The Internet Technology Adoption and Transition + (ITAT) workshop report [RFC7305] is also a recommended reading on + this same general topic. [RFC9049], an IRTF document, provides a + catalog of past issues to avoid and discusses incentives for adoption + of path signals such as the need for outperforming end-to-end + mechanisms or considering per-connection state. + + This document discusses different approaches for explicit + collaboration and provides guidance on architectural principles to + design new mechanisms. Section 2 discusses principles that good + design can follow. This section also provides examples and explores + the consequences of not following these principles in those examples. + Section 3 points to topics that need to be looked at more carefully + before any guidance can be given. + +2. Principles + + This section provides architecture-level principles for protocol + designers and recommends models to apply for network collaboration + and signaling. + + While [RFC8558] focuses specifically on communication to "on-path + elements", the principles described in this document apply + potentially to: + + * on-path signaling (in either direction) and + + * signaling with other elements in the network that are not directly + on-path but still influence end-to-end connections. + + An example of on-path signaling is communication between an endpoint + and a router on a network path. An example of signaling with another + network element is communication between an endpoint and a network- + assigned DNS server, firewall controller, or captive portal API + server. Note that these communications are conceptually independent + of the base flow, even if they share a packet; they are coming from + and going to other parties, rather than creating a multiparty + communication. + + Taken together, these principles focus on the inherent privacy and + security concerns of sharing information between endpoints and + network elements, emphasizing that careful scrutiny and a high bar of + consent and trust need to be applied. Given the known threat of + pervasive monitoring, the application of these principles is critical + to ensuring that the use of path signals does not create a + disproportionate opportunity for observers to extract new data from + flows. + +2.1. Intentional Distribution + + The following guideline is best expressed in [RFC8558]: + + | Fundamentally, this document recommends that implicit signals + | should be avoided and that an implicit signal should be replaced + | with an explicit signal only when the signal's originator intends + | that it be used by the network elements on the path. For many + | flows, this may result in the signal being absent but allows it to + | be present when needed. + + The goal is that any information should be provided knowingly, for a + specific purpose, sent in signals designed for that purpose, and that + any use of information should be done within that purpose. In + addition, an analysis of the security and privacy implications of the + specific purpose and associated information is needed. + + This guideline applies in the network element to application + direction as well: a network element should not unintentionally leak + information. While this document makes recommendations that are + applicable to many different situations, it is important to note that + the above call for careful analysis is key. Different types of + information, applications, and directions of communication influence + the analysis and can lead to very different conclusions about what + information can be shared and with whom. For instance, it is easy to + find examples of information that applications should not share with + network elements (e.g., content of communications) or that network + elements should not share with applications (e.g., detailed user + location in a wireless network). But, equally, information about + other things, such as the onset of congestion, should be possible to + share and can be beneficial information to all parties. + + Intentional distribution is a precondition for explicit collaboration + that enables each entity to have the highest possible level of + control about what information to share. + +2.2. Control of the Distribution of Information + + Explicit signals are not enough. The entities also need to agree to + exchange the information. Trust and mutual agreement between the + involved entities must determine the distribution of information in + order to give each entity adequate control over the collaboration or + information sharing. This can be achieved as discussed below. + + The sender needs to decide that it is willing to send information to + a specific entity or set of entities. Any passing of information or + request for an action needs to be explicit and use signaling + mechanisms that are designed for the purpose. Merely sending a + particular kind of packet to a destination should not be interpreted + as an implicit agreement. + + At the same time, the recipient of information or the target of a + request should have the option to agree or deny to receiving the + information. It should not be burdened with extra processing if it + does not have willingness or a need to do so. This happens naturally + in most protocol designs, but it has been a problem for some cases + where "slow path" packet processing is required or implied, and the + recipient or router is not willing to handle it. Performance impacts + like this are best avoided, however. + + In any case, all involved entities must be identified and potentially + authenticated if trust is required as a prerequisite to share certain + information. + + Many Internet communications are not performed on behalf of the + applications but are ultimately made on behalf of users. However, + not all information that may be shared directly relates to user + actions or other sensitive data. All shared information must be + evaluated carefully to identify potential privacy implications for + users. Information that directly relates to the user should not be + shared without the user's consent. It should be noted that the + interests of the user and other parties, such as the application + developer, may not always coincide; some applications may wish to + collect more information about the user than the user would like. As + discussed in [RFC8890], from an IETF point of view, the interests of + the user should be prioritized over those of the application + developer. The general issue of how to achieve a balance of control + between the actual user and an application representing a user's + interest is out of scope for this document. + +2.3. Protecting Information and Authentication + + Some simple forms of information often exist in cleartext form, e.g., + Explicit Congestion Notification (ECN) bits from routers are + generally not authenticated or integrity protected. This is possible + when the information exchanges do not carry any significantly + sensitive information from the parties. Often, these kinds of + interactions are also advisory in their nature (see Section 2.5). + + In other cases, it may be necessary to establish a secure signaling + channel for communication with a specific other party, e.g., between + a network element and an application. This channel may need to be + authenticated, integrity protected, and confidential. This is + necessary, for instance, if the particular information or request + needs to be shared in confidence only with a particular, trusted + network element or endpoint or if there is danger of an attack where + someone else may forge messages that could endanger the + communication. + + Authenticated integrity protections on signaled data can help ensure + that data received in a signal has not been modified by other + parties. Still, both network elements and endpoints need to be + careful in processing or responding to any signal. Whether through + bugs or attacks, the content of path signals can lead to unexpected + behaviors or security vulnerabilities if not properly handled. As a + result, the advice in Section 2.5 still applies even in situations + where there's a secure channel for sending information. + + However, it is important to note that authentication does not equal + trust. Whether a communication is with an application server or + network element that can be shown to be associated with a particular + domain name, it does not follow that information about the user can + be safely sent to it. + + In some cases, the ability of a party to show that it is on the path + can be beneficial. For instance, an ICMP error that refers to a + valid flow may be more trustworthy than any ICMP error claiming to + come from an address. + + Other cases may require more substantial assurances. For instance, a + specific trust arrangement may be established between a particular + network and application. Or technologies, such as confidential + computing, can be applied to provide an assurance that information + processed by a party is handled in an appropriate manner. + +2.4. Minimize Information + + Each party should provide only the information that is needed for the + other parties to perform the task for which collaboration is desired + and no more. This applies to information sent by an application + about itself, sent about users, or sent by the network. This also + applies to any information related to flow identification. + + An architecture can follow the guideline from [RFC8558] in using + explicit signals but still fail to differentiate properly between + information that should be kept private and information that should + be shared. [RFC6973] also outlines this principle of data + minimization as a mitigation technique to protect privacy and + provides further guidance. + + In looking at what information can or cannot be easily passed, we + need to consider both information from the network to the application + and from the application to the network. + + For the application-to-network direction, user-identifying + information can be problematic for privacy and tracking reasons. + Similarly, application identity can be problematic if it might form + the basis for prioritization or discrimination that the application + provider may not wish to happen. + + On the other hand, as noted above, information about general classes + of applications may be desirable to be given by application providers + if it enables prioritization that would improve service, e.g., + differentiation between interactive and non-interactive services. + + For the network-to-application direction, there is similarly + sensitive information, such as the precise location of the user. On + the other hand, various generic network conditions, predictive + bandwidth and latency capabilities, and so on might be attractive + information that applications can use to determine, for instance, + optimal strategies for changing codecs. However, information given + by the network about load conditions and so on should not form a + mechanism to provide a side channel into what other users are doing. + + While information needs to be specific and provided on a per-need + basis, it is often beneficial to provide declarative information + that, for instance, expresses application needs and then makes + specific requests for action. + +2.5. Limiting Impact of Information + + Information shared between a network element and an endpoint of a + connection needs to have a limited impact on the behavior of both + endpoints and network elements. Any action that an endpoint or + network element takes based on a path signal needs to be considered + appropriately based on the level of authentication and trust that has + been established, and it needs to be scoped to a specific network + path. + + For example, an ICMP signal from a network element to an endpoint can + be used to influence future behavior on that particular network path + (such as changing the effective packet size or closing a path- + specific connection) but should not be able to cause a multipath or + migration-capable transport connection to close. + + In many cases, path signals can be considered advisory information, + with the effect of optimizing or adjusting the behavior of + connections on a specific path. In the case of a firewall blocking + connectivity to a given host, endpoints should only interpret that as + the host being unavailable on that particular path; this is in + contrast to an end-to-end authenticated signal, such as a DNSSEC- + authenticated denial of existence [RFC7129]. + +2.6. Minimum Set of Entities + + It is recommended that a design identifies the minimum number of + entities needed to share a specific signal required for an identified + function. + + Often, this will be a very limited set, such as when an application + only needs to provide a signal to its peer at the other end of the + connection or a host needs to contact a specific VPN gateway. In + other cases, a broader set is needed, such as when explicit or + implicit signals from a potentially unknown set of multiple routers + along the path inform the endpoints about congestion. + + While it is tempting to consider removing these limitations in the + context of closed, private networks, each interaction is still best + considered separately, rather than simply allowing all information + exchanges within the closed network. Even in a closed network with + carefully managed elements, there may be compromised components, as + evidenced in the most extreme way by the Stuxnet worm that operated + in an air-gapped network. Most "closed" networks have at least some + needs and means to access the rest of the Internet and should not be + modeled as if they had an impenetrable security barrier. + +2.7. Carrying Information + + There is a distinction between what information is sent and how it is + sent. The information that is actually sent may be limited, while + the mechanisms for sending or requesting information can be capable + of sharing much more. + + There is a trade-off here between flexibility and ensuring that the + information is minimal in the future. The concern is that a fully + generic data-sharing approach between different layers and parties + could potentially be misused, e.g., by making the availability of + some information a requirement for passing through a network, such as + making it mandatory to identify specific applications or users. This + is undesirable. + + This document recommends that signaling mechanisms that send + information be built to specifically support sending the necessary, + minimal set of information (see Section 2.4) and no more. As + previously noted, flow-identifying information is a path signal in + itself, and as such, provisioning of flow identifiers also requires + protocol-specific analysis. + + Further, such mechanisms also need to have the ability to establish + an agreement (see Section 2.2) and sufficient trust to pass the + information (see Section 2.3). + +3. Further Work + + This is a developing field, and it is expected that our understanding + of it will continue to grow. One recent change is much higher use of + encryption at different protocol layers. This obviously impacts the + field greatly, by removing the ability to use most implicit signals. + However, it may also provide new tools for secure collaboration and + force a rethinking of how collaboration should be performed. + + While there are some examples of modern, well-designed collaboration + mechanisms, the list of examples is not long. Clearly, more work is + needed if we wish to realize the potential benefits of collaboration + in further cases. This requires a mindset change, a migration away + from using implicit signals. And of course we need to choose such + cases where the collaboration can be performed safely, where it is + not a privacy concern, and where the incentives of the relevant + parties are aligned. It should also be noted that many complex cases + would require significant developments in order to become feasible. + + Some of the most difficult areas are listed below. Research on these + topics would be welcome. Note that the topics include both those + dealing directly with on-path network element collaboration and some + adjacent issues that would influence such collaboration. + + * Some forms of collaboration may depend on business arrangements, + which may or may not be easy to put in place. For instance, some + quality-of-service mechanisms involve an expectation of paying for + a service. This is possible and has been successful within + individual domains, e.g., users can pay for higher data rates or + data caps in their ISP networks. However, it is a business-wise + proposition that is much harder for end-to-end connections across + multiple administrative domains [Claffy2015] [RFC9049]. + + * Secure communication with path elements is needed as discussed in + Section 2.3. Finding practical ways for this has been difficult, + both from the mechanics and scalability point of view, partially + because there is no easy way to find out which parties to trust or + what trust roots would be appropriate. Some application-network + element interaction designs have focused on information (such as + ECN bits) that is distributed openly within a path, but there are + limited examples of designs with secure information exchange with + specific network elements or endpoints. + + * The use of path signals to reduce the effects of denial-of-service + attacks, e.g., perhaps modern forms of "source quench" designs, + could be developed. The difficulty is finding a solution that + would be both effective against attacks and would not enable third + parties from slowing down or censoring someone else's + communication. + + * Work has begun on mechanisms that dissociate the information held + by servers from knowledge of the user's network location and + behavior. Among the solutions that exist for this but are not + widely deployed are [Oblivious] [PDoT] [DNS-CONFIDENTIAL] + [HTTP-OBLIVIOUS]. These solutions address specific parts of the + issue, and more work remains to find ways to limit the spread of + information about the user's actions. Host applications currently + share sensitive information about the user's action with a variety + of infrastructure and path elements, starting from basic data, + such as domain names, source and destination addresses, and + protocol header information. This can expand to detailed end-user + identity and other information learned by the servers. Work to + protect all of this information is needed. + + * Work is needed to explore how to increase the deployment of + mechanisms for sharing information from networks to applications. + There are some working examples of this, e.g., ECN. A few other + proposals have been made (see, e.g., + [MOBILE-THROUGHPUT-GUIDANCE]), but very few of those have seen + deployment. + + * Additional work on sharing information from applications to + networks would also be valuable. There are a few working examples + of this (see Section 1). Numerous proposals have been made in + this space, but most of them have not progressed through standards + or been deployed for a variety of reasons [RFC9049]. However, + several current or recent proposals exist, such as + [NETWORK-TOKENS]. + + * Data privacy regimes generally deal with multiple issues, not just + whether or not some information is shared with another party. For + instance, there may be rules regarding how long information can be + stored or what purpose that information may be used for. Similar + issues may also be applicable to the kind of information sharing + discussed in this document. + + * The present work has focused on the technical aspects of making + collaboration safe and mutually beneficial, but of course, + deployments need to take into account various regulatory and other + policy matters. These include privacy regulation, competitive + issues, network neutrality aspects, and so on. + +4. IANA Considerations + + This document has no IANA actions. + +5. Security Considerations + + This document has no security considerations. + +6. Informative References + + [Claffy2015] + Claffy, KC. and D. Clark, "Adding Enhanced Services to the + Internet: Lessons from History", TPRC 43: The 43rd + Research Conference on Communication, Information and + Internet Policy Paper, DOI 10.2139/ssrn.2587262, November + 2015, <https://papers.ssrn.com/sol3/ + papers.cfm?abstract_id=2587262>. + + [DNS-CONFIDENTIAL] + Arkko, J. and J. Novotny, "Privacy Improvements for DNS + Resolution with Confidential Computing", Work in Progress, + Internet-Draft, draft-arkko-dns-confidential-02, 2 July + 2021, <https://datatracker.ietf.org/doc/html/draft-arkko- + dns-confidential-02>. + + [EXPLICIT-COOP] + Trammell, B., Ed., "Architectural Considerations for + Transport Evolution with Explicit Path Cooperation", Work + in Progress, Internet-Draft, draft-trammell-stackevo- + explicit-coop-00, 23 September 2015, + <https://datatracker.ietf.org/doc/html/draft-trammell- + stackevo-explicit-coop-00>. + + [HTTP-OBLIVIOUS] + Thomson, M. and C. A. Wood, "Oblivious HTTP", Work in + Progress, Internet-Draft, draft-thomson-http-oblivious-02, + 24 August 2021, <https://datatracker.ietf.org/doc/html/ + draft-thomson-http-oblivious-02>. + + [MOBILE-THROUGHPUT-GUIDANCE] + Jain, A., Terzis, A., Flinck, H., Sprecher, N., + Arunachalam, S., Smith, K., Devarapalli, V., and R. Bar + Yanai, "Mobile Throughput Guidance Inband Signaling + Protocol", Work in Progress, Internet-Draft, draft-flinck- + mobile-throughput-guidance-04, 13 March 2017, + <https://datatracker.ietf.org/doc/html/draft-flinck- + mobile-throughput-guidance-04>. + + [NETWORK-TOKENS] + Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network + Tokens", Work in Progress, Internet-Draft, draft- + yiakoumis-network-tokens-02, 21 December 2020, + <https://datatracker.ietf.org/doc/html/draft-yiakoumis- + network-tokens-02>. + + [Oblivious] + Schmitt, P., Edmundson, A., Mankin, A., and N. Feamster, + "Oblivious DNS: Practical Privacy for DNS Queries", + Proceedings on Privacy Enhancing Technologies, Volume + 2019, Issue 2, pp. 228-244, DOI 10.2478/popets-2019-0028, + December 2018, <https://doi.org/10.2478/popets-2019-0028>. + + [PATH-SIGNALS-INFO] + Arkko, J., "Considerations on Information Passed between + Networks and Applications", Work in Progress, Internet- + Draft, draft-arkko-path-signals-information-00, 22 + February 2021, <https://datatracker.ietf.org/doc/html/ + draft-arkko-path-signals-information-00>. + + [PDoT] Nakatsuka, Y., Paverd, A., and G. Tsudik, "PDoT: Private + DNS-over-TLS with TEE Support", Digital Threats: Research + and Practice, Volume 2, Issue 1, Article No. 3, pp. 1-22, + DOI 10.1145/3431171, February 2021, + <https://doi.org/10.1145/3431171>. + + [PER-APP-NETWORKING] + Colitti, L. and T. Pauly, "Per-Application Networking + Considerations", Work in Progress, Internet-Draft, draft- + per-app-networking-considerations-00, 15 November 2020, + <https://datatracker.ietf.org/doc/html/draft-per-app- + networking-considerations-00>. + + [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful + Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, + <https://www.rfc-editor.org/info/rfc5218>. + + [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design + Considerations for Protocol Extensions", RFC 6709, + DOI 10.17487/RFC6709, September 2012, + <https://www.rfc-editor.org/info/rfc6709>. + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + <https://www.rfc-editor.org/info/rfc6973>. + + [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of + Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, + February 2014, <https://www.rfc-editor.org/info/rfc7129>. + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, <https://www.rfc-editor.org/info/rfc7258>. + + [RFC7305] Lear, E., Ed., "Report from the IAB Workshop on Internet + Technology Adoption and Transition (ITAT)", RFC 7305, + DOI 10.17487/RFC7305, July 2014, + <https://www.rfc-editor.org/info/rfc7305>. + + [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", + RFC 8558, DOI 10.17487/RFC8558, April 2019, + <https://www.rfc-editor.org/info/rfc8558>. + + [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, + DOI 10.17487/RFC8890, August 2020, + <https://www.rfc-editor.org/info/rfc8890>. + + [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based + Multiplexed and Secure Transport", RFC 9000, + DOI 10.17487/RFC9000, May 2021, + <https://www.rfc-editor.org/info/rfc9000>. + + [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to + Deployment (A Bestiary of Roads Not Taken)", RFC 9049, + DOI 10.17487/RFC9049, June 2021, + <https://www.rfc-editor.org/info/rfc9049>. + + [RFC9075] Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins, + "Report from the IAB COVID-19 Network Impacts Workshop + 2020", RFC 9075, DOI 10.17487/RFC9075, July 2021, + <https://www.rfc-editor.org/info/rfc9075>. + + [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", + STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, + <https://www.rfc-editor.org/info/rfc9293>. + + [RFC9312] Kühlewind, M. and B. Trammell, "Manageability of the QUIC + Transport Protocol", RFC 9312, DOI 10.17487/RFC9312, + September 2022, <https://www.rfc-editor.org/info/rfc9312>. + +IAB Members at the Time of Approval + + Internet Architecture Board members at the time this document was + approved for publication were: + + Jari Arkko + Deborah Brungard + Lars Eggert + Wes Hardaker + Cullen Jennings + Mallory Knodel + Mirja Kühlewind + Zhenbin Li + Tommy Pauly + David Schinazi + Russ White + Qin Wu + Jiankang Yao + +Acknowledgments + + The authors would like to thank everyone at the IETF, the IAB, and + our day jobs for interesting thoughts and proposals in this space. + Fragments of this document were also in [PER-APP-NETWORKING] and + [PATH-SIGNALS-INFO]. We would also like to acknowledge that similar + thoughts are presented in [EXPLICIT-COOP]. Finally, the authors + would like to thank Adrian Farrell, Toerless Eckert, Martin Thomson, + Mark Nottingham, Luis M. Contreras, Watson Ladd, Vittorio Bertola, + Andrew Campling, Eliot Lear, Spencer Dawkins, Christian Huitema, + David Schinazi, Cullen Jennings, Mallory Knodel, Zhenbin Li, Chris + Box, and Jeffrey Haas for useful feedback on this topic and document. + +Authors' Addresses + + Jari Arkko + Ericsson + Email: jari.arkko@ericsson.com + + + Ted Hardie + Cisco + Email: ted.ietf@gmail.com + + + Tommy Pauly + Apple + Email: tpauly@apple.com + + + Mirja Kühlewind + Ericsson + Email: mirja.kuehlewind@ericsson.com |