Multiplexed Application Substrate over QUIC Encryption Y. Rosomakho Internet-Draft Zscaler Intended status: Standards Track 28 February 2025 Expires: 1 September 2025 Optional TCP and UDP checksums for IP in HTTP draft-rosomakho-masque-optional-l4-checksum-latest Abstract 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. About This Document 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. 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 1 September 2025. Copyright Notice 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. Table of Contents 1. Introduction 2. Conventions and Definitions 3. Transport-Checksum-Optional header 4. Using Context ID to signal checksum omission 5. Security Considerations 6. IANA Considerations 6.1. HTTP Header 7. References 7.1. Normative References 7.2. Informative References Acknowledgments Author's Address 1. Introduction 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. 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. Transport-Checksum-Optional header 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. 4. Using Context ID to signal checksum omission 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. 5. Security Considerations Since HTTP transport provides integrity protection, checksum omission does not introduce additional security risks. 6. IANA Considerations 6.1. HTTP Header This document registers the "Transport-Checksum-Optional" header in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" . +===========================+=========+==========+=========+========+ |Field Name |Status |Structured|Reference|Comments| | | |Type | | | +===========================+=========+==========+=========+========+ |Transport-Checksum-Optional|permanent|Item |This |None | | | | |Document | | +---------------------------+---------+----------+---------+--------+ Table 1 7. References 7.1. Normative References [CONNECT-IP] Pauly, T., Ed., Schinazi, D., Chernyakhovsky, A., Kühlewind, M., and M. Westerlund, "Proxying IP in HTTP", RFC 9484, DOI 10.17487/RFC9484, October 2023, . [CONNECT-UDP] Schinazi, D., "Proxying UDP in HTTP", RFC 9298, DOI 10.17487/RFC9298, August 2022, . [CSUM] Braden, R., Borman, D., and C. Partridge, "Computing the Internet checksum", RFC 1071, DOI 10.17487/RFC1071, September 1988, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TCP] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . 7.2. Informative References [OFFLOADS] The Linux Kernel Documentation, "Segmentation Offloads", n.d., . Acknowledgments TODO acknowledge. Author's Address Yaroslav Rosomakho Zscaler Email: yrosomakho@zscaler.com