Internet-Draft GREASE for HTTP/2 June 2020
Bishop Expires 26 December 2020 [Page]
Intended Status:
Standards Track
M. Bishop



Reserves several values in the HTTP/2 registries to exercise the requirement that clients and servers ignore unknown values.

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 26 December 2020.

Table of Contents

1. Introduction

[UseIt] observes that extension and negotiation mechanisms which aren't exercised regularly can be found not to work when they are later employed by an extension to the protocol. [GREASE] is one mitigation which originated in TLS, registering multiple values in various TLS registries which can be sent prospectively by clients.

The common requirement of the different spaces described by these documents is the requirement that recipients ignore unrecognized values. By reserving a scattered set of codepoints to have no defined meaning, clients and servers can inject values from these ranges into connections on a regular basis and exercise this requirement.

HTTP/2 [HTTP2] frame types and settings employ a similar mechanism of ignoring unknown values. This makes HTTP/2 a good candidate to employ grease on connections. The need for such a technique was demonstrated recently by an HTTP/2 implementation which closed the connection upon receipt of an unknown setting.

2. Using GREASE in HTTP/2

2.1. GREASE for Frame Types

Frame types of the format 0xb + (0x1f * N) are reserved for use as grease. These frames have no semantic meaning, and SHOULD be send instead of using padding on DATA or HEADERS frames where possible. They MAY also be sent on connections where there is no application data currently being transferred. Endpoints MUST NOT consider these frames to have any meaning upon receipt.

The flags, the payload, and the length of the frames SHOULD be selected randomly, subject to implementation-defined limits on the length.

[HTTP2] is ambiguous about whether unknown frame types are permitted on streams in the "idle", "reserved", "closed", or "half-closed (local)" states. As a result, some implementations could legitimately consider this to be an error. Therefore, these frames SHOULD NOT be sent on streams in those states.


Settings identifiers of the format 0x?a?a are reserved for use as grease. Such settings have no defined meaning. Endpoints SHOULD include at least one such setting in their initial SETTINGS frame, and MAY send new SETTINGS frames during the connection containing additional grease values. Endpoints MUST NOT consider such settings to have any meaning upon receipt.

Because the setting has no defined meaning, the value of the setting SHOULD be selected randomly.

3. Security Considerations

The ability to design, implement, and deploy new protocol mechanisms can be critical to security.

4. IANA Considerations

4.1. Frame Types

This document reserves a range of entries in the "HTTP/2 Frame Type" registry defined in [HTTP2]. Each code of the format 0xb + (0x1f * N) for values of N in the range (0..7) (that is, 0xb, 0x2a, etc., through 0xe4) MUST NOT be assigned by IANA for any purpose.

4.2. Settings

This document reserves a range of entries in the "HTTP/2 Settings" registry defined in [HTTP2]. Each code of the format 0x?a?a where each ? is any octet (that is, 0x0a0a, 0x0a1a, etc. through 0xfafa) MUST NOT be assigned by IANA for any purpose.

5. References

5.1. Normative References

Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, , <>.

5.2. Informative References

Benjamin, D., "Applying GREASE to TLS Extensibility", Work in Progress, Internet-Draft, draft-ietf-tls-grease-04, , <>.
Thomson, M., "Long-term Viability of Protocol Extension Mechanisms", Work in Progress, Internet-Draft, draft-thomson-use-it-or-lose-it-04, , <>.

Appendix A. Acknowledgements

This draft arose from a discussion in the QUIC WG with Lucas Pardue, Ryan Hamilton, and Martin Thomson.

Author's Address

Mike Bishop