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

[Magnus Westerlund <[e-mail]>]

Hi,
I think you stated your view. I have stated my view. I think the best
is to progress, I just hope that there will not be an extensive
discussion against splitting the document if we get caught in a
situation where my fears are realized and we are getting feedback that
is directly related to the network to network use case and will take
some work to finish. 
Cheers
Magnus


On Tue, 2021-06-29 at 14:07 -0400, Alex Chernyakhovsky wrote:
> 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
> >