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

[Magnus Westerlund <[e-mail]>]

Hi David and WG,

Let me attempt to clarify a bit why I have made the comments I have made. I think they do stem from interepreting the network to network use cases as a very general technology and from the perspective of deploying this with clients which the server has limited trust in. I realize that you are likely comming from another perspective that you only intended to use this in cases where you have fairly high mutual trust in the client and the server. I think that is actually the major difference here and why you below think I am making a circular arguments. I think it all stem from lack of discussion of this use cases and what operational limitations we intended to have on the protocol.

So if the goal here is to have high mutual trust between client and server then I think a protocol solution may be able to be defined with such an applicability statement and less mandate on necessary protocol mechanisms to protect against malicous peers. I think that is in stark contrast against some of the other use cases where the trust in the client could be rather minimal. Like the client and server relationship is only this is a paying customer that gets a VPN access and the server has no idea what type of client or implementation that are the peer. This basic use cases will deploy with an addressing architecture that makes it much less vulnerable to malicous intent on the routing level.

So, can we please discuss what assumption we have on the client and server trust?

I also think your attempt to sweep the addressing schemes to be used by the servers under the rug and not disucss them have hurt the understanding. I at least have been guessing on possible deployment scenarios rather than that we have openly discussed them in the WG. Yes, they maybe not need to be detailed in the protocol solution or an arhcitecture document, however they would have made sense to have some addressing deployment scenarios in this requirement documents use case section to make clear what would have been intended. Because they do influence what is needed for the solution.

Cheers

Magnus