Re: iSCSI: keys/parameter dependence

[Martins Krikis <mkrikis@yahoo.com>]

(I've thrown some text out to keep it shorter)

--- "Robert D. Russell" <rdr@io.iol.unh.edu> wrote:

> The following paragraph from an e-mail from Martins
> Krikis
> made me realize that the definition of the new C bit
> is not correct, because it goes much further
> than is necessary to solve the "split key" problem,
> and as a result, it opens up a whole new set of
> problems,
> complicates what was previously a simple situation,
> and
> breaks a lot of already running and tested code.

The C-bit actually simplifies a previously very
complicated situation. As to "running and tested",
I don't think many people have encountered split
PDUs in operational stage or FFP Text negotiations
yet.

> I don't believe the intention of the recent
> discussion
> that led to the introduction of the C bit was, in
> fact,
> to allow "batching" or to throw out "ordering" of
> the
> sending of keys.  However, the definition in Draft
> 12-95
> sections 9.10.2  and 9.11.2 seems to now allow
> batching:

Those, who prefer the "batch-processing" approach
fought for the C-bit, so I would say that it was
introduced in order to allow it.

Regarding ordering, however, it had never been
defined, and I would hate to see it introduced.
In my opinion, it is best to treat all operational
parameters as independent and negotiate them as
such. Just before the commit 
(i.e., turning on the T or F bit), one can do an
all-encompassing consistency check and reset
the negotiations if the values violate the laws
imposed on them, or offer some more keys to solve
any such problems, if this is still possible.
I could even imagine negotiations
succeeding but laws 
(e.g. FirstBurstSize <= MaxBurstSize) not being
broken when sending data... OK, the last thing
might technically be forbidden at the moment
but it is not that unreasonable. It would be
something like 
FirstBursSize = min(FirstBurstSize, MaxBurstSize)
done after the negotiation end, and then you can
forget about dependencies.I think it is way
easier than worrying about key ordering every
time something is sent or received.

> (I agree with John Huffered that Martins' comments
> about
> "ordering" are not correct in any case.)

I'd have to know which particular ones are we
talking about in order to clarify my position.

> The problem I see with this definition of the C bit
> is that
> the sending side can force the receiving NOT to
> process
> a PDU containing key=value pairs, even if all those
> key=value
> pairs are complete within the PDU.  Therefore, the
> receiver
> is forced to save this PDU (and any number of
> following PDUs)
> until the sender finally sends C = 0.  

"You may process, just please don't send anything
back yet, because I'm not finished sending stuff
to you. The small PDU size wrt the abnormally large
data amounts that I have to send (all very important
and urgent) are making it hard for me to fit it all 
in a single PDU."

> In the worst
> case, the
> sender could send one key=value pair per PDU with
> the C bit set
> to 0 and the receiver could not reply to any of
> these until it
> got one with C bit set to 1.

If this is really a problem, I'm happy to retreat
my position to one of the other schemes, going
as far as allowing the responding side to send
responses and originate key declarations, but
not to originate keys that are not declarations.
I am really fond of doing batch-processing of the
keys and I would hate to have it broken again.

> As the e-mail from Martins indicates, some people
> are already
> taking this to mean that parameter negotiations will
> "normally"
> be batched. 

I'm planning to batch my parameters. But I don't
care how the other side processes them, as long as
it sticks to the (new) protocol and doesn't interrupt
me when I have the C-bit still set.

> Up until the introduction of the C bit,
> PDUs and keys
> in them were always processed as received, and most
> code already does
> this, since it is the most logical and efficient way
> to do it.
> We should still encourage this as the "normal" way
> of negotiating.

How could you possibly know what "most code" does?
I would even conjecture that most code isn't out
there open for examination or experimentation with.

Most code that I've seen does batch-processing.
I must admit, the batch is typically one PDU and
the code can break if keys are getting split.
The C-bit allows a trivial update of that code
to deal with split keys as well.

> I believe the problem we were trying to solve by
> introducing
> the C bit was the one where a key was split over a
> PDU boundary

sure

> -- we were not trying to redesign the negotiation
> mechanism,

and we didn't really. It's still essentially the
same, one side sends some pairs, the other side
answers. But PDU boundaries no longer mess up this
simple scheme.

> which was discussed on the mailing list long ago and
> has been
> working in a lot of running code for the past two
> plugfests.

Did you see split-keys outside of security stage? 
What happened, if so?

> Could we therefore please change the definition of
> the C bit in
> section 9.10.2 to read:
> "When set to 1, indicates that the text in this Text
> Request
> contains a single key=value pair, and that pair is
> incomplete
> within this PDU."

I could see it anyway when I find no terminating '\0'.
But how would this change help with the original
split-key problem (both sides feeling like 
originators)? Do you propose to send complete
pairs separated from split-pairs? And the sender
to check for each key=value whether it will fit
entirely or not? If so, please see the very
lengthy discussion which got us to the C-bit.

> I'm not happy about seeing such a major change (C
> flag bit)
> introduced so late in the process to solve an
> "almost" non-existant
> problem (split keys). 

Yes it is "almost" non-existant. That's why I asked
above, have you seen split-keys outside security
stage or not?

> It is "almost" non-existand
> because of
> the following considerations (some of which were
> already
> mentioned on the list and are just summarized here):
> During the login process, the PDU size is 8192
> bytes.
> Therefore, except for the long keys during
> negotiation
> that follows a chosen AuthMethod, there is never a
> need to split
> keys across pdu boundaries during login --
> even if you negotiate every possible login key
> (except those special keys that occur in security
> protocols)
> to its maximum length, you do not reach the total of
> 8192 bytes.
> It is not even close!  Therefore, there is no need
> for any
> implication that the C bit should appear during this
> process.

OK, disallow it completely. Just don't let some
split-keys make both sides feel like originators,
nor ask me to check each key=value pair I'm preparing
for fitting or not fitting.

> When those long security keys are needed, the
> negotiation process is
> in a 1 key over, 1 key back exchange mode, so there
> is no "batching"
> possible and the split key should in fact be the
> only key in the pdu.

Sure, although nothing prevents me from declaring
that my 1 key=value is my "whole batch" and apply
batch-processing to this pair.

> Finally, during text exchanges, there only 6 keys
> that can be
> legally sent (plus the X-extension key):
> SendTargets, TargetName,
> TargetAlias, TargetAddress, InitiatorAlias, and
> MaxRecvPDULength.
> None of these can legally have a value greater than
> 255 bytes,
> which is well less than the minimum PDU size (512
> bytes).

And how many instances of TargetName and TargetAddress
can the SendTargets command provoke from the other
side? I think it can easily overflow the 8192 bytes.

> So there is no need to split keys over boundaries
> during text
> negotiation, except perhaps for the X-extension
> keys.

One could get away without splitting keys ever
(but not necessarily without splitting values).
However, a scheme like that means that the sender
has to check whether a newly prepared pair fits
or doesn't (definition of "fits" varies depending
on whether the key may be split or not).
Again, the lengthy previous discussions were all
about why this would be a bad requirement to have.

> In summary, I would like to see as little disruption
> as possible
> to the key negotiation scheme which has been stable
> for a long time,

I think the C-bit just achieved that. A "batch"
is a "virtual PDU" (no length restrictions).
Once you get a "batch", you're welcome to send
the response batch, just as previously done with PDUs.
Except that nobody has to worry about split keys
anymore.

> I believe my modification to
> the definition of
> the C flag accomplishes that, without introducing
> any new, false
> perceptions about "batching" and "ordering".

It's nice that batching is now possible. Having
any ordering (within a "batch") is entirely 
unnecessary, however, IMO.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not be
            those of my emplyer


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com