From sacadmin Thu Aug 14 14:25:38 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7ELPcbr002745; Thu, 14 Aug 2008 14:25:38 -0700 (PDT) Received: (from sommerfe@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m7ELPcLO002741; Thu, 14 Aug 2008 14:25:38 -0700 (PDT) Date: Thu, 14 Aug 2008 14:25:38 -0700 (PDT) From: William Sommerfeld Message-Id: <200808142125.m7ELPcLO002741@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: ipsec-core@sun.com Subject: EOF of 2001/070 IPsec HW Acceleration support [PSARC/2008/522 FastTrack timeout 08/21/2008] Status: RO Content-Length: 580 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: EOF of 2001/070 IPsec HW Acceleration support 1.2. Name of Document Author/Supplier: Author: Dan McDonald 1.3 Date of This Document: 14 August, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sommerfeld@sun.com Thu Aug 14 14:29:11 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7ELTAgS003017 for ; Thu, 14 Aug 2008 14:29:11 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7ELSsk6020812; Fri, 15 Aug 2008 05:29:07 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5M00F0710HXH00@brm-avmta-1.central.sun.com>; Thu, 14 Aug 2008 15:29:05 -0600 (MDT) Received: from thunk.east.sun.com ([129.148.174.66]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M00LPW10GJ1C0@brm-avmta-1.central.sun.com>; Thu, 14 Aug 2008 15:29:05 -0600 (MDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7ELT1qc003236; Thu, 14 Aug 2008 17:29:01 -0400 (EDT) Date: Thu, 14 Aug 2008 17:28:59 -0400 From: Bill Sommerfeld Subject: 2008/522 EOF of 2001/070 IPsec HW Acceleration support To: PSARC-ext Cc: Dan McDonald Message-id: <1218749340.2286.25.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 3286 I'm sponsoring this case for Dan McDonald. Timeout expires 8/21/2008. Release binding is Minor - this interface will only be removed from post-Solaris-10 releases. This is an Open case about a Contract Private interface implemented by a closed-source driver for EOL'ed hardware which is used by the open-source Solaris IP stack. ---- We propose to remove the use of the DL_CAPAB_IPSEC_* interface capabilities from the solaris IP stack in a future Minor release. This is a Contracted Consolidation Private interface between ON and CPG. The hardware product which exported this interface (SCA 4000 aka. "Venus") has been EOLed due to RoHS. The SCA4000 combined a gigabit ethernet port with a cryptographic coprocessor; the DL_CAPAP_IPSEC_* interfaces allowed the crypto-aware NIC on board the SCA4000 to encrypt and then transmit, or receive and decrypt, an IPsec-encrypted packet without sending the packet data over the I/O bus three times (in and out of a crypto unit and then out the ethernet). The follow-on RoHS-compliant SCA-6000 does not include the on-board NIC; no other devices are known to export the same acceleration interface. If we want to support similar devices in the future, we do not recommend reusing this interface; instead, we recommend extending GLDv3 to control the functionality and share the IPsec SADB with the card via a synchronous function-call interface. Description: ------------ Part of PSARC 2001/070 describes STREAMS interfaces provided by a hardware driver to enable Network Interface Card (NIC)-level acceleration of IPsec encryption or data integrity. The only provider of this interface was the Sun Crypto Accelerator 4000, aka. "Venus". Venus has been EOLed due to non-compliance with EU RoHS laws. According to the contract in 2001/070: 7. Changes to INTERFACES requires ARC approval. If SUPPLIER decides to change (including replace or remove) any portion of the INTERFACES, SUPPLIER will notify CONSUMER of the proposed new version, no later than the application for ARC approval of the new version. If SUPPLIER and CONSUMER are contained in the same bundle, they have the option of arranging for simultaneous conversion to the new interfaces. If this is not possible, or if they are not in the same bundle, then SUPPLIER will either make best effort to work with CONSUMER so that CONSUMER can detect which version of INTERFACES is being supplied, or else SUPPLIER will make best effort to supply both old and new versions of INTERFACES. If SUPPLIER cannot make both versions of INTERFACES available, and SUPPLIER and CONSUMER cannot devise a method whereby CONSUMER can detect which version of INTERFACES is being supplied, and the old version of CONSUMER will not run with the new version of SUPPLIER, then either the EOL process must be followed by SUPPLIER, or else a major release of SUPPLIER will be required. The SUPPLIER was CPG - the Venus folks. We propose to stop using this interface within the Solaris IPsec stack. The Venus card can continue to be used to provide general cryptographic acceleration and keystore functionality even without the use of this interface. From gdamore@sun.com Fri Aug 15 00:45:23 2008 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 m7F7jNI2026252 for ; Fri, 15 Aug 2008 00:45:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7F7jHUB022133; Fri, 15 Aug 2008 08:45:22 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5M00G0DTJJLU00@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 01:45:19 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5M00D3UTJIV610@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 01:45:19 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7F7jIZo009441; Fri, 15 Aug 2008 00:45:18 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5M00801THQE700@fe-sfbay-09.sun.com> (original mail from gdamore@sun.com) ; Fri, 15 Aug 2008 00:45:18 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5M00KCQTJILEF0@fe-sfbay-09.sun.com>; Fri, 15 Aug 2008 00:45:18 -0700 (PDT) Date: Fri, 15 Aug 2008 00:39:27 -0700 From: "Garrett D'Amore" Subject: Re: 2008/522 EOF of 2001/070 IPsec HW Acceleration support In-reply-to: <1218749340.2286.25.camel@thunk> Sender: Garrett.Damore@sun.com To: Bill Sommerfeld Cc: PSARC-ext , Dan McDonald Message-id: <48A532AF.2010201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1218749340.2286.25.camel@thunk> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 4321 I'm wholly in favor of this case. However, to be fully clear, the SCA4000 should not suffer any loss in functionality, as it can use what we used to call "slow path IPsec acceleration", that is, it can use kcf to perform crypto operations for it. HOWEVER, there may be potential ramifications for * performance -- the "slow path" causes packets to traverse PCI busses 3 times, as noted, and certainly involves more complexity in the paths (notably kcf scheduling of crypto gets involved). * FIPS 140-2 compliance for SCA 4000? (Not that anyone would be certifying SCA 4000 on post S10 releases)... * Potential (uncertain!) management considerations for secure key management, although its unclear to me that SCA 4000 ever properly secured IPsec session keys. (IKE should be able to use secure storage for public keys via kcf, though.) -- Garrett Bill Sommerfeld wrote: > I'm sponsoring this case for Dan McDonald. Timeout expires 8/21/2008. > Release binding is Minor - this interface will only be removed from > post-Solaris-10 releases. > > This is an Open case about a Contract Private interface implemented by a > closed-source driver for EOL'ed hardware which is used by the > open-source Solaris IP stack. > > ---- > > We propose to remove the use of the DL_CAPAB_IPSEC_* interface > capabilities from the solaris IP stack in a future Minor release. > This is a Contracted Consolidation Private interface between ON and > CPG. > > The hardware product which exported this interface (SCA 4000 > aka. "Venus") has been EOLed due to RoHS. > > The SCA4000 combined a gigabit ethernet port with a cryptographic > coprocessor; the DL_CAPAP_IPSEC_* interfaces allowed the crypto-aware > NIC on board the SCA4000 to encrypt and then transmit, or receive and > decrypt, an IPsec-encrypted packet without sending the packet data > over the I/O bus three times (in and out of a crypto unit and then out > the ethernet). > > The follow-on RoHS-compliant SCA-6000 does not include the on-board > NIC; no other devices are known to export the same acceleration > interface. > > If we want to support similar devices in the future, we do not > recommend reusing this interface; instead, we recommend extending > GLDv3 to control the functionality and share the IPsec SADB with the > card via a synchronous function-call interface. > > Description: > ------------ > > Part of PSARC 2001/070 describes STREAMS interfaces provided by a > hardware driver to enable Network Interface Card (NIC)-level > acceleration of IPsec encryption or data integrity. > > The only provider of this interface was the Sun Crypto Accelerator 4000, > aka. "Venus". Venus has been EOLed due to non-compliance with EU RoHS laws. > According to the contract in 2001/070: > > 7. Changes to INTERFACES requires ARC approval. If SUPPLIER decides > to change (including replace or remove) any portion of the > INTERFACES, SUPPLIER will notify CONSUMER of the proposed new > version, no later than the application for ARC approval of the new > version. If SUPPLIER and CONSUMER are contained in the same bundle, > they have the option of arranging for simultaneous conversion to the > new interfaces. If this is not possible, or if they are not in the > same bundle, then SUPPLIER will either make best effort to work with > CONSUMER so that CONSUMER can detect which version of INTERFACES is > being supplied, or else SUPPLIER will make best effort to supply both > old and new versions of INTERFACES. If SUPPLIER cannot make both > versions of INTERFACES available, and SUPPLIER and CONSUMER cannot > devise a method whereby CONSUMER can detect which version of > INTERFACES is being supplied, and the old version of CONSUMER will > not run with the new version of SUPPLIER, then either the EOL process > must be followed by SUPPLIER, or else a major release of SUPPLIER > will be required. > > The SUPPLIER was CPG - the Venus folks. We propose to stop using this > interface within the Solaris IPsec stack. The Venus card can continue > to be used to provide general cryptographic acceleration and keystore > functionality even without the use of this interface. > > > > From sommerfeld@sun.com Fri Aug 15 07:51:21 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FEpKYZ005770 for ; Fri, 15 Aug 2008 07:51:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m7FEpJO2031414; Fri, 15 Aug 2008 08:51:19 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K5N00201D9I8V00@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 08:51:18 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00LJFD9H3O30@brm-avmta-1.central.sun.com>; Fri, 15 Aug 2008 08:51:18 -0600 (MDT) Received: from localhost.east.sun.com (vroom.East.Sun.COM [129.148.19.3]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7FEpHvP001304; Fri, 15 Aug 2008 10:51:17 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m7FEpHDv027666; Fri, 15 Aug 2008 10:51:17 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m7FEpGFc027665; Fri, 15 Aug 2008 10:51:16 -0400 (EDT) Date: Fri, 15 Aug 2008 10:51:16 -0400 From: Bill Sommerfeld Subject: Re: 2008/522 EOF of 2001/070 IPsec HW Acceleration support In-reply-to: <48A532AF.2010201@sun.com> To: "Garrett D'Amore" Cc: PSARC-ext , Dan McDonald Message-id: <1218811876.6977.23.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1218749340.2286.25.camel@thunk> <48A532AF.2010201@sun.com> X-Authentication-warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 1946 On Fri, 2008-08-15 at 00:39 -0700, Garrett D'Amore wrote: > * performance -- the "slow path" causes packets to traverse PCI > busses 3 times, as noted, and certainly involves more complexity in the > paths (notably kcf scheduling of crypto gets involved). The SCA4000 IPsec offload interface only accelerates 3DES; all the cool kids are now using AES. AES in software (not to mention the niagara 2 crypto functional units) on current systems will be faster than 3DES offloaded through an SCA4000 using this interface and the data will also make only one traversal of an I/O bus. IMHO the primary motivation for building IPsec offload in the 2001/070 style would be for assurance, not performance reasons: 1) to allow sensitive keying material to stay entirely within the boundary of the cryptographic device 2) to allow for clear separation between cleartext and ciphertext. 2001/070 was built purely as an acceleration interface with no possibility of keeping session keys material out of the hands of the host processor. > * FIPS 140-2 compliance for SCA 4000? (Not that anyone would be > certifying SCA 4000 on post S10 releases)... can you be more specific about why this might matter? the 2001/070 interface involves the host IPsec passing raw (unwrapped) keying material to the driver. > * Potential (uncertain!) management considerations for secure key > management, although its unclear to me that SCA 4000 ever properly > secured IPsec session keys. it's quite clear that 2001/070 interface used with IKE and IPsec ESP/AH required keying material to leave and then reenter the FIPS 140 evaluation boundary of the card. > (IKE should be able to use secure storage > for public keys via kcf, though.) More importantly, IKE will continue to be able to use secure storage for the long-term private authentication/signature keys via kcf/PKCS#11 and either the SCA4000 or SCA6000 keystore. - Bill From gdamore@Sun.COM Fri Aug 15 08:05:38 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m7FF5bf3006238 for ; Fri, 15 Aug 2008 08:05:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m7FF5RUB001969; Fri, 15 Aug 2008 23:05:36 +0800 (SGT) 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 <0K5N00G01DX94U00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 08:05:33 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K5N00GEBDX90N00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 15 Aug 2008 08:05:33 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m7FF5X2Q023499; Fri, 15 Aug 2008 08:05:33 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K5N00L01DJ95N00@fe-sfbay-10.sun.com> (original mail from gdamore@sun.com) ; Fri, 15 Aug 2008 08:05:33 -0700 (PDT) Received: from [10.7.251.172] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K5N004UDDX8HDF0@fe-sfbay-10.sun.com>; Fri, 15 Aug 2008 08:05:33 -0700 (PDT) Date: Fri, 15 Aug 2008 07:59:40 -0700 From: "Garrett D'Amore" Subject: Re: 2008/522 EOF of 2001/070 IPsec HW Acceleration support In-reply-to: <1218811876.6977.23.camel@localhost> Sender: Garrett.Damore@Sun.COM To: Bill Sommerfeld Cc: PSARC-ext , Dan McDonald Message-id: <48A599DC.7040201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1218749340.2286.25.camel@thunk> <48A532AF.2010201@sun.com> <1218811876.6977.23.camel@localhost> User-Agent: Thunderbird 2.0.0.14 (X11/20080616) Status: RO Content-Length: 3603 Bill Sommerfeld wrote: > On Fri, 2008-08-15 at 00:39 -0700, Garrett D'Amore wrote: > >> * performance -- the "slow path" causes packets to traverse PCI >> busses 3 times, as noted, and certainly involves more complexity in the >> paths (notably kcf scheduling of crypto gets involved). >> > > The SCA4000 IPsec offload interface only accelerates 3DES; all the cool > kids are now using AES. AES in software (not to mention the niagara 2 > crypto functional units) on current systems will be faster than 3DES > offloaded through an SCA4000 using this interface and the data will also > make only one traversal of an I/O bus. > Agreed. Recall, I'm in favor of this case. If Venus is EOL, then simplifying our stack would be a good thing. There may be folks who still have to use 3DES. (Though its been enough years now that hopefully that number is approaching vanishingly small. But then I suspect the number of customers who purchased SCA 4000 boards was pretty small as well.) > IMHO the primary motivation for building IPsec offload in the 2001/070 > style would be for assurance, not performance reasons: > 1) to allow sensitive keying material to stay entirely within the > boundary of the cryptographic device > 2) to allow for clear separation between cleartext and ciphertext. > > 2001/070 was built purely as an acceleration interface with no > possibility of keeping session keys material out of the hands of the > host processor. > Yes. Session keys make it to the host driver. At the time we did the work, the IPsec offload "inline" using these primitives was substantially faster than the out-of-band approach using kcf. > >> * FIPS 140-2 compliance for SCA 4000? (Not that anyone would be >> certifying SCA 4000 on post S10 releases)... >> > > can you be more specific about why this might matter? the 2001/070 > interface involves the host IPsec passing raw (unwrapped) keying > material to the driver. > The driver wraps the key material before passing it to the hardware. Its goofy. Read more below. > >> * Potential (uncertain!) management considerations for secure key >> management, although its unclear to me that SCA 4000 ever properly >> secured IPsec session keys. >> > > it's quite clear that 2001/070 interface used with IKE and IPsec ESP/AH > required keying material to leave and then reenter the FIPS 140 > evaluation boundary of the card. > Ah, but there are some goofy things in the language of FIPS 140-2, where if the keying material is "encrypted" before leaving the boundary, (and no specification is given for the mode of encryption) then it is considered OK. (Basically even very lame encryption with a fixed key qualifies as seperation of key material and data into separate logical channels.) So the driver negotiates a wrapping key with the board, and the board exports session keys wrapped, where the driver unwraps them. From a security standpoint, it offers absolutely *no* improvement. But it allowed for a FIPS evaluation. I'm not sure this is the way the final product shipped, but it was the way we were doing at the time I left the team. (I wrote that goofy code, with grave misgivings about it at the time.) > >> (IKE should be able to use secure storage >> for public keys via kcf, though.) >> > > More importantly, IKE will continue to be able to use secure storage for > the long-term private authentication/signature keys via kcf/PKCS#11 and > either the SCA4000 or SCA6000 keystore. > Right. -- Garrett > - Bill > > > > From sommerfeld@sun.com Tue Aug 26 15:44:39 2008 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 m7QMic1M014892 for ; Tue, 26 Aug 2008 15:44:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7QMiaw3016577; Tue, 26 Aug 2008 23:44:36 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K6800B01CIB4L00@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 15:44:35 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K68004FACIA4W90@nwk-avmta-2.sfbay.sun.com>; Tue, 26 Aug 2008 15:44:35 -0700 (PDT) Received: from localhost.SFBay.Sun.COM (dhcp-umpk17-109-36.SFBay.Sun.COM [129.146.109.36]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m7QMiY3c057216; Tue, 26 Aug 2008 18:44:34 -0400 (EDT) Received: from localhost.SFBay.Sun.COM (localhost [127.0.0.1]) by localhost.SFBay.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m7QMiWqE009647; Tue, 26 Aug 2008 15:44:33 -0700 (PDT) Received: (from sommerfeld@localhost) by localhost.SFBay.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m7QMiW0P009646; Tue, 26 Aug 2008 15:44:32 -0700 (PDT) Date: Tue, 26 Aug 2008 15:44:32 -0700 From: Bill Sommerfeld Subject: Re: 2008/522 EOF of 2001/070 IPsec HW Acceleration support In-reply-to: <1218749340.2286.25.camel@thunk> To: PSARC-ext Cc: Dan McDonald Message-id: <1219790672.1822.17.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <1218749340.2286.25.camel@thunk> X-Authentication-warning: localhost.SFBay.Sun.COM: sommerfeld set sender to sommerfeld@sun.com using -f Status: RO Content-Length: 110 According to the minutes of the PSARC meeting of 8/20/2008, this case was approved. I've marked it as such.