Subject: [Masque] Filtering function of the Masque server for traffic incoming to the client

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jul 2020 12:32:04 +0000

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. 

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. 

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. 

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. 

So what are peoples opinion here?

Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: David Schinazi <[email-masked]>
Date: Mon, 27 Jul 2020 06:51:15 -0700

Hi Magnus,

Some thoughts inline below.

>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

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

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

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

> --
> Masque mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/masque
>

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Mon, 27 Jul 2020 13:30:11 -0400

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 <[email-masked]>
wrote:

> From the discussions we had during the chartering of MASQUE, I really
> think that
> subnets they are offering as routable via MASQUE. All the server then
> needs to
>> <+46%2010%20714%2082%2087>
>> <+46%2073%20094%2090%2079>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Jul 2020 08:45:17 +0000

On Mon, 2020-07-27 at 06:51 -0700, David Schinazi wrote:
> On Mon, Jul 27, 2020 at 5:32 AM Magnus Westerlund <
> magnus.westerlund=[email-masked]> wrote:
> > Hi,
> > 

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. 

> and all other packets are dropped.

I personally are fine with that. I do have some notes on ICMP, but see below. 

> Similarly to UDP, I don't think we need to solve all aspects of this question
> within
> creates - such as IP addresses in use by both endpoints, and authorized routes
> in both directions.
> 

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Jul 2020 09:04:42 +0000

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

Magnus Westerlund

---

From: Alex Chernyakhovsky <[email-masked]>
Date: Tue, 28 Jul 2020 06:55:58 -0400

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=
[email-masked]> wrote:

> make
> clients.
> traverse
> overlapping
> > On Mon, Jul 27, 2020 at 9:51 AM David Schinazi <[email-masked]
> >
> > wrote:
> > > Hi Magnus,
> > >
> > > > 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
> think
> > > > IP. For UDP I think only accepting traffic from the reverse 5-tuple
> that
> > > > the
> > > > one should be able to run a server as a client of the MASQUE server.
> If it
> > > > does
> > > > that some traffic that doesn't match IP 3-tuple still need
> forwarding. The
> > > > best
> > > > comming in to the IP address and match the included header to
> existing
> > > > context
> needs