RE: iSCSI: keys/parameter dependence

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Thu, 30 Jan 2003 kevin_lemay@agilent.com wrote:

> I have to agree with Steve.
>

> Will someone explain to me the "value add" of sending the keys in
> multiple PDUs? Or in some other other than shown?

I think you missed a word in that last sentence.

The value for not being picky about order (within a PDU) is that you don't
then have to remember what order things were in. CHAP_N=...\000CHAP_R=...
gets handled the same as CHAP_R=...\000CHAP_N=... . We don't really worry
about the order of keys within a PDU anywhere else, so to worry about them
in the security phase would be weird.

However, I ALSO would really like to know what value-add there is in
letting the keys come in in different PDUs, please. Especially as our
system was made expecting everything in one packet (since we had to follow
that form), and now it's not compliant with the spec.

With the "everything in one PDU" interpretation, you can make a simple
state machine. You send a packet, then you expect certain given thing in
the next one. You get a packet, you know what you expect. If you don't get
it, there's an error.

Also, with everything in one PDU, you don't have to actually copy the
security keys during processing, which is kinda nice. You don't have to
malloc space you're going to free after you un-base64 or un-hex the
string.

> I sure don't see any value and see a bunch of interop problems if we allow it.

I agree. Since we have the 'C' bit, we have the ability to send all the
keys we need (PDU data size isn't an issue). All of the reasons I can see
for wanting to be able to wait when doing negotiations (like seeing what
target name you're talking to) don't really make sense when you're in the
middle of security negotiations.

Take care,

Bill