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

[Martin Duke <[e-mail]>]

I'd like to step in here as AD and make sure we are not talking past each
other here. IIUC:

(1) Magnus and Mirja do not want to implement 2.4.
(2) The authors want to make sure the design is extensible to support 2.4,
but are OK with some endpoints not supporting it.

It does not appear that there is tension between these points. However, I
understand that Magnus is concerned that 2.4 will hold up the core proxy-ip
draft unnecessarily.

As AD, if we come to that point, I see no requirement in the charter that
this be one or two documents; if the option is holding everything up, it
can go to the IESG while 2.4 has further refinement in the WG. I don't see
that we have to make this decision now.

Regarding the document at hand, the existing Sec 2 offers the possibility
that all of the use cases are optional. It does not preclude the path that
appears to have consensus.

Is that consistent with others' understanding?

Martin

On Mon, Jun 7, 2021 at 5:06 AM Spencer Dawkins at IETF <
[e-mail]> wrote:

>
>
> On Mon, Jun 7, 2021, 03:15 Magnus Westerlund <magnus.westerlund=
> [e-mail]> wrote:
>
>> 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.
>>
>
> I don't know if this would have helped, but I do wish we could tell
> (explicitly, in the requirements draft) which requirements arose from
> various use cases.
>
> I'm pretty sure that most participants think they know that (likely), but
> also think that other participants have the same understanding (perhaps
> less likely). I think that's what Magnus is saying here, if I'm reading the
> thread correctly.
>
> Do The Right Thing, of course.
>
> Best,
>
> Spencer
>
> 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
>>
>> --
>> Masque mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/masque
>>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>