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

[Luben Tuikov <luben@splentec.com>]

"Mallikarjun C." wrote:
>
> Since we define the max key size in chapter 4, I take it
> that you are concerned about very long lists causing buffer
> overruns even while each of the options being within legal size
> limits?

Yes, exactly.

Furthermore an individual value encoded representation
can have any length -- the draft only specifies that
its _decoded_ representation is <= 255 bytes.

That is "rogue=base64 of length 1e30,bye,bye" will make a node
die. (You get the meaning.)

Since a "KEY=VALUE" cannot contain 0x00 (since it separates it
from other assignments), we need to consider the entity
"KEY=VALUE" as a whole and impose restrictions on it
as a whole. (Reason 1)

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

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

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

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

-- 
Luben