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