HTTP/2 Fixed-Size Frames

draft-nottingham-httpbis-h2-fixed-frame-00

Abstract

This specification defines a HTTP/2 setting, SETTINGS_FIXED_FRAME_SIZE, that asks the peer to use padding and chunking to achieve a desired, static frame size for HEADERS and DATA frames.

Note to Readers

The issues list for this draft can be found at https://github.com/mnot/I-D/labels/httpbis-h2-fixed-frame.

The most recent (often, unpublished) draft is at https://mnot.github.io/I-D/httpbis-h2-fixed-frame/.

Recent changes are listed at https://github.com/mnot/I-D/commits/gh-pages/httpbis-h2-fixed-frame.

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 http://datatracker.ietf.org/drafts/current/.

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 July 24, 2016.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

Traffic analysis depends, in part, on using the difference between sizes of messages to characterise a particular flow.

HTTP/2 [RFC7540] allows its two major data-bearing frame types (HEADERS and DATA) to be split into multiple frames as well as padded with extra data. However, implementations to date do not use these capabilities in any regular way to combat traffic analysis.

This specification defines a new HTTP/2 setting that informs a peer when it is desirable to use frame splitting and padding to achieve this effect.

1.1 Notational Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119].

1.2 SETTINGS_FIXED_FRAME_SIZE (0xn)

This setting requests that the peer assure that HTTP/2 frame payloads (as per [RFC7540], Section 4.1) it sends are split into multiple frames and/or padded to the number of bytes indicated in its value, when the frame type allows.

A value of 0 indicates no fixed frame size is requested.

For example, if the setting value is 8192, a 10000 byte DATA frame payload would be sent as two 8192 byte frames, with 1808 bytes of padding in total (occurring in either frame, or both).

HEADERS frames would likewise be split into one HEADERS frame and an arbitrary number of CONTINUATION frames, with padding as necessary.

2. IANA Considerations

This specification registers an entry in the HTTP/2 Settings registry.

Name: SETTINGS_FIXED_FRAME_SIZE
Code: TBD
Initial Value: 0
Specification: [this document]

3. Security Considerations

Uniform frame sizes are not sufficient to combat traffic analysis on their own, since flows still carry metadata, timing, and other information.

4. Normative References

[RFC2119]: Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC7540]: Belshe, M., Peon, R., and M. Thomson, Ed., “Hypertext Transfer Protocol Version 2 (HTTP/2)”, RFC 7540, DOI 10.17487/RFC7540, May 2015, <http://www.rfc-editor.org/info/rfc7540>.

A. Acknowledgements

Well, Chaum for one.

Author's Address

Mark Nottingham
EMail: mnot@mnot.net
URI: https://www.mnot.net/