Aller au contenu principal

RFC 9298 - Proxy UDP dans HTTP

Internet Engineering Task Force (IETF) D. Schinazi Request for Comments: 9298 Google LLC Category: Standards Track August 2022 ISSN: 2070-1721

                      Proxy UDP dans HTTP

Résumé

Ce document décrit comment relayer (proxy) UDP dans HTTP, de manière similaire à la méthode HTTP CONNECT qui permet de relayer TCP dans HTTP. Plus spécifiquement, ce document définit un protocole qui permet à un client HTTP de créer un tunnel pour les communications UDP à travers un serveur HTTP qui agit comme un proxy.

Statut de ce mémoire

Ce document est un document de la série des normes Internet (Standards Track).

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). De plus amples informations sur les normes Internet sont disponibles dans la section 2 de la RFC 7841.

Des informations sur le statut actuel de ce document, les errata éventuels et la manière de fournir des commentaires sont disponibles sur https://www.rfc-editor.org/info/rfc9298.

Avis de droit d'auteur

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 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 des matières

  1. Introduction 1.1. Conventions et définitions

  2. Configuration du client

  3. Tunnelisation UDP sur HTTP 3.1. Traitement du proxy UDP 3.2. Requête HTTP/1.1 3.3. Réponse HTTP/1.1 3.4. Requêtes HTTP/2 et HTTP/3 3.5. Réponses HTTP/2 et HTTP/3

  4. Identifiants de contexte

  5. Format de charge utile de datagramme HTTP

  6. Considérations relatives aux performances 6.1. Considérations relatives au MTU 6.2. Tunnelisation des marques ECN

  7. Considérations de sécurité

  8. Considérations relatives à l'IANA 8.1. Jeton de mise à niveau HTTP 8.2. URI bien connu

  9. Références 9.1. Références normatives 9.2. Références informatives Remerciements Adresse de l'auteur

  10. Introduction

Alors que HTTP fournit la méthode CONNECT (voir la section 9.3.6 de [HTTP]) pour créer un tunnel TCP [TCP] vers un proxy, il manquait une méthode pour le faire pour le trafic UDP [UDP] avant cette spécification.

Ce document décrit un protocole pour tunneliser UDP vers un serveur agissant comme un proxy spécifique à UDP sur HTTP. Les tunnels UDP sont couramment utilisés pour créer une connexion virtuelle de bout en bout, qui peut ensuite être sécurisée à l'aide de QUIC [QUIC] ou d'un autre protocole fonctionnant sur UDP. Contrairement à la méthode HTTP CONNECT, le proxy UDP lui-même est identifié par une URL absolue contenant la destination du trafic. Les clients génèrent ces URL à l'aide d'un modèle d'URI [TEMPLATE], comme décrit dans la section 2.

Ce protocole prend en charge toutes les versions existantes de HTTP en utilisant des datagrammes HTTP [HTTP-DGRAM]. Lors de l'utilisation de HTTP/2 [HTTP/2] ou HTTP/3 [HTTP/3], il utilise HTTP Extended CONNECT comme décrit dans [EXT-CONNECT2] et [EXT-CONNECT3]. Lors de l'utilisation de HTTP/1.x [HTTP/1.1], il utilise la mise à niveau HTTP telle que définie dans la section 7.8 de [HTTP].

1.1. Conventions et définitions

Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

Dans ce document, nous utilisons le terme "proxy UDP" pour faire référence au serveur HTTP qui agit sur la demande de tunnelisation UDP du client pour ouvrir une socket UDP vers un serveur cible et qui génère la réponse à cette demande. S'il existe des intermédiaires HTTP (tels que définis dans la section 3.7 de [HTTP]) entre le client et le proxy UDP, ceux-ci sont appelés "intermédiaires" dans ce document.

Notez que, lorsque la version HTTP utilisée ne prend pas en charge le multiplexage des flux (comme HTTP/1.1), toute référence à "flux" dans ce document représente la connexion entière.

Dernière mise à jour le