--- 1/draft-ietf-masque-connect-udp-10.txt 2022-05-02 13:13:32.188430256 -0700 +++ 2/draft-ietf-masque-connect-udp-11.txt 2022-05-02 13:13:32.224431169 -0700 @@ -1,18 +1,18 @@ MASQUE D. Schinazi Internet-Draft Google LLC -Intended status: Standards Track 18 April 2022 -Expires: 20 October 2022 +Intended status: Standards Track 2 May 2022 +Expires: 3 November 2022 Proxying UDP in HTTP - draft-ietf-masque-connect-udp-10 + draft-ietf-masque-connect-udp-11 Abstract This document describes how to proxy UDP in HTTP, similar to how the HTTP CONNECT method allows proxying TCP in HTTP. More specifically, this document defines a protocol that allows HTTP clients to create a tunnel for UDP communications through an HTTP server that acts as a proxy. About This Document @@ -38,21 +38,21 @@ 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 20 October 2022. + This Internet-Draft will expire on 3 November 2022. 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 @@ -63,31 +63,31 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 2. Client Configuration . . . . . . . . . . . . . . . . . . . . 3 3. Tunnelling UDP over HTTP . . . . . . . . . . . . . . . . . . 4 3.1. UDP Proxy Handling . . . . . . . . . . . . . . . . . . . 5 3.2. HTTP/1.1 Request . . . . . . . . . . . . . . . . . . . . 6 3.3. HTTP/1.1 Response . . . . . . . . . . . . . . . . . . . . 7 - 3.4. HTTP/2 and HTTP/3 Requests . . . . . . . . . . . . . . . 7 + 3.4. HTTP/2 and HTTP/3 Requests . . . . . . . . . . . . . . . 8 3.5. HTTP/2 and HTTP/3 Responses . . . . . . . . . . . . . . . 8 - 3.6. Note About Draft Versions . . . . . . . . . . . . . . . . 8 + 3.6. Note About Draft Versions . . . . . . . . . . . . . . . . 9 4. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 9 5. HTTP Datagram Payload Format . . . . . . . . . . . . . . . . 10 6. Performance Considerations . . . . . . . . . . . . . . . . . 11 6.1. MTU Considerations . . . . . . . . . . . . . . . . . . . 11 - 6.2. Tunneling of ECN Marks . . . . . . . . . . . . . . . . . 11 + 6.2. Tunneling of ECN Marks . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 8.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 12 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 8.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 13 8.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction While HTTP provides the CONNECT method (see Section 9.3.6 of [HTTP]) @@ -206,24 +206,33 @@ encoding, so for example if the target_host is "2001:db8::42", it will be encoded in the URI as "2001%3Adb8%3A%3A42". By virtue of the definition of the Capsule Protocol (see [HTTP-DGRAM]), UDP proxying requests do not carry any message content. Similarly, successful UDP proxying responses also do not carry any message content. 3.1. UDP Proxy Handling - Upon receiving a UDP proxying request, the recipient UDP proxy - extracts the "target_host" and "target_port" variables from the URI - it has reconstructed from the request headers, and establishes a - tunnel by directly opening a UDP socket to the requested target. + Upon receiving a UDP proxying request: + + * if the recipient is configured to use another HTTP proxy, it will + act as an intermediary: it forwards the request to another HTTP + server. Note that such intermediaries may need to reencode the + request if they forward it using a version of HTTP that is + different from the one used to receive it, as the request encoding + differs by version (see below). + + * otherwise, the recipient will act as a UDP proxy: it extracts the + "target_host" and "target_port" variables from the URI it has + reconstructed from the request headers, and establishes a tunnel + by directly opening a UDP socket to the requested target. Unlike TCP, UDP is connection-less. The UDP proxy that opens the UDP socket has no way of knowing whether the destination is reachable. Therefore it needs to respond to the request without waiting for a packet from the target. However, if the target_host is a DNS name, the UDP proxy MUST perform DNS resolution before replying to the HTTP request. If errors occur during this process (for example, a DNS resolution failure), the UDP proxy MUST fail the request and SHOULD send details using an appropriate "Proxy-Status" header field [PROXY-STATUS].