On 01/26/2017 05:44 PM, Achtzehn Andreas (CM/ENA4) wrote:
Sorry for not getting back earlier. Comments are inline.
No worries :)
On Sun Jan 22 11:47:43 PST 2017 Daniel Wagner wrote:
> On 01/16/2017 02:00 PM, Nakamura, Yusuke (ADITJ/SWG) wrote:
>> We would like to propose two extensions to the session API interface of
>> ConnMan. The first extension enables a service differentiation for
>> processes run by the same user.It allows ConnMan to differentiate
>> between bearer usage permissions and the respective priorities based on
>> the requested service type.
> That should also be possible with the current code. You might need to
> write your own session plugin for this though. It is quite hard to
> support all types of application/user identification out of the box
> because it depends heavily on the system integrator's choices.
> When we were discussing the initial API design, the exact same proposal
> for application identification was on the table. Marcel convinced me
> that this is a rather bad idea. Mainly because you need to trust the
> application to provide the correct ID. There is nothing which stops any
> random application to set the magic ID to get full connectivity.
We principally would not trust the provided service information
The idea is to have the authentication of the application still
implemented through UID/GID/LSM, but allow the application to select
from different operational contexts. To elaborate on the example of the
web browser, the browser would know that it's now acting as facebook
client and would inform ConnMan so in session establishment phase or
through a Change call. Then, ConnMan may apply a different list of
AllowedBearers (the selection and/or priority ordering may change) and
connect the application to a different bearer. Naturally, the service
tag will not be a security feature as the application may freely select
from the defined service scopes. Nevertheless, it would ease bearer
management for our application case (relieving the application from
manually changing the AllowedBearer list).
So the problem is that the application such as a web browser expects
different configuration depending on the web site is serves. Now I
remember those use cases :)
If I understood you correctly, your problem is that you create several
sessions but you don't know which does what? And the ID would tell
ConnMan to apply the right configuration.
The modification would require an optional setting
which we would require to adjust also the session.c.
> I do not really follow the argumentation on the numbers of IP addresses
> and bearers. Are you trying to match several 'virtual machines' with one
> session? A Session is thought to be only used by one entity, until now
> that would a single application.
The different IP addresses would allow us to have several concurrent
service paths from a single entitity, similar to Lukasz patch for a
local application that would then use, e.g., bind-before-connect. The
reason for having different IPs is exactly about the concurrency issue
that we foresee when a single user has multiple paths open at the same
time (different apps, etc.).
One more subtle difference is that our source IP extension would act
on the forwarding behavior of the host running ConnMan. In Lukasz patch
the rule is applied to a netfilter chain that is acting on local
processes instead. Our proposal may therefore be used for implementing,
e.g., a webservice on a router running ConnMan which would enable
forwarding after authentication (just one example). This also changes
the meaning of "source IP" in our case. For Lukasz patch the source IP
apparently matches a local interface on the host running ConnMan, while
for us it's (as Lukasz I think pointed out already) an arbitrary source IP.
Thanks for the detailed explanation. This really helps understanding
what you are trying to solve. ConnMan so far ignored all non local use
cases. The Session API was also designed in this way. I haven't really
thought it through it yet so I can't really say something useful at this
point. Let me think a bit on this.
I am sorry not to give you a proper answer, it's getting a bit late :)