1. What is the proposal being presented for review? The project will deliver the basic features needed to use Solaris on a x86/SPARC platform as a L3/L4 load balancer. The ILB Phase 1 project will deliver the following features: o Stateless DSR and NAT operation modes offering the following load balancing algorithms: round-robin, src IP hash, hash, hash o A CLI and a configuration API to configure the various features as well as view statistics and configuration details. o Simple server monitoring features o High availability between load balancers in an active-standby configuration mode via VRRP protocol(RFC 3768). Note that VRRP will be delivered in Solaris as a seperate but parallel project[1]. In order to make load balancer failover transparent to client applications, the primary load balancer needs to synchronize its state (e.g. connection information) with the standby(backup) load balancer. This is needed so that when primary load balancer fails, and the standby load balancer takes over, it will have the state of most connections, so that almost all connections can continue to access the service through the standby load balancer. The ILB Phase 1 delivery will not include this synchronization capability, but it will be provided in later phases. Fragmentation handling by the load balancer will also be provided in later phases, along with other features. The project includes kernel and userland components. Thus ILB will be delivered as separate packages from the core stack with the following package names: SUNWilbr ILB kernel component SUNWilb components delivered in /usr which are: o ilbadm o libilb o ilbd For details of components please read design doc. We are seeking Standard review and requesting Minor release binding 2. Describe user interactions. * Are new user interfaces being proposed, or existing interfaces being changed? * Explain the similarities in proposed interfaces with existing OS user interfaces (Solaris, Linux, Windows, etc.). * Are there any install time changes? There are no changes in existing interfaces. The project will implement a new user interface for ILB adminstration. There are no install time changes necessary 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/ The core functionality of the load balancer administration will be implemented in a library(libilb) for consumption by the CLI(ilbadm) and 3rd party applications. Thus the libilb library will be provided with "Committed" classification. New ioctls that we plan to define for communication between ilbd and the ILB kernel engine will be classified as "Project Private" The ILB project will audit administration using the auditing interfaces that are defined by PSARC 200/517 4. Describe any dependencies on hardware (e.g. SPARC exclusive), and on other projects within Solaris. There are no hardware dependencies. ILB project is dependent on the following projects: o VRRP for ILB high availability feature o Crossbow for performance and scalability 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, ...? 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? Please see Section 9 of Design document. 6. Describe means of observing project functionality and performance, by an end user or by a system administrator. The ILB project's command line interface, ilbadm, can be used for following observability features: - packet forwarding distribution among back-end servers - NAT connection table - monitoring of ILB's execution of events 7. How does the project deal with faults and interruptions? Initialization and restarting? If for some reason the ILB daemon dies, it's restarted by SMF, and the daemon will send a reset notification to the ILB kernel component to clean up existing states. 8. How does the project interact with Solaris virtualization technologies (xVM, LDOMs, zones, SunCluster, etc.)? ILB is orthogonal to hardware virtualization. It can be used inside an exclusive-IP zone. 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? * Is there a means of aggregating management and/or configuration with other related projects? * Does this project deliver its own administration along with the other components, or is this project an administration interface for other projects? * Are there any external (to Solaris) management interfaces to consider, or being consumed? 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). The project will provide a command-line interface to administer the load balancer capability. In order to configure HA capability, the administrator will use the VRRP CLI(which will be provided by the VRRP project). 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/ Appendix 2. Administrative access and control RBAC (Role Based Access Control): See PSARC/1997/332 Execution Profiles for Restricted Environments http://opensolaris.org/os/community/arc/caselog/1997/332 Privilege: See PSARC/2002/188 Least Privilege for Solaris http://opensolaris.org/os/community/arc/caselog/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/