Re: [Masque] comments on draft-schinazi-masque [was:Re: Splitting MASQUE Obfuscation out of MASQUE]

Maxime Piraux <maxime.piraux@uclouvain.be> Fri, 17 January 2020 10:17 UTC

Return-Path: <maxime.piraux@uclouvain.be>
X-Original-To: masque@ietfa.amsl.com
Delivered-To: masque@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960831201DB for <masque@ietfa.amsl.com>; Fri, 17 Jan 2020 02:17:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 SD2LIwMlb8jz for <masque@ietfa.amsl.com>; Fri, 17 Jan 2020 02:17:06 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00136.outbound.protection.outlook.com [40.107.0.136]) (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 7426A12084B for <masque@ietf.org>; Fri, 17 Jan 2020 02:17:05 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uw71qm3hF1zCPD40Mm8PW0Dlqc6DciRpIDVxUcvzp2Kvvfk8XFufvtml4ykOXgt6dHE4w/jjheqaLq/uHH+Lat3vIFvBRu2Dl1Gniu/PLps5CxIiShicHLxlNGzZ4Ul4KOddOjLuiSrPdz9P5oWM9n+kHwBn5sUAG4+5PYglKUkZtZIKkTy56gAPNBnBxHM5kO15aay5E8v7W7lfRduhsLx6z7q81crDRtG679iiqSJt9fTVKgIkceSBfKd013B/sXjsKrY17TtPnHEEPLST0CIYRjhmeZRHm9hubDafi1OMSeyPPS3nQ9v615eS52IhGhHjHSHUlW09y7dVtUjmmw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BHIUKKgfseqO2uFdBydVm/+Pb0o0jjBfm3AjJaqibvg=; b=ClULMKCDTyX8ur5Hc9aZ2CrDjyxid2GCValuoEmIo43SM2MgbWbtmItvAOot3G+I/DOLisFh+qBHKZK2toBsK4T88ae5U8wxO4gdj02suhuoDDSYc8RZTtgFG9xnYT7l/IHNrzy1QmS9JyLoDpwKhQc1e5t6kk5Ys0wiEyNLcavJOMHwUuuKCDRP1lBy6YqYBjFXWzPYpMz1B/nrRGI6ZRc7avFjBdmJeGMK9dSaPOaC3FQz/nI4ShWQDs7csu2W0lCT9b3A/Ju2b4a3xAs7ZSzkH2b2aPY18ApMmv+kMHWHrRw0iJhwFSR0EXTYCtgOtP32FfYsmaAB0yvJX4kS3Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uclouvain.be; dmarc=pass action=none header.from=uclouvain.be; dkim=pass header.d=uclouvain.be; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uclouvain.be; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BHIUKKgfseqO2uFdBydVm/+Pb0o0jjBfm3AjJaqibvg=; b=HA4W2uU9fW4ahriaGKgqL2+5nUvpeRGurQ2X7TqrfJIm/X9u3UuGhz/6oTsvOVTxMlacd0dYGGAV44Nk2Yydxqhj2ty+xycQvVheF3AhXPHjX+mPgfsy0EmUxo/voodT3YbKoGYov8igfh3ucl198yWnd/WYMIrjqPtd61043Gw=
Received: from DBBPR03MB5429.eurprd03.prod.outlook.com (20.179.47.84) by DBBPR03MB5397.eurprd03.prod.outlook.com (20.179.47.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Fri, 17 Jan 2020 10:17:03 +0000
Received: from DBBPR03MB5429.eurprd03.prod.outlook.com ([fe80::f0fe:4894:aaa3:1687]) by DBBPR03MB5429.eurprd03.prod.outlook.com ([fe80::f0fe:4894:aaa3:1687%5]) with mapi id 15.20.2644.023; Fri, 17 Jan 2020 10:17:03 +0000
Received: from localhost.localdomain (2001:6a8:308f:2:612c:e2ac:628e:2eff) by AM0PR0102CA0066.eurprd01.prod.exchangelabs.com (2603:10a6:208::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20 via Frontend Transport; Fri, 17 Jan 2020 10:17:02 +0000
From: Maxime Piraux <maxime.piraux@uclouvain.be>
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, David Schinazi <dschinazi.ietf@gmail.com>, "masque@ietf.org" <masque@ietf.org>
CC: Olivier Bonaventure <olivier.bonaventure@uclouvain.be>
Thread-Topic: comments on draft-schinazi-masque [was:Re: [Masque] Splitting MASQUE Obfuscation out of MASQUE]
Thread-Index: AQHVyjh4MT/aHM32KESuKte+j5q+FqfuqhKA
Date: Fri, 17 Jan 2020 10:17:02 +0000
Message-ID: <9d620f46-bd39-68bd-9b57-127c31873956@uclouvain.be>
References: <1AD99831-1AFB-482A-ADEA-24C7AE04C419@ericsson.com>
In-Reply-To: <1AD99831-1AFB-482A-ADEA-24C7AE04C419@ericsson.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: AM0PR0102CA0066.eurprd01.prod.exchangelabs.com (2603:10a6:208::43) To DBBPR03MB5429.eurprd03.prod.outlook.com (2603:10a6:10:dc::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=maxime.piraux@uclouvain.be;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2001:6a8:308f:2:612c:e2ac:628e:2eff]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 890dbbe3-ca14-44ec-5574-08d79b366557
x-ms-traffictypediagnostic: DBBPR03MB5397:|DBBPR03MB5397:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <DBBPR03MB5397DF71B858768FDC44C9CD9F310@DBBPR03MB5397.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0285201563
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(366004)(376002)(396003)(39860400002)(136003)(346002)(189003)(199004)(8676002)(81166006)(110136005)(316002)(31696002)(16526019)(186003)(36756003)(107886003)(71200400001)(6506007)(53546011)(52116002)(6486002)(4326008)(86362001)(81156014)(2616005)(69590400006)(8936002)(478600001)(966005)(66574012)(2906002)(786003)(6512007)(5660300002)(66946007)(44832011)(66476007)(64756008)(31686004)(66446008)(66556008); DIR:OUT; SFP:1102; SCL:1; SRVR:DBBPR03MB5397; H:DBBPR03MB5429.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: uclouvain.be does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pGVuYPKmY9FlItWSMBANgMPYL/oL7Tz0XNAPrREg7/W/qlmjyyEWftjUyBMDhflWyhkLGsuOffGBaiGAa+ZlwdxgTOkpPqJ4S0FfxBZ2WOax6zprRok0mikD98u5FsQQrZ2KpOGLStIIxbGUIQ6y1PJcRGgNmD7FsYvqMIvPdtY3MF46OtUFehgFxYQELTb1jcSZPdKlaBC5GCDSVdl9IirRG3VrCMGt+mMvuGTE/LYb6u+n/W9EdpiLFUfOe7t+ZRzi+bK+vbw/4tg+CwKI2IRqBikimWAGlIacZEQ6N3aT2D3r+W8V5nqA2l9Drc5U/uRmDlFA9j48/vxUy8Me5TuDajjku87/PaLo07GTDHrP0HQb4PQi/yHR1fBuGKpdCzthvO2Cc48c+PcqcYTzoNFVX6p16JozeE463xX/kakpNVAuxFazLaNkXw02XyOMrSzYzv99ez7p0L/20ZhDAw0f1HhviZxpxRujUepbgr6tlkHDOliVrjjjLjXbt/Y9Vtp83PDQnkLaHAxmoRig783i6iRF3GGtY0e8GkVk7pPK5ticEc44Z7b13Y9Lz+GyxzMkI8P+Ym/675zrSy/gzw==
Content-Type: text/plain; charset="utf-8"
Content-ID: <ED7680DA0E4BF346856B1B33EF591308@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: uclouvain.be
X-MS-Exchange-CrossTenant-Network-Message-Id: 890dbbe3-ca14-44ec-5574-08d79b366557
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2020 10:17:02.8815 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 7ab090d4-fa2e-4ecf-bc7c-4127b4d582ec
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Hp0JCei7dh+HS0zbYldsQGehpIlH6dkqK/snQGSG897D5MWaL3bPtWhbucQy1quBwKR/UqsfjXVeLsIuV2qXFWoizRcFhD53yhux7b9Fsuk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR03MB5397
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/3D57aU4nFnADFVnZJRLziiYD8dQ>
Subject: Re: [Masque] comments on draft-schinazi-masque [was:Re: Splitting MASQUE Obfuscation out of MASQUE]
X-BeenThere: masque@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiplexed Application Substrate over QUIC Encryption <masque.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/masque>, <mailto:masque-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/masque/>
List-Post: <mailto:masque@ietf.org>
List-Help: <mailto:masque-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/masque>, <mailto:masque-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2020 10:17:11 -0000

Hi all,

> 3) There is also work in draft-piraux-quic-tunnel-00 (adding authors in cc’ed in case there are not on this list) which I think is related. They also use QUIC as tunneling protocol to an immediate proxy. On each stream they first negotiate the forwarding capabilities based on a TLV-based protocol and then, after an end TLV message, switch over to the actual payload data that is supposed to be forwarded. I think this is align with the TCP converter working in tcpm,
Indeed, thanks for linking our work.

> however, given QUIC supports multiplexing I think it is actually not necessary to prepend the negotiation part on the same stream, rather than using a separate control stream for that.
We actually considered using a separate control stream for opening new 
tunneled streams, but we chose not to. While it might be simpler to 
implement, using such a stream introduces head-of-line blocking between 
the forwarding requests. One forwarding request related to a stream B 
could be blocked because the forwarding request related to stream A was 
part of a lost packet. If stream A and stream B are totally unrelated, 
this introduces blocking that could be detrimental to performances. 
Also, there is no clear benefit to be able to deliver the streams data 
before their forwarding has been negotiated.

> In any case I think both proposals are indented to support similar functionality and therefore the signaling protocols should probably be aligned. Any thoughts here?
There are of course similarities between our work, but we operate in a 
different context than the obfuscation-oriented one of MASQUE. That 
might guide some parts of the design and introduce particularities that 
are relevant to one design but may be not to the other. E.g., MASQUE 
uses HTTP/3 for obfuscation purposes, while in our case we propose a new 
application protocol.

Maxime

Le 13/01/20 à 18:39, Mirja Kuehlewind a écrit :
> Hi David,
>
> thanks for splitting the document up!
>
> I guess the last paragraph in section 4, as well as section 6 and the IANA considerations in draft-schinazi-masque-obfuscation-00 could/should have also been moved to/left in draft-schinazi-masque-02…?
>
> A couple of comments/questions on draft-schinazi-masque-02:
>
> 1) The draft say at the beginning of section 3
>
> “As soon as the server has accepted the client's MASQUE initial
>     request, it can advertise support for MASQUE Applications, which will
>     be multiplexed over this HTTP/3 connection.“
>
> I wondering what you actually mean by “multiplexed over HTTP/3”. I believe the idea here is that you would always send a HTTP connect first, however, I would assume that you then leverage multiplexing on the QUIC layer, especially when you proxy (non-http) QUIC traffic or other UDP traffic…? Can you further explain?!
>
> 2) And also regarding the proxying of QUIC/UDP traffic: As far as I understand you propose to only use QUIC datagrams for this (+ potentially one QUIC stream as control channel?)? My thinking was that you can also instruct a MASQUE server to forward all data on one QUIC stream to a specific server. Yes, this would make the MASQUE proxying reliable but e.g. in case of a high loss link between the client and the MASQUE server this could actually be beneficial. Further I understand that more work is needed on the mapping of datagram-ID to target server but just mapping a certain stream ID to a target server would also be easier. In our work at Ericsson, we assume the first stream opened to be some control stream that then can be used to indicate forwarding requests/mappings for other streams as well as any additional data that the client and MASQUE server may want to exchange at any other time during the connection life time.
>
> 3) There is also work in draft-piraux-quic-tunnel-00 (adding authors in cc’ed in case there are not on this list) which I think is related. They also use QUIC as tunneling protocol to an immediate proxy. On each stream they first negotiate the forwarding capabilities based on a TLV-based protocol and then, after an end TLV message, switch over to the actual payload data that is supposed to be forwarded. I think this is align with the TCP converter working in tcpm, however, given QUIC supports multiplexing I think it is actually not necessary to prepend the negotiation part on the same stream, rather than using a separate control stream for that. In any case I think both proposals are indented to support similar functionality and therefore the signaling protocols should probably be aligned. Any thoughts here?
>
> Mirja
>
>
>
>
>
>
> From: Masque <masque-bounces@ietf.org> on behalf of David Schinazi <dschinazi.ietf@gmail.com>
> Date: Wednesday, 8. January 2020 at 23:01
> To: MASQUE <masque@ietf.org>
> Subject: [Masque] Splitting MASQUE Obfuscation out of MASQUE
>
> Hi MASQUE enthusiasts,
>
> One piece of feedback I've gotten about MASQUE was that there is more community interest in working on the "how do we make better proxies running over QUIC?" question than on the "how can I hide a VPN behind an HTTPS server?" question.
>
> Therefore I've split out the hidden VPN use-case into its own draft, named MASQUE Obfuscation:
> https://tools.ietf.org/html/draft-schinazi-masque-obfuscation
>
> The core MASQUE draft is now more focused on laying out a generic mechanism for multiplexing applications over QUIC:
> https://tools.ietf.org/html/draft-schinazi-masque
>
> Conceptually, MASQUE Obfuscation is now just a single use-case for MASQUE among others.
>
> In terms of next steps, I'll be working on fleshing out the specific protocol bits of MASQUE, and on a draft charter to discuss the potential creation of a MASQUE working group. More details to follow.
>
> Thanks,
> David