From krishna@sac.sfbay.sun.com Thu Sep 24 18:27:39 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8P1RdCI008877 for ; Thu, 24 Sep 2009 18:27:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8P1RZC7027441; Thu, 24 Sep 2009 18:27:38 -0700 (PDT) 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 <0KQI00C0D6Q1H800@brm-avmta-1.central.sun.com>; Thu, 24 Sep 2009 19:27:37 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQI008I46Q03KD0@brm-avmta-1.central.sun.com>; Thu, 24 Sep 2009 19:27:36 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8P1Raer019020; Thu, 24 Sep 2009 18:27:36 -0700 (PDT) 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 n8P1RZJc008872; Thu, 24 Sep 2009 18:27:35 -0700 (PDT) Received: (from krishna@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n8P1RZ5i008868; Thu, 24 Sep 2009 18:27:35 -0700 (PDT) Date: Thu, 24 Sep 2009 18:27:35 -0700 (PDT) From: Krishna Yenduri Subject: Changes to IPsec ESP to support Combined mode ciphers [PSARC/2009/513 FastTrack timeout 09/29/2009] To: PSARC-ext@sun.com Cc: mark.fenwick@sun.com Message-id: <200909250127.n8P1RZ5i008868@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 15734 I'm sponsoring the following fasttrack for Mark Fenwick. Timer expires 09/29/2009. I am setting a shorter timer at the request of the submitter. Please speak up if anyone needs more time. Release binding is Patch/Micro. Commitment levels match existing interfaces (Committed for CLI and PF_KEY, Project Private for PF_POLICY). Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Changes to IPsec ESP to support Combined mode ciphers 1.2. Name of Document Author/Supplier: Author: Mark Fenwick 1.3 Date of This Document: 24 September, 2009 4. Technical Description Description: ------------ IPsec ESP provides network packet encryption and authentication using encryption and authentication algorithms described by ipsecalgs(1m) and configured using the ipsecconf(1m) tokens: encr_algs ancr_auth_algs Each operation, that is encryption and authentication, is performed by a separate cryptographic mechanism in the encryption framework. The introduction of AES combined mode ciphers into the encryption framework began with AES CCM Mode (PSARC/2007/266), then AES GCM Mode. These combined mode ciphers provide a mechanism to encrypt and authenticate in a single operation. There are potential performance improvements when using combined mode ciphers. There are currently two combined mode AES cipher modes supported by the encryption framework: AES CCM - (Counter with CBC-MAC) AES GCM - (Galois/Counter Mode) AES GCM Mode is a requirement for NSA Suite B Cryptography, a US government standard for cryptographic algorithms. The support of AES GCM for IPsec ESP is a significant step towards Suite B compliance and puts Solaris on par with Linux and Microsoft Windows server 2008 R2 in this area. Implementation guidelines are provided by the following RFCs: 4309 - Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) 4106 - The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) Proposal: --------- The encryption framework mechanisms that support AES CCM/GCM require some additional parameters, which need to be provided by the key management mechanism (in.iked(1m) or ipseckey(1m)). To allow these parameters to be configured, the ipsecalgs(1m) command has been modified along with the getipsecalgsbyname() function. The changes are described below in the manual page diffs. The new ipsecalgs(1m) algorithm descriptions can be used by ipsecconf(1m) as part of the IPsec security policy. A new argument to ipseckey(1m) allows a specified number of bits in the keystring to be reserved, these are used for testing the algorithm, they would not be used in practice. The changes here are backwards compatible with existing IPsec algorithms and configuration. These changes are tracked by the following CRs: 6704686 IPsec/ESP needs to support Combined mode ciphers 6704682 IPsec/ESP should use AES-CCM 6884664 IPsec/ESP should support AES-GCM Mode 6843044 Need STC support for AES CCM/GCM Modes Details: -------- The following changes are proposed to pfkeyv2.h: New PF_KEY Encryption algorithms: #define SADB_EALG_AES_CCM_8 14 #define SADB_EALG_AES_CCM_12 15 #define SADB_EALG_AES_CCM_16 16 #define SADB_EALG_AES_GCM_8 18 #define SADB_EALG_AES_GCM_12 19 #define SADB_EALG_AES_GCM_16 20 The following changes to pfpolicy.h: New flags: #define ALG_FLAG_VALID 0x01 #define ALG_FLAG_COUNTERMODE 0x02 #define ALG_FLAG_COMBINED 0x04 #define ALG_FLAG_CCM 0x08 #define ALG_FLAG_GCM 0x10 New SPD attributes: #define SPD_ATTR_ALG_NPARAMS 0x00000122 #define SPD_ATTR_ALG_PARAMS 0x00000123 #define SPD_ATTR_ALG_FLAGS 0x00000124 The following changes to netdb.h: The a_mech_params and a_alg_flags elements have been added to ipsecalgent_t: typedef struct ipsecalgent { char **a_names; /* algorithm names */ int a_proto_num; /* protocol number */ int a_alg_num; /* algorithm number */ char *a_mech_name; /* encryption framework mechanism name */ int *a_block_sizes; /* supported block sizes */ int *a_key_sizes; /* supported key sizes */ int a_key_increment; /* key size increment */ int *a_mech_params; /* mechanism specific parameters */ int a_alg_flags; /* algorithm flags */ } ipsecalgent_t; Interfaces: ----------- +-----------------------------------+--------------------+---------------------+ | Interface Name | Commitment | Comments | +-----------------------------------+--------------------+---------------------+ | ipseckey(1m) commands: | Committed | documented in man | | reserved_bits | | page. | +-----------------------------------+--------------------+---------------------+ | ipsecalgs(1m) commands: | Committed | documented in man | | -M flag | | page. | | -I flag | | | | -S flag | | | +-----------------------------------+--------------------+---------------------+ | netdb.h | Committed | documented in man | | *a_mech_params | | page. | | a_alg_flags | | | +-----------------------------------+--------------------+---------------------+ | pfkeyv2.h | Committed | The respective | | SADB_EALG_AES_CCM_8 | | numbers were assigned| | SADB_EALG_AES_CCM_12 | | by IANA. | | SADB_EALG_AES_CCM_16 | | | | SADB_EALG_AES_GCM_8 | | | | SADB_EALG_AES_GCM_12 | | | | SADB_EALG_AES_GCM_16 | | | +-----------------------------------+--------------------+---------------------+ | pfpolicy.h | Project Private | | | ALG_FLAG_VALID | | | | ALG_FLAG_COUNTERMODE | | | | ALG_FLAG_COMBINED | | | | ALG_FLAG_CCM | | | | ALG_FLAG_GCM | | | | SPD_ATTR_ALG_NPARAMS | | | | SPD_ATTR_ALG_PARAMS | | | | SPD_ATTR_ALG_FLAGS | | | +-----------------------------------+--------------------+---------------------+ Man page changes: ----------------- getipsecalgbyname(3NSL) *** getipsecalgbyname.orig.text Mon Sep 21 16:34:28 2009 --- getipsecalgbyname.text Wed Sep 23 12:34:20 2009 *************** *** 102,111 **** --- 102,113 ---- int a_alg_num; /* algorithm number */ char *a_mech_name; /* mechanism name */ int *a_block_sizes; /* supported block sizes */ int *a_key_sizes; /* supported key sizes */ int a_key_increment; /* key size increment */ + int *a_mech_params; /* mechanism specific parameters */ + int a_alg_flags; /* algorithm flags */ } ipsecalgent_t; If a_key_increment is non-zero, a_key_sizes[0] contains the *************** *** 150,162 **** a_block_sizes is an array containing the supported block lengths or MAC lengths, in bytes, supported by the algo- rithm. The last valid value in the array is followed by an element containing the value 0. ERRORS When the specified algorithm cannot be returned to the ! caller, getipsecalgbynam() and getipsecalgbynum() return a value of NULL and set the integer pointed to by the errnop parameter to one of the following values: ENOMEM Not enough memory --- 152,174 ---- a_block_sizes is an array containing the supported block lengths or MAC lengths, in bytes, supported by the algo- rithm. The last valid value in the array is followed by an element containing the value 0. + a_mech_params is an array containing any additional + algorithm parameters needed by the cryptographic framework + mechanism. The order of the parameters and their use is not + specified. The last valid value in the array is followed by + an element containing the value 0. + + a_alg_flags is a bit mask of flags, these are used internally + by the IPsec esp code and by the IPsec administrative utilities. + Their meaning is not described here. + ERRORS When the specified algorithm cannot be returned to the ! caller, getipsecalgbyname() and getipsecalgbynum() return a value of NULL and set the integer pointed to by the errnop parameter to one of the following values: ENOMEM Not enough memory ipsecalgs(1m) *** ipsecalgs.orig.text Mon Sep 21 15:25:40 2009 --- ipsecalgs.text Thu Sep 24 17:07:34 2009 *************** *** 314,324 **** --- 314,353 ---- mation is not passed on to the kernel unless the -s is used. See NOTES for a description of how the ipsecalgs configuration is synchronized with the kernel at sys- tem restart. + The following options allow optional parameters to be configured. + These are currently only used for combined mode algorithms, that + is, algorithms that provide encryption and authentication in a + single operation. + -I The length of the Initialization Vector (IV) in bytes. + The default IV length is the same as the block length. + + -M The length of the MAC or ICV in bytes for combined mode + algorithms. + + -S The number of bytes of salt needed by the algorithm. The + salt needs to be provided by the key management mechanism. + + -F Algorithm flags. These influence the way in which the kernel + handles esp authentication in the kernel. They are also used + by ipseckey(1m) and ipsecconf(1m). Flags can be specified as + a comma separated list of tokens, see the example below. The + following tokens are supported: + + COUNTERMODE - The algorithm uses counter mode. + COMBINED - The algorithm provides encryption and authentication + in the same operation. + CCM - The cryptographic framework mechanism needs a + CK_AES_CCM_PARAMS structure. + GCM - The cryptographic framework mechanism needs a + CK_AES_GCM_PARAMS structure. + + The algorithm flags can be displayed with the -l option. + EXAMPLES Example 1 Adding a Protocol for IPsec Encryption *************** *** 364,374 **** --- 393,409 ---- example# svcadm refresh ipsecalgs + Example 4 Adding the AES Galois/Counter Mode (GCM) Algorithm + example# ipsecalgs -a -P3 -k 128-256 -K 128 -i 64 -N 20 -b 16 \ + -n "aes-gcm16,aes-gcm" -m CKM_AES_GCM -M 16 -I 8 -S 4 \ + -F GCM,COMBINED,COUNTER + + FILES /etc/inet/ipsecalgs File that contains the configured IPsec protocols and algorithm definitions. Never edit this file manually. ipsecconf(1m) *** ipsecconf.orig.text Mon Sep 21 16:58:37 2009 --- ipsecconf.text Thu Sep 24 11:08:21 2009 *************** *** 449,459 **** hmac-sha1 | hmac-sha256 | hmac-sha384 | hmac-sha512 | encr_alg ::= ['(' ')'] encr_algname ::= any | aes | aes-cbc | des | des-cbc | 3des | ! 3des-cbc | blowfish | blowfish-cbc | SunOS 5.11 Last change: 10 Jan 2008 7 --- 449,460 ---- hmac-sha1 | hmac-sha256 | hmac-sha384 | hmac-sha512 | encr_alg ::= ['(' ')'] encr_algname ::= any | aes | aes-cbc | des | des-cbc | 3des | ! 3des-cbc | blowfish | blowfish-cbc | aes-ccm | ! aes-gcm | SunOS 5.11 Last change: 10 Jan 2008 7 *************** *** 1671,1680 **** --- 1672,1704 ---- # Cover remote-site B traffic to my subnet. {tunnel ip.tun1 negotiate tunnel raddr B-prefix/24 laddr C-prefix/24} ipsec {encr_algs aes encr_auth_algs md5} + Example 18 Using Combined mode ciphers. + + Combined mode ciphers provide data privacy and message + authentication in a single operation. They are treated as special + versions of encr_algs. They provide message authentication + without the need to specify encr_auth_algs. The two combined mode + ciphers supported are: + + aes-ccm - AES CCM Mode(Counter with CBC-MAC) + aes-gcm - AES GCM Mode (Galois/Counter) + + The parameters used are the same as any other encr_algs value. + In both examples, the number in the algorithm token indicates the + length of the Integrity Check Vector (ICV) - see ipsecalgs(1m). + + # simple example using transport mode + {laddr 192.168.99.2 raddr 192.168.99.3} ipsec + {encr_algs aes-gcm sa shared} + # simple example using CCM mode and 128 bit keys + {laddr 192.168.99.100 raddr 192.168.99.200} ipsec + {encr_algs aes-ccm(128) sa shared} + + FILES /var/run/ipsecpolicy.conf Cache of IPsec policies currently configured for the system, maintained by ipsecconf command. Do not edit ipseckey(1m) *** ipseckey.orig.text Mon Sep 21 16:50:38 2009 --- ipseckey.text Mon Sep 21 16:58:04 2009 *************** *** 750,761 **** --- 750,766 ---- multi-key encryption algorithm is 3des, which would express itself as a 192-bit key, which is three 64-bit parity-included DES keys. This extension is used by the add and update commands. + reserved_bits + The last bits of the encrkey string are marked as + reserved in the PF_KEY message. This option is only for + testing certain encryption algorithms. + Certificate identities are very useful in the context of automated key management, as they tie the SA to the public key certificates used in most automated key management pro- tocols. They are less useful for manually added SAs. Unlike other extensions, srcidtype takes two values, a type, and an 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 Darren.Moffat@sun.com Fri Sep 25 01:53:08 2009 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 n8P8r739029814 for ; Fri, 25 Sep 2009 01:53:08 -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 n8P8r3pf012736 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 25 Sep 2009 16:53:06 +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 <0KQI00F0JRCH4M00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 01:53:05 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQI0029CRCGJE50@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 01:53:05 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8P8r3vU018726 for ; Fri, 25 Sep 2009 08:53:04 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQI00700PVFQ700@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 25 Sep 2009 09:52:55 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQI008F9RBXFB30@fe-emea-09.sun.com>; Fri, 25 Sep 2009 09:52:45 +0100 (BST) Date: Fri, 25 Sep 2009 09:52:45 +0100 From: Darren J Moffat Subject: Re: Changes to IPsec ESP to support Combined mode ciphers [PSARC/2009/513 FastTrack timeout 09/29/2009] In-reply-to: <200909250127.n8P1RZ5i008868@sac.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Krishna Yenduri Cc: PSARC-ext@sun.com, Mark.Fenwick@sun.com Message-id: <4ABC84DD.5090602@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909250127.n8P1RZ5i008868@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 516 All looks perfectly reasonable and as I'd expected given I'm familiar with IPsec and the use of CCM GCM modes. One small question though. I assume that /etc/inet/ipsecalgs will be updated by this case so that CCM and GCM are available without the admin having to run ipsecalgs(1M). I also assume that the already existing svc:/network/ipsec/ipsecalgs:default will be the SMF service doing this update - since we should no longer attempt to do this in class action or postinstall scripts. -- Darren J Moffat From Mark.Fenwick@sun.com Fri Sep 25 08:38:22 2009 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 n8PFcMZV007333 for ; Fri, 25 Sep 2009 08:38:22 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8PFcIrr055949; Fri, 25 Sep 2009 09:38:20 -0600 (MDT) 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 <0KQJ00K0JA3UK500@nwk-avmta-1.sfbay.Sun.COM>; Fri, 25 Sep 2009 08:38:18 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00CZ3A3TXJ30@nwk-avmta-1.sfbay.Sun.COM>; Fri, 25 Sep 2009 08:38:17 -0700 (PDT) Received: from youngs (punchin-client-10-7-250-59.SFBay.Sun.COM [10.7.250.59]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n8PFcGag196166; Fri, 25 Sep 2009 08:38:16 -0700 (PDT) Date: Fri, 25 Sep 2009 08:38:15 -0700 (PDT) From: Mark Fenwick Subject: Re: Changes to IPsec ESP to support Combined mode ciphers [PSARC/2009/513 FastTrack timeout 09/29/2009] In-reply-to: Your message with ID <4ABC84DD.5090602@Sun.COM> To: Darren J Moffat Cc: Krishna Yenduri , PSARC-ext@sun.com, Mark.Fenwick@sun.com Reply-to: Mark Fenwick Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1376 Hi Darren, > One small question though. I assume that /etc/inet/ipsecalgs will be > updated by this case so that CCM and GCM are available without the admin > having to run ipsecalgs(1M). I also assume that the already existing > svc:/network/ipsec/ipsecalgs:default will be the SMF service doing this > update - since we should no longer attempt to do this in class action or > postinstall scripts. /etc/inet/ipsecalgs will be updated, this means that new installs will get this file with GCM/CCM already in place. The class action script has been updated so that BFU and upgrade using SVR4 packages will do the right thing. Existing IPS installs will NOT get the new file when they do an image-update, they will have to run ipsecalgs(1m), but only if they want to use these new ciphers. IPsec will work just fine with the old ipsecalgs file for the existing ciphers. We plan on addressing ipsecalgs/IPS as a separate project, straight after this is done. Hope this clarifies. Mark ---------------------------------------------------------------------------- Mark Fenwick, Solaris Security Technologies. TEL: +1 (650) 786 2733 (X82733) __o Sun Microsystems Inc, Menlo Park, California. `\<,_ (*)/ (*) ---------------------------------------------------------------------------- From Mark.Fenwick@sun.com Mon Sep 28 10:46:10 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 n8SHk9aJ022651 for ; Mon, 28 Sep 2009 10:46:10 -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 n8SHk5CU011030; Mon, 28 Sep 2009 18:46:07 +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 <0KQP0090F00U3000@brm-avmta-1.central.sun.com>; Mon, 28 Sep 2009 11:46:06 -0600 (MDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP00MTB00T9S80@brm-avmta-1.central.sun.com>; Mon, 28 Sep 2009 11:46:05 -0600 (MDT) Received: from sr2-opensolaris (sr2-opensolaris.SFBay.Sun.COM [10.5.238.201]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with SMTP id n8SHk46j613137; Mon, 28 Sep 2009 10:46:04 -0700 (PDT) Date: Mon, 28 Sep 2009 10:46:12 -0700 (PDT) From: Mark Fenwick Subject: Re: Changes to IPsec ESP to support Combined mode ciphers [PSARC/2009/513 FastTrack timeout 09/29/2009] In-reply-to: Your message with ID To: Mark Fenwick Cc: Darren J Moffat , Krishna Yenduri , PSARC-ext@sun.com Reply-to: Mark Fenwick Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1776 See note inline: > > One small question though. I assume that /etc/inet/ipsecalgs will be > > updated by this case so that CCM and GCM are available without the admin > > having to run ipsecalgs(1M). I also assume that the already existing > > svc:/network/ipsec/ipsecalgs:default will be the SMF service doing this > > update - since we should no longer attempt to do this in class action or > > postinstall scripts. > > /etc/inet/ipsecalgs will be updated, this means that new installs will get > this file with GCM/CCM already in place. The class action script has been > updated so that BFU and upgrade using SVR4 packages will do the right thing. > Existing IPS installs will NOT get the new file when they do an > image-update, they will have to run ipsecalgs(1m), but only if they want to > use these new ciphers. IPsec will work just fine with the old ipsecalgs file > for the existing ciphers. I stand corrected, for an IPS install, image-update will replace the existing /etc/inet/ipsecalgs with the new one (which will include the new definitions for CCM/GCM), *provided* the user didn't modify this file with ipsecalgs(1m) after it was originally installed. This will probably cover almost all existing installations, the use of ipsecalgs(1m) to modify the definitions is not typical, usually only required for third-party algorithm support. Sorry for the confusion. Mark ---------------------------------------------------------------------------- Mark Fenwick, Solaris Security Technologies. TEL: +1 (650) 786 2733 (X82733) __o Sun Microsystems Inc, Menlo Park, California. `\<,_ (*)/ (*) ---------------------------------------------------------------------------- From Darren.Moffat@sun.com Mon Sep 28 11:33:13 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SIXCGQ024779 for ; Mon, 28 Sep 2009 11:33:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8SIXBj4028341 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 28 Sep 2009 11:33:11 -0700 (PDT) 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 <0KQP0090D27BXY00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Sep 2009 11:33:11 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP007Q027BCR30@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Sep 2009 11:33:11 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8SIXAJ7017476 for ; Mon, 28 Sep 2009 18:33:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQP00K0023G6U00@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Mon, 28 Sep 2009 19:33:05 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQP00AAT275JM60@fe-emea-09.sun.com>; Mon, 28 Sep 2009 19:33:05 +0100 (BST) Date: Mon, 28 Sep 2009 19:33:05 +0100 From: Darren J Moffat Subject: Re: Changes to IPsec ESP to support Combined mode ciphers [PSARC/2009/513 FastTrack timeout 09/29/2009] In-reply-to: Sender: Darren.Moffat@sun.com To: Mark Fenwick Cc: Krishna Yenduri , PSARC-ext@sun.com Message-id: <4AC10161.2030105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 1457 Mark Fenwick wrote: > See note inline: > >>> One small question though. I assume that /etc/inet/ipsecalgs will be >>> updated by this case so that CCM and GCM are available without the admin >>> having to run ipsecalgs(1M). I also assume that the already existing >>> svc:/network/ipsec/ipsecalgs:default will be the SMF service doing this >>> update - since we should no longer attempt to do this in class action or >>> postinstall scripts. >> /etc/inet/ipsecalgs will be updated, this means that new installs will get >> this file with GCM/CCM already in place. The class action script has been >> updated so that BFU and upgrade using SVR4 packages will do the right thing. >> Existing IPS installs will NOT get the new file when they do an >> image-update, they will have to run ipsecalgs(1m), but only if they want to >> use these new ciphers. IPsec will work just fine with the old ipsecalgs file >> for the existing ciphers. > > I stand corrected, for an IPS install, image-update will replace the existing /etc/inet/ipsecalgs with the new one (which will include the new definitions for CCM/GCM), *provided* the user didn't modify this file with ipsecalgs(1m) after it was originally installed. This will probably cover almost all existing installations, the use of ipsecalgs(1m) to modify the definitions is not typical, usually only required for third-party algorithm support. with that I gladly give the case my +1. -- Darren J Moffat From bhargava.yenduri@sun.com Wed Sep 30 10:26:23 2009 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 n8UHQMu7023843 for ; Wed, 30 Sep 2009 10:26:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8UHQIN7025629; Thu, 1 Oct 2009 01:26:20 +0800 (SGT) 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 <0KQS00109OFU1000@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 10:26:18 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQS00ILGOFTQ460@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 10:26:17 -0700 (PDT) Received: from [129.150.12.169] (vpn-129-150-12-169.SFBay.Sun.COM [129.150.12.169]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8UHQGLo147280; Wed, 30 Sep 2009 10:26:17 -0700 (PDT) Date: Wed, 30 Sep 2009 10:25:28 -0700 From: Krishna Yenduri Subject: Re: Changes to IPsec ESP to support Combined mode ciphers [PSARC/2009/513 FastTrack timeout 09/29/2009] In-reply-to: <200909250127.n8P1RZ5i008868@sac.sfbay.sun.com> To: PSARC-ext@sun.com Cc: mark.fenwick@sun.com Message-id: <4AC39488.6050405@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909250127.n8P1RZ5i008868@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 108 This case timed out yesterday and has a +1 from a member. Marking this case approved. Regards, -Krishna