OpenSolaris

  subsites   code review   repo   packages   bugs   defect   polls   planet
You are not signed in. Sign in or register.

Network Auto-Magic Requirements

Network Profiles [NP for short] are a way to simplify network configuration management, by allowing the user to specify various properties which determine how things work in different circumstances. (See the story boards for how we envision the user experience.) The properties include:
  • which network interface(s) to use
  • how to obtain IP address(es) for the interface(s) in use
  • which naming service(s) to use
  • a host name (and any required variations thereof)
  • routing information
  • a set of IP filter rules
  • smf(5) services
  • Others? [8]
The following are the requirements and non-requirements for the different phases of this project.

Phase 1 Requirements

1. The solution must support multiple configuration actions when a network is encountered [1]:
  1. Fully automatic based on characteristics of each network [9].
  2. Fully automatic when the network is remembered, but the user is prompted when the network is unknown [10].
  3. Always prompted.
  4. Fully manual, forcing the user to direct actions explicitly.
The suggested default is (b). Depending on which of these is in effect, certain sub-options may be applicable:
  • Upon encountering a new wireless network, the user must be notified and given the choice to associate or not.
  • The user must be allowed to associate with a network whose id is not broadcast.
  • The user must have the ability to start or stop a tunnel manually. The user's configured tunnels must be shutdown when the machine is shutdown, as part of an overall system requirement of stability at restart.
Then regardless of which of the above options is in effect, the solution must support a user-supplied "hook" program which allows the user to specify arbitrary actions to be triggered by these events.
2. The solution must have memory. [2]
3. The solution must be layerable. [3]
4. The solution must support import/export functionality, so the profiles on one machine can be exported in a form which can be imported on a different machine for cloning and/or migration. Do we understand sufficiently well how this will interact with other (non-network) profile mechanisms?
5. User Interface
  1. The solution must support a CLI and a GUI [4].
  2. Part of the UI must support the ability to query the user when applicable (e.g., when an X server is running); otherwise, a message must be logged instructing the user how to proceed.
6. The solution must support a mechanism for the kernel portion of DNA to notify the action logic (which will probably be in userland).
7. The solution's default action in all situations must be valid and legal. E.g., the system must not connect to an open WLAN without either explicit direction or an explicit OK from the user, as doing so without authorization is against the law in some places.
8. The solution must support different ranking criteria for selecting networks when two or more are available. At minimum, these criteria must include:
  • wired vs. wireless
  • historic frequency of use
For WLANs in particular, further criteria must include:
  • signal strength
  • security rating
Are there more criteria which need to be listed?
9. The solution must support verification [11]:
  1. Asynchronous/manual, where the user asks the system to verify that everything is configured as specified.
  2. Synchronous/automatic, where the system sanity checks the configuration e.g. to make sure name servers are reachable from the current sub-net, etc.
10. The solution must provide reasonable and complete defaults for as many events as possible: minimize the questions at the time of taking some action, but provide a way to change the outcome of that action.
11. The solution must support the decoupling of the profile used to install a system from its "working" profile. [5]
12. The solution must be backward compatible in the sense that it detects old manual configuration and converts it to whatever new repository is used.
13. The solution must support a post-configuration service-discovery phase. [6]
14. The solution must support simple, easy-to-use mechanisms for both:
  1. changing the system state & profiles
  2. querying the system state & profiles
15. XXX Are we doing enough to separate mechanism and policy? If not, we need such a requirement, or perhaps we need to be more explicit in the existing requirements.
16. The solution must be scalable such that e.g. the post-solution effort required to configure a large server like Jurassic be the same or less than the pre-solution effort. [7]
17. For security reasons, bridging networks must be not permitted by default. Are there other security issues which we have not yet considered?
18. The solution must fix the long-standing problem of serially testing each available interface.

Footnotes / Discussion

1. There are three basic modes:
  • Automatic: the system is proactive; the user does nothing (1a).
  • Manual: the system is reactive; the user is active (1d).
  • Mixed: the system is proactive but prompts the user; the user is passive (i.e., answers prompts but does nothing active). (1b & 1c are both variants of this).
2. I.e., the ability to keep track of network "locations" (including WLAN APs) and apply previously used preferences in the event that an old location is encountered again. This includes such things as WEP keys.
3. E.g., profile 1 (which specifies a wide array of settings) gets activated when a laptop is booted, then profile 2 (which only specifies a few settings) gets activated when the user punches in, resulting in the settings from profile 2 being activated in preference to those in profile 1, but other non-conflicting settings to be inherited from profile 1. Furthermore, when a transition between the two occurs (i.e., at punch-in or punch-out in the example), the configuration attributes common to both profiles must not be reset.
4. There was some debate about whether a GUI is required for phase 1, or only for phase 2. Initially consensus seemed to be phase 2, but then it was suggested that the lack of a GUI in phase 1 would mean that our primary users would not be adequately covered. We eventually decided that this concern was merited, and thus a GUI became a phase 1 requirement.
5. I.e. if installing Red Hat, the user is asked for the network awareness information up-front, and at the end, it gives a choice to just apply the same information to the installed bits or enter completely different ones. Solaris assumes where a system is installed is where it will be used. Improve on Red Hat though: don't discard the installation information, but save it as an "initial installation network profile" or something. Then at initial boot, the user would be prompted whether to select the "initial installation profile" or specify a new profile.
6. This is for the Bonjour component of this project. (link forthcoming)
7. Large not in terms of number of processors or anything like that, but rather in terms of network configuration complexity. Think `ifconfig -a | wc -l` if it helps.
8. A high-level issue which has not yet been addressed is the distinction between system properties and user properties. For example, most properties listed above are clearly system properties, but things like proxies (HTTP, FTP, SOCKS, etc.) could easily have a system default with per-user overrides. An issue related to this is secure delegation, or role-based access control: a mechanism for privileged users to set any properties, but for unprivileged users to set only certain properties.
9. There are two subtly distinct issues here:
  • Multiple physical or semi-physical (VLAN) interfaces, each of which can detect its attachment to a network and extract information from there.
  • Multiple networks, each of which is a collection of subnets and policies for forwarding, security, name services, and the like.
In that latter category, "SWAN" and "Internet" are two examples of networks. One could have one or more interfaces connected to each, modulo IT policies, but the overall configuration of the system would need to be partitioned into "stuff that applies to SWAN traffic" and "stuff that is for the Internet."
10. Is there a single user, or even necessarily a user (logged in) at all? We may need to expand and/or clarify this requirement as well.
11. Some types of verification (such as making sure that a configuration is complete and self-consistent) are straightforward whereas other types (such as whether or not a remote host is reachable) are problematic.

Phase 2 Requirements

1. The solution must support some sort of "parental lock mode" for phase 2, perhaps something akin to the Mac OS X concept of regular vs. admin users.

General Non-Requirements

1. The solution is not required to detect manual changes done to the configuration, such as rewriting /etc/nsswitch.conf. But the solution must allow manual changes to profiles.
2. The solution is not required to be usable to set up a grid of machines; however, the solution must not make this task harder.