Re: [Masque] Filtering function of the Masque server for traffic incoming to the client
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 28 July 2020 08:45 UTC
Return-Path: <magnus.westerlund@ericsson.com>
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 9201D3A08C6 for <masque@ietfa.amsl.com>; Tue, 28 Jul 2020 01:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.com
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 zOHJBjJoTcBc for <masque@ietfa.amsl.com>; Tue, 28 Jul 2020 01:45:20 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70050.outbound.protection.outlook.com [40.107.7.50]) (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 285F33A08C1 for <masque@ietf.org>; Tue, 28 Jul 2020 01:45:19 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N0b0QKX8fQrmJUErlzVVjDPc/BaqpoS021pyqtP6C/NJIasKAD29VyhsI+OSa+ckIuYYagk1nMoMy4SkK4F+lDOwjXRlnNUuuPwd8/9dNCxmUatm5e0gTd/rMPXNOmi5EMugKP6Nz8E7m8LL9IaFRGgs8GP7cs9u5mGgway6RdmCFOwwkcAB8b9O4H3tzX+l+GVSEREDsQy3kzX7GFA/bbg6fZNiq/huPWuI2AO1+/jA260UlVzCojIXawGsdAFs0Kb7caCQ0lmy02SG16vCYBWA+ZyND4BSRc4lS0uYzUJNwg/luWHulsQCKlIHEzyqLZ/X0I2beTQnSNT6X2GgEw==
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=NJ3JOVsAG1vx/JQdFtiv2PanTaGzaW2WvrtryBqrGHA=; b=X4uLZMvAS3Ux6eBrQZkad83QGJVyQuh5a0K41of0bvXiNhQb2b5nauihFT0aFHV7JodPXgzsRVdgmHjr+Z9eflBmD+MViI4l/Rxtq+U88YWnbNVGZCK+CKbf5sR5vM/0V4+d2ilLNUD+t4PHb+2sSYys46RgB2tvwWaDGjAtSD2qacPCrvdTMcwpQp8I96nmUNMLUT1iAMmai1Klrk31cVSPiigtiE0nfExazuv8aQTU+WNKs0x0iBgG60l5gBtVkXMJgD3FlBxaxH+/R/0j7tEb+f5yZ/8PtWwA8y81xgrKHhW1vK582jTm2Awg1F8Ys3cYaXxGg3pasudQkMwASw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NJ3JOVsAG1vx/JQdFtiv2PanTaGzaW2WvrtryBqrGHA=; b=A5hugxYXKo4J7QWjczbFjtesvOB6Fu9pRf/hEDxNZhNM5CD/zzDEqJ0Fj9MznIeTd00VXbpMlsTmH+qYPvbyx5bnwDaeOrosr7GlB0FzVtX9Lw677W5cTABthUx2gowjttWY7n/KYyB6eVcEo3/obaMqvYHz0XH1nqPdKHUNxqA=
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR07MB3338.eurprd07.prod.outlook.com (2603:10a6:7:2d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Tue, 28 Jul 2020 08:45:17 +0000
Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351%6]) with mapi id 15.20.3239.015; Tue, 28 Jul 2020 08:45:17 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "dschinazi.ietf@gmail.com" <dschinazi.ietf@gmail.com>
CC: "masque@ietf.org" <masque@ietf.org>
Thread-Topic: [Masque] Filtering function of the Masque server for traffic incoming to the client
Thread-Index: AQHWZBHvaYNmk9XMQ0e65P+3GCMwmqkbcdmAgAE8nYA=
Date: Tue, 28 Jul 2020 08:45:17 +0000
Message-ID: <a1dd9e98f3c857c1abcdcb57ffd6ec07207c7f63.camel@ericsson.com>
References: <6cc97d7064070453574c7549c2e8af3892fe023c.camel@ericsson.com> <CAPDSy+7wR_rkY2BESYFr4wU57EokkXjR7LXi_ouOp=LZOR2EyA@mail.gmail.com>
In-Reply-To: <CAPDSy+7wR_rkY2BESYFr4wU57EokkXjR7LXi_ouOp=LZOR2EyA@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [158.174.130.202]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6613fefd-1946-4ab3-3384-08d832d28dc8
x-ms-traffictypediagnostic: HE1PR07MB3338:
x-microsoft-antispam-prvs: <HE1PR07MB3338D171522E7DC0932AFC5895730@HE1PR07MB3338.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: y5GpxGC1HiCgPKyz7uWSVaOiRThJ78NjJIUYJquRU4IYovpqnn0bhCifMDgAQYyT8FgpNLtckFH8zYm6F9DugPJpTdFEd6mjwvVxMQSq5hYIifsQwPDdRTio9z2Nfni5LTgT6gtVMIDDGXnt9jxe5trYmvbKQ3th7QArtgjlz0RSYpl3o0wVw1CHFxNyUmAYaVphYodmw+hKzgmjSd8QFPe+wCFFTtuyUDREeAjLJcYmS68sB0ZMLRaLp/IZdYjgnkXn2Xzf+oK2CzpCIXSEfWaYgdFu9Xn21uecYr3BVZcvUdy0l2q7J/Dx/zt3+k+JGf1+u0D27A2Vqfr6/u336QvURqFv8GWiPfc1X7FRqzp0qexFA6o0/dahUt36RnCQKMgRJTLjQttq3Sh3BeyZCjcKSwwJ/YA0u0uB3YT0pimQ0tS9C3nP406+asmNEWBfkR41X1RDMVgrt3/4Hgm9BA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(6512007)(2616005)(66476007)(66574015)(66946007)(83380400001)(2906002)(316002)(76116006)(64756008)(66446008)(66556008)(8936002)(186003)(4326008)(966005)(26005)(71200400001)(53546011)(6506007)(6916009)(8676002)(86362001)(44832011)(36756003)(5660300002)(478600001)(6486002)(99106002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: xW8TCvPmQC8S4yUSc5z1EvhAhCX36yHpngDWWh1RMa+YJtWmWz2GTrqYfnmYk1yfS9BdqcmtZV1W0I89LaVnE/jUffwq0kmXF+E3EtirjD4M0JIHiezzaMLoGa0XkTL9eskG8YUi4KUySOjvO6qHVf/26002HJxncZFkJBrAdeVxKNkgSNj0wFqxyALYOVlNcdoXKaeFow4KnFLXPLJHZicLjUc6yUyRvjzKoLSJPLkdH9N0efE22u56leibfN4ccca9QP2SaWVD3lrN6tnUtNPdV788OXB4vx62HRvxgE2AVJ/Qpz26SXntQh9n6b6eUZ44oAfZ3Ul38Z/ghzVt4y6gYb2AgDb88cSZptjXojDIA4WTxlqwnV2wesoZPnbH71CB2IWXi/QPfNy/q78CE1Rn1ROFSPA+GKw9dcDwp0vanZqe4vWQKqrVdhy+x8sCmapxwJXHEJHQcbJ7x+68L+G84g7ktLcrP6y4RqiMsBl6O4rGqucRkkvY1jeWuseSyXJ4DOwdjDreSnv5zbGpvCzYi6ABGqKFZ8nUwb33jiJryQGVAjbS6ONG0DoKxrck2jnDS94fszDiTkmuf9Dvmp29MxrLOD1GULN5FU3OaKDntOorL+pLXpCcYzSC2toBozlFWOVp/pydZgm77mByFA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <4FCD6E2970986A42B0E32A41442353AB@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6613fefd-1946-4ab3-3384-08d832d28dc8
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 08:45:17.5074 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: fJR3tHo6X6jbopnv0KT/jouTnYoOyIkh/5Vskj2bsi39e89NYKB0E/FIXlrsjwZYPP2XmfQfPGzNLgkza/Ocs2t5+50CGNM6k39Rk/cmriE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3338
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/V-BkBnzYfSuNq6OPi1rxHUM-n1A>
Subject: Re: [Masque] Filtering function of the Masque server for traffic incoming to the client
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: Tue, 28 Jul 2020 08:45:23 -0000
On Mon, 2020-07-27 at 06:51 -0700, David Schinazi wrote: > Hi Magnus, > > Some thoughts inline below. > > On Mon, Jul 27, 2020 at 5:32 AM Magnus Westerlund < > magnus.westerlund=40ericsson.com@dmarc.ietf.org> wrote: > > Hi, > > > > A question I have to the WG is how its view are on filtering function of the > > MASQUE server for incoming traffic from remote addresses. This comes from > > the > > perspective of what is in TURN for this. TURN requires the client to > > explcitly > > indicate the remote address (IP + Port) to receive traffic. > > From the discussions we had during the chartering of MASQUE, I really think > that > we should keep TURN out of scope for MASQUE. I adds significant complexity > that is not warranted for all use-cases, and can be added on top of MASQUE > later. So, I am only using TURN's filtering as an example here as it is well defined how it works. In TURN the client borrows a specific IP+UDP port on the external side of the TURN server. However, the filtering function is that you have to specifiy what remote source address should be accepted to be received and forward to the client by the server. > > > So the question is what behavior we do expect from MASQUE for both UDP and > > for > > IP. For UDP I think only accepting traffic from the reverse 5-tuple that the > > client requested to communicate to. > > Yes, I would keep CONNECT-UDP as simple as possible, and that means that > one CONNECT-UDP request maps to a given 5-tuple on the proxy-server leg, > and all other packets are dropped. I personally are fine with that. I do have some notes on ICMP, but see below. > > > For IP I think the decision is tougher. But, I think the primary question is > > if > > one should be able to run a server as a client of the MASQUE server. If it > > does > > then any traffic to the leased IP address needs to be accepted. Thus > > questions > > about being open for any traffic and potential for attack traffic etc. > > Similarly to UDP, I don't think we need to solve all aspects of this question > within > MASQUE itself. MASQUE needs to negotiate the specifics of the IP tunnel it > creates - such as IP addresses in use by both endpoints, and authorized routes > in both directions. > > > A special case if one doesn't allow any remote source through to the client, > > is > > that some traffic that doesn't match IP 3-tuple still need forwarding. The > > best > > example I have is that a MASQUE server will need to look at the ICMP traffic > > comming in to the IP address and match the included header to existing > > context > > and forward it to the relevant client if it matches. > > Can you elaborate on your example please? Which IP addresses are used on the > ICMP packet, and on the packet that triggered the ICMP? So you can see this exemplified in my presentation slides for today: Slide 13 of https://www.ietf.org/proceedings/108/slides/slides-108-masque-transport- considerations-for-ip-and-udp-tunneling-00 So the packet generating the ICMP, for example a PTB would be from the MASQUE server to the target address, i.e. so dest: Target, source Masque server external address (IP+UDP port) borrowed to client. The ICMP message will be going to the Masque server external IP address, and hopefully inlcude enough headers to determine that the packet that generated this PTB was a packet with the source address the client borrowed. However the source address of the ICMP message is the router generating the message. This is one reason why ICMP throuhg NAT and Firewalls are working poorly due to that node have to dig into the ICMP and determine that it matches a particular existing flow and then forward it. So for a specific UDP port the MASQUE server will be required to check the ICMP message and map it to the particular client's UDP flow, and then generate an asynchronous signalling message to the client related to this UDP flow. For an IP proxying service, the whole ICMP message could in practice be forwarded to the client, but if there is a 3-tuple filtering in place it will drop it. Thus, a reason for treating ICMP different. > > I think all we need for this in MASQUE is for the endpoints to negotiate which > subnets they are offering as routable via MASQUE. All the server then needs to > do is ensure that two clients do not offer overlapping subnets. Or are you > envisioning some complexity that I'm not seeing? I interpret this to say that any source address with a destination address belonging to the subnet provided to the client will be forwarded to the client. Cheers Magnus Westerlund ---------------------------------------------------------------------- Networks, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [Masque] Filtering function of the Masque server … Magnus Westerlund
- Re: [Masque] Filtering function of the Masque ser… David Schinazi
- Re: [Masque] Filtering function of the Masque ser… Alex Chernyakhovsky
- Re: [Masque] Filtering function of the Masque ser… Magnus Westerlund
- Re: [Masque] Filtering function of the Masque ser… Magnus Westerlund
- Re: [Masque] Filtering function of the Masque ser… Alex Chernyakhovsky