Re: iSCSI: SecurityContextComplete without operational parameters

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

> I believe the login process would be considerably simplified if it
> were cleanly separated into two distinct subphases: the security
> negotiation subphase, and the operational parameter subphase, with
> a REQUIRED demarcation line (i.e., the SecurityContextComplete=yes
> handshake) between them.

I strongly agree with the thrust of Bob's suggestion here, but maybe
not the details.

Personally, I find the `SecurityContextComplete=' thing a bit of an
irritant.  It doesn't not add any additional information to either
end, it only reconfirms that both ends are in sync.  Every security
handshake has an architected protocol where the completion is
unambiguous to both ends, assuming the handshake has been properly
implemented.  As such, the context complete message is something that
the endpoints must check, but it's a really odd condition if you
receive it when you're not expecting it.  The exception cases are
either not getting the `ContextComplete' when you expect it, or
getting `ContextComplete' prematurely.  Either alternative indicates
an implementation bug.  Getting it prematurely is somewhat terrifying
to contemplate :^)

That said I think the login process should have little or NO branching
complexity to it.  Put another way, a state machine processing login
would be a single spine, with the only branching being for failure.

The FCP `negotiation' (AKA PRLI) is the right way to go.  That is,
EVERY parameter included in the request, and in the response.

I also agree that having a strong demarcation between security
exchange and operational parameter exchange is the right thing to do.
To be fair, I believe that this demarcation is the intent of the spec
even if it might not be well explained.

If you wanted to apply the single spine principle to security and
operational phases, you could stipulate that EVERY login have a
security exchange, even if it leads to no security.  Personally,
having a single branch in the login state machine (security ->
operational or just operational) probably wouldn't make a big
difference one way or the other.

A key question here is what's our target round trip time?  I think a
70 MS RTT is a generous target, in which case, I don't see a really
compelling reason to try an optimize for a single round-trip exchange
in the no security case.  However, maybe y'all think 1 S RTT is the
target, in which case having the possibility of one round-trip login
is a big improvement over a two-round trip login.  Of course, that one
round-trip wouldn't get you security.

Steph