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

[Alex Chernyakhovsky <[e-mail]>]

Hi Magnus,

Inline.

Sincerely,
-Alex


On Tue, Jun 29, 2021 at 6:02 AM Magnus Westerlund <
[e-mail]> wrote:

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


These concerns are valid, but they apply to a system implementation, not
the protocol. As we've discussed numerous times, these sorts of things can
be accomplished with IPSec, yet the IPSec RFCs do not go into the details
that you are requesting. I am not saying that we shouldn't have such
guidance, but we have no requirement that it appear in the same document
nor be published at the same time as the rest of the work we are currently
discussing. I believe we're all in agreement there --- but I don't
understand what concretely you're concerned about delaying if we are going
to be able to break things up into separate documents, if/when that becomes
necessary.


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


Again, this is a system concern, not a protocol one. A sufficiently
extensible protocol, as we are aiming to design, can handle both of these
cases regardless of what policy and considerations we end up having in
place. Our goal is to design this sufficiently extensible protocol.


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


Yes, I explicitly believe we can do so, and this is evidenced by the IPSec
RFCs. For example, RFC4301, which talks about the IPSec security
architecture, makes no mention of this.

We cannot operate without some abstractions, or else we will end up caught
up in discussions that can make no progress. It is sufficient for us to
begin implementation work and note that security considerations exist and
operators are responsible for validating these routes per their own policy.


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


Again, we have to operate at a reasonable level of abstraction. What you're
suggesting amounts to turning these documents into a massive compendium, to
which I see limited benefit.


>
>
> Cheers
>
> Magnus Westerlund
>