Re: [storm] New IPsec security text for iSCSI

Mallikarjun Chadalapaka <cbm@chadalapaka.com> Thu, 20 October 2011 01:46 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 02F701F0C4D for <storm@ietfa.amsl.com>; Wed, 19 Oct 2011 18:46:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 6mYRuFIYhI+V for <storm@ietfa.amsl.com>; Wed, 19 Oct 2011 18:46:27 -0700 (PDT)
Received: from snt0-omc3-s24.snt0.hotmail.com (snt0-omc3-s24.snt0.hotmail.com [65.55.90.163]) by ietfa.amsl.com (Postfix) with ESMTP id 66EDD1F0C4B for <storm@ietf.org>; Wed, 19 Oct 2011 18:46:27 -0700 (PDT)
Received: from SNT131-DS18 ([65.55.90.137]) by snt0-omc3-s24.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 18:46:26 -0700
X-Originating-IP: [131.107.0.94]
X-Originating-Email: [cbm@chadalapaka.com]
Message-ID: <SNT131-ds1880C1655AF3F4FAF6C4E0A0EB0@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>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058D073AB1@MX14A.corp.emc.com>
Date: Wed, 19 Oct 2011 18:46:25 -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+R4RqFZPZAFpfFlKljYtaMA=
Content-Language: en-us
X-OriginalArrivalTime: 20 Oct 2011 01:46:26.0905 (UTC) FILETIME=[14B81C90:01CC8ECA]
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 01:46:28 -0000

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