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

[Spencer Dawkins at IETF <[e-mail]>]

To the upthread posters - that sounds good to me.

Thanks, Martin, for helping clarify the expectations.

Best,

Spencer

On Mon, Jun 7, 2021 at 5:41 PM David Schinazi <[e-mail]>
wrote:

> That makes sense to me. The requirements document states that the
> network-to-network use-case will be optional to implement, so it won't be a
> burden. As we make progress on building the actual protocol, we'll find out
> whether the network-to-network use-case adds delays or not. If it does,
> then we'll split it off to its own document. Alternatively, I think Magnus
> has offered a great suggestion in his latest message: a separate
> architecture document. This way we can keep the protocol document shorter
> and tackle the policy/address-validation/trust/addressing questions in the
> architecture document. Either way, it does sound like we have a good path
> forward to wrap up the requirements document.
>
> David
>
> On Mon, Jun 7, 2021 at 1:07 PM Christopher Wood <[e-mail]>
> wrote:
>
>> As Martin points out, the solution for the network-to-network use case in
>> Section 2.4 can be split out into a separate document should we run into
>> timeline issues down the road.
>>
>> To that end, we'd like to reiterate that the purpose of this WGLC is to
>> determine if we can we move forward with this understanding and consensus
>> on this document in its current state, plus or minus maybe some editorial
>> cleanup. If not, what specific requirements in the document are
>> problematic, and why?
>>
>> Thanks,
>> Chris and Eric
>>
>> On Mon, Jun 7, 2021, at 12:54 PM, Alex Chernyakhovsky wrote:
>> > Hi Martin,
>> >
>> > Thanks for weighing in, and I agree with your interpretation that there
>> > is no tension between these two points.
>> >
>> > I agree that should we run into timeline issues with the implementation
>> > drafts, it is possible to split out the section 2.4 implementation into
>> > its own document. We should cross that bridge if/when we get there.
>> >
>> > Sincerely,
>> > -Alex
>> >
>> > On Mon, Jun 7, 2021 at 3:39 PM Martin Duke <[e-mail]>
>> wrote:
>> > > 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
>> > > --
>> > > Masque mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/masque
>>
>