Subject: RE: iSCSI Security rough consensus

From: "Somesh Gupta" <[email-masked]>
Date: Fri, 4 May 2001 12:05:10 -0700

David,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, May 04, 2001 11:58 AM
> To: [email-masked]; [email-masked]
> Subject: RE: iSCSI Security rough consensus
> 
> 
> > Does this consensus mean that the iSCSI header and data CRCs
> > are no longer part of the specification, or are we
> > still requiring one or the other or both?
> 
> Repeat after me: "CRCs are not security mechanisms" ;-)
> ;-), and see the previous email on this list about the
> consequences of WEP trying to use CRCs in this fashion.

  My only excuse is that I did not mean "CRCs are a security
  mechanism":-) I only meant that since ESP will provide
  integrity (and authentication), will we still have CRCs.
> 
> Yes, CRCs are still required for data integrity (e.g.,
> when ESP is not present).  If one knows that ESP with
> its keyed HMAC is being used in the stack between TCP and
> IP, then it would make sense not to use CRCs at the iSCSI
> level, hence they're required to implement, but configurable
> to use (which will also be the case for ESP).

  Sure would be nice if we could make up our minds and just
  implement one mechanism.

  Here we have two mechanisms (iSCSI header/data integrity
  and ESP) which are both mandatory to implement and 
  optional to use. Since ESP seems like a superset why not
  just have that and get rid of the "integrity only" iSCSI
  CRC mechanism.

  Hopefully this will lead to everyone implementing it and
  using it (leading to a better and more secure world :-)).  

> This may
> not always be possible, as one of the things mentioned
> in the meeting is that if the IPSec implementation is
> independent of iSCSI (e.g., supplied as part of the OS),
> there's no general standard way for iSCSI to figure out
> that IPSec is there or what it's doing to traffic on any
> particular iSCSI connection.
> 
> Thanks,
> --David
> 
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> [email-masked]       Mobile: +1 (978) 394-7754
> ---------------------------------------------------

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: [email-masked]
Date: Fri, 4 May 2001 14:57:41 -0400

to use (which will also be the case for ESP).  This may

Thanks,
--David

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 May 2001 15:44:46 -0700 (PDT)

> > to use (which will also be the case for ESP).

The issue here is where the data invalidation is coming from. If it is
occuring on the wire, then IPSEC will solve the problem and a CRC (or a
TCP checksum for that matter) is redundant. However, if it is occuring
later, then IPSEC may not be an appropriate solution, particularly since
acceleration technologies mean that IPSEC may be stripped off even before
the packet is moved off the interface for the first time. 

Ultimately the decision should rest on consideration of the
empirical evidence of where the problem is.