|
On 01.10.2015 19:02, Dan Williams
wrote:
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. As I see it the goals of containerized applications and MIF are not the same. Maybe there is some overlap, but in the end those are two orthogonal mechanism which might be combined if necessary, but also might not. The goal of MIF WG is to develop mechanisms that would allow network providers (and system administrators) to provision nodes with multiple configuration parameters (provisioning domains) for different purposes. This, most importantly, implies incremental changes to different network protocols. So, what we would like to do is something (either in NetworkManager itself, or in separate software component) that would manipulate namespaces based on the information received from the network and based on local policies. Of course that these changes might be done in already containerized applications. 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. Yes, this is something open for discussions. Here is one use case scenario we were thinking of: 1. When user creates new VPN connection, there is a check box with text something like " Allow restricted access for certain applications to VPN connection ". 2. After VPN is activated new namespace is created and interface belonging to VPN moved to the new namespace. 3. When user starts new Firefox process it is started something like this: pvdtool firefox -P VPN -no-remote pvdtool will provide user with a list of available connections (Ethernet, VPN) with user friendly names/descriptions and allow user to select through which connection new Firefox should communicate. If user select VPN then switch is made to separate network namespace and then Firefox process is started. Note that many things should be governed by policy and for this there should be a policy language. Anyway, what do you (and the standards) really mean by "conflicting"? Is that about address ranges, or DNS information, or proxies, or domains, or...? For example, you are at a home network where network 192.168.1.0/24 is used. Using VPN you connect to a corporate network that also uses 192.168.1.0/24. Suddenly, your home network is unreachable due to the routing conflicts. SG |
Attachment:
signature.asc
Description: OpenPGP digital signature