RE: Interest in a UDP equivalent to the CONNECT method

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Sun, 04 February 2018 14:40 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 077A6127077 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 4 Feb 2018 06:40:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 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] 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 lQ2KsEnDCB6G for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 4 Feb 2018 06:40:40 -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 E523112700F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 4 Feb 2018 06:40:37 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1eiLQ9-00039h-SM for ietf-http-wg-dist@listhub.w3.org; Sun, 04 Feb 2018 14:37:29 +0000
Resent-Date: Sun, 04 Feb 2018 14:37:29 +0000
Resent-Message-Id: <E1eiLQ9-00039h-SM@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) 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 1eiLPs-0002wC-Dq for ietf-http-wg@listhub.w3.org; Sun, 04 Feb 2018 14:37:12 +0000
Received: from mailout1.cwwtf.bbc.co.uk ([132.185.160.180]) by mimas.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <Lucas.Pardue@bbc.co.uk>) id 1eiLPq-0005Tb-V6 for ietf-http-wg@w3.org; Sun, 04 Feb 2018 14:37:12 +0000
Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w14Eamlq002351; Sun, 4 Feb 2018 14:36:48 GMT
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1008.national.core.bbc.co.uk ([10.161.14.22]) with mapi id 14.03.0361.001; Sun, 4 Feb 2018 14:36:48 +0000
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>, 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/9QAF1AmAAC3F4sA=
Date: Sun, 04 Feb 2018 14:36:47 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BACAEAB@bgb01xud1012>
References: <7CF7F94CB496BF4FAB1676F375F9666A3BACADD6@bgb01xud1012> <621FA945-105E-4E1A-8A07-48741C4A9AE0@ericsson.com>
In-Reply-To: <621FA945-105E-4E1A-8A07-48741C4A9AE0@ericsson.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.212]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23642.000
x-tm-as-result: No--11.853700-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BACAEABbgb01xud1012_"
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: mimas.w3.org 1eiLPq-0005Tb-V6 d03ee7035bebbd6c448b434d9219c1fc
X-Original-To: ietf-http-wg@w3.org
Subject: RE: Interest in a UDP equivalent to the CONNECT method
Archived-At: <https://www.w3.org/mid/7CF7F94CB496BF4FAB1676F375F9666A3BACAEAB@bgb01xud1012>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/35079
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 Göran,

The intent is to emulate the behavior of CONNECT as far as possible, just with UDP as the transport for the remote side.

To this end, the scenario would allow a chain. From RFC 7231 section 4.2.6:

   The recipient proxy can establish a tunnel either by directly
   connecting to the request-target or, if configured to use another
   proxy, by forwarding the CONNECT request to the next inbound proxy.

Regards
Lucas

From: Göran Eriksson AP [mailto:goran.ap.eriksson@ericsson.com]
Sent: 03 February 2018 15:42
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; HTTP Working Group <ietf-http-wg@w3.org>
Cc: bemasc@google.com
Subject: Re: Interest in a UDP equivalent to the CONNECT method


On 2018-02-03, 15:31, "Lucas Pardue" <Lucas.Pardue@bbc.co.uk<mailto:Lucas.Pardue@bbc.co.uk>> wrote:

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.

Just to make sure I get it right; the intent is to support the case of a  L4 proxy (L4 after connection being established) with UDP (QUIC) on the remote side, as seen from the client.

If so, +1.

Does your scenario assume only one proxy between the client and the remote host or is the case of a set of proxies in a chain included?

Best Regards
Göran