RE: Questions on HTTP URI schemes and QUIC

Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com> Wed, 25 July 2018 03:33 UTC

Return-Path: <sridhar.bhaskaran@huawei.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F38130F47 for <quic@ietfa.amsl.com>; Tue, 24 Jul 2018 20:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 PWXot1QGlh-L for <quic@ietfa.amsl.com>; Tue, 24 Jul 2018 20:33:44 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 88EC2130E00 for <quic@ietf.org>; Tue, 24 Jul 2018 20:33:44 -0700 (PDT)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E697B5FDEE602 for <quic@ietf.org>; Wed, 25 Jul 2018 04:33:38 +0100 (IST)
Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.399.0; Wed, 25 Jul 2018 04:33:22 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0382.000; Wed, 25 Jul 2018 09:03:10 +0530
From: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>
To: Ted Hardie <ted.ietf@gmail.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kAAIXnVMADZ7w3QAA8EpoAAIxU/UA==
Date: Wed, 25 Jul 2018 03:33:09 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com> <CA+9kkMAZqQviCshp8opYD4OBtG+SrXJ7TeXvwMzne_xDa4-_QA@mail.gmail.com>
In-Reply-To: <CA+9kkMAZqQviCshp8opYD4OBtG+SrXJ7TeXvwMzne_xDa4-_QA@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.148.60]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/zv1xEz-CnOd8M-H8-Xzze1_FSgc>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jul 2018 03:33:47 -0000

Hi Ted,

>> Before going down that road, may I ask why 3gpp prefers the bump-in-the-wire style proxy, rather than a configured proxy?  A configured proxy can act as a back-to-back user agent, which allows the kind of inspection you describe.  The  mechanism can also be set to work either on a per-network basis or globally (depending on the configuration and the topology).  Is that not a better fit for your deployment model?

[Sridhar] In 3GPP architecture, from a HTTP client perspective it believes it is invoking the API exposed by a HTTP server. If the client is configured to route the request via a proxy (configuration is at HTTP level and application is unaware of it), then what should be the ":authority" pseudo header in a HTTP/2 request (i.e the authority part of the URI)? If the authority part of the URI still refers to an FQDN / IP address of the HTTP server, then isn’t the TLS certificate exchange supposed to happen against this? On the other hand, if the authority part of the URI refers to the proxy's endpoint itself, then how does the proxy know where to route the request further? 

By the way are there any IETF drafts / RFCs that explain how this would work?

I may be missing few details here. Could you please clarify how a configured proxy acting as B2B user agent would 

a) terminate TLS by providing a valid certificate for the domain / authority with which the client is intending to communicate 
b) how the proxy will route the HTTP/2 request to the right server (and based on which information in the HTTP/2 request)?
c) Any IETF draft / RFC that explains this.

Thanks
Sridhar

From: Ted Hardie [mailto:ted.ietf@gmail.com] 
Sent: Tuesday, July 24, 2018 9:38 PM
To: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>
Cc: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; IETF QUIC WG <quic@ietf.org>
Subject: Re: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

On Mon, Jul 23, 2018 at 8:36 PM, Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com> wrote:
 
Yes this is understood. One follow up question is - can a bump in TLS (TLS interception) where a proxy provides certificates on behalf of origin host signed by its own CA (provided the client is configured to trust this CA) work with QUIC? Can this be made to work to intercept the protected payload at a proxy?

Thanks
Sridhar

Before going down that road, may I ask why 3gpp prefers the bump-in-the-wire style proxy, rather than a configured proxy?  A configured proxy can act as a back-to-back user agent, which allows the kind of inspection you describe.  The  mechanism can also be set to work either on a per-network basis or globally (depending on the configuration and the topology).  Is that not a better fit for your deployment model?

regards,

Ted