1. What is the proposal being presented for review? * Give an overview of the project and its phase(s). This project is a redesign and reimplementation of the IP tunneling functionality in Solaris. It delivers a GLDv3 driver (iptun) that implements IP tunnel links atop which IP interfaces can be plumbed. Tunnel links are managed using new dladm(1M) subroutines (implemented using new libdladm functions), and IP interfaces above tunnel links are created using ifconfig(1M) as with any other type of IP interface. It replaces the old STREAMS-based IP tunneling implementation which depended on the ifconfig(1M) command to plumb tunneling modules (tun, atun, and 6to4tun) atop of /dev/ip or /dev/ip6. With this project, tunnel links gain functionality common to other links, including link vanity naming (introduced by Clearview in PSARC 2006/499), link-layer observability using traditional observability tools such as Wireshark and snoop(1M), and the assignment of tunnel links to exclusive stack non-global zones. * Describe the exposure (OpenSolaris), scope and type of review desired (overview, full case, etc.) This is a full, Open review. * Indicate the release binding requested by the project team. See: http://www.opensolaris.org/os/community/arc/policies/release-taxonomy/ Minor release binding is requested. The EOL and removal of IPv6 automatic tunneling (see [1] section 13), and the removal of the tun(7M) socket ioctls (see [1] section 7.1) are incompatible changes that would introduce risk unsuitable for a patch. * What are the project's deliverables? - A new iptun GLDv3 driver - Three new GLDv3 MAC-type plugins: ipv4, ipv6, and 6to4 - New IP tunneling dladm(1M) subcommands - New IP tunneling management functions in libdladm.so.1 - New sys_iptun_config privilege - New svc:/network/iptun:default SMF service to instantiate persistent IP tunnel links and the IP interfaces above them - Updates to various parts of the system to allow administration of tunnels from within non-global zones - EOF and removal of the "automatic tunneling" functionality described in atun(7M) * How does this project align with existing or proposed ARC cases? This project is the final deliverable under the Clearview umbrella case: 2005/132 Clearview: Network Interface Coherence This project depends on the following ARC cases: 2006/249 Nemo Changes for Binary Compatibility 2006/248 Nemo MAC-Type Plugin Architecture 2006/499 Clearview Nemo unification and vanity naming 2007/311 EOF of Mobile IP 2007/429 Brussels - enhanced network driver configuration via dladm 2008/175 Brussels framework enhancements to get/set defaults 2008/222 Brussels persistence 2008/473 Fine-Grained Privileges for Datalink Administration 2009/410 Datalink Administration from Non-Global Zones 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? New subcommands are added to dladm(1M). The existing ifconfig(1M) commands to manipulate tunnel links (tsrc, tdst, thoplimit, and encaplimit) will remain for backward compatibility, but will call in to the new libdladm functions. * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). The mechanisms for the configuration of IP tunnels varies greatly between different operating systems. Linux has the /sbin/ip command that has the ability to configure tunnels (among other things), and the BSDs manage tunnels using ifconfig (using subcommands that are different than the existing Solaris subcommands). It is not a goal of this project to be compatible nor similar with these administrative interfaces, as the goal of this project is to make IP tunnel links behave similarly to other types of links on Solaris, and those are configured using dladm(1M). * Are there any install time changes? No. 3. What are the exported (defined by your project) and imported (defined by another project that your project then references) interfaces or protocols and their respective stability levels? See: http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/ * Is there a versioning scheme in place? * Has the team secured interface contracts where necessary? * Use an ARC prescribed interface table format. +-------------------------------------------------------------------------+ | Interfaces Exported | +---------------------+------------------------+--------------------------+ | Interface Name | Classification | Comment | +---------------------+------------------------+--------------------------+ | dladm *-iptun | Committed | [1] section 4 | | subcommands | | | | | | | | sys_iptun_config | Committed | [1] section 10.4 | | | | | | MAC-type plugins | Consolidation Private | [1] section 8.1 | | | | | | libdladm iptun_*() | Consolidation Private | [1] section 6 | | functions | | | | | | | | IPTUN_* ioctls | Project Private | [1] section 7.1 | +---------------------+------------------------+--------------------------+ 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. There are no such dependencies. 5. Projects need to be aware of the overall security of the system and how their components affect it. Which parts of this project are critical to the security of the system to avoid such unintended consequences such as unauthorized system entry, unauthorized access to or modification of data, elevation of privilege, denial of service, violation of labeled security, ...? Does this project require elevated privilege? A number of specific policies and practices address various aspects of the security of the system. They are found in appendix 1. Which of these are applicable to this project, and how are they addressed? Administration of IP tunnel links requires the new sys_iptun_config privilege, which is contained by the existing sys_dl_config privilege. This privilege is needed so that IP tunnel administration can be delegated to exclusive stack non-global zones while not allowing adminsitration of all types of datalinks from such zones (which still require sys_dl_config). 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. The new dladm show-iptun subcommand shows configured tunnel links. The existing dladm show-link -s subcommand shows statistics associated with all links including tunnel links. The snoop(1M) command (or equivalent network observability tool) can be used to observe packets over tunnel links. 7. How does the project deal with faults and interruptions? Initialization and restarting? N/A 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, Branded zones, SunCluster, etc.)? The introduction of IP tunnel links to the system allows for their assignment to exclusive stack non-global zones via zonecfg. This was previously not possible. For example, one can now create a tunnel link from the global zone from a global zone IP address and a remote destination reachable from the global zone, then assign the resulting tunnel link to a non-global zone. An administrator in the non-global zone can plumb IP interfaces over this point-to-point tunnel. Architecture is also needed to allow IP tunnel links to be managed from within non-global zones. This is an extension of the architecture already defined by PSARC 2009/410, which this case depends on. There is otherwise no change to how IP tunnels are managed from virtual environments. 9. Does this project require administration (i.e., configuration or management)? If so, * How is the project administered, and what sort of review process has this user interface undergone? The project adds subcommands to the existing dladm(1M) command, and those subcommands adhere to the style of existing subcommands. The project has undergone design review. * Is there a means of aggregating management and/or configuration with other related projects? No. * Does this project deliver its own administration along with the other components, or is this project an administration interface for other projects? It delivers its own administration. * Are there any external (to Solaris) management interfaces to consider, or being consumed? No. Projects that require or deliver administrative interfaces are often by their nature security components of the system and should likely address the security question (#5 above, with attention to RBAC and Audit). (See also appendix 2). 10. Have you reviewed the Policies and Best Practices? Are there any exceptions this project needs? See http://www.opensolaris.org/os/community/arc/policies/ http://www.opensolaris.org/os/community/arc/bestpractices/ There are no exceptions. Appendix 1. Security references Plugable Authentication Modules http://opensolaris.org/os/community/arc/policies/PAM/ Audit Policy http://opensolaris.org/os/community/arc/policies/audit-policy/ Service Management Facility (SMF) usage http://opensolaris.org/os/community/arc/policies/SMF-policy/ Install-Time Security http://opensolaris.org/os/community/arc/policies/ITS/ Network Install-Time Security http://opensolaris.org/os/community/arc/policies/NITS-policy/ Secure - by - Default http://opensolaris.org/os/community/arc/policies/secure-by-default/ When to use setuid -vs - RBAC roles and profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-intro/ Building RBAC Rights Profiles http://opensolaris.org/os/community/arc/bestpractices/rbac-profiles/ Adding RBAC Authorizations http://opensolaris.org/os/community/arc/bestpractices/rbac-auths/ Reusable Passwords in Command Line Arguments and Environment Variables http://opensolaris.org/os/community/arc/bestpractices/passwords-cli/ Storing Reusable Passwords on a FileSystem http://opensolaris.org/os/community/arc/bestpractices/passwords-files/ Administrative and Security Precedents and Policies http://opensolaris.org/os/community/arc/bestpractices/overview-admin-security/ Security Questions http://opensolaris.org/os/community/arc/bestpractices/security-questions/ Labeled Security: http://en.wikipedia.org/wiki/Multilevel_security See also PSARC/2002/762 Layered Trusted Solaris http://arc.opensolaris.org/caselog/PSARC/2002/762 Appendix 2. Administrative access and control RBAC (Role Based Access Control): See PSARC/1997/332 Execution Profiles for Restricted Environments http://arc.opensolaris.org/caselog/PSARC/1997/332 Privilege: See PSARC/2002/188 Least Privilege for Solaris http://arc.opensolaris.org/caselog/PSARC/2002/188 Appendix 3. Policies and Best Practices references http://www.opensolaris.org/os/community/arc/policies/ http://www.opensolaris.org/os/community/arc/bestpractices/ Appendix 4. References (relative to materials directory) [1] iptun-design.pdf - Design & Architecture Specification [2] dladm.1m.txt - Draft dladm(1M) manpage with changebars [3] dladm.1m.diff.txt - Draft dladm(1M) manpage diffs [4] ifconfig.1m.txt - Draft ifconfig(1M) manpage with changebars [5] ifconfig.1m.diff.txt - Draft ifconfig(1M) manpage diffs