RE: Questions on HTTP URI schemes and QUIC

Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com> Tue, 24 July 2018 03:37 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 0567E130FCE for <quic@ietfa.amsl.com>; Mon, 23 Jul 2018 20:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 ZBkmHvda_fdq for <quic@ietfa.amsl.com>; Mon, 23 Jul 2018 20:37:02 -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 C9D4C130DFE for <quic@ietf.org>; Mon, 23 Jul 2018 20:37:01 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 53754BFD5272C for <quic@ietf.org>; Tue, 24 Jul 2018 04:36:58 +0100 (IST)
Received: from BLREML405-HUB.china.huawei.com (10.20.4.41) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 24 Jul 2018 04:36:59 +0100
Received: from BLREML503-MBX.china.huawei.com ([169.254.9.4]) by BLREML405-HUB.china.huawei.com ([10.20.4.41]) with mapi id 14.03.0382.000; Tue, 24 Jul 2018 09:06:50 +0530
From: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, 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/3zQAGQAMgAByo3kAAIXnVMADZ7w3Q
Date: Tue, 24 Jul 2018 03:36:50 +0000
Message-ID: <0E42DD26875E1748992B1E3F732A36AE0129E9E9@BLREML503-MBX.china.huawei.com>
References: <0E42DD26875E1748992B1E3F732A36AE0129BCBA@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB77BFA@bgb01xud1012> <0E42DD26875E1748992B1E3F732A36AE0129C45B@BLREML503-MBX.china.huawei.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB786A5@bgb01xud1012>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.148.205]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/EYvl43JLvVsKYjCuiStiO1W8fu8>
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: Tue, 24 Jul 2018 03:37:04 -0000

Hi Lucas,

>> Are the required transformations shareable (or captured in some 3GPP document). We are aware of a congestion control use case but additional ones are welcome.

The draft change requests are currently being discussed between 3GPP SA3 and CT4. You will see the updated specs once this is agreed - after September. The latest draft CR is available @ http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_91Bis_LaJolla/Docs/S3-181937.zip. Note that this draft CR is for 3GPP release 15 where the transport is TCP/TLS. My questions below are for the study item in 3GPP release 16 where we are exploring if QUIC can be used as an alternate transport.

>> However, considering the model I have for tunnelling QUIC, the amount of in-the-loop processing possible is likely to be minimal due to the end-to-end QUIC security context. The proxy will have access to IP, UDP and QUIC headers but not QUIC protected payload.

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
-----Original Message-----
From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] 
Sent: Friday, July 20, 2018 1:06 AM
To: Sridhar Bhaskaran <sridhar.bhaskaran@huawei.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: Questions on HTTP URI schemes and QUIC

Hi Sridhar,

Thanks for sharing the 3GPP work.

Sridhar wrote:

>Note that this SEPP is not a blind forwarding proxy. It does message 
>transformations based on operator policies. So as highlighted in slide 
>8 SEPP's role is "in the loop".

Are the required transformations shareable (or captured in some 3GPP document). We are aware of a congestion control use case but additional ones are welcome.

However, considering the model I have for tunnelling QUIC, the amount of in-the-loop processing possible is likely to be minimal due to the end-to-end QUIC security context. The proxy will have access to IP, UDP and QUIC headers but not QUIC protected payload.

Kind regards
Lucas