|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI login phasingJulian, I like the intent of your proposal, with explict keys to mark the beginning of the phases. I still think we could achieve most of this with the existing handshake protocols (SecurityContextComplete for the SecurityPhase phase, F=1 bits for the OperationalPhase). We just need to define exactly when the SecurityPhase is (and is not) entered. I still vote for going through the SecurityPhase all the time. But, your proposal is a bit more precise on these points, and a more complete solution. Regards, Steve Senum Julian Satran wrote: > > Dear colleagues, > > As some of you have complained about difficulty in implementing the login > phase I thought it might be worthwhile to consider a slight departure from > the current description. > > The current text assumes that negotiations are forming one tree and the > "login machine" has to parse the tree. > A leaf node will completely define a state and some pathes may get you to > error. > > I was driven to this design by the need to keep the parsing tree minimal > (under the assumption that any split in subtrees > will result is some parameters needing to appear in several subtrees). > > However - after the noisy (mostly UPPERCASE) debate - I came to realize > that few if any have done the generalized mapping I started with, and > implemented a parser, and ad-hoc, man-glued, engines have to have smaller > trees for the next plugfest (although by then some bright undergraduate > student may take onto himself to give us an open-source yacc definition of > the login phase!). > > I looked at the 2 phases and the number of key=values that they share are > probably limited today at initiator and target names (some > organizations/configurations want them for authentication while some others > will object to them being revealed in the "open phase") and as such we may > want to slit the login in 2, completely bracketed, phases each of them > optional but not both: > > a security phase that if present must start with the login command and > is bracketed by the pairs SecurityPhase=start and ended by > SecurityPhase=end (on both initiator and target) > an operational-parameter-negotiation phase that must follow security > phase (if there is a security phase) and is bracketed by the pairs > OperationalPhase=start and OperationalPhase=end (on both initiator and > target) > > Some additional rules will apply: > > No request/response will span phases > The phase closing handshake can start on both sides but if started at > target will be followed by an "full initiator target handshake" - i.e a > new phase or the "curtain close" end always with the target having the > last word. > keys will be clearly segregated and only a few (like names) should be > allowed in both. > > Comments? > > Julo
Home Last updated: Tue Sep 04 01:04:10 2001 6315 messages in chronological order |