Re: [storm] New IPsec security text for iSCSI

Mallikarjun Chadalapaka <> Thu, 20 October 2011 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F06C321F8C07 for <>; Thu, 20 Oct 2011 10:42:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eaFy-voE7Z4H for <>; Thu, 20 Oct 2011 10:42:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 257E921F8B84 for <>; Thu, 20 Oct 2011 10:42:58 -0700 (PDT)
Received: from SNT131-DS17 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 10:42:59 -0700
X-Originating-IP: []
X-Originating-Email: []
Message-ID: <SNT131-ds17D0EB0FD0ED74A054CC2BA0EB0@phx.gbl>
From: Mallikarjun Chadalapaka <>
To: <>, <>
References: <SNT131-ds2B6E0369C0591DF047263A0FD0@phx.gbl> <> <SNT131-ds1880C1655AF3F4FAF6C4E0A0EB0@phx.gbl> <>
In-Reply-To: <>
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.



-----Original Message-----
From: [] 
Sent: Thursday, October 20, 2011 5:30 AM
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
	- IKEv1 + ESPv3 is limited to 32 bit sequence numbers.
	- IKEv2 + ESPv3 is required in order to use 64 bit sequence numbers.


> -----Original Message-----
> From: Mallikarjun Chadalapaka []
> Sent: Wednesday, October 19, 2011 9:46 PM
> To: Black, David;
> 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
> 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: []
> Sent: Wednesday, October 19, 2011 3:04 PM
> To:;
> 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
> 		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
> 		(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
> 		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
>        Mobile: +1 (978) 394-7754
> ----------------------------------------------------