1. What specifically is the proposal that we are reviewing? - What is the technical content of the project? This project provides Ethernet datalink-layer bridge functionality for Solaris and OpenSolaris. The primary (normative) architectural documentation is provided in the case materials directory as: bridging-spec.txt bridging-security.txt Additional (non-normative) information is available in: rbridges-net-summit.odp high-level presentation bridging-design.pdf draft design document The additional materials provide some background information, but are not needed for this review, and are not expected to be under review in the ARC. (In particular, the high level presentation is a bit dated now due to Crossbow, and the design document is known to be incomplete.) - Is this a new product, or a change to a pre-existing one? If it is a change, would you consider it a "major", "minor", or "micro" change? See the Release Taxonomy in: http://sac.sfbay/BestPractices/release_taxonomy.html This is a minor change to an existing product. - If your project is an evolution of a previous project, what changed from one version to another? This project adds bridging to the existing datalink layer feature set. - What is the motivation for it, in general as well as specific terms? (Note that not everyone on the ARC will be an expert in the area.) Bridging is a standard IEEE 802 feature, and can be used to construct a number of other useful solutions including "stealth" firewalls (using L2 filtering), greatly simplified test configurations for IPMP and NWAM, and the implementation of WiFi access point functionality. On its own, bridging can be useful when Solaris is used for embedded systems and is a complement to our existing routing functionality. - What are the expected benefits for Sun? As above; addition of bridging features that can be used in a variety of situations. - By what criteria will you judge its success? + Successful conformance and interoperability test runs at UNH. + Successful internal testing of bridging functionality. 2. Describe how your project changes the user experience, upon installation and during normal operation. - What does the user perceive when the system is upgraded from a previous release? The default_tag (IEEE PVID) will be set automatically on upgrade on each port. If the user does not have VLAN ID 1 configured, and on initial installs, the default_tag will be set to 1, per the standard. If the user does have VLAN ID 1 in use on an existing interface, then PVID functionality will be disabled by setting the parameter to zero, and the administrator may need to change it, as there's no way for the upgrade code to "guess" at the correct value. This issue does not alter how the system operates after an upgrade in any noticeable way. It's a IEEE and bridge conformance issue, and has an effect only when bridging between interfaces, which does not occur by default. (Configuring a bridge requires administrative action.) 3. What is its plan? - What is its current status? Has a design review been done? Are there multiple delivery phases? There is currently one delivery planned, and the delivery includes both basic bridging functionality (this project) and RBridges (a separate project to be introduced later). Design review has not yet been started. 4. Are there related projects in Sun? - If so, what is the proposal's relationship to their work? Which not-yet- delivered Sun (or non-Sun) projects (libraries, hardware, etc.) does this project depend upon? What other projects, if any, depend on this one? This project is part of the overall RBridges/TRILL project. It was delayed due to Crossbow considerations. It doesn't depend on any other project, nor do other projects depend on it. However, the functionality will be quite useful when combined with L2 filtering, and is planned to be a fundamental component for networking test configurations. - Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose? If not, please explain the areas of disagreement. We're changing dladm and the Nemo/MAC layer to insert another component that is quite similar to the existing 802.3ad aggregation support. We have been in periodic communication with the other teams involved, and a primary means of that will be the design document, when that is complete. We do have basic agreement on the architectural differences between Crossbow's virtual switches and IEEE standard bridging; the projects are not in conflict at that level. 5. How is the project delivered into the system? - Identify packages, directories, libraries, databases, etc. Existing SUNWckr, SUNWcsd, and SUNWhea are modified. The SUNWcnetr postinstall script and BFU are updated to handle the default_tag issue. This will need to be revisited for OpenSolaris. 6. Describe the project's hardware platform dependencies. - Explain any reasons why it would not work on both SPARC and Intel? N/A (works on both) 7. System administration - How will the project's deliverables be installed and (re)configured? Installed by normal packaging, configured by dladm. - How will the project's deliverables be uninstalled? Uninstalled by packaging. (Not normally uninstalled.) - Does it use inetd to start itself? No. - Does it need installation within any global system tables? Yes; it registers with SMF and uses the existing dladm datalink.conf. - Does it use a naming service such as NIS, NIS+ or LDAP? No. - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? None. - How does this project's administrative mechanisms fit into Sun's system administration strategies? E.g., how does it fit under the Solaris Management Console (SMC) and Web-Based Enterprise Management (WBEM), how does it make use of roles, authorizations and rights profiles? Additionally, how does it provide for administrative audit in support of the Solaris BSM configuration? dladm(1M) fits into an existing "Network Management" RBAC profile. - What tunable parameters are exported? Can they be changed without rebooting the system? Examples include, but are not limited to, entries in /etc/system and ndd(8) parameters. What ranges are appropriate for each tunable? What are the commitment levels associated with each tunable (these are interfaces)? The tunables are all accessible from the dladm(1M) command line, described in the separate bridging-spec.txt document. They can also be modified via SMF; see the document. 8. Reliability, Availability, Serviceability (RAS) - Does the project make any material improvement to RAS? No. - How can users/administrators diagnose failures or determine operational state? (For example, how could a user tell the difference between a failure and very slow performance?) Status is provided through dladm(1M) and kstats. - What are the project's effects on boot time requirements? None expected. - How does the project handle dynamic reconfiguration (DR) events? Bridges must be unconfigured first in order to remove links, much like aggregations and other dladm features. - What mechanisms are provided for continuous availability of service? N/A - Does the project call panic()? Explain why these panics cannot be avoided. No. - How are significant administrative or error conditions transmitted? SNMP traps? Email notification? Most events are signaled through dladm and SMF state. Some debug and unusual events may be logged through syslog. - How does the project deal with failure and recovery? N/A - Does it ever require reboot? If so, explain why this situation cannot be avoided. No. - How does your project deal with network failures (including partition and re- integration)? How do you handle the failure of hardware that your project depends on? If the hardware fails, then the link can be removed from the bridge while the system is running. Otherwise failure and recovery have no effect. - Can it save/restore or checkpoint and recover? N/A - Can its files be corrupted by failures? Does it clean up any locks/files after crashes? N/A 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? Yes; via dladm and kstats. - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? Using "dladm show-bridge" to view status. The user can also snoop on the bridge itself, in addition to snooping individual links. - What statistics does the subsystem export, and by what mechanism? kstats - What state information is logged? debug only via syslog - In principle, would it be possible for a program to tune the activity of your project? Yes. 10. What are the security implications of this project? - What security issues do you address in your project? + We omit GVRP. + We use the existing PRIV_SYS_DL_CONFIG privilege for L2 configuration. + We automatically shut down bridge forwarding if the daemon is terminated. - The Solaris BSM configuration carries a Common Criteria (CC) Controlled Access Protection Profile (CAPP) -- Orange Book C2 -- and a Role Based Access Control Protection Profile (RBAC) -- rating, does the addition of your project effect this rating? E.g., does it introduce interfaces that make access or privilege decisions that are not audited, does it introduce removable media support that is not managed by the allocate subsystem, does it provide administration mechanisms that are not audited? The existing dladm datalink.conf mechanism appears not to be audited. Other than that, there should be no unaudited interfaces. (The project team is willing to work with the Auditing Team to resolve these issues.) - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? No. - Please justify the introduction of any (all) new setuid executables. N/A - Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. A separate Security Questionnaire http://sac.sfbay/cgi-bin/bp.cgi?NAME=Security.bp is provided for more detailed guidance on the necessary information. Cases are encouraged to fill out and include the Security questionnaire (leveraging references to existing documentation) in the case materials. Projects must highlight information for the following important areas: - What features are newly visible on the network and how are they protected from exploitation (e.g. unauthorized access, eavesdropping) - If the project makes decisions about which users, hosts, services, ... are allowed to access resources it manages, how is the requestor's identity determined and what data is used to determine if the access granted. Also how this data is protected from tampering. - What privileges beyond what a common user (e.g. 'noaccess') can perform does this project require and why those are necessary. - What parts of the project are active upon default install and how it can be turned off. See bridging-security.txt document. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? Nevada and OpenSolaris - Environment variables? Exit status? Signals issued? Signals caught? (See signal(3HEAD).) Internally, we use SIGHUP to re-read configuration after changing SMF parameters (for the "refresh" action), and SIGTERM to shut down the daemon normally. No other signals are used. No evironment variables or exit status values are defined. - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? No. - Does it use any "hidden" (filename begins with ".") or temp files? No. - Does it use any locking files? No. - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? See bridging-spec.txt. getopt: yes - Is there support for standard forms, e.g. "-display" for X programs? Are these propagated to sub-environments? N/A - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? librstp.so.1 libdlpi.so.1 libdladm.so.1 libsocket.so.1 (for debug messages) - Identify and justify the requirement for any static libraries. N/A - Does it depend on kernel features not provided in your packages and not in the default kernel (e.g. Berkeley compatibility package, /usr/ccs, /usr/ucblib, optional kernel loadable modules)? N/A - Is your project 64-bit clean/ready? If not, are there any architectural reasons why it would not work in a 64-bit environment? Does it interoperate with 64-bit versions? 64-bit clean. - Does the project depend on particular versions of supporting software (especially Java virtual machines)? If so, do you deliver a private copy? What happens if a conflicting or incompatible version is already or subsequently installed on the system? N/A - Is the project internationalized and localized? N/A - Is the project compatible with IPV6 interfaces and addresses? N/A (IPv6 works fine) 12. What is its window/desktop operational environment? - Is it ICCCM compliant (ICCCM is the standard protocol for interacting with window managers)? - X properties: Which ones does it depend on? Which ones does it export, and what are their types? - Describe your project's support for User Interface facilities including Help, Undo, Cut/Paste, Drag and Drop, Props, Find, Stop? - How do you respond to property change notification and ICCCM client messages (e.g. Do you respond to "save workspace")? - Which window-system toolkit/desktop does your project depend on? - Can it execute remotely? Is the user aware that the tool is executing remotely? Does it matter? - Which X extensions does it use (e.g. SHM, DGA, Multi-Buffering? (Hint: use "xdpyinfo") - How does it use colormap entries? Can you share them? - Does it handle 24-bit operation? All N/A. 13. What interfaces does your project import and export? Exported Interface Stability Comments --------- --------- -------- dladm *-bridge Committed new subcommands field names Committed dladm show-bridge -o link properties Committed show-link BRIDGE Committed new field kstats Volatile Should be raised later /dev/bridge/ Committed Observability node control ioctls Project Private /usr/lib/bridged Project Private svc:/network/bridge Committed SMF URI config/* Project Private SMF properties bridge module Project Private Kernel bridging module /var/run/bridge_door/ Project Private Doors interface to daemons librstp.so.1 Project Private RSTP implementation Imported Interface Stability Comments --------- --------- -------- mac, dls, dld Consolidation Private Kernel APIs - Exported public library APIs and ABIs Protocols (public or private) Drag and Drop ToolTalk Cut/Paste N/A - Other interfaces N/A - What other applications should it interoperate with? How will it do so? All bridges implementing STP, RSTP, and MSTP. - Is it "pipeable"? How does it use stdin, stdout, stderr? Yes; dladm has a parseable output mode that we use. - Explain the significant file formats, names, syntax, and semantics. N/A - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? N/A - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? Yes. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? - Protocols (public or private) IEEE 802.1D bridging with RSTP - Private ToolTalk usage - Files - Other - Are the interfaces re-entrant? N/A 15. Is the interface extensible? How will the interface evolve? - How is versioning handled? By default, the system runs the newest variant of Spanning Tree available. A special "force protocol" tunable (part of the IEEE specification) is provided so that users can prevent the use of newer protocols once they become available; capping at a particular version, if desired. - What was the commitment level of the previous version? N/A - Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? Yes. - What are the clients over which a change should be managed? N/A - How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? The standards are set by the IEEE in this area. Transitions (so far) have been backwards and forwards compatible. 16. How do the interfaces adapt to a changing world? - What is its relationship with (or difficulties with) multimedia? 3D desktops? Nomadic computers? Storage-less clients? A networked file system model (i.e., a network-wide file manager)? N/A 17. Interoperability - If applicable, explain your project's interoperability with the other major implementations in the industry. In particular, does it interoperate with Microsoft's implementation, if one exists? We expect to test with major bridge/switch vendors through UNH and lab testing. - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? Nothing. - Does your project assume that a Solaris-based system must be in control of the primary administrative node? No. 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? N/A - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? Bridge forwarding should be comparable to ordinary IP forwarding, if not faster. Testing will be performed using UNH gear and in-house tests. - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? N/A - What is your project's MT model? How does it use threads internally? How does it expect its client to use threads? If it uses callbacks, can the called entity create a thread and recursively call back? The daemon is MT, but only for the doors interface and signal handling. The main STP processing is single-threaded. This is a control path, not data, so it's not expected to be a limiting factor. The kernel portion is fully MT-hot. - What is the impact on overall system performance? What is the average working set of this component? How much of this is shared/sharable by other apps? The memory effect for the daemon should be negligible. The kernel component needs storage for forwarding entries, and may be a limiting factor. The most important issue is that all interfaces on a bridge _must_ be in promiscuous mode at all times. This is part of the definition of bridge operation. It's not optional. - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? Yes; the daemon wakes up every second to send STP messages per the standard. - Will it require large files/databases (for example, new fonts)? No. - Do files, databases or heap space tend to grow with time/load? What mechanisms does the user have to use to control this? What happens to performance/system load? Kernel forwarding entries are aged away if not used. 19. Please identify any issues that you would like the ARC to address. - Interface classification, deviations from standards, architectural conflicts, release constraints... - Are there issues or related projects that the ARC should advise the appropriate steering committees? + L2 filtering must never filter the BPDU messages away. (This is a general issue, and is still true if this project never delivers.) + Auditing issues seem incomplete; we're willing to work with the Auditing Team off-line to get these resolved. It's possible that there are multiple underlying issues to investigate. 20. Appendices to include - One-Pager. - Prototype specification. - References to other documents. (Place copies in case directory.) See materials directory for: bridging-spec.txt bridging-security.txt rbridges-net-summit.odp bridging-design.pdf