Re: iSCSI: response to second login (with same ISID)

[Stephen Bailey <steph@cs.uchicago.edu>]

Nick & Santosh,

> I expect other folks will be clever enough to think of other ways to use
> this "user mode access" capability of TCP/IP to use remote iSCSI devices
> without kernel co-operation.  Can we enable them to peacefully co-exist with
> each other?  Can they peacefully co-exist with kernel mode drivers?

There's a nice, elegant can of worms, I mean solution, to this
problem.  In fact, I'm sure this is probably just a rehash of somebody
else's (Jim Hafner's) proposal, but I'm going to beat out some
implications.  Some people might say this is already the way things
work.  I don't see anything in the spec that precludes this
interpretation, anyway.

If a SCSI I (as in I_T) is defined by a unique Initiator Name, then
you simply say that each distinct iSCSI entity within a system (and
across systems too, of course) has it's own Initiator Name.  That
means that each entity has it's own, distinct SID space.

In other words, the kernel mode iSCSI entity will have a different
Initiator Name from the user-mode programs.  Each iSCSI entity (user
program or kernel) is responsible for producing its own Initiator
Name, AND authenticating that name with the target.  A user mode
program could find the kernel's initiator name, but it couldn't
perform the proper authentication, so it would not be able to `hijack'
the TSID.  Similarly noncooperative user mode programs could not
authenticate themselves as each other either.

> You may think this is a bit far fetched, but I almost have such a
> program.

Not at all.  I think it's a very exciting possibility.  One of the
features which an iSCSI running on RDMA can offer is fully accelerated
(as in, hardware handled data), user-mode (OS-bypassed) iSCSI
connections.  This is a major reason why I keep pushing iSCSI/RDMA as
The Right Thing.

> Santosh said:
> I'm in support of adding a bit ("login unconditionally") to the Login
> PDU that allows the initiator to specify whether any previous session
> for that ISID, if it exists, is to be logged out and a new session login
> established.

Given the idea above, it's not necessary.  Even if you discount the
idea above (which you better not, or I'm going to be really MAD!), I
don't see how such a bit would be used.  What is the algorithm for
setting the bit?

If you allow multiple entities (e.g. a user-client and a kernel
client) to use the same Initiator Name, one of those entities can deny
service from the other, accidentally, or deliberately by having the
bit set.  Specifically, to allow access at all in this scenario, it
must either be the case that:

  o two entities can authenticate with the same Initiator Name
or
  o no authentication is required

In this case, you can not force a malicious or clumsy entity not to
set the bit, which means that one entity can deny service to the other
by hijacking (forcing implicit logout) a session.

Even if you disallow multiple entities using the same Initiator Name,
the policing behavior of the `~login unconditionally' setting doesn't
buy you much.  The first time in your life you login with a TSID, you
must assume that you may have been logged in to the same target in a
previous life (reboot), within RA_TOV.  You have no way (no memory of
the previous life) to know that you did not do that.  Therefore,
clearly, the first time in your life you use a TSID, you will login
with `login unconditionally'.  On subsequent logins with a TSID within
the same life you could set '~login unconditionally' and you might
learn that you blew your TSID allocation policy (or something else),
but frankly, it seems like a pretty small gain.  Even if you always
login with `login unconditionally', you will still certainly know if
you blown your TSID allocation policy.

Steph

P.S.

> (or class driver if I have my Microsoft terminology correct)

Actually, that's VMS[++ == WNT] terminology, and yep you got it :^)