Re: [storm] New IPsec security text for iSCSI

[<[e-mail]>]

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:[e-mail]]
> Sent: Thursday, October 20, 2011 1:43 PM
> To: Black, David; [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, October 20, 2011 5:30 AM
> To: [e-mail]; [e-mail]
> 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:[e-mail]]
> > Sent: Wednesday, October 19, 2011 9:46 PM
> > To: Black, David; [e-mail]
> > 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: [e-mail] [mailto:[e-mail]]
> > Sent: Wednesday, October 19, 2011 3:04 PM
> > To: [e-mail]; [e-mail]
> > 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
> > [phone]             FAX: [phone]
> > [e-mail]        Mobile: [phone]
> > ----------------------------------------------------
> >
> >
> 
>