iSCSI: Text request/response spanning - security issue?

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

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.

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.

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

.
.
.
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>@ece.cmu.edu on 03/29/2002 12:27:22 PM

Sent by:    owner-ips@ece.cmu.edu


To:    wrstuden@wasabisystems.com
cc:    ips@ece.cmu.edu
Subject:    Re: iSCSI: Text request/response spanning - security issue?



Excerpt of message (sent 29 March 2002) by Bill Studenmund:
> > Yes, you can renegotiate after login, but login is the primary
> > negotiation point.  I think a fixed minimum requirement is more
> > straightforward.
>
> While having a minimum required is good, if we don't have a way to
> negotiate a larger value, how can we really use a larger value? So if we
> can't negotiate the largest size we allow for key=value items and for the
> set, aren't you really suggesting we just pick a number and that's it?
>
> What's the alternative? Send something too large and either crash the
> other side or have some 'I'm confused' error come back? At least with
> negotiation, each side will know what it can and can't send.

If you crash, you have a bug.  I was assuming a reject that says "your
text is too long".

> So here's the suggestion again. We start negotiation with a default value
> for the largest key=value item that can be sent, and the largest set of
> items that can be sent. These defaults are the minimum required that you
> mention. If we want, either side can try to negotiate these values
larger.
> If negotiation suceeds, then future steps of negotiation can use the
> larger values. Negotiation can't lower the values below the minimum
> required.

That sounds workable but I don't see the justification for that extra
complexity.  Luben brought up the original issue as a denial of
service concern.  Is there a plausible real-world example where
someone will want to send a meaningful negotiation exchange that's
"very large"?  I don't know of one.  If there isn't a real need for
the complexity, let's make the minimal fix needed, which is to say
"everyone must support at least x" without negotiating x.

     paul