Re: [Masque] Filtering function of the Masque server for traffic incoming to the client
Alex Chernyakhovsky <achernya@google.com> Tue, 28 July 2020 10:56 UTC
Return-Path: <achernya@google.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 551133A0AFF for <masque@ietfa.amsl.com>; Tue, 28 Jul 2020 03:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.357
X-Spam-Level:
X-Spam-Status: No, score=-16.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 dWI5WX2lcQUx for <masque@ietfa.amsl.com>; Tue, 28 Jul 2020 03:56:11 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5743A0AE6 for <masque@ietf.org>; Tue, 28 Jul 2020 03:56:11 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id h1so14535965otq.12 for <masque@ietf.org>; Tue, 28 Jul 2020 03:56:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cR0Gr2RtdCQCuja2ceNhA2OaU0VmFvDF413+b64ef4s=; b=mM50zL4W8XQfU4UyBZX1JCLWdQMFP9Q3+FJPmQxkpDT5zBd0TQyaFanPFcTCTHxeJp hdAG+NXX1IqGKaaheyEDFjYIslmgARh/sUvB5xLPNtvicVuBoEUJo8zxjyQEo412p0Fg VssG+fV8U06nyocw3Q1DjuBLVPliGqzxGGBQ8oKLWYnkHnb1xIo9dUCD56T5rBp2u2kY QEOka60phJ7FwslwwfTI2J46XFarIIMtS3a60cjmzF/ngzj00FokhGtecNzVEVAPd/yU e8p5vRweo8U43DOAFCMv8+5No9NXXoQup9R6elXJMaMqJh88ueP2VV10sf2v6b0gf6mO pcNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cR0Gr2RtdCQCuja2ceNhA2OaU0VmFvDF413+b64ef4s=; b=o4bE93epXj+4R1UikiLiWTLQfHhe+phyB/mvgNr7TFNppgfeqMz1BZ32+7eEA9FmMQ QcoOXFcTGfnSbsDLHs/UfbybqOEedEeUXT7RWy3A70XszVSPnU7iJMKotAeJN1hRqFTf zm+GWRWkjJz6n03868IXhRnDJyEwdAqs0R2b7A91CWub37gWDu9dBuxrZniVfvit+bHf zwt46iPTc4ofUzqVQoOmhNYzw+32xvbB4JJY2fhGEQz3NjcNrCVH3SLbsQ7wfFAZ/EzH H6qi0c6xVISssjrJtb738/0wQmkczuONDkUsLPcEJ3VIQviFoSy56PH/BFosPvrUltT2 XhRg==
X-Gm-Message-State: AOAM532PknA+S2dtx7IB7q97hNWYV+1obNpAiEAWPEqOMRwGWxGReoPl 40HOjzcSFmaiL6UWRDm77t3qTdULEdHuIROw4UZcFHPAE8BZyA==
X-Google-Smtp-Source: ABdhPJw6xpoXG51KmZidx40f3qtZxqnlOpU6hISWNTRNJQxCShdIW2whlfKcllDFMGLUF3kgBXoNl8DE0KAbCGzjNX4=
X-Received: by 2002:a9d:4f04:: with SMTP id d4mr4968255otl.210.1595933769966; Tue, 28 Jul 2020 03:56:09 -0700 (PDT)
MIME-Version: 1.0
References: <6cc97d7064070453574c7549c2e8af3892fe023c.camel@ericsson.com> <CAPDSy+7wR_rkY2BESYFr4wU57EokkXjR7LXi_ouOp=LZOR2EyA@mail.gmail.com> <CAHbWFkQkc5Uo8stu60SmoGuEP_MNSf0kESdGdP7KmtTVSJD=tw@mail.gmail.com> <2729b0183830cdb9a4b3d226b4c46dbefff9cee1.camel@ericsson.com>
In-Reply-To: <2729b0183830cdb9a4b3d226b4c46dbefff9cee1.camel@ericsson.com>
From: Alex Chernyakhovsky <achernya@google.com>
Date: Tue, 28 Jul 2020 06:55:58 -0400
Message-ID: <CAHbWFkSqboDSoybP3PcOgaTacaL6h-XYGhFnU4ras_rH9JZrjw@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund=40ericsson.com@dmarc.ietf.org>
Cc: "dschinazi.ietf@gmail.com" <dschinazi.ietf@gmail.com>, "masque@ietf.org" <masque@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000724d8605ab7e4908"
Archived-At: <https://mailarchive.ietf.org/arch/msg/masque/mXb6_qcWOytYVTef3s-jBXbIOk0>
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 10:56:21 -0000
Hi, In draft-cms-masque-ip-proxy-reqs-00 we explicitly talk about how believe NAT should be out of scope for masque, and that can be done by a different layer. From my perspective, it's acceptable for an implementation to have a server assign out of a NAT range and use some other software package to provide the NAT (such as the linux kernel). The address filtering done by the NAT implementation and by the masque client/server become separate things. The masque stack only needs to ensure the routed IP addresses match the ranges being announced/requested. Sincerely, -Alex On Tue, Jul 28, 2020 at 5:04 AM Magnus Westerlund <magnus.westerlund= 40ericsson.com@dmarc.ietf.org> wrote: > Hi, > > I think this sounds mostly reasonable for packets destination address when > incoming to the masque server on the external address/prefix provided to > the > client. > > What really starts worrying me here is advertised routes through the Masque > Server. So you are basically saying that the MASQUE client can be an > router for > a network, and then use the MASQUE server to inject routes for that > network with > transit over the MASQUE server. Isn't this creeping the scope for the IP > proxying service way to far? I would expect a client to borrow a single > IPv4 > address or a /64 unicast IPv6 sub-net at the most. For IPv4 I would even > epxect > that people get a 10.0.0.0/24 address and then there is a NAT in front of > the > MASQUE server external address range. > > What I was really asking about what source address filtering should be > applied > to any for these incoming packets on the MASQUE server external side. > > Cheers > > Magnus > > On Mon, 2020-07-27 at 13:30 -0400, Alex Chernyakhovsky wrote: > > Hi, > > > > I'd like to add some more thoughts to the IP-specific tunnel aspects that > > David outlined. In our experience with QBONE, the important thing is to > make > > sure that the packets from both endpoints are routable. That means that > if a > > packet appears, either on the server or client, for a destination that > is not > > exposed through the tunnel, then the packet should be dropped (or > accepted by > > some other route other than the tunnel itself). > > > > Suppose that you have a case with server-assigned IP addresses to all > clients. > > The server can easily ensure that all packets destined towards the > client are > > the only ones it routes into the tunnel. For defense in depth, the client > > implementation should drop any packet that is to a destination that is > not > > exposed through the tunnel, as we should defend against a buggy/malicious > > server implementation. > > > > This gets a bit more complicated with advertised routes, since there's > not a > > single IP address (or range) to check, but nonetheless the same ideas > hold: > > both sides of the tunnel should drop packets that are not to valid > > destinations, either from the tunnel or from the outside interface. > > > > For the ICMP example, the client should have routes installed for the IP > > address that's sourcing the IP packets. The server should also know these > > routes, and be able to prevent the ICMP packet from traversing the > tunnel if > > it's not to an allowed source or destination range. > > > > If we did allow packets with IPs not advertised across the tunnel to > traverse > > the tunnel, then the response packets would go through a different path, > and > > likely be blackholed. > > > > To David's point about "[ensuring] that two clients do not offer > overlapping > > subnets": I actually think we should allow this case, for load-balancing > > across multiple client instances, particularly for the network-to-network > > (site-to-site) use case. But then the complexity becomes ensuring that > the > > overlaps are from authenticated clients permitted to do so. > > > > Sincerely, > > -Alex > > > > On Mon, Jul 27, 2020 at 9:51 AM David Schinazi <dschinazi.ietf@gmail.com > > > > 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 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. > > > > > > > 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? > > > > > > 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? > > > > > > Cheers, > > > David > > > > > > > So what are peoples opinion here? > > > > > > > > > > > > Cheers > > > > > > > > Magnus Westerlund > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > Networks, Ericsson Research > > > > > ---------------------------------------------------------------------- > > > > Ericsson AB | Phone +46 10 7148287 > <+46%2010%20714%2082%2087> > > > > Torshamnsgatan 23 | Mobile +46 73 0949079 > <+46%2073%20094%2090%2079> > > > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > -- > > > > Masque mailing list > > > > Masque@ietf.org > > > > https://www.ietf.org/mailman/listinfo/masque > -- > Cheers > > Magnus Westerlund > > > ---------------------------------------------------------------------- > Networks, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > <+46%2010%20714%2082%2087> > Torshamnsgatan 23 | Mobile +46 73 0949079 > <+46%2073%20094%2090%2079> > 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