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

[Martin Duke <[e-mail]>]

To clarify what I meant, I'm suggesting the the future IP proxy document
can split out the network-network use case specification if that proves to
be problematic.

I am not saying we should have two requirements documents.

On Mon, Jun 7, 2021 at 12:25 PM Martin Duke <[e-mail]> wrote:

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