Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 4 Sep 2019 21:25:25 +0200
From:   =?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek 
        <michal.lowas-rzechonek@silvair.com>
To:     linux-bluetooth@vger.kernel.org
Cc:     Brian Gix <brian.gix@intel.com>,
        Inga Stotland <inga.stotland@intel.com>,
        Szymon =?utf-8?Q?S=C5=82upik?= <simon@silvair.com>
Subject: Re: mesh: org.bluez.mesh.Element.MessageReceived method does not
 provide destination address
Message-ID: <20190904192525.2dqyihabxmigb54m@kynes>
Mail-Followup-To: linux-bluetooth@vger.kernel.org,
        Brian Gix <brian.gix@intel.com>,
        Inga Stotland <inga.stotland@intel.com>,
        Szymon =?utf-8?Q?S=C5=82upik?= <simon@silvair.com>
References: <20190830184301.zd3zaqrw7mv6r252@kynes>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20190830184301.zd3zaqrw7mv6r252@kynes>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hello,

On 08/30, Michał Lowas-Rzechonek wrote:
> When trying to use subscriptions in meshd, I've noticed that
> MessageReceived API does not provide the application with destination
> address of the deceived message - instead, it only sends a boolean flag
> saying if the message was part of a model subscription, or not.
> 
> I think this is problematic. There are use cases where a model is
> interested in the destination address of a group subscription. For
> example:

Alright, so it seems that is not as straightforward as I would like it
to be...

First of all, it seems that the specification doesn't *strictly* require
the model to know the value of the destination address of received
messages. The only passage that somewhat relates to that is in Mesh
Models spec v1.0.1, 3.3.2.2.3 "Receiving Generic Delta Set", but at the
moment we think that the requirement about aborting transacations
specified there can be satisfied without knowing the numeric value of a
destination address.

Other things have been neatly summarized by Brian, so I'm gonna respond
as usual.

On 09/04, Gix, Brian wrote:
> Well, what we are trying to balance here is:
>
> 1. Keeping the APIs as simple as possible

Yes, but not simpler...

> 2. Not exposing any information that we don't absolutely need to

And this is the thing I simply don't agree with. Security in mesh is
based on *keys*, not *APIs*.

We discussed access to the keyring before and I kind of agree that
applications don't really need access to key values, as long as various
Import*() methods exist. So keys are covered.

But hiding anything else does not make any sense. Certainly, it doesn't
"increase security" by any means. There is no reason why a model should
not have access to pretty much the whole payload (once it passes all the
layers, subscriptions and bindings are verified etc)., a complete
network layer included.

My primary argument is this: BT mesh is a relatively young standard and
apart from what's in Mesh Models spec we don't see many applications in
the wild. Who knows what the people are going to do with it? One of the
reasons we would like BT mesh to be available as free software is to
enable various people to play with it and invent new, interesting
applications (ideally, they would make it back to SIG and be adopted as
official specification, but that's another story).

In my opinion, keeping that power away from users, because there is no
"official" spec that uses certain information, is harmful.

> 3. Enabling valid use cases.
>
> We also are trying to stay true to the *spirit* of the specifications,
> and so I get a little uncomfortable with arguments like "The spec
> doesn't explicitely disallow it, so we need to support it".

And who gets to decide which use cases are "valid" and "true to the
spirit"?

The two examples I provided are *not* violating the spec in any way.
For the record:
 - a combined server/client sitting on element 1 that receives onoff
   messages and, depending on the destination address, sends a different
   onoff messages to a "regular" onoff server sitting on element 0,
   allowing efficient control over switching scenes involving large
   number of nodes
 - a model that acts as a IPv6 gateway and directly maps virtual
   addresses to IPv6 addresses of nodes living on the other side of the
   gateway

> That said, in this case we are proposing substituting a boolean
> argument (called "subscription", but really just a differentiator
> between a message received as a Unicast message vs a Group or Virtual
> address) with the actual destrination address. If this was as simple
> as a parameter swap, I would say "Go for it", but because of Virtual
> Addresses, it means substituting *two* methods for the one.  Then to
> continue down the rabbit hole, every *App* needs to support both
> methods which increases their complexity as well.

Well, if the application is not using virtual addresses then it doesn't
need to implement the method.

> I remember having this conversation just between Inga and myself when
> designing the interface, which is why we went for the Boolean
> argument...  to keep the API simpler in both the Applications and in
> the Daemon.  But if we are *absolutely sure* that there are valid Use
> Cases that *require* the knowledge of *which* subscription a message
> was received with, then we may have no choice.
>
> Some of the use-cases suggested I believe are invalid...  Multiple
> models on the same element are not allowed to execute the same
> opcode... or at least not ones that change a local state.

Could you elaborate? The two examples above don't require executing the
same opcode on different models.

The first one (in a slightly different form, but the idea is the same)
is already deployed in a production environment.

> This is Inga's area of expertice (both on the App side and the Daemon
> side) so I am inclined to trust her judgement.  But I would *really*
> like to avoid adding yet another MessageRecieved method if possibled.

We could make the address a D-Bus variant. I proposed two methods,
because I find variants somewhat cumbersome, but I have no strong
opinion about that.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND