From sac-owner Thu Oct 29 16:30:02 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9TNU1A4009222 for ; Thu, 29 Oct 2009 16:30:01 -0700 (PDT) Received: from sunmail5.uk.sun.com (localhost [127.0.0.1]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9TNU0VL016111 for ; Thu, 29 Oct 2009 23:30:00 GMT Received: (from noaccess@localhost) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/Submit) id n9TNU0MX016110 for one-pager-not-2b-used-directly; Thu, 29 Oct 2009 23:30:00 GMT Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n9TNTxCM016059 for <@sunmail2sca.sfbay.sun.com:one-pager@sun.com>; Thu, 29 Oct 2009 23:30:00 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSA00G09ULZFJ00@nwk-avmta-1.sfbay.Sun.COM> for one-pager@sun.com (ORCPT one-pager@sun.com); Thu, 29 Oct 2009 16:29:59 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSA00B7QULYRE30@nwk-avmta-1.sfbay.Sun.COM> for one-pager@sun.com (ORCPT one-pager@sun.com); Thu, 29 Oct 2009 16:29:58 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com (localhost [127.0.0.1]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9TNTwdf560690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Oct 2009 16:29:58 -0700 (PDT) Received: (from apersson@localhost) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n9TNTwAE560689 for one-pager@sun.com; Thu, 29 Oct 2009 16:29:58 -0700 (PDT) Date: Thu, 29 Oct 2009 16:29:58 -0700 From: Anders Persson Subject: [2009/590]Socket Filter Framework To: one-pager@sun.com Message-id: <20091029232958.GG499046@jurassic-x4600.Eng.Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 4621 Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Socket Filter Framework 1.2. Name of Document Author/Supplier: Anders Persson 1.3. Date of This Document: 29 October, 2009 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Robert Lavender 1.4.4. The name of your business unit: Systems 1.5. Email Aliases: 1.5.1. Responsible Manager: Victor.Nelson@sun.com 1.5.2. Responsible Engineer: Anders.Persson@sun.com 1.5.3. Marketing Manager: 1.5.4. Interest List: s10netperf@sun.com 2. Project Summary 2.1. Project Description: This is a project to implement a socket filter framework, which makes it possible for modules to intercept requests and notifications passed between the socket and protocol layers. The Solaris SSL kernel proxy (PSARC/2005/625) will be converted to use the framework. 2.2. Risks and Assumptions: There are no apparent risks, and no assumptions have been made. 3. Business Summary 3.1. Problem Area: Network performance. 3.2. Market/Requester: Solaris customers. 3.3. Business Justification: This project provides a framework for developing filters that can increase the network performance for a number of applications. For example, a socket splicing filter could be used to redirect data from one socket to another with crossing the user/kernel boundary. 3.4. Competitive Analysis: 3.5. Opportunity Window/Exposure: 3.6. How will you know when you are done?: When KSSL has be ported to the socket filter framework. 4. Technical Description: 4.1. Details: A filter is configured to work with one or more socket types and it can be attached either automatically to all matching sockets or programmatically to a specific socket by the request of an application. Once attached, the filter exists in the socket layer, but sits logically in between the socket and transport layers where it is notified of user requests and transport events via callback functions. The action a filter can take depend on the callback. But typically a filter can modify or deny socket operations, transform, delay and inject data, as well as defer the notification of new connections. 4.2. Bug/RFE Number(s): TBD 4.3. In Scope: Socket Filter framework and one filter (SSL kernel proxy). 4.4. Out of Scope: No socket filters other than the SSL kernel proxy will be delivered. 4.5. Interfaces: soconfig: new subcommands will be added to configure socket filters. The stability level will be Consolidation Private. setsockopt(3M): new options will be added for controlling filters on a socket. The stability level will be Committed. 4.6. Doc Impact: The man page for setsockopt(3) will need updates to describe new socket options. 4.7. Admin/Config Impact: No impact by default. New filters will be controlled by smf services. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: N/A 4.10. Packaging & Delivery: No new packages are anticipated. SUNWckr and SUNWcsr will be updated. 4.11. Security Impact: The socket filter framework does not have a security impact. However, individual filters may have an impact since they can result in a socket being bound, or connected to a different address than requested by the application. The administrator is in control of what filters are enabled, and the documentation of each filter would discuss any security implications. 4.12. Dependencies: None 5. Reference Documents: None 6. Resources and Schedule: 6.1. Projected Availability: snv_136 6.2. Cost of Effort: Development: 10 weeks Testing: 4 weeks 6.3. Cost of Capital Resources: No new resources required. 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: N/A 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: None 6.4.7. Target RTI Date/Release: snv_136 6.4.8. Target Code Design Review Date: November, 2009 6.4.9. Update approval addition: No 6.5. ARC review type: Standard 6.6. ARC Exposure: open 7. Prototype Availability: 7.1. Prototype Availability: Now 7.2. Prototype Cost: