Re: [Masque] WGLC for "Requirements for a MASQUE Protocol to Proxy IP Traffic"

[Magnus Westerlund <[e-mail]>]

Hi David,

On Mon, 2021-06-28 at 09:36 -0700, David Schinazi wrote:
> Hi Magnus,
> 
> Thank you for clarifying *what* you would prefer to see in scope.
> Can you explain *why* you are advocating for those topics?

So the reason I am advocating for additional care in relation to routing
information is the fact that a malicous and successful injection of a route into
a network can be used as an tool to attack third parties. You could potentially
divert traffic to perform other attacks or monitoring for survailence or
information gathering. 

And I think the main difference between the network to network VPN case compared
to the customer VPN, is that the later only forwards traffic with a destination
of the address/network the MASQUE Server lent to the MASQUE client. That makes
the threat model match the leaf node, not a transit or multihomed network which
network to network VPN easily create.  

And with that change to the threat model the mitigations and security
considerations are impacted. Which in terms is what I fear will delay the
specification additionally. Do you think you can write a specification without
bringing up the security considerations for the protocol field that carries
route prefix information? 

The requirements document is very clear in Section 3.5 that a protocol mechanism
is needed for route negotiation. That negotiation will be used to affect the
MASQUE endpoints routing state. Which in its tern requires the implementation to
consider which traffic it should accept. Yes, there is a trust question here in
regards to authenticy and identity of who makes a statement about that
authenticity in the request. But it is also a question of what threats are
inherent in this mechanism and what each endpoint needs to consider when using
this mechanism to safely use it to forwards traffic through the tunnel. 

> In particular, you seem to be treating the routing table as
> something unique that needs to be handled differently, and I
> don't understand that. Many HTTP methods involve changing
> local state - if I click the Like button on a website, a database
> gets updated somewhere, for example. The routing table is a
> database, and it's unclear to me why it needs to be treated
> differently. It seems absolutely reasonable to have text in the
> security considerations section that states that servers shouldn't
> let unauthenticated clients modify any server databases without
> checks, but it sounds like you're suggesting that the protocol
> solution document be opinionated about trust, and that would
> severely limit the applicability of the protocol - various use-cases
> will have different means of authenticating clients and picking
> policies for what a client is allowed to do, and we cannot preclude
> those.


The routing information carried in a MASQUE specific mechanism that directly
impact what traffic that MASQUE endpoint will forward and what mechanisms will
be needed to mitigate threats is the same as any HTTP application. So this is
not the same as a general HTTP using applicaiton. The HTTP using application
will have to evaluate the risks with the implemented function in that
application, just like I asking us to carefully consider the impact of the
application MASQUE. 

And when it comes to authentication mechanism I think for interoperability it
will be necessary for the MASQUE application to require something to be
mandatory to implement, even if that is the Mandatory to implement by the
targeted HTTP versions. However, MASQUE service clearly have similar
considerations to TURN servers where the failure to early on consider if one had
mechanisms that was suited to the use cases. The issue with TURN was that for
example WebRTC services wanted to provision its users with user individual
credentials where the TURN services could be a contracted thrid party service
that supported many WebRTC services concurrently.

But to conclude all I am really expecting is that the security considerations
and the mitigations in the MASQUE protocol specification consider the MASQUE
application in all its use cases listed in the requirements. 

Cheers

Magnus Westerlund