Re: [storm] New IPsec security text for iSCSI

<david.black@emc.com> Thu, 20 October 2011 12:30 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D921721F8B32 for <storm@ietfa.amsl.com>; Thu, 20 Oct 2011 05:30:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LngEBZOCahXv for <storm@ietfa.amsl.com>; Thu, 20 Oct 2011 05:30:32 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 28C1121F8ADE for <storm@ietf.org>; Thu, 20 Oct 2011 05:30:31 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9KCUPsQ020388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2011 08:30:26 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 20 Oct 2011 08:30:10 -0400
Received: from mxhub15.corp.emc.com (mxhub15.corp.emc.com [128.221.56.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9KCUAt8028075; Thu, 20 Oct 2011 08:30:10 -0400
Received: from mxhub39.corp.emc.com (128.222.70.106) by mxhub15.corp.emc.com (128.221.56.104) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 Oct 2011 08:30:10 -0400
Received: from mx14a.corp.emc.com ([169.254.1.78]) by mxhub39.corp.emc.com ([128.222.70.106]) with mapi; Thu, 20 Oct 2011 08:30:09 -0400
From: <david.black@emc.com>
To: <cbm@chadalapaka.com>, <storm@ietf.org>
Date: Thu, 20 Oct 2011 08:30:06 -0400
Thread-Topic: New IPsec security text for iSCSI
Thread-Index: AQFuBqClpMPcT3PPU9Tf+R4RqFZPZAFpfFlKljYtaMCAAL4asA==
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058D073B40@MX14A.corp.emc.com>
References: <SNT131-ds2B6E0369C0591DF047263A0FD0@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E058D073AB1@MX14A.corp.emc.com> <SNT131-ds1880C1655AF3F4FAF6C4E0A0EB0@phx.gbl>
In-Reply-To: <SNT131-ds1880C1655AF3F4FAF6C4E0A0EB0@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [storm] New IPsec security text for iSCSI
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2011 12:30:33 -0000

Hi Mallikarjun,

The previous text in -03 of the consolidated draft was incorrect (sorry).

The problem is that 64-bit sequence numbers only exist in ESPv3 (part of
IPsec v3), and can only be turned on by IKEv2 (part of IPsec v3) - use of
IKEv1 or ESPv2 (part of IPsec v2) always results in use of 32 bit sequence
numbers.  So, the result is:

	- ESPv2 sequence numbers are always 32 bits (for both IKEv1 and IKEv2).
	- IKEv1 + ESPv3 is limited to 32 bit sequence numbers.
	- IKEv2 + ESPv3 is required in order to use 64 bit sequence numbers.

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> Sent: Wednesday, October 19, 2011 9:46 PM
> To: Black, David; storm@ietf.org
> Subject: RE: New IPsec security text for iSCSI
> 
> Hi David,
> 
> Many thanks for proposing the new text.  I have read through the proposed
> changes, and they all look consistent with the top-level summary you have
> provided below.
> 
> With respect to #2 below (implementations at 1Gbps or higher), I am reading
> your new text to mean different from your summary, I may just be misreading
> however.
> 
> Previous text required "MUST implement" of sequence number extension even
> with IKEv1.  The new text seems to limit the MUST requirement just to those
> that use IKEv2 - "... iSCSI implementation that is capable of operating  at
> speeds of 1 Gbps and that implements both IKEv2..."    IMHO, the older text
> already seems to have the requisite force you summarized below under #2.
> Please correct if I'm off in the weeds here....
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: david.black@emc.com [mailto:david.black@emc.com]
> Sent: Wednesday, October 19, 2011 3:04 PM
> To: cbm@chadalapaka.com; storm@ietf.org
> Subject: New IPsec security text for iSCSI
> 
> The attached text file contains the new security text for the iSCSI
> consolidated draft, with differences marked against the -03 version of that
> draft.  The primary changes are to rewrite the IPsec requirements as
> previously announced:
> 
> 	- MUST implement IPsec, 2400-series RFCs (IPsec v2, IKEv1).
> 	- SHOULD implement IPsec, 4300-series RFCs (IPsec v3, IKEv2).
> 
> In addition, I have made the following three IPsec requirements changes that
> seemed appropriate - an important purpose of this message is to solicit
> comments on them (including any objections):
> 
> 	1) If IKEv2 is supported, then AES GCM SHOULD be implemented.  AES GCM is
> 		(IMHO) a better choice than the combination of AES CBC MAC with XCBC
> 		and AES CTR, but I did not remove the SHOULD recommendations for
> 		the latter two (FWIW, both of these SHOULD be implemented for IKEv2,
> 		see RFC 4307).
> 	2) For implementations expected to operate at 1Gbps or greater: If ESPv3
> 		(part of IPsec v3) is implemented, extended (64-bit) sequence numbers
> 		MUST be implemented and SHOULD be used (RFC 3720 indicated that this
> 		requirement was coming, so here it is ...).
> 	3) DES MUST NOT be used (RFC 3720 specified that DES SHOULD NOT be used).
> 		The reason for this change should be obvious ;-).
> 
> I also added a paragraph to indicate that determination of which versions of
> IPsec are supported by a target is out of scope, but if both initiator and
> target support both IPsec v2 and v3, then use of v3 is recommended [lower
> case, this is deliberate].
> 
> Note that RFC 3723 needs to be added to the list of RFCs that are updated by
> the iSCSI consolidated draft.  There will be a number of references that
> will need to be added - I didn't put those into the attached text file.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> david.black@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 
>