]> Cloudflare

lucaspardue.24.7@gmail.com

next generation unicorn sparkling distributed ledger Long-term interoperability of protocols is an important goal of the network standards process. Part of realizing long-term protocol deployment success is the ability to support change. Change can require adjustments such as extension to the protocol, modifying usage patterns within the current protocol constraints, or a replacement protocol. This document present considerations for protocol designers and implementers about applying protocol maintenance concepts About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Long-term interoperability of protocols is an important goal of the network standards process . Part of realizing long-term protocol deployment success is the ability to support change. Change can require adjustments such as extension to the protocol, modifying usage patterns within the current protocol constraints, or a replacement protocol. Greasing is one technique that supports the long term-viability of protocol extension points. It was originally designed for TLS as a later addition to help mitigate observed deployment issues. Subsequently, other protocols such as QUIC and HTTP/3 embedded greasing capability into the protocol, along with policies and IANA registries, in order to avoid ossification-related problems emerging in the first place. Greasing is suitable for many protocols but not all. discusses the applicability and limitations of greasing. presents considerations for applying grease that help to ensure it can most effectively reach its maintenance goals. Changing user needs may require that applications modify how they use a protocol without needing to change the protocol itself. For example, a deployment that supported a download-oriented population might wish to enable support for user uploads. This would change interactions and traffic flows but still behave completely within the design constraints of the network protocols. Implementations and deployments might discover ossification affects this form of change because expectations form around patterns of usage. presents considerations about how increasing the variability of protocols can mitigate some of these concerns. Replacing a protocol may be required where the changing needs or environment push protocol usage outside its original design parameters and extensions cannot elegantly fill the gap. Replacing a protocol may also be desirable as a form of baseline, a formal declaration of protocol and extension(s) combination that is common, that may simplify deployment by reducing failures related to combinatorial extensions problems. A replacement protocol version may or may not be compatible with other versions. A protocol may or may not have a mechanism for version selection or agility. presents considerations about designing for and/or implementing version negotiation and migration.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Considerations for Applying Greasing Greasing can take many forms, depending on the protocol and the nature of its extension points. Where a protocol uses registered values (i.e. codepoints) or numbers in a well defined range, a common approach (see , , or ), is to reserve a subset of the range for the purposes of greasing. Ths approach is detailed more thoroughly in . However, protocol designers or implementers may find it difficult to apply those suggestions in abstract. The likely success or efficacy of this method can be improved by the following suggestions. It is assumed that endpoint should implement robust and broad extension handling. When acting as a receiver or a parser, the implementation should not treat codepoints reserved for the purposes of greasing as individually special. In other words, rather than implementation looking specifically for reserved values, it is better to have a "catch all" mechanism that can handle receipt of unknown extensions gracefully or without error. In order to exercise receiver capability, it is advisable that senders send values from the ranges reserved for greasing. However, picking a deterministic value risks a value becoming ossified itself. One outcome of that is receivers being written to handle a single expected value rather than the generic handling described above. One way to help mitigate this is to reserve a sufficiently large range of values for greasing, and ensure that senders chose values from that range with diversity and non-determinism. The specific nature of size and distribution of the grease range needs to accommodate the protocol constraints. For instance, an 8-bit field can only represent a small range of values and it may be too costly to dedicate many of them solely for the purpose of greasing. However, protocols that use 32-bit or 64-bit fields are unlikely to have restrictions. It is beneficial to have a large set of reserved numbers for the purpose of greasing. However, protocol designers that wish to do so may encounter difficulties in expressing the large range in their protocol documents and/or in an IANA registry. One approach to this problem has been to define the set algorithmically in the protocol definition and request that IANA reserve only a single entry in the respective table that covers the entire range; see for example https://www.iana.org/assignments/http3-parameters/http3-parameters.xhtml#http3-parameters-frame-types. This range should be protected from registering from any other purpose. Deciding an appropriate label for this protected range is important. Labelling it simply "reserved" may be confused with other ranges that are reserved for private or experimental extensions. An implementer that conflates these two meanings may cause a new class of interoperability failure. Therefore a label such as "reserved for greasing" may help to avoid the confusion. If choosing to use an algorithm to define the set, it is encourage to use unique algorithms. This again improves the chances that receivers will build robust extension handling rather that a simple special-case ignore list. Protocols that do reserve ranges for greasing introduce a new consideration for real extensions. It is common to want to reserve a block of code points for iteration and experimentation. Depending how the algorithm spreads numbers through the full range, any single block of uninterrupted values may be too small to be usable. This could lead to unintentional use of a greased value. Since it is intended for receivers to ignore values reserved for greasing, designers and implementers need to remain aware that unintentional use of greased values by a sender for a real extension may cause a failure. Receiver implementations may unintentionally build a reliance on the occurrence of greasing in the temporal or spatial domain. Senders are advised to implementation non-determinism of when they use grease in addition to what values they send. and might not be suitable for all protocols but where it is already defined or can be added, it is important for endpoints to exercise it correctly in order to achieve the maintenance goals.

Considerations for Increasing Protocol Variability While greasing is one method to deal with falsifying active use of a protocols extensions points, it cannot address positive use. A protocol may define a wide-ranging extension capability but if senders do not use it, then interoperability problems may not arise, leading to ossification until a real use case emerges. Variation of protocol extension points with positive use in mind can help exercise protocols and ensure long-term maintenance and interoperability. This can be thought of, to some extent, as protocol fuzzing. It can be a difficult area to exercise because varying the protocol elements may change the actual outcome of interactions, leading to real errors. However, some elements can be safely changed and the following are some examples. QUIC packets contain frames. Receivers might build expectations on the longitudinal aspects of packets or frames - size, ordering, frequency, etc. A sender can quite often manipulate these parameters and stay compliant to the requirements of the QUIC protocol. For example, QUIC streams are an ordered reliable byte stream that is serialized as a sequence of STREAM frames with a length and offset. Receivers are expected to reassemble frames into an ordered reliable byte stream such that an application reading from a stream can be abstracted from matters of the transport later. A sender that purposefully reorders STREAM frames will help exercise the reassembly features of the receiver. It is not expected that this would cause a functional failure in the application layer. However, it may introduce delays or stream head-of-line blocking that affect the performance aspects of a transmission, which may not be acceptable for a given use case.

Considerations for Protocol Versions There are intrinsic and well-documented issues related to testing version negotiation of protocols; see and Sections and of . This section will be expanded with advice for protocol designers and implementers about how to approach these problems.

Security Considerations The considerations in , , , and all apply to the topics discussed in this document. The use of protocol features, extensions, and versions can already allow fingerprinting. Any techniques that change parameters in any way, including but not limited to those discussed in this document, can affect fingerprinting. A deeper analysis of this topic has been deemed out of scope.

IANA Considerations This document has no IANA actions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. The main goal of the networking standards process is to enable the long-term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem. The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls. The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community. This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised to ensure peers correctly handle unknown values. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. The ability to change protocols depends on exercising the extension and version-negotiation mechanisms that support change. This document explores how regular use of new protocol features can ensure that it remains possible to deploy changes to a protocol. Examples are given where lack of use caused changes to be more difficult or costly. This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this. This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.

Acknowledgments This work is a summary of the topics discussed during EDM meetings. The contributors at those meetings are thanked.