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

From: [email-masked]
Date: Wed, 3 Jul 2002 10:06:54 -0400

Replying to a couple of messages on this topic.

--- Use of decimal for binary items

> There was NEVER a discussion about forbidding decimal for binary items.

Ok, that's why it's now under discussion in WG Last Call.

> It would be counterproductive to forbid them as they are so widely
> used in programming.

The request to forbid them seems to have evolved into a request to
more carefully classify binary items into those that can ordinarily
be expected to fit in 64 bits (decimal format ok) and those that will
generally not fit (decimal format not ok, even if a particular value
fits).  This is consistent with our restriction of base-64 to large
binary items.  As Pat Thaler wrote:

> 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

The only ones of these that should routinely fit in 64 bits are SRP's
g (usually a small integer, even though it's mathematically a member of
a very large binary field - I think Paul Koning missed the fact that
generators tend to be single-digit numbers) and s (doesn't need to be
a large number to get the job done).  If any of the others happen to
fit in 64 bits, that's a hint that something may be wrong with security
(e.g., CHAP's C and R should be 128 bits - if either has 64 bits of
leading zeroes, something's probably wrong).  On this basis, I'm
inclined to agree with Pat that:

> 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 would make an exception to allow decimal for SRP's g and possibly SRP's
s for the sort of convenience reason that Julian gave above ("widely
used in programming").

I'd recommend this change to large-binary-value with the exception of
SRP's g and possibly SRP's s as the way forward.

--- 64 vs. 32 bits

> I went back to the mailing list - and there was a clear consensus to keep
> it to 64 bits (my original proposal was unlimited and  I suggested rhen
128
> to alleviate concerns about conversion difficulty for unlimited numbers).

That matches what I recall from mailing list discussion, 32 bits was not
considered at the time.

> The issue was raised without checking the libraries:

[... snip ...]

> I don't know about Windmills - but I assume that most modern development
> environments are supporting 64bit integers.

I suspect the response to this is that not everyone is using a "modern
development environment" ... ;-)

> Are we going to take for granted any assertion made on the list?

Yes and no.  When someone working on an implementation reports that some
aspect of the protocol spec is causing difficulty, we should at least
believe that the person is in fact having some difficulty.  Whether we
should accept arbitrary proposals to remove difficulty is a different
question (iSCSI is not a simple protocol - some things are going to
be difficult/tricky to implement - TANSTAAFL*).

On this particular issue, I don't see support for or the need to reduce
the upper limit on size of numbers that can be encoded in decimal from
64 bits to 32 bits, but the US holiday is starting to get in the way
of list discussion.  What this would mean for implementers is that the
string decoding logic must be able to handle decimal representations of
integers that fit in 64 bits, but an implementation may restrict the
allowed ranges of the values (negotiated for keys) to fit in 32 bits.
This roughly matches what Mark Bakke described:

> 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.

Allowing decimal values to go up to 64 bits in size strikes me
as a reasonable "future-proofing" measure - in 20/20 hindsight, I
would think that the SNMP folks wish they'd put 64 bit support into
SMIv1/SNMPv1 even if there had been little use for it at the time.

So, this change (64 to 32 bits) does not need to be made now, but I
will be watching the mailing list early next week just in case some
people who care about this have already signed off for the US holiday
and have additional input to contribute.

Thanks,
--David

p.s. * TANSTAAFL = There Ain't No Such Thing As A Free Lunch
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: Paul Koning <[email-masked]>
Date: Wed, 3 Jul 2002 11:24:24 -0400

Excerpt of message (sent 3 July 2002) by [email-masked]:
> ...
> a large number to get the job done). 

You're right about g.  As for S, it's the result of an exponentiation
modulo N, so it's no more likely to be a small integer than the other
SRP intermediate values.  Note that values supplied by the other end
are involved (as in conventional D-H) so you don't have the ability to
constrain your implementation to produce small S values.

In other words, S, A, and B will be bignums with probability
essentialy == 1.0, and allowing them ever to be encoded other than by
the large-binary-value rules is a waste of effort.

    paul

---

From: Martins Krikis <[email-masked]>
Date: Wed, 3 Jul 2002 16:45:11 -0700 (PDT)

> decimal for binary items.

There may not have been a big discussion about it,
since everybody was concentrating on disallowing
base64 for numbers (yes, all of them; IMO most
people seemed to think that binary strings would
suffice and that large-numerical-values aren't
necessary) or on limiting the size numerical values
encoded in decimal. But it was certainly mentioned
multiple times under various subject lines:

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09780.html

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10125.html

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10153.html

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10250.html

> > It would be counterproductive to forbid them
> > as they are so widely used in programming.

> The request to forbid them seems to have evolved

I'd like to disagree about the programming part,
but more importantly, why don't we reinstate 
the original request to forbid using decimal for
binary items? It is not a very useful way
of representing even short binary items because
there is no way to express the number of leading
0-bytes, for example. In case there is a vote on
this, I'm against using decimal for binary items.

> it to 64 bits (my original proposal was unlimited
> and  I suggested rhen 128

Getting it down from unlimited was way more
important than getting it down to 32, but it
certainly was considered:

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09804.html

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09808.html

http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09810.html

> > environments are supporting 64bit integers.

Some of us are working in kernel-space, and there
aren't many reasons for a kernel running on a 32-bit
architecture to provide 64-bit integer conversion
routines.

I am not saying that I don't know how to write
such a routine, just that there are normal reasons
why some people may prefer 32 to 64. In case there
is a vote, I'm for 32.

Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer.

__________________________________________________
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com

---

From: "Julian Satran \(Actcom\)" <[email-masked]>
Date: Fri, 5 Jul 2002 07:12:54 +0300

Martins - you have a very good point - and we considered briefly to forbid
decimal from the outset but many of the team felt that this  would be a bad
idea as values get copied from a context to another. And the we looked at
coding for other RFCs and we found decimal everywhere - addresses,
identifiers, ports etc., and thought it would be a bad idea to forbid them
in iSCSI

Julo

---

From: Martins Krikis <[email-masked]>
Date: Fri, 5 Jul 2002 07:42:14 -0700 (PDT)

--- "Julian Satran (Actcom)"
> identifiers, ports etc., and thought it would be a

Julian,

I cannot find a single post on this mailing list
saying that forbidding decimal encoding for binary
items would be a bad idea. I did find several (and
quoted 4) that actually recommended dropping decimal
encoding for binary items. Lately there have been
many more such posts. All those other RFCs, I
suspect, are actually dealing with numbers. I have
no objections to using decimal encoding for numbers
(that is things, that normally fit in your
machine's registers and are treated as numerical,
not as bit-strings). You have yet to provide an
example of something that is clearly a binary
string (and not used as a number) and is being
commonly encoded in decimal. If you find such a
thing, can you tell us what's the scheme for telling
how many null-bytes this binary string starts with?