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

[Alex Chernyakhovsky <[e-mail]>]

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]
>> <+46%2010%20714%2082%2087>
>> Torshamnsgatan 23           | Mobile [phone]
>> <+46%2073%20094%2090%2079>
>> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
>> ----------------------------------------------------------------------
>>
>>
>> --
>> Masque mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/masque
>>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>