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

[Christopher Wood <[e-mail]>]

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