draft-ietf-masque-connect-udp-10.txt   draft-ietf-masque-connect-udp-11.txt 
MASQUE D. Schinazi MASQUE D. Schinazi
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Standards Track 18 April 2022 Intended status: Standards Track 2 May 2022
Expires: 20 October 2022 Expires: 3 November 2022
Proxying UDP in HTTP Proxying UDP in HTTP
draft-ietf-masque-connect-udp-10 draft-ietf-masque-connect-udp-11
Abstract Abstract
This document describes how to proxy UDP in HTTP, similar to how the This document describes how to proxy UDP in HTTP, similar to how the
HTTP CONNECT method allows proxying TCP in HTTP. More specifically, HTTP CONNECT method allows proxying TCP in HTTP. More specifically,
this document defines a protocol that allows HTTP clients to create a this document defines a protocol that allows HTTP clients to create a
tunnel for UDP communications through an HTTP server that acts as a tunnel for UDP communications through an HTTP server that acts as a
proxy. proxy.
About This Document About This Document
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 20 October 2022. This Internet-Draft will expire on 3 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3 1.1. Conventions and Definitions . . . . . . . . . . . . . . . 3
2. Client Configuration . . . . . . . . . . . . . . . . . . . . 3 2. Client Configuration . . . . . . . . . . . . . . . . . . . . 3
3. Tunnelling UDP over HTTP . . . . . . . . . . . . . . . . . . 4 3. Tunnelling UDP over HTTP . . . . . . . . . . . . . . . . . . 4
3.1. UDP Proxy Handling . . . . . . . . . . . . . . . . . . . 5 3.1. UDP Proxy Handling . . . . . . . . . . . . . . . . . . . 5
3.2. HTTP/1.1 Request . . . . . . . . . . . . . . . . . . . . 6 3.2. HTTP/1.1 Request . . . . . . . . . . . . . . . . . . . . 6
3.3. HTTP/1.1 Response . . . . . . . . . . . . . . . . . . . . 7 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.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 4. Context Identifiers . . . . . . . . . . . . . . . . . . . . . 9
5. HTTP Datagram Payload Format . . . . . . . . . . . . . . . . 10 5. HTTP Datagram Payload Format . . . . . . . . . . . . . . . . 10
6. Performance Considerations . . . . . . . . . . . . . . . . . 11 6. Performance Considerations . . . . . . . . . . . . . . . . . 11
6.1. MTU 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 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 12 8.1. HTTP Upgrade Token . . . . . . . . . . . . . . . . . . . 13
8.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 13 8.2. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
While HTTP provides the CONNECT method (see Section 9.3.6 of [HTTP]) While HTTP provides the CONNECT method (see Section 9.3.6 of [HTTP])
skipping to change at page 5, line 27 skipping to change at page 5, line 27
encoding, so for example if the target_host is "2001:db8::42", it encoding, so for example if the target_host is "2001:db8::42", it
will be encoded in the URI as "2001%3Adb8%3A%3A42". will be encoded in the URI as "2001%3Adb8%3A%3A42".
By virtue of the definition of the Capsule Protocol (see By virtue of the definition of the Capsule Protocol (see
[HTTP-DGRAM]), UDP proxying requests do not carry any message [HTTP-DGRAM]), UDP proxying requests do not carry any message
content. Similarly, successful UDP proxying responses also do not content. Similarly, successful UDP proxying responses also do not
carry any message content. carry any message content.
3.1. UDP Proxy Handling 3.1. UDP Proxy Handling
Upon receiving a UDP proxying request, the recipient UDP proxy Upon receiving a UDP proxying request:
extracts the "target_host" and "target_port" variables from the URI
it has reconstructed from the request headers, and establishes a * if the recipient is configured to use another HTTP proxy, it will
tunnel by directly opening a UDP socket to the requested target. 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 Unlike TCP, UDP is connection-less. The UDP proxy that opens the UDP
socket has no way of knowing whether the destination is reachable. socket has no way of knowing whether the destination is reachable.
Therefore it needs to respond to the request without waiting for a 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, 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 the UDP proxy MUST perform DNS resolution before replying to the HTTP
request. If errors occur during this process (for example, a DNS request. If errors occur during this process (for example, a DNS
resolution failure), the UDP proxy MUST fail the request and SHOULD resolution failure), the UDP proxy MUST fail the request and SHOULD
send details using an appropriate "Proxy-Status" header field send details using an appropriate "Proxy-Status" header field
[PROXY-STATUS]. [PROXY-STATUS].
 End of changes. 8 change blocks. 
13 lines changed or deleted 22 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/