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

[David Schinazi <[e-mail]>]

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
>