Aller au contenu principal

RFC 9298 - Proxy UDP dans HTTP

Groupe de travail d'ingénierie Internet (IETF) D. Schinazi Demande de commentaires : 9298 Google LLC Catégorie : voie de normalisation août 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 et les personnes identifiées comme auteurs du document. Tous droits réservés.

Ce document est soumis au BCP 78 et aux dispositions juridiques de l'IETF Trust relatives aux documents de l'IETF (https://trustee.ietf.org/license-info), en vigueur à la date de publication de ce document. Veuillez lire attentivement ces textes, car ils décrivent vos droits et restrictions concernant ce document. Les composants de code extraits de ce document doivent inclure le texte de la licence BSD révisée décrit à la section 4.e des dispositions juridiques de l'IETF Trust et sont fournis sans garantie, comme indiqué dans la licence BSD révisée.

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