1. What specifically is the proposal that we are reviewing? Currently there is no way of observing local traffic on Solaris. Local traffic includes 127.0.0.1 traffic as well as traffic between addresses hosted on the same system. The reason there is no observability is due to the ip module recognising the traffic is destined for the same host and looping it back internally, without passing it down to the nic. Additionally the tcp module now also loops traffic back internally for local connections. - What is the technical content of the project? This project is proposing the addition of a new set of devices which will allow observability of network traffic at the IP layer. The new devices will be /dev/lo0 to provide compatibility with other Unix variants and devices in /dev/ipnet which will map to the physical interfaces plumbed on a machine. The new devices will also be exportable to a non-global zone so snooping from within a non-global zone will become possible. In itself, being able to observe loopback traffic is a feature that has been missing from Solaris for some time. However, with the introduction of zones this lack of observability means there is currently no way of observing inter-zone or intra-zone traffic. This proposal will make observing this traffic possible. As well as making loopback traffic observable, the ipnet devices will also allow an IPMP group to be observed once the IPMP re-architecture is completed. - 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? This is a change to the existing Solaris product and a patch binding will be requested for this project. - What is the motivation for it, in general as well as specific terms? The motivation, and benefit, for Sun are detailed above and in the case materials. 2. Describe how your project changes the user experience, upon installation and during normal operation. Under normal operation there will be no change. However, for administrators troubleshooting network problems there will now be the new set of devices available for running network monitoring tools such as snoop on. 3. What is its plan? - What is its current status? Has a design review been done? Are there multiple delivery phases? A design review was conducted on opensolaris.org in the networking community and we plan on releasing early access bits through opensolaris.org. The first piece released on Open Solaris was the /dev/lo0 device. However, the plan is to integrate both the /dev/lo0 device and the ipnet component, at the same time. - What is its current status? The /dev/lo0 component and the ipnet device have both been released on Opensolaris. 4. Are there related projects in Sun? We will be using the new netinfo(9f) interfaces provided by the "Packet Filtering Hooks API" case (PSARC/2005/334). Currently the interfaces provided by the Packet Filtering Hooks API don't provide a way of associating a zoneid with an address. This project will add new interfaces to the API to do this. The new interfaces have been implemented but will not be part of Packet Filtering Hooks putback due to time constraints and do not form part of this case. No other projects have a hard dependency on this project. The Clearview IPMP Rearchitecture project has a soft dependency on this project. With the new ipmp device created as part of this work, there will also be a corresponding /dev/ipnet/ipmp node that will allow an IPMP group to be observed directly, without having to observe all the underlying links that make up the group. This has been a long standing problem with IPMP. 5. How is the project delivered into the system? The new devices will be delivered as part of SUNWckr. As mentioned above there will be two new devices introduced with project, /dev/lo0 and device nodes in /dev/ipnet/ for each physical interface on the system. The devices in /dev/ipnet/ will be created and destroyed dynamically. 6. Describe the project's hardware platform dependencies. None 7. System administration - How will the project's deliverables be installed and (re)configured? The deliverables from this project will be delivered as part of SUNWckr and so will form part of a standard install using standard package utilities. - How will the project's deliverables be uninstalled? Given the changes are part of the base system there will not be anyway of uninstalling the new devices. - Does it use inetd to start itself? No. - Does it need installation within any global system tables? No. - 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? N/A - 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)? None. 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?) N/A - What are the project's effects on boot time requirements? None. - How does the project handle dynamic reconfiguration (DR) events? In the case where new interfaces are added/replaced the /dev/ipnet/ directory will be updated accordingly. - 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? N/A - 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. N/A - 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? N/A - 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)? No. The new devices themselves do not expose any internal state information as there is nothing of interest for an administrator. Essentially the new devices provide access to traffic passing through the ip module and are DLPI devices to allow existing network monitoring tools such as snoop to access them. They do not allow packets to be sent only received. - How would a user or administrator tell that this subsystem is or is not behaving as anticipated? By using traditional network monitoring tools such as snoop. An example would be snoop working on the underlying link, /dev/bge0, but not on the corresponding /dev/ipnet device, /dev/ipnet/bge0. - What statistics does the subsystem export, and by what mechanism? None. - What state information is logged? None. - In principle, would it be possible for a program to tune the activity of your project? No. 10. What are the security implications of this project? - What security issues do you address in your project? The project addresses the need for an administrator to require PRIV_NET_RAW to access the new devices, thus giving them more access than actually required. We will introduce a new privilege, PRIV_NET_OBSERVABILITY, as detailed below. - 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? No. - Is system or subsystem security compromised in any way if your project's configuration files are corrupt or missing? N/A - 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. Local connections have always been more trusted than connections on the wire. For connections on the wire there is always the possibility of anonymous eavesdroppers, the same is not true for local connections. Given this, traffic on the wire might be subject to encryption whilst local traffic may not under the assumption there is no problem of someone eavesdropping. Allowing observation of local traffic clearly breaks this assumption. The project will introduce a new privilege, PRIV_NET_OBSERVABILITY. This will just allow access to the ipnet devices where packets can only be observed not sent. Given the new risks exposing observation of local traffic brings, the proposed new privilege may be refined in the future, adding finer grained privileges. As an example of how this privilege might be refined, there could be separate privileges for observing intrazone, interzone, and inter-machine traffic. However, for now we plan on keeping one high level privilege, which only uid 0 will be granted by default. 11. What is its UNIX operational environment: - Which Solaris release(s) does it run on? The project is targeting nevada and a Solaris 10 update. - Environment variables? Exit status? Signals issued? Signals caught? (See signal(3HEAD).) N/A - Device drivers directly used (e.g. /dev/audio)? .rc/defaults or other resource/configuration files or databases? None. - Does it use any "hidden" (filename begins with ".") or temp files? No. - Does it use any locking files? No. - Command line or calling syntax: A new option will be added to snoop(1M) to specify that the ipnet devices are to be used, rather than the network device itself. New filtering options will also be added to allow administrators to filter on the zone id. The changes to the manpage are below. ------- snoop.1m ------- *** /tmp/sccs.pDaOse Thu Mar 23 19:43:19 2006 --- snoop.1m Thu Mar 23 19:31:36 2006 *************** *** 4,10 **** snoop - capture and inspect network packets SYNOPSIS ! snoop [-aqrCDNPSvV] [ -t [r | a | d] ] [-c maxcount] [-d device] [-i filename] [-n filename] [-o filename] [ -p first [ , last]] [-s snaplen] [ -x offset [ , length]] [expres- sion] --- 4,10 ---- snoop - capture and inspect network packets SYNOPSIS ! snoop [-aqrCDINPSvV] [ -t [r | a | d] ] [-c maxcount] [-d device] [-i filename] [-n filename] [-o filename] [ -p first [ , last]] [-s snaplen] [ -x offset [ , length]] [expres- sion] *************** *** 55,60 **** --- 55,63 ---- where. Packets are not displayed when this flag is used. + -I Capture packets using the devices in + /dev/ipnet. + -P Capture packets in non-promiscuous mode. Only broadcast, multicast, or packets addressed to the host *************** *** 397,402 **** --- 400,410 ---- from qualifier may be used to select either call or reply packets only. + zone zoneid + + True if zoneid matches either the src or destination + zoneid of a packet received on an ipnet device. + ldap True if the packet is an LDAP packet on port 389. *************** *** 672,678 **** SEE ALSO netstat(1M), hosts(4), rpc(4), services(4), attributes(5), ! audio(7I), bufmod(7M), dlpi(7P), pfmod(7M), tun(7M) Callaghan, B. and Gilligan, R. RFC 1761, Snoop Version 2 Packet Capture File Format. Network Working Group. February --- 680,686 ---- SEE ALSO netstat(1M), hosts(4), rpc(4), services(4), attributes(5), ! audio(7I), bufmod(7M), dlpi(7P), ipnet(7D), pfmod(7M), tun(7M) Callaghan, B. and Gilligan, R. RFC 1761, Snoop Version 2 Packet Capture File Format. Network Working Group. February - 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")? N/A - 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)? No. The only dependency that the project has is on the pfhooks project for the netinfo interface they are introducing and this project will be part of the default kernel. Also the pfhooks project is targeting a Solaris 10 update. - 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? Yes. - 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? No. - Is the project internationalized and localized? N/A - Is the project compatible with IPV6 interfaces and addresses? Yes. 12. What is its window/desktop operational environment? Not applicable, no graphical components are provided by this project. 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., "Standard," "Stable," and "Evolving;" 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 () Contract private Interfaces Exported Interface Classification Comments My_subroutine_name Committed MY_MACRO Project private Etc, etc, etc... Interfaces Imported Interface Classification Comments netinfo(9f) Uncommitted PSARC/2005/334 Interfaces Exported Interface Classification Comments DL_IOC_IPNET_INFO Committed inet/ipnet.h struct dl_ipnet_info Committed inet/ipnet.h DL_IPNETINFO_VERSION Committed inet/ipnet.h DL_IPNET Committed sys/dlpi.h ip_register_cb() Project Private inet/ip.h ip_unregister_cb() Project Private inet/ip.h PRIV_NET_OBSERVABILITY Committed sys/priv_names.h /dev/lo0 Committed lo0 (7D) /dev/ipnet/* Committed ipnet (7D) Committed zoneid Committed snoop (1m) net_getlifzone() Committed neti.h net_getlif_flags() Committed neti.h NE_SET_ZONE Committed hook_event.h NE_LIF_UP Committed hook_event.h NE_LIF_DOWN Committed hook_event.h - Exported public library APIs and ABIs Protocols (public or private) Drag and Drop ToolTalk Cut/Paste DLPI - Other interfaces N/A - What other applications should it interoperate with? How will it do so? The new devices provided are DLPI devices of a new DL_IPNET. As such they devices should function with any DLPI application so long as the application is modified to understand the new type. As part of this project libpcap will be updated to understand the new type to allow applications such as Ethereal to work with them. - Is it "pipeable"? How does it use stdin, stdout, stderr? N/A - Explain the significant file formats, names, syntax, and semantics. The project introduces a new DLPI mac type, DL_IPNET, and this new type will have it's own header format as described by dl_ipnet_info.The header will be stored in big endian which matches the existing snoop header format. By default, the ipnet device will only pass up packet data. To get the ancillary data header, an application will need to issue the new DL_IOC_IPNET_INFO ioctl. The new ioctl will take a boolean parameter to enable or disable the facility. Although the header will be of fixed size, the actual length will be dependent on the version. An application will issue a DL_IOC_IPNET_INFO request passing in 1 to enable the facility. The device will return a non-zero value indicating the current DL_IOC_IPNET_INFO version. - Is there a public namespace? (Can third parties create names in your namespace?) How is this administered? No. - Are the externally visible interfaces documented clearly enough for a non-Sun client to use them successfully? The new devices and their exported interfaces will be documented in their respective manpages. 14. What are its other significant internal interfaces inter-subsystem and inter-invocation)? - Protocols (public or private) None. - Private ToolTalk usage None. - Files None. - Other The project will introduce a hook framework into ip implemented on a very simple callback mechanism. The ipnet device and /dev/lo0 device will register with the ip module by calling ip_register_cb() and passing in a callback function. In the case of ipnet, registration with the ip module will occur once there are devices in /dev/ipnet/ and unregister with the ip module in the event there are no IP interfaces configured and thus no devices in /dev/ipnet/. In the ip module the registered callback functions are stored in a list, when a hook is run each callback will be called and data passed back to the caller. Both ipnet and /dev/lo0 will process these messages using a taskq to avoid blocking the ip module. The callback interfaces will be Project Private. The devices unregister with the ip module by calling ip_unregister_cb(). Given the simplicity of the callbacks this project plans on adding there should be nothing to prevent them been re-implemented using PEF (packet event framework) should it ever become available or another more generic - Are the interfaces re-entrant? Yes. 15. Is the interface extensible? How will the interface evolve? - How is versioning handled? The proposed header format for the new DLPI mac type will be extensible using a version number contained in the header. To access the header an application will issue a new ioctl, DL_IOC_IPNET_INFO, which will return the current version. The length field in the new header allows old applications to work with the newer versions as they can interpret the fields they understand and skip the rest. New applications will also work with older versions of the header using the version number. They can either fail, or ideally only interpret the fields for that version. - 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)? N/A - What are the clients over which a change should be managed? Third party network monitoring tools such as ethereal and libraries such as libpcap would need to be modified. - How is transition to a new version to be accomplished? What are the consequences to ISV's and their customers? If the header for the new DL_IPNET device needs to be expanded and the version number incremented the changes would need to be feed back into the community so tools such as ethereal could take advantage of the new information contained in the header. 16. How do the interfaces adapt to a changing world? The new header format proposed for the DL_IPNET mac type is extensible and allows for any future enhancements anyone might want to make. In the future if PEF or an equivalent component is implemented then the existing hook framework in the ip module that this project introduces could be replaced. The proposed framework and the requirements on it have been kept simple so that in the future it should be easy to change. 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? Currently other Unix variants provide access to local IP traffic through a /dev/lo* device. The actual name of this device varies linux provides /dev/lo or /dev/lo0, BSD variants provide /dev/lo0. This project will introduce a /dev/lo0 device as well as the new /dev/ipnet/ devices to provide a consistent model. We are only providing administrative interoperability, not programmatic interoperability. Given the underlying implementation varies between operating systems, and we will be ensuring the new DL_IPNET devices are supported in third party software such as libpcap, there is no need for consistency here. - What would be different about installing your project in a heterogeneous site instead of a homogeneous one (such as Sun)? N/A - Does your project assume that a Solaris-based system must be in control of the primary administrative node? N/A 18. Performance - How will the project contribute (positively or negatively) to "system load" and "perceived performance"? In the case where no one is using the devices to monitor IP traffic we expect no performance impact. When the devices are been used there will be a performance impact in the same way that there is today when users run network monitoring tools on network interfaces. The hope is that performance will not drop more than 10%. - What are the performance goals of the project? How were they evaluated? What is the test or reference platform? The project aims to no degrade performance by more than 10% when running a network monitoring tool on the new devices. - 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 devices will process the packets in the new devices in the devices srv(9E) routine to avoid blocking the ip module. - 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? In the case where the devices are not been used we expect no performance impact. - Does this application "wake up" periodically? How often and under what conditions? What is the working set associated with this behavior? N/A - 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? No. 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? None. 20. Appendices to include The design specification for the proposal can be found here: ipobs-design.pdf