Re: [storm] New IPsec security text for iSCSI

Mallikarjun Chadalapaka <cbm@chadalapaka.com> Thu, 20 October 2011 17:42 UTC

Return-Path: <cbm@chadalapaka.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 F06C321F8C07 for <storm@ietfa.amsl.com>; Thu, 20 Oct 2011 10:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level:
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599]
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 eaFy-voE7Z4H for <storm@ietfa.amsl.com>; Thu, 20 Oct 2011 10:42:59 -0700 (PDT)
Received: from snt0-omc3-s41.snt0.hotmail.com (snt0-omc3-s41.snt0.hotmail.com [65.54.51.78]) by ietfa.amsl.com (Postfix) with ESMTP id 257E921F8B84 for <storm@ietf.org>; Thu, 20 Oct 2011 10:42:58 -0700 (PDT)
Received: from SNT131-DS17 ([65.55.90.136]) by snt0-omc3-s41.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 10:42:59 -0700
X-Originating-IP: [131.107.0.94]
X-Originating-Email: [cbm@chadalapaka.com]
Message-ID: <SNT131-ds17D0EB0FD0ED74A054CC2BA0EB0@phx.gbl>
From: Mallikarjun Chadalapaka <cbm@chadalapaka.com>
To: <david.black@emc.com>, <storm@ietf.org>
References: <SNT131-ds2B6E0369C0591DF047263A0FD0@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E058D073AB1@MX14A.corp.emc.com> <SNT131-ds1880C1655AF3F4FAF6C4E0A0EB0@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E058D073B40@MX14A.corp.emc.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058D073B40@MX14A.corp.emc.com>
Date: Thu, 20 Oct 2011 10:42:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFuBqClpMPcT3PPU9Tf+R4RqFZPZAFpfFlKALIsbwsBX2xlFZYmsrPQ
Content-Language: en-us
X-OriginalArrivalTime: 20 Oct 2011 17:42:59.0233 (UTC) FILETIME=[B5366110:01CC8F4F]
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 17:43:00 -0000

OK, thanks David.  That explains it, :)

I have traced this issue back to an email conversation with Julian from
11/07 where we've agreed to bump this up to a MUST for the same reasons
you've articulated below.  In clear hindsight however, l should have
confirmed that IKEv1 cannot support 64-bit sequence numbers and should have
added the cross-reference to IKEv2, my bad.

In any case, it's good to clean this up now.  I will wait for list feedback
for a few more days, before adding this text to the draft.  Draft submission
cut-off date for Taipei IETF is only a few days away.

Thanks.

Mallikarjun



-----Original Message-----
From: david.black@emc.com [mailto:david.black@emc.com] 
Sent: Thursday, October 20, 2011 5:30 AM
To: cbm@chadalapaka.com; storm@ietf.org
Subject: RE: New IPsec security text for iSCSI

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
> ----------------------------------------------------
> 
>