draft-ietf-httpbis-connect-tcp-13.txt   draft-ietf-httpbis-connect-tcp-latest.txt 
httpbis Working Group B. Schwartz httpbis Working Group B. Schwartz
Internet-Draft Meta Platforms, Inc. Internet-Draft Meta Platforms, Inc.
Intended status: Standards Track August 17, 2026 Intended status: Standards Track November 03, 2026
Expires: February 18, 2027 Expires: May 7, 2027
Template-Driven HTTP CONNECT Proxying for TCP Template-Driven HTTP CONNECT Proxying for TCP
draft-ietf-httpbis-connect-tcp-13 draft-ietf-httpbis-connect-tcp-latest
Abstract Abstract
TCP proxying using HTTP CONNECT has long been part of the core HTTP TCP tunneling using HTTP CONNECT has long been part of the core HTTP
specification. However, this proxying functionality has several specification. However, this tunneling functionality has several
important deficiencies in modern HTTP environments. This important deficiencies due to the lack of a well-defined HTTP origin
specification defines an alternative HTTP proxy service configuration or path. This specification remedies those deficiencies by defining
for TCP connections. This configuration is described by a URI CONNECT-TCP, an alternative protocol for tunneling TCP in HTTP. A
Template, similar to the CONNECT-UDP and CONNECT-IP protocols. proxy service for this protocol is described by a URI Template,
similar to the CONNECT-UDP and CONNECT-IP protocols.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2027. This Internet-Draft will expire on May 7, 2027.
Copyright Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Payload Transport . . . . . . . . . . . . . . . . . . . . 4
3.2. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 6 3.2. In HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Use of Other Relevant Headers . . . . . . . . . . . . . . 7 3.3. In HTTP/2 and HTTP/3 . . . . . . . . . . . . . . . . . . 7
3.3.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 7 3.4. Use of Other Relevant Headers . . . . . . . . . . . . . . 8
3.3.2. Authentication Headers . . . . . . . . . . . . . . . 7 3.4.1. Origin-scoped Headers . . . . . . . . . . . . . . . . 8
3.4. Closing Connections . . . . . . . . . . . . . . . . . . . 8 3.4.2. Authentication Headers . . . . . . . . . . . . . . . 8
3.4.1. Handling Invalid Data . . . . . . . . . . . . . . . . 10 3.4.3. Caching Headers . . . . . . . . . . . . . . . . . . . 9
4. Additional Connection Setup Behaviors . . . . . . . . . . . . 10 3.5. Closing Connections . . . . . . . . . . . . . . . . . . . 9
4.1. Latency optimizations . . . . . . . . . . . . . . . . . . 10 3.5.1. Handling Invalid Data . . . . . . . . . . . . . . . . 11
4.2. Conveying metadata . . . . . . . . . . . . . . . . . . . 11 4. Additional Connection Setup Behaviors . . . . . . . . . . . . 11
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Latency Optimizations . . . . . . . . . . . . . . . . . . 12
5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Indicating Failure . . . . . . . . . . . . . . . . . . . 12
5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Conveying Metadata . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 13 5.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Operational Considerations . . . . . . . . . . . . . . . . . 14 5.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 15 5.3. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Gateway Compatibility . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7.3. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Resource Exhaustion attacks . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.2. Client Authentication . . . . . . . . . . . . . . . . . . 17
8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 16 6.3. TLS Early Data . . . . . . . . . . . . . . . . . . . . . 17
8.1.1. Interop testing . . . . . . . . . . . . . . . . . . . 17 7. Operational Considerations . . . . . . . . . . . . . . . . . 17
8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 17 7.1. Avoiding HTTP/1.1 . . . . . . . . . . . . . . . . . . . . 17
8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 17 7.2. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. Scope of Packet-Level Metadata . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 7.4. IP address sharing . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 19 7.5. Diagnostics and Monitoring . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. New Upgrade Token . . . . . . . . . . . . . . . . . . . . 20
8.1.1. Interop testing . . . . . . . . . . . . . . . . . . . 20
8.2. New MASQUE Default Template . . . . . . . . . . . . . . . 20
8.3. New Capsule Type . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
1.1. History 1.1. History
HTTP has used the CONNECT method for proxying TCP connections since HTTP has used the CONNECT method for tunneling TCP connections since
HTTP/1.1. When using CONNECT, the request target specifies a host HTTP/1.1. When using CONNECT, the request target specifies a host
and port number, and the proxy forwards TCP payloads between the and port number, and the proxy forwards TCP payloads between the
client and this destination ([HTTP], Section 9.3.6). To date, this client and the target destination ([HTTP], Section 9.3.6). Prior to
is the only mechanism defined for proxying TCP over HTTP. In this this specification, this was the only mechanism defined for proxying
specification, this is referred to as a "classic HTTP CONNECT proxy". TCP over HTTP. In this specification, this arrangement is referred
to as a "classic HTTP CONNECT proxy".
HTTP/3 uses a UDP transport, so it cannot be forwarded using the pre- HTTP/3 [RFC9114] uses a UDP transport, so it cannot be forwarded
existing CONNECT mechanism. To enable forward proxying of HTTP/3, using the pre-existing CONNECT mechanism. To enable forward proxying
the MASQUE effort has defined proxy mechanisms that are capable of of HTTP/3, the MASQUE effort has defined proxy mechanisms that are
proxying UDP datagrams [CONNECT-UDP], and more generally IP datagrams capable of tunneling UDP datagrams [CONNECT-UDP], and more generally
[CONNECT-IP]. The destination host and port number (if applicable) IP datagrams [CONNECT-IP]. The destination host and port number (if
are encoded into the HTTP resource path, and end-to-end datagrams are applicable) are encoded into the HTTP resource path, and end-to-end
wrapped into HTTP Datagrams [CAPSULE] on the client-proxy path. datagrams are wrapped into HTTP Datagrams [CAPSULE] on the client-
proxy path.
1.2. Problems 1.2. Problems
HTTP clients can be configured to use proxies by selecting a proxy HTTP clients can be configured to use proxies by selecting a proxy
hostname, a port, and whether to use a security protocol. However, hostname, a port number, and whether to use a security protocol.
Classic HTTP CONNECT requests using the proxy do not carry this However, classic HTTP CONNECT requests using the proxy do not carry
configuration information. Instead, they only indicate the hostname this configuration information. Instead, they only indicate the
and port of the target. This prevents any HTTP server from hosting hostname and port of the target. This prevents any HTTP server from
multiple distinct proxy services, as the server cannot distinguish hosting multiple distinct proxy services, as the server cannot
them by path (as with distinct resources) or by origin (as in distinguish them by path (as with distinct resources) or by origin
"virtual hosting"). (as in "virtual hosting").
The absence of an explicit origin for the proxy also rules out the The absence of an explicit origin for the proxy also rules out the
usual defenses against server port misdirection attacks (see usual defenses against server port misdirection attacks (see
Section 7.4 of [HTTP]) and creates ambiguity about the use of origin- Section 7.4 of [HTTP]) and creates ambiguity about the use of origin-
scoped response header fields (e.g., "Alt-Svc" [ALT-SVC], "Strict- scoped response header fields (e.g., Alt-Svc [ALT-SVC] or Strict-
Transport-Security" [HSTS]). Transport-Security [HSTS]).
Classic HTTP CONNECT requests are not extensible to carry in-stream Classic HTTP CONNECT requests are not extensible to carry in-stream
metadata. For example, the WRAP_UP capsule metadata. For example, the WRAP_UP capsule
[I-D.ietf-httpbis-wrap-up] cannot be used with Classic HTTP CONNECT. [I-D.ietf-httpbis-wrap-up] cannot be used with classic HTTP CONNECT.
1.3. Overview 1.3. Overview
This specification describes an alternative mechanism for proxying This specification describes an alternative mechanism for tunneling
TCP in HTTP. Like [CONNECT-UDP] and [CONNECT-IP], the proxy service TCP in HTTP. Like [CONNECT-UDP] and [CONNECT-IP], the proxy service
is identified by a URI Template. Proxy interactions reuse standard is identified by a URI Template. Proxy interactions reuse standard
HTTP components and semantics, avoiding changes to the core HTTP HTTP components and semantics, avoiding changes to the core HTTP
protocol. protocol.
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
In this document, the term "proxy" refers to the HTTP server that
acts upon a client's TCP tunneling request. If there are HTTP
intermediaries (as defined in Section 3.7 of [HTTP]) between the
client and the proxy, those are referred to as "intermediaries" or
"gateways" in this document.
The term "endpoint" describes an implementation of this specification
in either client or proxy role.
The protocol defined in this specification is termed "CONNECT-TCP".
The term "CONNECT-TCP proxy" refers to a proxy that is identified by
a URI Template for CONNECT-TCP.
3. Specification 3. Specification
A template-driven TCP transport proxy for HTTP is identified by a URI A template-driven TCP transport proxy for HTTP is identified by a URI
Template [RFC6570] containing variables named "target_host" and Template [RFC6570] containing variables named "target_host" and
"target_port". This URI Template and its variable values MUST meet "target_port". This URI Template and its variable values MUST meet
all the same requirements as for UDP proxying ([CONNECT-UDP], all the same requirements as for UDP proxying (Sections 2 and 3 of
Section 2), and are subject to the same validation rules. The client [CONNECT-UDP]), and are subject to the same validation rules.
MUST substitute the destination host and port number into this Clients MUST substitute the destination host and port number into
template to produce the request URI. The derived URI serves as the this template to produce a request URI. The derived URI serves as
destination of a Capsule Protocol connection using the Upgrade Token the destination of a Capsule Protocol connection using the Upgrade
"connect-tcp" (see registration in Section 8.1). Token "connect-tcp" (see registration in Section 8.1).
When using "connect-tcp", TCP payload data is sent in the payload of If the request is well-formed and permissible, the proxy MUST attempt
to establish the TCP connection before sending a final success or
failure response.
3.1. Payload Transport
When using CONNECT-TCP, TCP payload data is sent in the payload of
new Capsule Types named DATA and FINAL_DATA (see Figure 1 and new Capsule Types named DATA and FINAL_DATA (see Figure 1 and
registrations in Section 8.3). The ordered concatenation of these registrations in Section 8.3). The ordered concatenation of these
capsule payloads, which MAY be empty, represents the TCP payload capsule payloads, which MAY be empty, represents the TCP payload
data. A FINAL_DATA capsule additionally indicates that the sender data. A FINAL_DATA capsule additionally indicates that the sender
has closed this stream, semantically equivalent to TCP FIN. After has closed this stream, semantically equivalent to TCP FIN. After
sending a FINAL_DATA capsule, an endpoint MUST NOT send any more DATA sending a FINAL_DATA capsule, an endpoint MUST NOT send any more DATA
or FINAL_DATA capsules on this data stream. (See Section 3.4 for or FINAL_DATA capsules on this data stream. See Section 3.5 for
related requirements.) related requirements.
DATA Capsule { DATA Capsule {
Type (i) = 0x08, Type (i) = 0x08,
Length (i), # MAY be zero Length (i), # may be zero
TCP Payload (..), TCP Payload (..),
} }
FINAL_DATA Capsule { FINAL_DATA Capsule {
Type (i) = 0x09, Type (i) = 0x09,
Length (i), # MAY be zero Length (i), # may be zero
TCP Payload (..), TCP Payload (..),
} }
Figure 1: DATA and FINAL_DATA Capsule Formats Figure 1: DATA and FINAL_DATA Capsule Formats, using notation from
Section 1.3 of [QUIC]
The boundaries between DATA and FINAL_DATA capsules are not The boundaries between DATA and FINAL_DATA capsules are not
significant, and are not expected to match TCP segments, TLS records, significant, and are not expected to match TCP segments, TLS records,
HTTP DATA frames, QUIC STREAM frames, etc. Recipients SHOULD begin HTTP DATA frames, QUIC STREAM frames, etc. Recipients SHOULD begin
forwarding payload from a DATA or FINAL_DATA capsule without waiting forwarding payload from a DATA or FINAL_DATA capsule without waiting
to receive the entire capsule. to receive the entire capsule, especially if the capsule is large.
An intermediary MAY merge and split successive DATA and FINAL_DATA An intermediary MAY merge and split successive DATA and FINAL_DATA
capsules, subject to the following requirements: capsules, subject to the following requirements:
o There are no intervening capsules of other types. o There are no intervening capsules of other types.
o The order of payload content is preserved. o The order of payload content is preserved.
o The final emitted capsule uses the same capsule type (DATA or o The final emitted capsule uses the same capsule type (DATA or
FINAL_DATA) as the final input capsule, and all others use the FINAL_DATA) as the final input capsule, and all others use the
DATA capsule type. DATA capsule type.
For example, an intermediary holding two successive DATA capsules in For example, an intermediary holding two successive DATA capsules in
its transmission buffer could merge them, saving at least 2 bytes of its transmission buffer could merge them, saving at least 2 bytes of
encapsulation overhead when they are forwarded. encapsulation overhead when they are forwarded.
This protocol can be extended by defining additional relevant Capsule This protocol supports backward-compatible extensions via additional
Types. According to the Capsule Protocol ([CAPSULE], Section 3.2), Capsule Types, as described in Section 3.2 of [CAPSULE].
new Capsule Types should be ignored by pre-existing proxies and
intermediaries. If a new Capsule Type cannot safely be ignored, the
endpoints can confirm support using a new HTTP header field.
3.1. In HTTP/1.1 3.2. In HTTP/1.1
In HTTP/1.1 [RFC9112], the client uses the proxy by issuing a request In HTTP/1.1 [RFC9112], the client uses the proxy by issuing a request
as follows: as follows:
o The method SHALL be "GET". o The method SHALL be GET.
o The request's target SHALL correspond to the URI derived from o The request's target SHALL correspond to the URI derived from
expansion of the proxy's URI Template. expansion of the proxy's URI Template.
o The request SHALL include a single "Host" header field containing o The request SHALL include a single Host header field whose value
the origin of the proxy. identifies the proxy.
o The request SHALL include a "Connection" header field with the o The request SHALL include a Connection header field with the value
value "Upgrade". (Note that this requirement is case-insensitive "Upgrade". (Note that this requirement is case-insensitive as per
as per Section 7.6.1 of [HTTP].) Section 7.6.1 of [HTTP].)
o The request SHALL include an "Upgrade" header field with the value o The request SHALL include an Upgrade header field with the value
"connect-tcp". "connect-tcp".
o The request SHOULD include a "Capsule-Protocol: ?1" header (as o The request SHOULD include a "Capsule-Protocol: ?1" header field
recommended in [CAPSULE], Section 3.4). (as recommended in [CAPSULE], Section 3.4).
If the request is well-formed and permissible, the proxy MUST attempt If the TCP connection is successful, the response SHALL be as
to establish the TCP connection before sending any response status follows:
code other than "100 (Continue)" (see Section 4.2). If the TCP
connection is successful, the response SHALL be as follows:
o The HTTP status code SHALL be "101 (Switching Protocols)". o The HTTP status code SHALL be 101 (Switching Protocols).
o The response SHALL include a "Connection" header field with the o The response SHALL include a Connection header field with the
value "Upgrade". value "Upgrade".
o The response SHALL include a single "Upgrade" header field with o The response SHALL include a single Upgrade header field with the
the value "connect-tcp". value "connect-tcp".
o The response SHOULD include a "Capsule-Protocol: ?1" header (as
above).
If the request is malformed or impermissible, the proxy MUST return a o The response SHOULD include a "Capsule-Protocol: ?1" header field
4XX error code. If a TCP connection was not established, the proxy (as above).
MUST NOT switch protocols to "connect-tcp", and the client MAY reuse
this connection for additional HTTP requests.
Client Proxy If a TCP connection was not established, the proxy MUST NOT switch
protocols to CONNECT-TCP, and the client MAY reuse this connection
for additional HTTP requests.
GET /proxy?target_host=192.0.2.1&target_port=443 HTTP/1.1 GET /proxy?target_host=192.0.2.1&target_port=443 HTTP/1.1
Host: example.com Host: example.com
Connection: Upgrade Connection: Upgrade
Upgrade: connect-tcp Upgrade: connect-tcp
Capsule-Protocol: ?1 Capsule-Protocol: ?1
** Proxy establishes a TCP connection to 192.0.2.1:443 ** CONNECT-TCP in HTTP/1.1: Example request for a connection to
192.0.2.1:443 via https://example.com/proxy{?target_host,target_port}
HTTP/1.1 101 Switching Protocols HTTP/1.1 100 Continue
Connection: Upgrade
Upgrade: connect-tcp
Capsule-Protocol: ?1
Templated TCP proxy example in HTTP/1.1 CONNECT-TCP in HTTP/1.1: Initial response
3.2. In HTTP/2 and HTTP/3 HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-tcp
Capsule-Protocol: ?1
Proxy-Status: example.com
CONNECT-TCP in HTTP/1.1: Final success response
3.3. In HTTP/2 and HTTP/3
In HTTP/2 and HTTP/3, the proxy MUST include In HTTP/2 and HTTP/3, the proxy MUST include
SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame [RFC8441] SETTINGS_ENABLE_CONNECT_PROTOCOL in its SETTINGS frame [RFC8441]
[RFC9220]. The client uses the proxy by issuing an "extended [RFC9220]. The client uses the proxy by issuing an "extended
CONNECT" request as follows: CONNECT" request as follows:
o The :method pseudo-header field SHALL be "CONNECT". o The :method pseudo-header field SHALL be CONNECT.
o The :protocol pseudo-header field SHALL be "connect-tcp". o The :protocol pseudo-header field SHALL be "connect-tcp".
o The :authority pseudo-header field SHALL contain the authority of o The :authority pseudo-header field SHALL contain the authority of
the proxy. the proxy.
o The :path and :scheme pseudo-header fields SHALL contain the path o The :path and :scheme pseudo-header fields SHALL contain the path
and scheme of the request URI derived from the proxy's URI and scheme of the request URI derived from the proxy's URI
Template. Template.
A templated TCP proxying request that does not conform to all of A CONNECT-TCP request that does not conform to all of these
these requirements represents a client error (see [HTTP], requirements represents a client error (see [HTTP], Section 15.5) and
Section 15.5) and may be malformed (see Section 8.1.1 of [RFC9113] may be malformed (see Section 8.1.1 of [RFC9113] and Section 4.1.2 of
and Section 4.1.2 of [RFC9114]). [RFC9114]).
Additionally the "capsule-protocol" header field SHOULD be present Additionally, the Capsule-Protocol header field SHOULD be present
with a value of "?1" (as recommended in [CAPSULE], Section 3.4). with a value of "?1" (as recommended in [CAPSULE], Section 3.4).
HEADERS HEADERS
:method = CONNECT :method = CONNECT
:scheme = https :scheme = https
:authority = request-proxy.example :authority = example.com
:path = /proxy?target_host=2001%3Adb8%3A%3A1&target_port=443 :path = /proxy?target_host=2001%3Adb8%3A%3A1&target_port=443
:protocol = connect-tcp :protocol = connect-tcp
capsule-protocol = ?1 capsule-protocol = ?1
... ...
Templated TCP proxy example in HTTP/2 CONNECT-TCP in HTTP/2: Example request to [2001:db8::1]:443
3.3. Use of Other Relevant Headers 3.4. Use of Other Relevant Headers
3.3.1. Origin-scoped Headers 3.4.1. Origin-scoped Headers
Ordinary HTTP headers apply only to the single resource identified in Ordinary HTTP headers apply only to the single resource identified in
the request or response. An origin-scoped HTTP header is a special the request or response. An origin-scoped HTTP header is a special
response header that is intended to change the client's behavior for response header that is intended to change the client's behavior for
subsequent requests to any resource on this origin. subsequent requests to any resource on this origin.
Unlike classic HTTP CONNECT proxies, a templated TCP proxy has an Unlike classic HTTP CONNECT proxies, a CONNECT-TCP proxy has an
unambiguous origin of its own. Origin-scoped headers apply to this unambiguous origin of its own. Origin-scoped headers apply to this
origin when they are associated with a templated TCP proxy response. origin when they are associated with a CONNECT-TCP response. Here
Here are some origin-scoped headers that could potentially be sent by are some origin-scoped headers that could potentially be sent by a
a templated TCP proxy: CONNECT-TCP proxy:
o "Alt-Svc" [ALT-SVC] o Alt-Svc [ALT-SVC]
o "Strict-Transport-Security" [HSTS] o Strict-Transport-Security [HSTS]
o "Accept-CH" [RFC8942] o Accept-CH [RFC8942]
o "Set-Cookie" [RFC6265], which has configurable scope. o Set-Cookie [RFC6265], which has configurable scope.
o "Clear-Site-Data" [CLEAR-SITE-DATA] o Clear-Site-Data [CLEAR-SITE-DATA]
3.3.2. Authentication Headers 3.4.2. Authentication Headers
Authentication to a templated TCP proxy normally uses ordinary HTTP Authentication to a CONNECT-TCP proxy normally uses ordinary HTTP
authentication via the "401 (Unauthorized)" response code, the "WWW- authentication via the 401 (Unauthorized) response code, the WWW-
Authenticate" response header field, and the "Authorization" request Authenticate response header field, and the Authorization request
header field ([HTTP], Section 11.6). A templated TCP proxy does not header field ([HTTP], Section 11.6). A CONNECT-TCP proxy does not
use the "407 (Proxy Authentication Required)" response code and use the 407 (Proxy Authentication Required) status code and related
related header fields ([HTTP], Section 11.7) because they do not header fields ([HTTP], Section 11.7) because they do not traverse
traverse HTTP gateways (see Section 7.2). HTTP gateways (see Section 5.3).
Clients SHOULD assume that all proxy resources generated by a single Clients SHOULD assume that all proxy resources generated by a single
template share a protection space (i.e., a realm) ([HTTP], template share a protection space (i.e., a realm) ([HTTP],
Section 11.5). For many authentication schemes, this will allow the Section 11.5). For many authentication schemes, this will allow the
client to avoid waiting for a "401 (Unauthorized)" response before client to avoid waiting for a 401 (Unauthorized) response before each
each new connection through the proxy. new connection through the proxy.
TLS Client Certificate authentication can also be used (see TLS Client Certificate authentication can also be used (see
Section 7.2). Section 5.3).
3.4. Closing Connections 3.4.3. Caching Headers
In HTTP/2 and HTTP/3, this specification uses the CONNECT method,
which is not subject to caching ([HTTP], Section 9.3.6). However, in
HTTP/1.1, the method is GET, which in other usages can be cacheable.
To minimize discrepancies between HTTP versions, the following
requirements apply when using HTTP/1.1:
o If the response has a heuristically cacheable status code ([HTTP],
Section 15.1), it SHOULD also carry a "Cache-Control: no-store"
header field ([HTTP-CACHING], Section 5.2).
* This can occur if the request is rejected or the connection
fails.
o The proxy SHOULD NOT attach any other caching-related header
fields to the response.
3.5. Closing Connections
Connection termination is essentially symmetrical for proxies and Connection termination is essentially symmetrical for proxies and
their clients. In this section, we use the term "endpoint" to their clients, which we refer to here as the "endpoints" of a
describe an implementation of this specification in either role. request.
When closing connections, endpoints are subject to the following When closing connections, endpoints are subject to the following
requirements: requirements:
o When an endpoint receives a valid TCP FIN, it MUST send a o When an endpoint receives a valid TCP FIN, it MUST send a
FINAL_DATA capsule. FINAL_DATA capsule.
o When an endpoint receives a valid FINAL_DATA capsule, it MUST send o When an endpoint receives a valid FINAL_DATA capsule, it MUST send
a TCP FIN. a TCP FIN.
o When a TCP connection reaches the TIME-WAIT or CLOSED state, the o When a TCP connection reaches the TIME-WAIT or CLOSED state, the
associated endpoint MUST close its send stream. associated endpoint MUST close its send stream.
* If the connection closed gracefully, the endpoint MUST close * If the connection closed gracefully, the endpoint MUST close
the send stream gracefully. the send stream gracefully.
* Otherwise, the endpoint SHOULD close the send stream abruptly, * Otherwise, the endpoint SHOULD close the send stream abruptly,
using a mechanism appropriate to the HTTP version: using a mechanism appropriate to the HTTP version:
+ HTTP/3: reset the stream with H3_CONNECT_ERROR; see [QUIC], + HTTP/3: reset the stream with H3_CONNECT_ERROR; see [QUIC],
Section 19.4 and [RFC9114], Section 8.1 Section 19.4 and [RFC9114], Section 8.1.
+ HTTP/2: reset the stream with CONNECT_ERROR; see [RFC9113], + HTTP/2: reset the stream with CONNECT_ERROR; see [RFC9113],
Sections 6.4 and 7 Sections 6.4 and 7.
+ HTTP/1.1 over TLS: TCP shutdown without a TLS closure alert; + HTTP/1.1 over TLS: TCP shutdown without a TLS closure alert;
see [TLS], Section 6.1. see [TLS], Section 6.1.
+ HTTP/1.1 without TLS: TCP RST + HTTP/1.1 without TLS: TCP RST.
o When the receive stream is closed abruptly or without a FINAL_DATA o When the receive stream is closed abruptly or without a FINAL_DATA
capsule received, the endpoint SHOULD send a TCP RST if the TCP capsule received, the endpoint SHOULD send a TCP RST if the TCP
subsystem permits it. subsystem permits it.
Any locally imposed timeout (Section 7.2) MUST be treated as an
abrupt closure of the affected stream or connection.
The mandatory behaviors above enable endpoints to detect any The mandatory behaviors above enable endpoints to detect any
truncation of incoming TCP data. The recommended behaviors propagate truncation of incoming TCP data. The recommended behaviors propagate
any TCP errors through the proxy connection. any TCP errors through the tunnel.
+-------+ +------------+ +------------+ +-------+ In HTTP/3, endpoints MAY negotiate and use the RESET_STREAM_AT frame
| TCP A | | Endpoint A | | Endpoint B | | TCP B | in order to reduce data loss during an abrupt closure
+-+-----+ +-+----------+ +----------+-+ +-----+-+ [I-D.ietf-quic-reliable-stream-reset]. However, RESET_STREAM_AT may
+---"abc"--->+-------DATA{"abc"}------->+---"abc"--->| not be very effective in this case, as TCP implementations will
+----FIN---->+------FINAL_DATA{""}----->+----FIN---->| typically discard pending data when a RST is received.
|<---FIN-----+<-----FINAL_DATA{""}------+<---FIN-----+
| |<----QUIC.STREAM{FIN}-----+ | +-------+ +------------+ +------------+ +-------+
+---FINACK-->+-----QUIC.STREAM{FIN}---->| | | TCP A | | Endpoint A | | Endpoint B | | TCP B |
| | | | +-+-----+ +-+----------+ +----------+-+ +-----+-+
+---"abc"--->+--------DATA{"abc"}------->+---"abc"--->|
+----FIN---->+------FINAL_DATA{""}------>+----FIN---->|
|<---FIN-----+<-----FINAL_DATA{""}-------+<---FIN-----+
| |<----QUIC.STREAM{FIN}------+ |
+---FINACK-->+-----QUIC.STREAM{FIN}----->| |
| | | |
Simple graceful termination example (HTTP/3) Simple graceful termination example (HTTP/3)
+-------+ +------------+ +------------+ +-------+ +-------+ +------------+ +------------+ +-------+
| TCP A | | Endpoint A | | Endpoint B | | TCP B | | TCP A | | Endpoint A | | Endpoint B | | TCP B |
+-+-----+ +-+----------+ +----------+-+ +-----+-+ +-+-----+ +-+----------+ +----------+-+ +-----+-+
+----RST---->+---RST_STREAM{CON_ERR}--->+----RST---->| +----RST---->+----RST_STREAM{CON_ERR}--->+----RST---->|
| | | | | | | |
Simple TCP RST termination example (HTTP/2) Simple TCP RST termination example (HTTP/2)
+-------+ +------------+ +------------+ +-------+ +-------+ +------------+ +------------+ +-------+
| TCP A | | Endpoint A | | Endpoint B | | TCP B | | TCP A | | Endpoint A | | Endpoint B | | TCP B |
+-+-----+ +-+----------+ +----------+-+ +-----+-+ +-+-----+ +-+----------+ +----------+-+ +-----+-+
+---"abc"--->+-------DATA{"abc"}------->+---"abc"--->| +---"abc"--->+--------DATA{"abc"}------->+---"abc"--->|
| | (... timeout @ A ...) | | | | (... timeout @ A ...) | |
| +--FIN (no close_notify)-->+----RST---->| | +--FIN (no close_notify) -->+----RST---->|
| | | | | | | |
Timeout example (HTTP/1.1) Timeout example (HTTP/1.1)
+-------+ +------------+ +------------+ +-------+ +-------+ +------------+ +------------+ +-------+
| TCP A | | Endpoint A | | Endpoint B | | TCP B | | TCP A | | Endpoint A | | Endpoint B | | TCP B |
+-+-----+ +-+----------+ +----------+-+ +-----+-+ +-+-----+ +-+----------+ +----------+-+ +-----+-+
+-----FIN--->+-------FINAL_DATA{""}---->+-----FIN--->| +-----FIN--->+-------FINAL_DATA{""}----->+-----FIN--->|
| | | | | | | |
| (FIN) | | (FIN) | | (FIN) | | (FIN) |
|<---"abc"---+<----FINAL_DATA{"abc"}----+<---"abc"---+ |<---"abc"---+<----FINAL_DATA{"abc"}-----+<---"abc"---+
| |<----QUIC.STREAM{FIN}-----+ | | |<----QUIC.STREAM{FIN}------+ |
+-----RST--->+-----H3_CONNECT_ERROR---->+-----RST--->| +-----RST--->+-----H3_CONNECT_ERROR----->+-----RST--->|
| | | | | | | |
RST after FIN example (HTTP/3) RST after FIN example (HTTP/3)
3.4.1. Handling Invalid Data 3.5.1. Handling Invalid Data
An endpoint that receives invalid data from its peer is subject to An endpoint that receives invalid data from its peer is subject to
the same requirements as when receiving an abrupt closure of the the same requirements as when receiving an abrupt closure of the
receive stream (see Section 3.4). Some examples of invalid data receive stream (see Section 3.5). Some examples of invalid data
include: include:
o A second FINAL_DATA capsule. o A second FINAL_DATA capsule.
o A DATA capsule after FINAL_DATA. o A DATA capsule after FINAL_DATA.
o Data that results in a parsing error under the Capsule Protocol. o Data that results in a parsing error under the Capsule Protocol.
o A capsule that is truncated by the end of the stream. o A capsule that is truncated by the end of the stream.
skipping to change at page 10, line 44 skipping to change at page 12, line 5
Note that very large DATA and FINAL_DATA capsules are still valid, as Note that very large DATA and FINAL_DATA capsules are still valid, as
they can be forwarded incrementally using a bounded memory buffer. they can be forwarded incrementally using a bounded memory buffer.
4. Additional Connection Setup Behaviors 4. Additional Connection Setup Behaviors
This section discusses some behaviors that are permitted or This section discusses some behaviors that are permitted or
recommended in order to enhance the performance or functionality of recommended in order to enhance the performance or functionality of
connection setup. connection setup.
4.1. Latency optimizations 4.1. Latency Optimizations
When using this specification in HTTP/2 or HTTP/3, clients MAY start When using this specification in HTTP/2 or HTTP/3, clients MAY start
sending TCP stream content optimistically, subject to flow control sending TCP stream content optimistically, subject to flow control
limits (Section 5.2 of [RFC9113] or Section 4.1 of [QUIC]). Proxies limits (Section 5.2 of [RFC9113] or Section 4.1 of [QUIC]). Proxies
MUST buffer this "optimistic" content until the TCP stream becomes MUST buffer this "optimistic" content until the TCP stream becomes
writable, and discard it if the TCP connection fails. (Clients MUST writable, and discard it if the TCP connection fails.
NOT use "optimistic" behavior in HTTP/1.1, as this would interfere
with reuse of the connection after an error response such as "401 Clients MUST NOT use "optimistic" behavior in HTTP/1.1, as this would
(Unauthorized)".) interfere with reuse of the connection after an error response such
as 401 (Unauthorized).
Servers that host a proxy under this specification MAY offer support Servers that host a proxy under this specification MAY offer support
for TLS early data in accordance with [RFC8470]. Clients MAY send for TLS early data in accordance with [RFC8470]. Clients MAY send
"connect-tcp" requests in early data, and MAY include "optimistic" CONNECT-TCP requests in early data, and MAY include "optimistic" TCP
TCP content in early data (in HTTP/2 and HTTP/3). At the TLS layer, content in early data (in HTTP/2 and HTTP/3). At the TLS layer,
proxies MAY ignore, reject, or accept the "early_data" extension proxies MAY ignore, reject, or accept the "early_data" extension
([TLS], Section 4.2.10). At the HTTP layer, proxies MAY process the ([TLS], Section 4.3.10). At the HTTP layer, proxies MAY process the
request immediately, return a "425 (Too Early)" response ([RFC8470], request immediately, return a 425 (Too Early) response ([RFC8470],
Section 5.2), or delay some or all processing of the request until Section 5.2), or delay some or all processing of the request until
the handshake completes. For example, a proxy with limited anti- the handshake completes. For example, a proxy with limited anti-
replay defenses might choose to perform DNS resolution of the replay defenses might choose to perform DNS resolution of
"target_host" when a request arrives in early data, but delay the TCP "target_host" when a request arrives in early data, but delay the TCP
connection until the TLS handshake completes. connection until the TLS handshake completes.
When DNS resolution of "target_host" produces multiple IP addresses, When DNS resolution of "target_host" produces IP addresses from
proxies SHOULD use a racing procedure such as Happy Eyeballs [HEv2] multiple address families, proxies SHOULD use a racing procedure such
to accelerate connection establishment. Proxies that race multiple as Happy Eyeballs [HEv2] to accelerate connection establishment.
connection attempts MUST buffer any optimistic content until a Proxies that race multiple connection attempts MUST buffer any
connection is selected and MUST NOT transmit any payload data on the optimistic content until a connection is selected and MUST NOT
other connections. transmit any payload data on the other connections.
4.2. Conveying metadata 4.2. Indicating Failure
This specification supports the "Expect: 100-continue" request header Failure to initiate a tunnel is indicated by the HTTP status code.
([HTTP], Section 10.1.1) in any HTTP version. The "100 (Continue)"
status code confirms receipt of a request at the proxy without A 4xx status code indicates that the request is malformed or
waiting for the proxy-destination TCP handshake to succeed or fail. impermissible. For example, if the proxy performs DNS resolution of
Clients MAY send "Expect: 100-continue", and proxies MUST respect it "target_host" and receives an IP address that is disallowed by the
by returning "100 (Continue)" if the request is not immediately proxy's policy, it might return 403 (Forbidden).
rejected. This allows for a few useful improvements:
A 5xx status code indicates a failure in the attempt, such as when a
TCP connection was attempted but did not succeed. The 502 (Bad
Gateway) and 504 (Gateway Timeout) status codes are commonly used.
The 429 (Too Many Requests) and 503 (Service Unavailable) status
codes indicate a temporary failure, and can carry a Retry-After
response header field ([HTTP], Section 10.2.3). If included, this
field applies to all requests using this URI Template.
4.3. Conveying Metadata
This specification supports the 100 (Continue) status code ([HTTP],
Section 15.2.1) in any HTTP version. Proxies SHOULD send this status
code whenever they accept a request, without waiting for the proxy-
destination TCP handshake to succeed or fail. This allows for a few
useful improvements:
o Clients can provide a clearer status indication while waiting for o Clients can provide a clearer status indication while waiting for
the destination host to respond. (TCP handshakes can hang for the destination host to respond. (TCP handshakes can hang for
several minutes before failing.) several minutes before failing.)
o Clients can apply separate timeouts to the proxying request and o Clients can apply separate timeouts to the tunneling request and
connection establishment. connection establishment.
o In HTTP/2 and HTTP/3, clients have the option to delay some or all o In HTTP/2 and HTTP/3, clients have the option to delay some or all
of the optimistic payload data until after confirming that the of the optimistic payload data until after confirming that the
request is permissible. This strategy reduces wasted effort when request is permissible. This strategy reduces wasted effort when
the request is rejected. the request is rejected.
Proxies implementing this specification SHOULD include a "Proxy- Note that a client in this specification cannot send an "Expect:
Status" response header field [RFC9209] in any success or failure 100-continue" request header field, because the request does not
response (i.e., status codes 101, 2XX, 4XX, or 5XX) to support include any "content" ([HTTP], Section 10.1.1).
Proxies implementing this specification SHOULD include a Proxy-Status
response header field [PROXY-STATUS] in any success or failure
response (i.e., status codes 101, 2xx, 4xx, or 5xx) to support
advanced client behaviors and diagnostics. Clients and proxies MUST advanced client behaviors and diagnostics. Clients and proxies MUST
NOT send trailer fields on "connect-tcp" streams. NOT send trailer fields on CONNECT-TCP streams.
5. Applicability 5. Applicability
5.1. Servers 5.1. Servers
For server operators, template-driven TCP proxies are particularly For server operators, CONNECT-TCP proxies are particularly valuable
valuable in situations where virtual-hosting is needed, or where in situations where virtual-hosting is needed, or where multiple
multiple proxies must share an origin. For example, the proxy might proxies must share an origin. For example, the proxy might benefit
benefit from sharing an HTTP gateway that provides DDoS defense, from sharing an HTTP gateway that provides DDoS defense, performs
performs request sanitization, or enforces user authorization. request sanitization, or enforces user authorization (Section 5.3).
Template-driven TCP proxies can also be made invisible to probes from CONNECT-TCP proxies can also be made invisible to probes from
unauthorized clients: unauthorized clients:
o The URI template can include a high-entropy path, similar to o The URI template can include a high-entropy path, similar to
Capability URLs [CAPABILITY]. Capability URLs [CAPABILITY].
o The proxy can require HTTP Concealed Authentication ([CONCEALED], o The proxy can require HTTP Concealed Authentication ([CONCEALED],
Section 6.4). Section 6.4).
5.2. Clients 5.2. Clients
Clients for this specification MAY accept various configuration This specification does not require any specific type of
inputs, including: configuration input. Suitable configuration input types include:
o A URI Template string, as described in Section 3. o A URI Template string, as described in Section 3.
o An IP address or hostname, with optional or required port and o An IP address or hostname, with optional or required port and
scheme (as often used to describe classic HTTP CONNECT proxies). scheme (as often used to describe classic HTTP CONNECT proxies).
A corresponding template-driven TCP proxy might be found in two A corresponding CONNECT-TCP proxy might be found in two ways:
ways:
* At the default template for "connect-tcp" (Figure 2). * At the default template for "connect-tcp" (Figure 2).
* In the "proxy" dictionary of a provisioning domain resource at * In the "proxies" array of a provisioning domain resource
the corresponding .well-known URI retrieved from the corresponding ".well-known" URI (Sections 2
([I-D.ietf-intarea-proxy-config], Section 2). and 3 of [I-D.ietf-intarea-proxy-config]).
o The full URI, including path, of a provisioning domain resource o A provisioning domain resource, configured directly or identified
containing one or more "connect-tcp" proxy sub-dictionaries by a local or remote URI (e.g., using "file://" or "https://").
([I-D.ietf-intarea-proxy-config], Section 3).
https://$PROXY_HOST:$PROXY_PORT/.well-known/masque https://$PROXY_HOST:$PROXY_PORT/.well-known/masque
/tcp/{target_host}/{target_port}/ /tcp/{target_host}/{target_port}/
Figure 2: Registered default template Figure 2: Registered default template
All of these input types MAY share a single input string, as they can All of these input types MAY share a single input string, as they can
be disambiguated reliably by parsing and probing. However, it may be be disambiguated reliably by parsing and probing. However, it may be
preferable to indicate the configuration input type explicitly, to preferable to indicate the configuration input type explicitly, to
reduce probing delays while supporting clients with differing reduce probing delays while supporting clients with differing
capabilities. capabilities.
Clients SHOULD treat certain errors during classic HTTP CONNECT as Clients SHOULD treat certain errors during classic HTTP CONNECT as
indications that the proxy might only support "connect-tcp": indications that the proxy might only support CONNECT-TCP:
o In HTTP/1.1: the response status code is "426 (Upgrade Required)", o In HTTP/1.1: the response's status code is 426 (Upgrade Required),
with an "Upgrade: connect-tcp" response header. with an "Upgrade: connect-tcp" response header.
o In any HTTP version: the response status code is "501 (Not o In any HTTP version: the response's status code is 501 (Not
Implemented)". Implemented).
* Requires SETTINGS_ENABLE_CONNECT_PROTOCOL to have been * Requires SETTINGS_ENABLE_CONNECT_PROTOCOL to have been
negotiated in HTTP/2 or HTTP/3. negotiated in HTTP/2 or HTTP/3.
If the client infers that classic HTTP CONNECT is not supported, it If the client infers that classic HTTP CONNECT is not supported, it
SHOULD retry the request using the registered default template for SHOULD retry the request using the registered default template for
"connect-tcp" (Figure 2). If this request succeeds, the client "connect-tcp" (Figure 2). If this request succeeds, the client
SHOULD record a preference for "connect-tcp" to avoid further retry SHOULD record a preference for CONNECT-TCP to avoid further retry
delays. delays.
5.3. Gateways
CONNECT-TCP requests can traverse standard HTTP gateways to ease
implementation and allow use of shared infrastructure. However,
current gateways might need modifications to support TCP proxy
services. To be compatible, a gateway MUST:
o support Extended CONNECT (if acting as an HTTP/2 or HTTP/3
server).
o support HTTP/1.1 Upgrade to "connect-tcp" (if acting as an
HTTP/1.1 server).
* only after forwarding the upgrade request to the origin and
observing a success response.
o forward the "connect-tcp" protocol to the origin.
o convert CONNECT-TCP requests between all supported HTTP server and
client versions.
o allow any Proxy-Status headers to traverse the gateway.
If the proxy relies on TLS Client Certificates for client
authentication, the gateway MUST perform this authentication itself
or pass the relevant information to the origin (e.g., using a Client-
Cert request header field [RFC9440]).
6. Security Considerations 6. Security Considerations
Template-driven TCP proxying is largely subject to the same security CONNECT-TCP is largely subject to the same security risks as classic
risks as classic HTTP CONNECT. For example, any restrictions on HTTP CONNECT. For example, any restrictions on authorized use of the
authorized use of the proxy (see [HTTP], Section 9.3.6) apply equally proxy (see [HTTP], Section 9.3.6) apply equally to both. The
to both. "destination_ip_prohibited" Proxy Error Type from Section 2.3.5 of
[PROXY-STATUS] can be useful when rejecting unauthorized requests.
A small additional risk is posed by the use of a URI Template parser A small additional risk is posed by the use of a URI Template parser
on the client side. The template input string could be crafted to on the client side. The template input string could be crafted to
exploit any vulnerabilities in the parser implementation. Client exploit any vulnerabilities in the parser implementation. Client
implementers should apply their usual precautions for code that implementers should apply their usual precautions for code that
processes untrusted inputs. processes untrusted inputs.
See Section 7 of [CONNECT-UDP] for a comparison of the risks of
operating a TCP or UDP proxy.
6.1. Resource Exhaustion attacks 6.1. Resource Exhaustion attacks
A malicious client can achieve cause highly asymmetric resource usage A malicious client can cause highly asymmetric resource usage at the
at the proxy by colluding with a destination server and violating the proxy by colluding with a destination server and violating the
ordinary rules of TCP or HTTP. Some example attacks, and mitigations ordinary rules of TCP or HTTP. Some example attacks, and mitigations
that proxies can apply: that proxies can apply:
o *Connection Pileup*: A malicious client can attempt to open a o *Connection Pileup*: A malicious client can attempt to open a
large number of connections to exhaust the proxy's memory, port, large number of connections to exhaust the proxy's memory, port,
or file descriptor limits. When using HTTP/2 or HTTP/3, each or file descriptor limits. When using HTTP/2 or HTTP/3, each
incremental TCP connection imposes a much higher cost on the proxy incremental TCP connection imposes a much higher cost on the proxy
than on the attacker. than on the attacker.
* Mitigation: Limit the number of concurrent connections per * Mitigation: Limit the number of concurrent connections per
skipping to change at page 14, line 19 skipping to change at page 16, line 30
o *Window Bloat*: An attacker can grow the receive window size by o *Window Bloat*: An attacker can grow the receive window size by
simulating a "long, fat network" ([RFC7323], Section 1.1), then simulating a "long, fat network" ([RFC7323], Section 1.1), then
fill the window (from the sender) and stop acknowledging it (at fill the window (from the sender) and stop acknowledging it (at
the receiver). This leaves the proxy buffering up to 1 GiB of TCP the receiver). This leaves the proxy buffering up to 1 GiB of TCP
data until some timeout, while the attacker does not have to data until some timeout, while the attacker does not have to
retain a large buffer. retain a large buffer.
* Mitigation: Limit the maximum receive window for TCP and HTTP * Mitigation: Limit the maximum receive window for TCP and HTTP
connections, and the size of userspace buffers used for connections, and the size of userspace buffers used for
proxying. Alternatively, monitor the connections' send queues forwarding data. Alternatively, monitor the connections' send
and limit the total buffered data per client. queues and limit the total buffered data per client.
o *WAIT Abuse*: An attacker can force the proxy into a TIME-WAIT, o *WAIT Abuse*: An attacker can force the proxy into a TIME-WAIT,
CLOSE-WAIT, or FIN-WAIT state until the timer expires, tying up a CLOSE-WAIT, or FIN-WAIT state until the timer expires, tying up a
proxy-to-destination 4-tuple for up to four minutes after the proxy-to-destination 4-tuple for up to four minutes after the
client's connection is closed. client's connection is closed.
* Mitigations: * Mitigations:
+ Enable the PAWS optimization ([RFC7323], Section 5) across + Enable the PAWS optimization ([RFC7323], Section 5) across
successive connections (e.g., Linux's "tcp_tw_reuse=1" successive connections (e.g., Linux's "tcp_tw_reuse=1"
skipping to change at page 14, line 46 skipping to change at page 17, line 10
+ Limit the number of connections for each client to each + Limit the number of connections for each client to each
destination, even if those connections are in a waiting destination, even if those connections are in a waiting
state and the corresponding CONNECT stream is closed. state and the corresponding CONNECT stream is closed.
+ If necessary, perform an abrupt TCP closure that destroys + If necessary, perform an abrupt TCP closure that destroys
the Transmission Control Block. Note that reusing a 4-tuple the Transmission Control Block. Note that reusing a 4-tuple
in this way can increase the risk of interference between in this way can increase the risk of interference between
successive connections. successive connections.
6.2. Client Authentication
A proxy server operating without access controls on the open internet
(an "open proxy") is likely to be discovered and misused quickly by
attackers. HTTP client authentication is the most common way to
avoid this misuse.
Section 3.4.2 describes how to use HTTP client authentication with
this specification. Each HTTP client authentication scheme offers
distinct security properties, so care should be taken to select an
appropriate scheme for each deployment. See [HTTP], Section 17.16
for additional guidance related to HTTP authentication.
6.3. TLS Early Data
This specification supports sending both proxying requests and
optimistic payload data in TLS early data (Section 4.1). TLS 1.3
recommends, but does not require, replay protection for this data
([TLS], Section 8), so a replay attack could cause the proxy service
to establish multiple connections to the target, and to deliver any
optimistic payload data on each of these connections. When such a
replay attack would cause harm (e.g., when the optimistic data
represents a non-idempotent application command), clients MUST NOT
use TLS early data.
See Section 6 of [RFC8470] for additional relevant security
considerations.
7. Operational Considerations 7. Operational Considerations
7.1. Avoiding HTTP/1.1 7.1. Avoiding HTTP/1.1
While this specification is fully functional under HTTP/1.1, While this specification is fully functional under HTTP/1.1,
performance-sensitive deployments SHOULD use HTTP/2 or HTTP/3 performance-sensitive deployments SHOULD use HTTP/2 or HTTP/3
instead. When using HTTP/1.1: instead. When using HTTP/1.1:
o Each CONNECT request requires a new TCP and TLS connection, o Each CONNECT request requires a new TCP and TLS connection,
imposing a higher cost in setup latency, congestion control imposing a higher cost in setup latency, congestion control
convergence, CPU time, and data transfer. convergence, CPU time, and data transfer.
o The graceful and abrupt closure signals (Section 3.4) are more o The graceful and abrupt closure signals (Section 3.5) are more
likely to be missing or corrupted: likely to be missing or corrupted:
* Some implementations may be unable to emit the recommended * Some implementations may be unable to emit the recommended
abrupt closure signals, due to limitations in their TCP and TLS abrupt closure signals, due to limitations in their TCP and TLS
subsystems. subsystems.
* Faulty implementations may fail to send a TLS closure alert * Faulty implementations may fail to send a TLS closure alert
during graceful shutdown, or fail to report an error when the during graceful shutdown, or fail to report an error when the
expected closure alert is not received. These misbehaviors are expected closure alert is not received. These misbehaviors are
not compliant with [TLS], but they are common nonetheless among not compliant with [TLS], but they are common nonetheless among
skipping to change at page 15, line 37 skipping to change at page 18, line 25
o The number of active connections through each client may be o The number of active connections through each client may be
limited by the number of available TCP client ports, especially limited by the number of available TCP client ports, especially
if: if:
* The client only has one IP address that can be used to reach * The client only has one IP address that can be used to reach
the proxy. the proxy.
* The client is shared between many parties, such as when acting * The client is shared between many parties, such as when acting
as a gateway or concentrator. as a gateway or concentrator.
* The proxied connections are often closed by the destination. * The tunneled connections are often closed by the destination.
This causes the client to initiate closure of the client-to- This causes the client to initiate closure of the client-to-
proxy connection, leaving the client in a TIME-WAIT state for proxy connection, leaving the client in a TIME-WAIT state for
up to four minutes. up to four minutes.
7.2. Gateway Compatibility 7.2. Timeouts
Templated TCP proxies can make use of standard HTTP gateways and
path-routing to ease implementation and allow use of shared
infrastructure. However, current gateways might need modifications
to support TCP proxy services. To be compatible, a gateway must:
o support Extended CONNECT (if acting as an HTTP/2 or HTTP/3
server).
o support HTTP/1.1 Upgrade to "connect-tcp" (if acting as an
HTTP/1.1 server)
* only after forwarding the upgrade request to the origin and
observing a success response.
o forward the "connect-tcp" protocol to the origin.
o convert "connect-tcp" requests between all supported HTTP server
and client versions.
o allow any "Proxy-Status" headers to traverse the gateway.
If the proxy relies on TLS Client Certificates for client
authentication, the gateway must perform this authentication itself
or pass the relevant information to the origin (e.g., using a
"Client-Cert" request header field [RFC9440]).
7.3. Timeouts
Except when actively sending or receiving data, an endpoint is always Except when actively sending or receiving data, an endpoint is always
waiting for an event from its peer or its TCP connection. HTTP and waiting for an event from its peer or its TCP connection. HTTP and
TCP are designed to ensure that such an event always arrives, so the TCP are designed to ensure that such an event always arrives, so the
connection is never permanently stuck in any state until it is fully connection is never permanently stuck in any state until it is fully
closed. However, for efficient operation, it may be necessary to closed. However, for efficient operation, it may be necessary to
adjust the settings for TCP keep-alives ([TCP], Section 3.8.4), QUIC adjust the settings for TCP keep-alives ([TCP], Section 3.8.4), QUIC
idle timeouts ([QUIC], Section 10.1), HTTP/2 PING frames ([RFC9113], idle timeouts ([QUIC], Section 10.1), HTTP/2 PING frames ([RFC9113],
Section 6.7), and other transport options. Section 6.7), and other transport options.
Endpoints MAY impose additional timeouts, especially as a defense Endpoints MAY impose additional timeouts, especially as a defense
against certain resource exhaustion attacks (Section 6.1). However, against certain resource exhaustion attacks (Section 6.1). However,
operators should apply timeouts cautiously to minimize the impact on operators should apply timeouts cautiously to minimize the impact on
connections that are functioning but slow. Any timeout imposed by connections that are functioning but slow. See Section 3.5 for
the endpoint MUST be treated as an abrupt closure of the affected related requirements.
stream or connection (Section 3.4).
For example, enabling PING frames on idle HTTP/2 connections allows
the operator to prevent some kinds of failures and detect failed
connections faster, but it uses more bandwidth, CPU time, and radio
power, and increases the risk of false-positive connection failures.
Optimal transport settings will depend on the network environment
(e.g., mobile vs. fixed), characteristics of the tunneled
application, and many other considerations.
7.3. Scope of Packet-Level Metadata
This specification does not provide a way to pass packet-level
metadata such as IPv6 Extension Headers [RFC2460], Section 4,
DiffServ Codepoints (DSCP) [RFC2474], or Explicit Congestion
Notification (ECN) marks [RFC3168] through the tunnel. TCP options
and non-fatal ICMP messages (e.g., Packet Too Big) are similarly not
relayed. Instead, these signals are processed by the relevant
endpoint of this specification, which is also the TCP endpoint and
only relays payload data through the tunnel.
Consumption and generation of these signals on each connection is
controlled by the endpoint, and is independent from any behaviors of
the other endpoint and any similar signals on the tunnel's HTTP
connection. If the operator has requirements related to these
behaviors, it must configure the relevant endpoint (typically the
proxy) accordingly.
7.4. IP address sharing
A TCP proxy typically uses the same IP address to establish
connections on behalf of multiple clients, especially in IPv4.
[RFC6269] provides guidance regarding difficulties that can arise
from IP address sharing, including in this arrangement.
7.5. Diagnostics and Monitoring
A proxy in this protocol reports success or failure in each response
via the HTTP status code and the Proxy-Status response header field.
Monitoring those error codes is a sensible way to assess the
functioning of a proxy server. Other relevant performance indicators
may include:
o Abrupt closure rates
o Number of active tunnels per user
o Total throughput in each direction
o Number of bytes buffered
o Connection duration
o Time spent establishing or closing connections
o Number of half-closed or WAIT-state connections
o DNS resolution delay
An increase in any of these measures could indicate an operational
problem or a resource exhaustion attack (Section 6.1). See
Section 6.1 for guidance on relevant defenses and limits.
8. IANA Considerations 8. IANA Considerations
8.1. New Upgrade Token 8.1. New Upgrade Token
IF APPROVED, IANA is requested to add the following entry to the HTTP IANA is requested to add the following entry to the "HTTP Upgrade
Upgrade Token Registry: Tokens" registry under "Hypertext Transfer Protocol (HTTP) Upgrade
Token Registry" registry group:
+---------------+--------------------------+-----------------+ +---------------+-------------------+-----------------+-------------+
| Value | Description | Reference | | Value | Description | Expected | Reference |
+---------------+--------------------------+-----------------+ | | | Version Tokens | |
| "connect-tcp" | Proxying of TCP payloads | (This document) | +---------------+-------------------+-----------------+-------------+
+---------------+--------------------------+-----------------+ | "connect-tcp" | Proxying of TCP | (None) | (This |
| | payloads | | document) |
+---------------+-------------------+-----------------+-------------+
8.1.1. Interop testing 8.1.1. Interop testing
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
For interoperability testing of this draft version, implementations For interoperability testing of this draft version, implementations
SHALL use the value "connect-tcp-12". SHALL use the value "connect-tcp-12".
8.2. New MASQUE Default Template 8.2. New MASQUE Default Template
IF APPROVED, IANA is requested to add the following entry to the IANA is requested to add the following entry to the "MASQUE URI
"MASQUE URI Suffixes" registry: Suffixes" registry under "Multiplexed Application Substrate over QUIC
Encryption (MASQUE)" registry group:
+--------------+--------------+-----------------+ +--------------+--------------+-----------------+
| Path Segment | Description | Reference | | Path Segment | Description | Reference |
+--------------+--------------+-----------------+ +--------------+--------------+-----------------+
| tcp | TCP Proxying | (This document) | | tcp | TCP Proxying | (This document) |
+--------------+--------------+-----------------+ +--------------+--------------+-----------------+
8.3. New Capsule Type 8.3. New Capsule Type
IF APPROVED, IANA is requested to add the following entry to the IANA is requested to add the following entry to the "HTTP Capsule
"HTTP Capsule Types" registry: Types" registry under "Multiplexed Application Substrate over QUIC
Encryption (MASQUE)" registry group:
+------+------------+-----------+------------+------------+---------+ +------+------------+-----------+------------+------------+---------+
| Valu | Capsule | Status | Reference | Change | Contact | | Valu | Capsule | Status | Reference | Change | Contact |
| e | Type | | | Controller | | | e | Type | | | Controller | |
+------+------------+-----------+------------+------------+---------+ +------+------------+-----------+------------+------------+---------+
| 0x08 | DATA | permanent | (This | IETF | HTTPBIS | | 0x08 | DATA | permanent | (This | IETF | HTTPBIS |
| | | | document), | | | | | | | document), | | |
| | | | Section 3 | | | | | | | Section 3 | | |
| | | | | | | | | | | | | |
| 0x09 | FINAL_DATA | permanent | (This | IETF | HTTPBIS | | 0x09 | FINAL_DATA | permanent | (This | IETF | HTTPBIS |
skipping to change at page 18, line 10 skipping to change at page 21, line 36
[CONNECT-UDP] [CONNECT-UDP]
Schinazi, D., "Proxying UDP in HTTP", RFC 9298, Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022, DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/info/rfc9298>. <https://www.rfc-editor.org/info/rfc9298>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[PROXY-STATUS]
Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
Response Header Field", RFC 9209, DOI 10.17487/RFC9209,
June 2022, <https://www.rfc-editor.org/info/rfc9209>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 18, line 48 skipping to change at page 22, line 33
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>. June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022, DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>. <https://www.rfc-editor.org/info/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>. June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[RFC9209] Nottingham, M. and P. Sikora, "The Proxy-Status HTTP
Response Header Field", RFC 9209, DOI 10.17487/RFC9209,
June 2022, <https://www.rfc-editor.org/info/rfc9209>.
[RFC9220] Hamilton, R., "Bootstrapping WebSockets with HTTP/3", [RFC9220] Hamilton, R., "Bootstrapping WebSockets with HTTP/3",
RFC 9220, DOI 10.17487/RFC9220, June 2022, RFC 9220, DOI 10.17487/RFC9220, June 2022,
<https://www.rfc-editor.org/info/rfc9220>. <https://www.rfc-editor.org/info/rfc9220>.
[TCP] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026, Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
<https://www.rfc-editor.org/info/rfc9846>. <https://www.rfc-editor.org/info/rfc9846>.
9.2. Informative References 9.2. Informative References
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
skipping to change at page 19, line 49 skipping to change at page 23, line 35
[HEv2] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [HEv2] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
[HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [HSTS] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012, DOI 10.17487/RFC6797, November 2012,
<https://www.rfc-editor.org/info/rfc6797>. <https://www.rfc-editor.org/info/rfc6797>.
[HTTP-CACHING]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/info/rfc9111>.
[I-D.ietf-httpbis-wrap-up] [I-D.ietf-httpbis-wrap-up]
Schinazi, D. and L. Pardue, "The HTTP Wrap Up Capsule", Schinazi, D. and L. Pardue, "The HTTP Wrap Up Capsule",
draft-ietf-httpbis-wrap-up-01 (work in progress), July draft-ietf-httpbis-wrap-up-01 (work in progress), July
2025. 2025.
[I-D.ietf-intarea-proxy-config] [I-D.ietf-intarea-proxy-config]
Pauly, T., Damjanovic, D., and Y. Rosomakho, Pauly, T., Damjanovic, D., and Y. Rosomakho,
"Communicating Proxy Configurations in Provisioning "Communicating Proxy Configurations in Provisioning
Domains", draft-ietf-intarea-proxy-config-14 (work in Domains", draft-ietf-intarea-proxy-config-14 (work in
progress), May 2026. progress), May 2026.
[I-D.ietf-quic-reliable-stream-reset]
Seemann, M. and K. Oku, "QUIC Stream Resets with Partial
Delivery", draft-ietf-quic-reliable-stream-reset-11 (work
in progress), September 2026.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/info/rfc6269>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance", Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, DOI 10.17487/RFC7323, September 2014, RFC 7323, DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/info/rfc7323>. <https://www.rfc-editor.org/info/rfc7323>.
[RFC8942] Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942, [RFC8942] Grigorik, I. and Y. Weiss, "HTTP Client Hints", RFC 8942,
DOI 10.17487/RFC8942, February 2021, DOI 10.17487/RFC8942, February 2021,
<https://www.rfc-editor.org/info/rfc8942>. <https://www.rfc-editor.org/info/rfc8942>.
[RFC9440] Campbell, B. and M. Bishop, "Client-Cert HTTP Header [RFC9440] Campbell, B. and M. Bishop, "Client-Cert HTTP Header
Field", RFC 9440, DOI 10.17487/RFC9440, July 2023, Field", RFC 9440, DOI 10.17487/RFC9440, July 2023,
<https://www.rfc-editor.org/info/rfc9440>. <https://www.rfc-editor.org/info/rfc9440>.
[SYSCTL] "IP Sysctl -- The Linux Kernel documentation", June 2026, [SYSCTL] "IP Sysctl -- The Linux Kernel documentation", June 2026,
<https://www.kernel.org/doc/html/v7.1/networking/ip- <https://www.kernel.org/doc/html/v7.1/networking/ip-
sysctl.html>. sysctl.html>.
[TCP] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
Acknowledgments Acknowledgments
Thanks to Amos Jeffries, Tommy Pauly, Kyle Nekritz, David Schinazi, This document benefited from close review and suggested changes by:
and Kazuho Oku for close review and suggested changes.
o Mohamed Boucadair
o Deb Cooley
o Gorry Fairhurst
o Thomas Fossati
o Amos Jeffries
o Mahesh Jethanandani
o Antun Jurkovic
o Eric Kinnear
o Kyle Nekritz
o Kazuho Oku
o Tommy Pauly
o Yaroslav Romakho
o David Schinazi
o Ketan Talaulikar
o Willy Tarreau
Author's Address Author's Address
Benjamin M. Schwartz Benjamin M. Schwartz
Meta Platforms, Inc. Meta Platforms, Inc.
Email: ietf@bemasc.net Email: ietf@bemasc.net
 End of changes. 114 change blocks. 
298 lines changed or deleted 532 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/