PSARC Questions Version 1.17 Here is a comprehensive list of questions that ARC members may ask of project presenters. Providing this information in advance of your review will greatly simplify the ARC's process of identifying the critical information relevant to your project. It is expected that many of these issues may be unresolved at the time of an inception review. However, they should be answerable at commitment review, and may be addressed at inception if significant. Please make your answers concise! Most if not all of these questions will be addressed in related documents such as 1-pagers, specs, design documents, etc. There is no reason to duplicate effort, and "see section 3.2 in the design spec" is an excellent answer. Of course, the referenced material must be provided with your submission. Entire sets of questions may be N/A for your project. For example, device drivers rarely have GUIs, and so the entire GUI section can just be deleted. In such cases, PLEASE NOTE N/A FOR THE MAIN QUESTION, AND DELETE THE REST OF THAT QUESTION SET. This questionnaire is meant to provide the ARC with an overview of your project, and it touches on the main areas of architectural interest. This template will be revised based on its users' experiences; your comments and suggestions are welcome. Send them to john.plocher@sun.com. For advice about architectural choices, pointers to various SAC guidelines, and other project considerations including Licensing and Patents, see http://sac.sfbay/arc/ARC-Considerations.html ------------------------------------------------------------------------ 1. What specifically is the proposal that we are reviewing? Labeled IPsec phase 1 - What is the technical content of the project? Trusted Solaris and Trusted Extensions include a labeled networking capability which associates sensistivity labels with network traffic, allowing traffic of differing sensitivity to be isolated and contained. The existing trusted networking protocol in TX, CIPSO, assumes that the underlying network is secure and that CIPSO packet headers cannot be manipulated or observed by an adversary while packets are in transit. The project will permit TX sensitivity labels to be associated with IPsec-protected traffic, allowing labeled networking over untrusted networks. Please provide diagrams that illustrate the project's architecture and interfaces. Be specific about deliverable components and their interfaces. Pay particular attention to describing the scope of the project, especially near the project boundaries. - Is this a new product, or a change to a pre-existing one? This is a compatible extension to the existing Solaris IPsec and Trusted Networking subsystems; we believe it would be compatible with a Micro/Patch release binding but have no plans at present to backport to a Patch release. - 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.) Existing CIPSO labeled networking implemented by TX assumes that IP packets cannot be observed or modified in transit. Many existing networks (including the inter-campus backbone links used within the SWAN) drop CIPSO-labeled packets, preventing the use of labeled networking. This project will connect IPsec and Trusted Networking by providing an alternate sensitivity labeling mechanism within IPsec. - What are the expected benefits for Sun? Increased applicability of Trusted Extensions; increased security within TX deployments. - By what criteria will you judge its success? A successful deployment of IPsec-protected labeled networking in production. 2. Describe how your project changes the user experience, upon installation and during normal operation. No change to user experience unless both IPsec, TX, and the new features of this project are enabled. 3. What is its plan? - What is its current status? Has a design review been done? Are there multiple delivery phases? Design review of phase 1 was completed on the security-discuss@opensolaris.org mailing list; later phases are less well defined at this point. 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? The FMAC project is investigating new types of mandatory labels. There is a project under way to port the racoon2 key management package; once that is further along this project will need to investigate extending it to handle labels. - 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. I'm in communication with engineers involved with all related projects I'm aware of. 5. How is the project delivered into the system? Through existing packages, executables, and shared libraries. 6. Describe the project's hardware platform dependencies. None. 7. System administration - How will the project's deliverables be installed and (re)configured? Through binaries which are part of core metaclusters. Configuration will be via new syntax in existing config files. - How will the project's deliverables be uninstalled? N/A - Does it use inetd to start itself? No; - Does it need installation within any global system tables? - Does it use a naming service such as NIS, NIS+ or LDAP? - What are its on-going maintenance requirements (e.g. Keeping global tables up to date, trimming files)? Labeled IPsec will require coordinated management of TX networking databases and IPsec and IKE policy configuration as a network grows and evolves. Tools to assist in doing that are beyond the scope of this project, but would form the core of a reasonable follow-on project. - 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? Out of scope for this project. - 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)? 8. Reliability, Availability, Serviceability (RAS) This project makes no significant change to RAS relative to existing IPsec and TX; there's room for improvement in many areas but it's not this project. 9. Observability - Does the project export status, either via observable output (e.g., netstat) or via internal data structures (kstats)? The existing ipseckey(1m) command provides visibility into the state of the SADB and can monitor PF_KEY transactions; it will be extended to display sensitivity labels when present. - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? - What statistics does the subsystem export, and by what mechanism? - What state information is logged? - In principle, would it be possible for a program to tune the activity of your project? N/A. This project doesn't introduce tunables which would make that plausible. 10. What are the security implications of this project? - What security issues do you address in your project? - 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? - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? - 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. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? Intended to be part of systems identifying themselves as SunOS 5.11 and later - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? Uses IPsec - Command line or calling syntax: What options are supported? (please include man pages if available) Does it conform to getopt() parsing requirements? - What shared libraries does it use? (Hint: if you have code use "ldd" and "dump -Lv")? IKE/IPsec commands now link against TX shared libraries to convert labels to and from human-readable form. More specifically: in.iked decodes labels to textual form using label_to_str in debug messages. ipseckey similarly uses label_to_str when displaying active security associations, and uses str_to_label when creating manually-keyed labeled security associations. - Is the project compatible with IPV6 interfaces and addresses? Yes. 12. What is its window/desktop operational environment? N/A 13. What interfaces does your project import and export? - Please provide a table of imported and exported interfaces, including stability levels. Pay close attention to the classification of these interfaces in the Interface Taxonomy -- e.g., "Committed," "Uncommitted," and "*Private;" see: http://sac.sfbay/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp Use the following format: Interfaces Imported Interface Classification Comments The_referring_standard Committed ANSI Xy.Tz 1999 draft 37 Somebody_else () Consolidation Private Interfaces Exported Interface Classification Comments My_subroutine_name Committed MY_MACRO Project Private Etc, etc, etc... ike config file Committed PF_KEY extensions Committed - Exported public library APIs and ABIs Protocols (public or private) Drag and Drop ToolTalk Cut/Paste - Other interfaces - What other applications should it interoperate with? How will it do so? - Is it "pipeable"? How does it use stdin, stdout, stderr? - Explain the significant file formats, names, syntax, and semantics. - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? We haven't had cycles to adequately document Sun's previous extensions to PF_KEY; this project is one more reason why we need to do this. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? - Protocols (public or private) - Files - Other - Are the interfaces re-entrant? Standard protocols: PF_KEY IPsec ESP/AH IKEv1 CIPSO 15. Is the interface extensible? How will the interface evolve? - How is versioning handled? - What was the commitment level of the previous version? - Can this version co-exist with existing standards and with earlier and later versions or with alternative implementations (perhaps by other vendors)? - What are the clients over which a change should be managed? - How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? 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)? 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? - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? - Does your project assume that a Solaris-based system must be in control of the primary administrative node? we're implementing an open spec (IKEv1 SIT_SECRECY labels) which to our knowledge nobody else has implemented. Single-label interoperability is a requirement and is simple (our system asserts that all traffic to/from a peer address has label X). Multi-label interoperability requires agreement on what a "label" is. SELinux has very different labels. The FMAC project might help multi-label IPsec interoperability with SELinux but it's too soon to say for sure. 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? - Does the application pause for significant amounts of time? Can the user interact with the application while it is performing long-duration tasks? - 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? - 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? - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? - Will it require large files/databases (for example, new fonts)? - 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? IPsec has inherent cryptographic and policy enforcement overhead; TX has inherent policy enforcement overhead. Enabling both features will inherently be slower than running with cleartext unlabeled traffic; this project's performance goal is to deliver performance roughly comparable to the worst of either labeled cleartext or unlabeled IPsec. 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? 20. Appendices to include - One-Pager. - Prototype specification. - References to other documents. (Place copies in case directory.)