Re: [storm] New IPsec security text for iSCSI

<david.black@emc.com> Thu, 20 October 2011 19:01 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 9D0551F0C4C for <storm@ietfa.amsl.com>; Thu, 20 Oct 2011 12:01: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=[AWL=0.000, 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 kVRNC0KZAVJR for <storm@ietfa.amsl.com>; Thu, 20 Oct 2011 12:01: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 9AEF11F0C35 for <storm@ietf.org>; Thu, 20 Oct 2011 12:01:22 -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 p9KJ1JQ5005621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2011 15:01:19 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 20 Oct 2011 15:01:16 -0400
Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p9KJ1FIF031165; Thu, 20 Oct 2011 15:01:16 -0400
Received: from mx14a.corp.emc.com ([169.254.1.78]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Thu, 20 Oct 2011 15:01:15 -0400
From: <david.black@emc.com>
To: <cbm@chadalapaka.com>, <storm@ietf.org>
Date: Thu, 20 Oct 2011 15:01:15 -0400
Thread-Topic: New IPsec security text for iSCSI
Thread-Index: AQFuBqClpMPcT3PPU9Tf+R4RqFZPZAFpfFlKALIsbwsBX2xlFZYmsrPQgAAcYAA=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058D073D45@MX14A.corp.emc.com>
References: <SNT131-ds2B6E0369C0591DF047263A0FD0@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E058D073AB1@MX14A.corp.emc.com> <SNT131-ds1880C1655AF3F4FAF6C4E0A0EB0@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E058D073B40@MX14A.corp.emc.com> <SNT131-ds17D0EB0FD0ED74A054CC2BA0EB0@phx.gbl>
In-Reply-To: <SNT131-ds17D0EB0FD0ED74A054CC2BA0EB0@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 19:01:33 -0000

Great - please make sure that these security requirements changes are
added to the section that summarizes changes from previous RFCs.

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> Sent: Thursday, October 20, 2011 1:43 PM
> To: Black, David; storm@ietf.org
> Subject: RE: New IPsec security text for iSCSI
> 
> 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
> > ----------------------------------------------------
> >
> >
> 
>