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
----------------------------------------------------------------------