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

["John Hufferd" <hufferd@us.ibm.com>]

If you do not have enough buffers to support the Max certificate that you
support, then you can not receive the Max certificate that you support.

Again, I see no problem.  I do not think we need to put the obvious into
the draft.

We need to move into the thought process of:  if it is not really broken
"Don't Fix it".  We can spend much time, clarifying the obvious, along with
the increasing length of the draft, in fact there is no end to clarifying
the obvious.  The Draft is long enough as it is.  Lets move on.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: hufferd@us.ibm.com


Paul Koning <ni1d@arrl.net> on 03/30/2002 02:10:30 PM

To:    John Hufferd/San Jose/IBM@IBMUS
cc:    ips@ece.cmu.edu
Subject:    Re: iSCSI: Text request/response spanning - security issue?



Excerpt of message (sent 29 March 2002) by John Hufferd:
>
> Before we run off to far in this direction, ....
>
> Each Key of the Key=value pairs, supplies enough information to
understand
> the Max length of the value that follows.  The length permitted by each
> keyword that is supported, should  be enough to define the approprate
> length for any key=value pair.  I think that the implementation can
> determine the Max amount of buffer it needs by computing the Max size
based
> on the keywords supported.

Maybe not if you want to be picky.  Is there a limit on the number of
leading zeroes that a numeric value may have?  I suppose a way to
handle that is "a receiver is not required to accept values other than
zero that begin with 0".

> I think the item that got us into the Multi PDU  spanning of a key=value
is
> the Certificates associated with authentication.  So depending on the
type
> of Authentication supported, and the Max size of Certificates supported,
> you can compute the Max size of the total key=value buffer needed.

From what I remember about certificates, it isn't easy -- or even
feasible -- to specify a sensible upper bound on their size.
Especially as people start putting more and more crud into
certificates.

> I do not see anything broken here.  Hence, I do not think a fix is
needed.

Let's make sure that we can indeed specify an upper bound on each
value for each key -- and document in the spec what that limit is.  If
that can be done then indeed we're done.

(I wouldn't worry about X-foo keys; if you don't support them then it
doesn't matter how long they are, and if you do support a particular
one, then it's up to the spec of that specific key to bound its size.)

     paul