draft-ietf-masque-connect-udp-11.txt   draft-ietf-masque-connect-udp-12.txt 
MASQUE D. Schinazi MASQUE D. Schinazi
Internet-Draft Google LLC Internet-Draft Google LLC
Intended status: Standards Track 2 May 2022 Intended status: Standards Track 3 May 2022
Expires: 3 November 2022 Expires: 4 November 2022
Proxying UDP in HTTP Proxying UDP in HTTP
draft-ietf-masque-connect-udp-11 draft-ietf-masque-connect-udp-12
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 3 November 2022. This Internet-Draft will expire on 4 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 5, line 46 skipping to change at page 5, line 46
* otherwise, the recipient will act as a UDP proxy: it extracts the * otherwise, the recipient will act as a UDP proxy: it extracts the
"target_host" and "target_port" variables from the URI it has "target_host" and "target_port" variables from the URI it has
reconstructed from the request headers, and establishes a tunnel reconstructed from the request headers, and establishes a tunnel
by directly opening a UDP socket to the requested target. 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, the UDP proxy MUST
resolution failure), the UDP proxy MUST fail the request and SHOULD fail the request and SHOULD send details using an appropriate "Proxy-
send details using an appropriate "Proxy-Status" header field Status" header field [PROXY-STATUS] (for example, if DNS resolution
[PROXY-STATUS]. returns an error, the proxy can use the dns_error Proxy Error Type
from Section 2.3.2 of [PROXY-STATUS]).
UDP proxies can use connected UDP sockets if their operating system UDP proxies can use connected UDP sockets if their operating system
supports them, as that allows the UDP proxy to rely on the kernel to supports them, as that allows the UDP proxy to rely on the kernel to
only send it UDP packets that match the correct 5-tuple. If the UDP only send it UDP packets that match the correct 5-tuple. If the UDP
proxy uses a non-connected socket, it MUST validate the IP source proxy uses a non-connected socket, it MUST validate the IP source
address and UDP source port on received packets to ensure they match address and UDP source port on received packets to ensure they match
the client's request. Packets that do not match MUST be discarded by the client's request. Packets that do not match MUST be discarded by
the UDP proxy. the UDP proxy.
The lifetime of the socket is tied to the request stream. The UDP The lifetime of the socket is tied to the request stream. The UDP
 End of changes. 4 change blocks. 
8 lines changed or deleted 9 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/