RE: Questions on HTTP URI schemes and QUIC

Lucas Pardue <Lucas.Pardue@bbc.co.uk> Wed, 25 July 2018 08:24 UTC

Return-Path: <Lucas.Pardue@bbc.co.uk>
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 BA492130E4A for <quic@ietfa.amsl.com>; Wed, 25 Jul 2018 01:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PZ9C2jXn-W3K for <quic@ietfa.amsl.com>; Wed, 25 Jul 2018 01:24:23 -0700 (PDT)
Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB32A130DC6 for <quic@ietf.org>; Wed, 25 Jul 2018 01:24:23 -0700 (PDT)
Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w6P8Nvl2026546; Wed, 25 Jul 2018 09:23:57 +0100 (BST)
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.0389.001; Wed, 25 Jul 2018 09:23:57 +0100
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>, Martin Thomson <martin.thomson@gmail.com>, QUIC WG <quic@ietf.org>
CC: Ted Hardie <ted.ietf@gmail.com>
Subject: RE: Questions on HTTP URI schemes and QUIC
Thread-Topic: Questions on HTTP URI schemes and QUIC
Thread-Index: AdQehQaTzEsbGZZvQ4ml64uCil/3zQAGQAMgAByo3kAAIXnVMADZ7w3QABhyo4AAF+7DgAAHNtmAAAC3vAAAA/ntzA==
Date: Wed, 25 Jul 2018 08:23:56 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB799EE@bgb01xud1012>
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> <0E42DD26875E1748992B1E3F732A36AE0129F121@BLREML503-MBX.china.huawei.com> <CABkgnnWvroAJtgOp=1=TMfJeV1Sr0rPJV_g4B6sdWO0fNyWDYg@mail.gmail.com>, <0E42DD26875E1748992B1E3F732A36AE0129F263@BLREML503-MBX.china.huawei.com>
In-Reply-To: <0E42DD26875E1748992B1E3F732A36AE0129F263@BLREML503-MBX.china.huawei.com>
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
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/tghza2PAdvj9MZSDGNrmY25AhFw>
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 08:24:26 -0000

Hi Sridhar,

What is the relationship between PLMN A and PLMN B? Is this "the public Internet" or more a collection of operator networks? If there is a coordinated handoff then, although operating in different trust domains, it seems feasible for the SEPPS to trust each other. Is that not the case?

Trust of course requires some provisioning/orchestration of services at a system level but from the client perspective,  HTTP clients at any point in the chain could believe they are in communication with the final target server.

Lucas
________________________________________
From: QUIC [quic-bounces@ietf.org] on behalf of Sridhar Bhaskaran [sridhar.bhaskaran@huawei.com]
Sent: 25 July 2018 08:20
To: Martin Thomson; QUIC WG
Cc: Ted Hardie
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Martin,

Thanks for the clarification.

>> The latter is what we call a reverse proxy or gateway.  For that to work, the "proxy" needs to hold a certificate and keys that are valid for the identified authority.  The proxy can usually only operate for a single authority for each connection (RFC 7540 covers the exceptions to this).  It can use the TLS server_name extension and HTTP Host header field to demultiplex requests for multiple names if it is authoritative for more than one.  Each name typically needs a separate connection.

[Sridhar] Reverse proxies to terminate TLS can be deployed when the proxy is in the same trust domain as the origin server since the reverse proxy can be configured to expose the API endpoint towards the clients and masks the presence of backend servers. . But in 3GPP the HTTP API call is like below

HTTP Client in Network A (PLMN A) --> SEPP of PLMN A [ Trust Boundary crossed here] --> SEPP of PLMN B --> HTTP server in Network B (PLMN B)

So here the client's transport connection (TLS or QUIC) terminates at SEPP of PLMN A which acts as forward proxy. So for a https:// scheme URI, the client has to trust the SEPP A as a certificate authority if it acts as a bump in TLS and provides a certificate on behalf of the HTTP origin server.

I think the back to back user agent type proxy may not exactly fit here due to involvement of multiple proxies (SEPP A, SEPP B).

Thanks
Sridhar