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

[David Schinazi <[e-mail]>]

Hi Magnus,

Thank you for clarifying *what* you would prefer to see in scope.
Can you explain *why* you are advocating for those topics?
In particular, you seem to be treating the routing table as
something unique that needs to be handled differently, and I
don't understand that. Many HTTP methods involve changing
local state - if I click the Like button on a website, a database
gets updated somewhere, for example. The routing table is a
database, and it's unclear to me why it needs to be treated
differently. It seems absolutely reasonable to have text in the
security considerations section that states that servers shouldn't
let unauthenticated clients modify any server databases without
checks, but it sounds like you're suggesting that the protocol
solution document be opinionated about trust, and that would
severely limit the applicability of the protocol - various use-cases
will have different means of authenticating clients and picking
policies for what a client is allowed to do, and we cannot preclude
those.

David

On Mon, Jun 28, 2021 at 9:04 AM Magnus Westerlund <
[e-mail]> wrote:

> Hi,
>
> Sorry for the delayed response.
>
> From my perspective you can't just state that trust is out of scope. For a
> solution document I would see the need to discuss the security
> implications for
> a MASQUE endpoint between the authorization that can be derived from the
> protocol mechanisms for endpoint identity versus the MASQUE protocol
> requests
> impact on external state such as routing tables and their potential
> implications.
>
> From my perspective if the IP proxying protocol expresses information about
> routes we will end up having to discuss the purpose and security
> implications of
> those routes and the endpoints trust in what is stated.
>
> Cheers
>
> Magnus
>
> On Wed, 2021-06-09 at 18:17 -0700, David Schinazi wrote:
> > Hi Magnus,
> >
> > You're correct that this isn't currently explicit in the document. The
> > intention of the authors was to declare trust out of scope for the IP
> > proxying protocol. Similar to IP, DHCP, ESP, etc, the protocol itself
> > does not need to worry about trust as that is better handled at a policy
> > layer that lives outside of the protocol. Since the IP Proxying
> > Requirements document only applies requirements to the IP proxying
> > protocol, trust is also out of scope for the requirements document. I can
> > add a subsection to Section 5 (Non-Requirements) if you'd like.
> >
> > If we agree that trust is out of scope, then the risk for added delay is
> low.
> >
> > David
> >
> > On Tue, Jun 8, 2021 at 12:46 AM Magnus Westerlund <
> > [e-mail]> wrote:
> > > Hi,
> > >
> > > I agree that one can split later, with some additional delay. How
> > > problematic waiting with splitting is depends on what the network to
> > > network use cases is supposed to cover. I think we need to figure out
> > > what type of threat model and mutual trust the two MASQUE endpoint is
> > > expected to have in this use case.
> > >
> > > So, can we please figure this out becasue I think that will clarify if
> > > there is low risk for extra delay or significant risk for extra delay?
> > > This is a request for better clarification in the requirements document
> > > on 2.4.
> > >
> > > Cheers
> > >
> > > Magnus
> > >
> > >
> > > On Mon, 2021-06-07 at 13:07 -0700, Christopher Wood 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
>