Subject: RE: iSCSI: Decimal encoding - why 64 bits ?

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Tue, 2 Jul 2002 16:40:47 -0600

Mark,

What about 40-bit to 56-bit decimal encoded binary values? They are allowed.

4.1
binary-value includes regular-binary-value and large-binary-value.
regular-binary-value is for strings less than 64 bits and allows decimal encoding. (It says less than 64 and decimal encoded binary strings are always in bytes so the largest decimal encoded binary would be 56 bits.)

10.4 SRP: N,g,s,A,B,M and H(A | M | K) are binary-values
10.5 CHAP: C and R are binary-values

10.2 and 10.3 use large-binary-value instead of binary-value and I can't find any other use of binary-value.

Normally, the values defined as binary-values for SRP and CHAP would be 64 bits or longer anyway, but someone could send short keys and encode them in decimal according to the current draft. This should be eliminated. 

Regards,
Pat

-----Original Message-----
From: Mark Bakke [mailto:[email-masked]]
Sent: Tuesday, July 02, 2002 3:36 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: iSCSI: Decimal encoding - why 64 bits ?

For what it's worth, none of the numeric values for iSCSI that
can be retrieved or set via the MIB require more than 32 bits
(other than counters, but I doubt we would ever send a counter
during negotiation :-).  The allowable ranges just didn't need
more than that.

Anyway, I haven't seen a need to provide support for 64-bit
values in our implementation yet, since none of the numeric
keys can have values that high.

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Mark Bakke <[email-masked]>
Date: Wed, 03 Jul 2002 07:33:45 -0500

Pat-

We use hex for binary values; it just made the most sense to us.  So
I agree that decimal for binary values ought to be eliminated, particularly
since they can sometimes be longer than 64 bits, and sometimes shorter.
I can't see the value in accepting the same key in one case as a binary
string, and another as an integer.  In the MIB, any key information
(the CHAP and SRP passwords) are configured as octet strings, not integers.

Anyway, I'm not necessarily trying to change anything, but if there's
an opportunity to decide on when and whether decimal is used, I don't
see any use for decimal > 32 bits.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054

---

From: Paul Koning <[email-masked]>
Date: Wed, 3 Jul 2002 09:25:16 -0400

Excerpt of message (sent 2 July 2002) by THALER,PAT (A-Roseville,ex1):
> 10.2 and 10.3 use large-binary-value instead of binary-value and I
> can't find any other use of binary-value.
> 
> Normally, the values defined as binary-values for SRP and CHAP would
> be 64 bits or longer anyway, but someone could send short keys and
> encode them in decimal according to the current draft. This should be
> eliminated.

I agree.

Actually, H(A|M|K) in SRP and R in CHAP both can only be
large-binary-value since their length is always greater than 8 bytes.
The same goes for N and g in SRP (since these systems are all based on
modular arithmetic with a modulus of at least several hundred bits).

The probability of the other SRP items coming out small enough
numerically to fit in 64 bits is essentially zero.  It makes no sense
for the spec to allow it.

In CHAP, C should not be short for the same reason that the password
should not be short.

So I conclude that there are good technical reasons why all these
items must be large-binary-value.

      paul