A Sequence Number Extension for HTTP Datagrams

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 https://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 27 April 2023.¶

Copyright Notice

Copyright (c) 2022 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This document defines a sequence number extension to HTTP datagrams [RFC9297]. Sequence numbers at the HTTP datagram layer allows a receiving endpoint to implement arbitrary reordering logic, which can be useful when proxied datagrams are sent over multiple paths simultaneously, e.g. using the multipath QUIC extension [MPQUIC]. The extension applies to HTTP datagrams when they are used with the extended CONNECT method and the protocols are either connect-ip [CONNECT-IP] or connect-udp [RFC9298].¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Sequence Number Datagram Extension

The Sequence Number datagram extension prepends sequence numbers to HTTP datagrams. Datagram sequence numbers are unsigned integers initiated to 0 and are incremented by 1 for every transmitted HTTP datagram, except for when the integer overflows and is reset to 0. The extension can be used with the HTTP CONNECT method when the :protocol pseudo header is equal to "connect-udp" or "connect-ip". Use of the sequence number extension is determined per request, and the scope of a datagram sequence is limited to a single request stream. Datagrams with different quarter stream IDs can not share a common sequence number space.¶

REGISTER_SEQUENCE_CONTEXT Capsule {
  Type (i) = REGISTER_SEQUENCE_CONTEXT,
  Length (i),
  Context ID (i),
  Payload Context ID (i),
  Representation (8)
}

ADD_SEQUENCE_CONTEXT Capsule {
  Type (i) = ADD_SEQUENCE_CONTEXT,
  Length (i),
  Sequence Context ID (i),
  Context ID (i),
  Payload Context ID (i)
}

Sequence Number Datagram {
  Context ID (i),
  Sequence Number (8..64),
  Payload (..)
}

4. Security Considerations

Although the usage of the sequence number is not defined by this specification, there is an underlying assumption that the sequence numbers are assigned in transmission order of HTTP datagram sent in the context of this HTTP request. Any attacker that can break that assumption will thus impact any node that uses the sequence number. By altering the sequence number in HTTP datagrams, an attacker can impact how much data a receiver is buffering for the following purposes:¶

• Resource exhaustion attack by maximizing the amount of data buffered in each HTTP request context¶
• Introducing reordering, jitter and additional delay in the path properties for these datagram¶
• Cause the sequence number using node to drop some HTTP Datagrams by causing them to be so far reordered that some policy in the receiving node drops the datagram.¶

A malicious endpoint is more likely to mount a resource exhaustion attack, while HTTP intermediares could be used by an third party attacker to impact the HTTP datagram flow between a source and a destination.¶

A user that buffers datagrams based on sequence numbers should ensure that they have protection against resource exhaustion attacks by limiting the size of their buffers.¶

5. IANA Considerations

Acknowledgments

TODO acknowledge.¶

Authors' Addresses