Re: NM and IETF MIF working group



On Tue, 2015-09-22 at 12:44 +0200, Stjepan Groš wrote:
Hi Lubomir,

after some time I'm sending followup on this. I would like to flesh out
and discuss our ideas before we start implementing them to be certain
that they will be useful for NetworkManager users.

On 07.09.2015 18:10, Lubomir Rintel wrote:
Hello Stjepan,

On Mon, 2015-09-07 at 12:05 +0200, Stjepan Groš wrote:
So, it seems to me that the NetworkManager is the core component on the
client side that will have to have functionality specified by MIF
allowing node to use multiple connections in parallel (this, of course,
doesn't mean that it is the only component that will have to be
changed). But since we are at the very beginning of this, we would like
to hear thoughts from developers about this? Did anyone tried to do
this? Give any thought to this and come out with a possible solution, or
problems?
We do essentially deal with this to some extent by setting metrics to
the routes we set up. We assign priorities to different device types so
that e.g. Wired Ethernet is preferred over Wi-Fi or Mobile Broadband.
We do also remember order in which routes were added so that newly
activated connections on multi-homed hosts don't "steal" the existing
connections.

That said, I haven't really had a look (maybe someone else from the
team had?) at the documents you're created and discussed so far so my
understanding of the problem scope might be limited.


First, our task is to implement MIF on Linux/Fedora and we didn't
participate in the standardization process, at least not until now.
Anyway, I suppose that the best document to read is RFC6418 which
summarizes problems associated with multiple interfaces and/or
connections that MIF WG tries to address. RFC7556 defines solution
architecture and also discusses some issues. So, I'll continue from that
point on and use the terminology introduced by the given RFCs.

What we in my group were discussing in the past two weeks was how to
approach the problem of multiple, sometimes conflicting, connections on
a single node. In the end we concluded to approach this using network
name spaces which would be controlled by Network Manger. In other words,
whenever NetworkManager receives new PvD (think of PvD as a coherent set
of network configuration data) it assigns this data to the root network
name space but also creates a new network name space in which the given
configuration data is the only network configuration.

To run a new process (e.g. Firefox) that uses the particular connection
(for example VPN) it is enough to use nsenter(1) command in CLI. For
GUI, at the moment, we don't know what is the best way/the most user
friendly to allow users to run applications in certain name spaces, so
this is open to discussions.

Few things are also necessary. First, of course, is the way for
NetworkManager to discover PvDs (explicit and implicit). The second is
that not always it is necessary to create new name space. Sometimes
conflicts between different network configuration can be resolved in a
single namespace. To solve that problem we would define language and
engine that would allow control of NMs behavior when applying network
configuration data. For example, at the present moment interface
priorities are hardcoded, i.e. if there are WiFi and wired connection,
default route from wired connection is used. This policy language would
allow this to be specified independently from the code of NM and thus be
made much more flexible for different use cases.

What do you think about it? Do you have any suggestions or alternative
approaches?

It sounds like there's a ton of overlap with containerized applications
which do just about the same thing.  At least, they need all the same
network setup infrastructure.  If you're going to the trouble of putting
Firefox into a different network namespace, you might as well go to the
trouble of containerizing it for some small additional security and
sandboxing.

Second the user interaction model really needs to be discussed here,
unless there's something I haven't read that addresses it.  The
technical details are easy to understand, but how that translates to
what apps get launched in what PvD and whether PvDs get used at all
(even if the network advertises them), and how segmentation occurs in a
way that's understandable or even usable to the person at the machine.

Anyway, what do you (and the standards) really mean by "conflicting"?
Is that about address ranges, or DNS information, or proxies, or
domains, or...?

Dan



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]