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

[Magnus Westerlund <[e-mail]>]

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 <[e-mail]>
> wrote:
> > Hi Magnus,
> > 
> > Some thoughts inline below.
> > 
> > On Mon, Jul 27, 2020 at 5:32 AM Magnus Westerlund <
> > magnus.westerlund=[e-mail]> 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  [phone]
> > > Torshamnsgatan 23           | Mobile [phone]
> > > SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> > > ----------------------------------------------------------------------
> > > 
> > > 
> > > -- 
> > > Masque mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/masque
-- 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------