Re: [iSCSI]: Key negotiation procedure proposal

[Luben Tuikov <luben@splentec.com>]

Martins Krikis wrote:
> 
> I'm afraid I'm agreeing with Bill or Paul more here
> than with you.

In other words you'd use ``simple implementation''
rule. That is fine.
 
> First of all what you propose looks like
> renegotion to me.

It is NOT, since the Originator is NOT allowed
to send the same key twice, see implied rule 1.
(If a Responder replies with Reject, then the Originator
SHOULD NOT renegotiate the rejected key.)

> However, just like Bill I don't like having to
> send the key again in the next sequence.

This has already been finalized -- see the
mailing list.

> What if there is no space to send the key again
> in the same PDU and it has to be left for the
> next time?

You could put it right after: e.g.
[BHS+[opt]]key=Reject\000key=reponder_value\000...

> Then it does need this extra state
> again. Also, if it does get Reject-ed by the
> other side (original Originator, now Responder),
> we don't want to treat it as a no-renegotiation
> violation, (unless we'll be closing the connection),
> so we may need state.

Please note when this happens, there's no
choice but to close the connection!
I.e. both sides rejected each other's
values -- this is the core rule, and the result
of rejection on both sides == non-operability.
 
Yes, you do need state at the originator.

> To put it briefly, I think it still is too
> complicated. The less state we can get away
> with, the better.

Well this is implementation issues.

I think that the negotiation schematic is pretty
simple, easiliy transferable into if () {} else {} etc.
 
> Speaking of mathematics, we have to express clearly
> what the requirements are, then we can start proving
> minimal sets of rules to satisfy those requirements.

I think that all here in this mailing list know
what the requrements are -- interoperability.

> Do we have a requirement to let the other side know
> what values we would have accepted? I'm saying, let's
> just Reject what we don't like, close the connection
> if we wish,

There is no other choice Martins -- is it?
(Interoperability...)

> > > Example 2:
> > > ----------
> > > O: v = x  -->
> > >          <--   R: v = y
> > >
> > > O: 1) v = y is OK, continue, as normal,
> > >
> > >    2) v = y is unacceptable,
> > >
> > >    v = Reject -->
> > >
> > >    close the connection (reason just given).
> 
> I don't quite get this one. How can y be unacceptable?

Say, its a mininum of some values and the Originator
found y to be too small.

Anyway, we have to cover all.

> In summary, I think I'm happy with what's currently
> in 12-92, i.e., a key used twice by the same side
> is a no-renegotiation violation.

Currently it looks like ``simple implementations''
with the added bonus of loops.

First, Originator shouldn't ``guess'' and keep sending
same_key=value pairs indefinitely.

Second, in 4.2.2, 12-92, third change-bar from top
has a inconsistenly problem (contradiction)
as has been shown in this mailing list many times before.
Depending on MAY 1) Reject, 2) send admissible value
plus the next sentence ``not admissible by the
selection rules...'' we get to a contradicion
of negotiation...

?

-- 
Luben