Re: iSCSI: Text request/response spanning - security issue?

[Paul Koning <ni1d@arrl.net>]

>>>>> "Luben" == Luben Tuikov <luben@splentec.com> writes:

 Luben> ...We cannot control the format of the VALUE (above), as
 Luben> companies will add their own keys. (Reason 2)

 Luben> Thus we need to restrict the "KEY=VALUE" as a whole, its
 Luben> internals past iSCSI are up to the implementations/ companies
 Luben> which add them.

 Luben> If we impose restrictions on "KEY=VALUE" then we need not
 Luben> impose restrictions on the size of KEY or VALUE separately,
 Luben> just that KEY cannot be an empty sequence.

 Luben> The node should know in advance how big of a span a
 Luben> "KEY=VALUE" will be in order to 1) reject it (out of
 Luben> resources) or 2) prepare for its arrival (whatever this
 Luben> means).

I would argue that an implementation can, and should, have its own
protective limits no matter what the standard may have to say about
it.  If a well-crafted sequence of messages crashes an implementation,
the blame goes to the implementation, not to the standard.

But I do agree that the standard needs to say more.  Given that
resources and needs may vary, it seems overly restrictive to place a
hard upper bound on the overall size.  What I would propose instead is
that the standard specify an overall size that all implementations
MUST support.  Larger sizes may be accepted if the implementation has
the needed memory -- which allows implementations that have special
requirements to deal with that within the standard -- but a conforming
implementation would be entitled to reject such large negotiations.

One question: are we concerned here with an individual "key=value" or
with all of the key=value pairs in the text messages taken together?
I can see reasons to worry about the entire set of key=value pairs, so
having a size bound (as in "everyone MUST support at least this much")
on that would take care of the entire question in one step.

       paul