Interest in a UDP equivalent to the CONNECT method

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Sat, 03 February 2018 14:31 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0417712D82C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 3 Feb 2018 06:31:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff1oCL3d5tdW for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 3 Feb 2018 06:31:14 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443C4129BBF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 3 Feb 2018 06:31:12 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ehynb-0004qW-Ic for ietf-http-wg-dist@listhub.w3.org; Sat, 03 Feb 2018 14:28:11 +0000
Resent-Date: Sat, 03 Feb 2018 14:28:11 +0000
Resent-Message-Id: <E1ehynb-0004qW-Ic@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <Lucas.Pardue@bbc.co.uk>) id 1ehynR-0004nr-1v for ietf-http-wg@listhub.w3.org; Sat, 03 Feb 2018 14:28:01 +0000
Received: from mailout0.telhc.bbc.co.uk ([132.185.161.179]) by titan.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <Lucas.Pardue@bbc.co.uk>) id 1ehynO-0007WD-D9 for ietf-http-wg@w3.org; Sat, 03 Feb 2018 14:28:00 +0000
Received: from BGB01XI1009.national.core.bbc.co.uk (bgb01xi1009.national.core.bbc.co.uk [10.161.14.23]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w13ERaC9003129; Sat, 3 Feb 2018 14:27:36 GMT
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1009.national.core.bbc.co.uk ([10.161.14.23]) with mapi id 14.03.0361.001; Sat, 3 Feb 2018 14:27:35 +0000
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: HTTP Working Group <ietf-http-wg@w3.org>
CC: "bemasc@google.com" <bemasc@google.com>
Thread-Topic: Interest in a UDP equivalent to the CONNECT method
Thread-Index: AdOc9p/RJM+VVNUGQX2RQg/+Gk9/9Q==
Date: Sat, 3 Feb 2018 14:27:35 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BACADD6@bgb01xud1012>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.213]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23640.000
x-tm-as-result: No--11.899500-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BACADD6bgb01xud1012_"
MIME-Version: 1.0
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=0.308, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, W3C_NW=0.5
X-W3C-Scan-Sig: titan.w3.org 1ehynO-0007WD-D9 d4973f2292e3e777e2c15776cde08460
X-Original-To: ietf-http-wg@w3.org
Subject: Interest in a UDP equivalent to the CONNECT method
Archived-At: <https://www.w3.org/mid/7CF7F94CB496BF4FAB1676F375F9666A3BACADD6@bgb01xud1012>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/35075
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi,

I'm wondering if there is interest from the WG in the following space before investing any more technical effort.

It recently struck me that there might be a use in iterating upon the CONNECT method, in order to support a world of UDP servers that support HTTP/QUIC. That spec neatly summarises the current state of play:


   In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a
   tunnel to a remote host.  In HTTP/2, the CONNECT method is used to
   establish a tunnel over a single HTTP/2 stream to a remote host for
   similar purposes.

   A CONNECT request in HTTP/QUIC functions in the same manner as in
   HTTP/2.  The request MUST be formatted as described in [RFC7540],
   Section 8.3<https://tools.ietf.org/html/rfc7540#section-8.3>.3>.  A CONNECT request that does not conform to these
   restrictions is malformed.  The request stream MUST NOT be half-
   closed at the end of the request.

   A proxy that supports CONNECT establishes a TCP connection
   ([RFC0793<https://tools.ietf.org/html/rfc0793>]) to the server identified in the ":authority" pseudo-
   header field.  Once this connection is successfully established, the
   proxy sends a HEADERS frame containing a 2xx series status code to
   the client, as defined in [RFC7231], Section 4.3.6<https://tools.ietf.org/html/rfc7231#section-4.3.6>.6>.

The sad part here is that an HTTP/QUIC client that uses an HTTP/QUIC proxy in this mode needs to support TCP for secure connection to the remote host. This presents some resistance to moving away from TCP in the future.

I wondered if something better could exist, and Ben Schwartz and I batted some ideas around. The strongest one was the idea of a new method (e.g. UDPBIND) that would allow a client to indicate to the proxy that it wished to communicate with the remote host using UDP. Depending on the protocol being used for client-to-proxy communication some options present themselves (NB: the data exchanged is the serialization of TLS handshake and protected packet format):


  *   HTTP/QUIC
     *   DATA frames sent by client (UDP) are transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (UDP).
  *   HTTP/2
     *   DATA frames sent by client (TCP) are transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is packaged into DATA frames, which are then transmitted to the client (TCP).
  *   HTTP/1.1 ?
     *   data sent by the client (TCP) is transmitted by the proxy to the remote host UDP port (UDP).
     *   data received by the proxy (UDP) is transmitted to the client (TCP).

The conversion between TCP and UDP should be treated carefully, payloads may be segmented unexpectedly.

The handling of UDP "closure" is a problem area that needs more thought.

Kind regards
Lucas