RE: iSCSI Security rough consensus

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

Mike,

My only point was that off-loading an end to end error check with hardware
raises the level of integrity which must be assured at the hardware/software
interface.  In essence, I was agreeing with Santosh while underlining the
initial concern.  As this concern is "Out of Scope", I too agree that this
will not be covered within this workgroup but an area left unresolved as it
relates to iSCSI.

Doug


> The end-to-end integrity checks are from a source fault zone to a
> destination fault zone.  What happens within a fault zone is
> implementation
> specific and beyond the scope of the iSCSI specification.  The litany of
> potential problems within a fault zone are interesting and are being
> addressed by various techniques all of which are again outside
> the scope of
> the iSCSI specification and clearly where many vendors will differentiate
> their product offerings.
>
> It would be beneficial to this workgroup to avoid mixing the
> fault zone and
> iSCSI requirements to avoid creating confusion or what may be
> construed as
> FUD.  The workgroup appears to be in consensus on where iSCSI integrity
> checking applies and the problems it addresses.  Unless there is
> something
> new to add from an iSCSI technical perspective in this area, may
> we move on
> to getting this specification complete so we can implement it and
> see if it
> really works.
>
> Mike
>
>
>
> At 07:03 PM 5/7/2001 -0700, Douglas Otis wrote:
> >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
> > >
> > >
>
>