RE: iSCSI Security rough consensus

["Douglas Otis" <dotis@sanlight.net>]

Somesh,

You have it correct.  The general intent of an end to end integrity check is
to do something light weight within software to catch a myriad of errors
that crop up due to various hardware failures (R*****k and M*******h as
example), as well as bugs within variations of the theme called TCP.  One
can only hope such checking automation does not introduce corrupt data as a
result.  New hardware/software MUST maintain integrity.  There is a history
that gives one pause however.

Doug


> I was trying not to react to the string of messages, but
> this message finally did it(and nothing wrong with the message
> itself and no offense meant to the author). What the message
> implies is that no intermediate hops can be trusted and that
> integrity must be end-to-end.
>
> Taken to the literal extreme, this means that the system must
> at the application level (in the host) generate some integrity
> checks which should then be verified every
> time the data is used (perhaps by an end application again).
>
> Even with the CRC, the following errors will go undetected,
> unless protected by some other means (well engineered, well
> tested devices)
>
> 1. Host software.
> 2. Host memory to adapter path
> 3. Adapter memory
> 4. Adapter software
> 5. Any virtualization device in the middle including
>       software, memory, fabric etc on the device including
>       any fibre-channel/scsi storage at the back end
>       (assuming they will recreate resegment PDUs)
> 6. Any target adapter & adapter memory
> 7. Any paths within the target
> 8. The storage itself
> 9. and then the reverse path
>
> If end-to-end integrity is a must, it seems that the TCP checksum
> offload and iSCSI CRC in off-board hardware must be avoided.
>
> Or did I miss something somewhere.
>
> Somesh
>
> > -----Original Message-----
> > From: vince_cavanna@agilent.com [mailto:vince_cavanna@agilent.com]
> > Sent: Monday, May 07, 2001 2:13 PM
> > To: mbakke@cisco.com; Black_David@emc.com
> > Cc: someshg@yahoo.com; ips@ece.cmu.edu; vince_cavanna@agilent.com
> > Subject: RE: iSCSI Security rough consensus
> >
> >
> > Here is a paper by well-known authors that supports Mark's
> reasoning that
> > the end-to-end iSCSI check is indispensable even when IPsec is on ....
> >
> > Jonathan Stone and Craig artridge in "When the CRC and TCP checksum
> > disagree" study the sources of errors that are not caught by link level
> > checks and that therefore stress a higher layer error check
> > mechansim. Such
> > errors are quite prevalent and one signifcant source of such
> errors is the
> > end-host itself. The authors emphasize that "hardware must not
> be trusted"
> > and that "many encryption solutions such as IPsec do not provide
> > additional
> > (over existing checks) protection because the encryption is
> > applied too late
> > in the transmission process, often after the data has passed
> through a DMA
> > engine. Rather the application must add the checksum before
> > handing its data
> > to TCP (ala SSL)". The authors recommend that "for truly
> valuable data (in
> > my opinion all data handled by iSCSI) the application should add
> > a stronger
> > application-level checksum".
> >
> > Vince
> >
> > |-----Original Message-----
> > |From: Mark Bakke [mailto:mbakke@cisco.com]
> > |Sent: Friday, May 04, 2001 1:04 PM
> > |To: Black_David@emc.com
> > |Cc: someshg@yahoo.com; ips@ece.cmu.edu
> > |Subject: Re: iSCSI Security rough consensus
> > |
> > |
> > |Black_David@emc.com wrote:
> > |>
> > |> > 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.
> > |>
> > |> It sure would be nice, and in fact we had almost
> > |> exactly this discussion later in the evening as
> > |> part of the error recovery section of the agenda.
> > |> The fly in the ointment is that the HMAC integrity
> > |> algorithm that is at the core of ESP's integrity
> > |> support is considerably more expensive (software
> > |> or hardware) than a CRC, and this isn't likely
> > |> to improve as I understand things.  I would expect
> > |> to see implementations with ESP completely in
> > |> software and visible performance impacts.
> > |
> > |That's just part of the reason behind having both.  The other is
> > |that most implementations won't run IPsec end-to-end; either IPsec
> > |is provided in an external device, or even in an iSCSI gateway.
> > |In the latter case, all layers are removed and replaced, including
> > |iSCSI.  Only the SCSI-level information (data, CDBs) go all the
> > |way end-to-end.  Since iSCSI can CRC the SCSI-level data, it can
> > |provide the data integrity that will keep our customers happy.
> > |
> > |The use of the iSCSI CRC is the minimum requirement; adding the
> > |IPsec-level integrity check strengthens it, and can simplify error
> > |recovery over a not-so-good or untrusted network.
> > |
> > |--
> > |Mark
> > |
> > |>
> > |> I really need to get the meeting minutes written up :-).
> > |>
> > |> 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
> > |> black_david@emc.com       Mobile: +1 (978) 394-7754
> > |> ---------------------------------------------------
> > |
> > |--
> > |Mark A. Bakke
> > |Cisco Systems
> > |mbakke@cisco.com
> > |763.398.1054
> > |
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>