| Internet-Draft | TODO - Abbreviation | February 2025 |
| Rosomakho | Expires 1 September 2025 | [Page] |
This document specifies an extension to IP over HTTP, allowing communicating parties to negotiate the omission of TCP and UDP checksum computations in tunneled packets. It provides a mechanism for agreement on this capability and assigns Context Identifiers to mark packets where checksum computation is intentionally bypassed.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://yaroslavros.github.io/masque-optional-l4-checksum/draft-rosomakho-masque-optional-l4-checksum.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rosomakho-masque-optional-l4-checksum/.¶
Discussion of this document takes place on the Multiplexed Application Substrate over QUIC Encryption mailing list (mailto:masque@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/masque/. Subscribe at https://www.ietf.org/mailman/listinfo/masque/.¶
Source for this draft and an issue tracker can be found at https://github.com/yaroslavros/masque-optional-l4-checksum.¶
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 1 September 2025.¶
Copyright (c) 2025 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.¶
Proxying IP in HTTP [CONNECT-IP] allows IP packets to be tunneled over an HTTP connection. TCP [TCP] and UDP [UDP] packets encapsulated in this mechanism are expected to include correct internet checksums [CSUM] in corresponding transport layer header. This checksum is designed to reduce chances of packet corruption in transit.¶
A CONNECT-IP endpoint accepting IP packets for HTTP transit may obtain them without pre-calculated checksums. This can be beneficial in scenarios where segmentation offloading is used or when packets are generated directly by the tunneling endpoint, reducing redundant computational overhead. Similarly, the receiver of IP packets encapsulated in HTTP may need to remove TCP and UDP headers from some packets during segmentation offloading. Additionally, if the packets are processed locally, the receiver may ignore the checksums since HTTP provides reliable transport, making the embedded checksumming mechanism redundant.¶
To signal support of checksum omission, endpoints include "Transport-Checksum-Optional" header field, as defined in Section 3. The value of the header corresponds to the Context Identifier for the datagrams with potentially incorrect TCP or UDP checksums.¶
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.¶
A client initiating IP proxying via a CONNECT request as defined in [CONNECT-IP] includes the "Transport-Checksum-Optional" header to indicate that it supports transport checksum omission and would like to negotiate it. The value of the header will be set to non-zero even-numbered Context Identifier as defined in Section 4 of [CONNECT-UDP]. If the server includes the "Transport-Checksum-Optional" header in the response and sets it to an odd-numbered value as long as it also supports transport checksum omission mechanism and would like to use it.¶
Server MUST NOT include "Transport-Checksum-Optional" header in response to request that did not include this header. Client receiving unexpected "Transport-Checksum-Optional" header in server response MUST treat the proxying attempt as failed and abort the connection.¶
To indicate TCP and UDP checksum omission the endpoints use datagram Context Identifier that they previously provided to the peer through the "Transport-Checksum-Optional" header. TCP and UDP packets encapsulated into datagrams with that Context Identifier SHOULD have checksum set to all zero. If the receiver of the datagram needs to route that packet without removing transport layer header for segmentation offloading purposes, it MUST calculate the checksum and populate the field accordingly.¶
Datagrams containing TCP and UDP packets with known correct checksums MUST NOT use Context Identifier signaled in the "Transport-Checksum-Optional" header.¶
This mechanism is designed only for TCP and UDP checksums. Checksums of other transport layer protocols or IPv4 header MUST NOT be omitted.¶
Since HTTP transport provides integrity protection, checksum omission does not introduce additional security risks.¶
This document registers the "Transport-Checksum-Optional" header in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" <https://www.iana.org/assignments/http-fields>.¶
| Field Name | Status | Structured Type | Reference | Comments |
|---|---|---|---|---|
| Transport-Checksum-Optional | permanent | Item | This Document | None |
TODO acknowledge.¶