Re: iSCSI draft 02: digests

[Mark Bakke <mbakke@cisco.com>]

Kalman-

We could define a digest that used private keys to do this, and
the negotiation mechanism supports the addition of such a scheme.
However, putting in MD5 or SHA instead of a CRC is computationally
intensive, and I think that a CRC should still be the "default"
data integrity mechanism that most implementations will support.
I think that you are right about a malicious snooper getting in
the way; if the snooper consistently messes us up, building new
connections may not fix the problem.  In this case, detecting the
problem is all we can do.

BTW, when we talk about rebuilding a connection, we really are doing
that -- terminating the old TCP connection, and starting a brand-new
one, within the same session if possible.  This is different from
resetting a connection.

One side note about this is that the CRC is really meant to protect
the SCSI data itself (along with commands and status), and as such
has to be done at the iSCSI level.  When someone malicious is added
to the middle, it seems that the TCP stream itself is the entity
to be protected.  Since this usually means protecting data privacy,
and preventing replay as well as protecting integrity, I would
recommend that in these cases running iSCSI over IPSec would be a
simpler approach that would not affect iSCSI itself quite so much.
Besides, hardware is already available to do IPSec at reasonably
high speeds.

--
Mark

meth@il.ibm.com wrote:
> 
> Randall, Mark, Julian,
> Can't the digest also be used to detect a snooper? The iSCSI packet may
> have been intercepted by a malicious snooper, the packet may have been
> corrupted, and the checksum may have been fixed up to reflect the corrupted
> packet. The digest, if it is built using the original sender's private key,
> cannot be fixed up by a malicious snooper, and hence the receiver detects
> the corruption of the packet. In this case TCP is not at fault. Does
> resetting the connection gain us anything in this case?
> 
> - Kalman Meth
> 
> "Randall R. Stewart" <randall@stewart.chicago.il.us> on 05/12/2000 18:17:39
> 
> Please respond to "Randall R. Stewart" <randall@stewart.chicago.il.us>
> 
> To:   Mark Bakke <mbakke@cisco.com>
> cc:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
> Subject:  Re: iSCSI draft 02: digests
> 
> Mark/Julian:
> 
> Mark Bakke wrote:
> >
> > Yes, the connection should not be recovered, but the iSCSI session
> > can be.
> 
> I have thought on this for a bit, and it seems to me one must
> have a look at what went wrong if a digest fails and yet TCP
> still delivered the packet. Was it TCP's fault? Well in some
> ways one could answer yes... since what happened is a sequence
> of bit errors was somewhere introduced to the IP packets that
> caused:
> 
> A) TCP's (and IP's) checksum to still pass
> and
> B) The stronger digest protection detected the error.
> 
> Now then, the question is how can we fix the problem?
> I think that you must get a new copy of the bad segment
> to the receiver... Here in lies the question, what will
> make it so we can do so:
> 
> Will restarting the TCP connection (or keeping the same
> one for that matter), make any difference? I don't think
> so... it was something in the network that caused this
> error to occur, if it is a fluke then retransmitting the
> packet on the same or a new connection will not make
> a bit of difference ... since it is the network that
> corrupted the packet. If it is not a fluke random chance, then
> you have a more serious network (or TCP stack) problem and
> all the restarts in the world are not going to make the packet
> go through since the network or stack will just keep re-corrupting
> the packet...
> 
> Bottom line is I am not convinced reseting the connection will
> gain you anything.. I don't think it will hurt .. but I don't
> see you gaining anything...
> 
> R
> 
> >
> > --
> > Mark
> >
> > julian_satran@il.ibm.com wrote:
> > >
> > > Mark,
> > >
> > > I also gave it some more thought.
> > >
> > > Since a digest failure is a transport failure that went undetected by
> TCP
> > > dropping and restarting a connection won't do us to much good - if we
> use
> > > the same link we may end up having some more.
> > >
> > > We should treat them as iSCSI failures and have iSCSI restart the
> command
> > > without restarting the connection.
> > >
> > > Regards,
> > > Julo
> > >
> > > Mark Bakke <mbakke@cisco.com> on 05/12/2000 00:18:28
> > >
> > > Please respond to Mark Bakke <mbakke@cisco.com>
> > >
> > > To:   Julian Satran/Haifa/IBM@IBMIL
> > > cc:   ips@ece.cmu.edu
> > > Subject:  Re: iSCSI draft 02: digests
> > >
> > > Julian-
> > >
> > > Here's what we had in mind for recovering from digest/CRC failures:
> > >
> > > 1. If the digest failure is on a command, status, or iSCSI header,
> > >    this means that a length field could be corrupted.  This should
> > >    not happen often, but it may be possible to re-send the command
> > >    if both the initiator and target can do session recovery as in
> > >    the iSCSI spec.  In any case, the connection should be terminated,
> > >    and a new one built in its place.  If session recovery is supported
> > >    and is successful, the missing iSCSI PDU(s) during and after the
> > >    digest failure are re-send, re-responded, and no harm done.  If
> > >    session recovery fails, the upper SCSI layer must receive the
> > >    failure, and do whatever recovery is necessary.  In any case, the
> > >    old connection should not be used after the failure.
> > >
> > > 2. If the digest failure is on a SCSI data block, iSCSI length fields
> > >    are not affected, so there may be a possible way to resend the
> > >    data.  However, doing this is probably not worthwhile, so I think
> > >    that in the data digest case, the same recovery as in (1) should
> > >    be used.
> > >
> > > --
> > > Mark
> > >
> > > julian_satran@il.ibm.com wrote:
> > > >
> > > > Like on a data failure on any bus. Raise a check condition and end
> the
> > > > command with an error but let it go up to
> > > > the normal end.  I will spec it.
> > > >
> > > > Thanks,
> > > > Julo
> > > >
> > > > Matt Wakeley <matt_wakeley@agilent.com> on 29/11/2000 01:39:22
> > > >
> > > > Please respond to Matt Wakeley <matt_wakeley@agilent.com>
> > > >
> > > > To:   ips@ece.cmu.edu
> > > > cc:
> > > > Subject:  iSCSI draft 02: digests
> > > >
> > > > In appendix A is a (brief) description of the iSCSI header and data
> > > > digests.
> > > >
> > > > What is the expected behavior if there is a digest failure?  Just
> throw
> > > the
> > > > PDU away?
> > > >
> > > > -Matt
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> 
> --
> Randall R. Stewart
> randall@stewart.chicago.il.us or rrs@cisco.com
> 815-342-5222 (cell) 815-477-2127 (work)

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054