RE: iSCSI Security rough consensus

[Michael Krause <krause@cup.hp.com>]

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
> >
> >