Subject: [storm] iSCSI and Unicode (newprep BOF)

From: <[email-masked]>
Date: Mon, 22 Mar 2010 22:23:14 -0400

I'll be giving a short presentation on iSCSI and Unicode to the newprep BOF tomorrow afternoon in Anaheim:
http://www.ietf.org/proceedings/10mar/slides/newprep-2.pdf

The short story here is that Unicode and international domain names have moved beyond the stringprep technique that iSCSI uses (RFC 3722 is the stringprep profile for iSCSI), so this BOF is exploring a framework update to stringprep that should allow iSCSI to move forward with Unicode changes.

For anyone interested in exploring further, the rest of the materials for this BOF would be a good place to start.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Mark Bakke (mbakke)" <[email-masked]>
Date: Mon, 22 Mar 2010 22:28:14 -0500

David,

This looks right to me.

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, March 22, 2010 9:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: [storm] iSCSI and Unicode (newprep BOF)

Thanks,
--David

_______________________________________________
storm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/storm

---

From: "Paul Koning" <[email-masked]>
Date: Tue, 23 Mar 2010 07:02:38 -0400

Re "Any update SHOULD be backward compatible with RFC 3722" -- I don't understand the "SHOULD".  The obvious word is "MUST".  More precisely -- and maybe this is where the "SHOULD" came in? -- an IQN that was legal under RFC 3722 must still be legal, and two names that under the old rules were considered different must still be different. 

Do you have a pointer to places to start to learn what newprep is all about?

	paul 

> Sent: Monday, March 22, 2010 10:23 PM
> To: [email-masked]
> Cc: [email-masked]
> The short story here is that Unicode and international domain names
> have moved beyond the stringprep technique that iSCSI uses (RFC 3722 is
> the stringprep profile for iSCSI), so this BOF is exploring a framework
> update to stringprep that should allow iSCSI to move forward with
> Unicode changes.
> 
> For anyone interested in exploring further, the rest of the materials
> for this BOF would be a good place to start.
> 
> Thanks,
> --David

---

From: <[email-masked]>
Date: Tue, 23 Mar 2010 13:23:29 -0400

Paul,

Thanks for the quick response.

> Re "Any update SHOULD be backward compatible with RFC 3722" -- I don't understand the "SHOULD".  The
> obvious word is "MUST".  More precisely -- and maybe this is where the "SHOULD" came in? -- an IQN
> that was legal under RFC 3722 must still be legal, and two names that under the old rules were
> considered different must still be different.

The "SHOULD" is there to a significant extent so that I can plead "I'm not a Unicode expert" ;-).  At the iSCSI protocol level, I expect everything to be backwards-compatible because iSCSI names aren't checked for stringprep compliance on login (the iSCSI name string comparison for equality is basically opaque wrt Unicode issues).

Moving up to the iSCSI name input level (human involvement), it is possible that things have changed in Unicode so that the same Unicode input string will need to map to a different newprep output string vs. stringprep output string for reasons involving Unicode.  If that's the case (and especially if some previously valid inputs have to be prohibited), then everything will need to be carefully explained and documented with advice on how to cope ... but I hesitate to lead with a "MUST", as the IDN folks have much deeper knowledge of what's going on here, what needed to be done with Unicode domain names, and why (a "MUST" risks freezing iSCSI @ an old version of Unicode).

> Do you have a pointer to places to start to learn what newprep is all about?

Look for newprep materials here: https://datatracker.ietf.org/meeting/77/materials.html

Today's meeting is a BOF to talk about whether there's a problem and what to do about it.  If the conclusion is that something needs to be done, details will emerge.

Thanks,
--David

> From: Paul Koning [mailto:[email-masked]]
> Sent: Tuesday, March 23, 2010 7:03 AM
> To: Black, David; [email-masked]
> Subject: RE: [storm] iSCSI and Unicode (newprep BOF)
> 
> Re "Any update SHOULD be backward compatible with RFC 3722" -- I don't understand the "SHOULD".  The
> obvious word is "MUST".  More precisely -- and maybe this is where the "SHOULD" came in? -- an IQN
> that was legal under RFC 3722 must still be legal, and two names that under the old rules were
> considered different must still be different.
>

---

From: "Paul Koning" <[email-masked]>
Date: Tue, 23 Mar 2010 15:34:05 -0400

> > that was legal under RFC 3722 must still be legal, and two names
that
> under the old rules were
> The "SHOULD" is there to a significant extent so that I can plead "I'm
> not a Unicode expert" ;-).  At the iSCSI protocol level, I expect
> everything to be backwards-compatible because iSCSI names aren't
> checked for stringprep compliance on login (the iSCSI name string
> comparison for equality is basically opaque wrt Unicode issues).
> 
> Moving up to the iSCSI name input level (human involvement), it is
> possible that things have changed in Unicode so that the same Unicode
> input string will need to map to a different newprep output string vs.
> stringprep output string for reasons involving Unicode.  If that's the
> case (and especially if some previously valid inputs have to be
> prohibited), then everything will need to be carefully explained and
> documented with advice on how to cope ... but I hesitate to lead with
a
> "MUST", as the IDN folks have much deeper knowledge of what's going on
> here, what needed to be done with Unicode domain names, and why (a
> "MUST" risks freezing iSCSI @ an old version of Unicode).

If so, then so be it.  I really do want MUST here.

Consider a simple example.  To avoid getting deep into Unicode, let's
use an ASCII analogy.  Let's say the old rule is that names are prepped
by tolower() and the new rule says they are prepped by toupper().  And
let's assume that this operation is done only when the target name is
mentioned in some management UI as you suggested.  (I think we might do
it also at login, but it doesn't actually affect the outcome of the
example in a way that matters.)

Ok, so in the old version, the admin asked me to create target Foo,
which I prepped to "foo", so we now have that target.  Next the user
tells the initiator to log in to Foo and the initiator preps that to
"foo" which comes across the login protocol exchange and all is well.  

Now we go to the new rule.  The admin sets up a new initiator, and tell
it to connect to Foo.  That initiator UI preps the string, which results
in "FOO".  That comes across in the login.  We do binary compare at
login time, so the result of the login operation is "no such target". 

You might think you can cure this problem by re-prepping all previously
stored names with the new rules.  That works ONLY if (a) all previously
valid names are still valid, (b) all previously distinct names are still
distinct.

We clearly can't have a case where an existing iSCSI target becomes
inaccessible because of new name rules; this is my reason for saying
that any newprep changes MUST not have such an effect.

	paul

---

From: <[email-masked]>
Date: Tue, 23 Mar 2010 18:28:52 -0400

Paul,

I concur with your reasoning, example and strong desire for "MUST".

The newprep BOF is starting now - I'll report on results.

Thanks,
--David

> Sent: Tuesday, March 23, 2010 3:34 PM
that under the old rules were
> > documented with advice on how to cope ... but I hesitate to lead
with  a

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Mar 2010 19:45:37 -0700

> The newprep BOF is starting now - I'll report on results.

And if you'd like to join that conversation, go here:

https://www.ietf.org/mailman/listinfo/newprep

/psa

---

From: <[email-masked]>
Date: Tue, 23 Mar 2010 22:59:15 -0400

Bad news - we are going to have unavoidable incompatibility problems,
courtesy of domain name changes in how Unicode is handled.  There are
four characters that cause these problems, of which the easiest to
explain is the German eszett or sharp s (looks like a Greek beta
character for those not familiar with German):

	http://en.wikipedia.org/wiki/%C3%9F

This is often changed to a pair of ordinary s characters (e.g. StraBe
vs. Strasse), but that change is not always correct.  Stringprep mapped
sharp s to ss, but the new 2008 domain name specifications apparently
allow the Unicode character to be used - LATIN SMALL LETTER SHARP S'
(U+00DF).  Any IQN constructed from such a domain name would be
corrupted by stringprep mapping sharp s to ss.

While easiest to explain, this is not the worst problem - the worst
problem involves some non-printing format characters that stringprep
ignores in a fashion that causes serious problems (meaning changes) in
languages such as Persian.

More details on the newprep BOF coming in a later message. 

Thanks,
--David

> > documented with advice on how to cope ... but I hesitate to lead
with

---

From: Julian Satran <[email-masked]>
Date: Wed, 24 Mar 2010 07:47:12 +0200

A way out that would enable things to coexist would be to negotiate  
stringprep or nameprep with stringprep mandatory and default and  
nameprep only when the two parties have it. It may not be a major  
issue for a while (or till we learn to live in Babylon :-)).

Regards,
Julo

---

From: "Paul Koning" <[email-masked]>
Date: Wed, 24 Mar 2010 13:26:52 -0400

> issue for a while (or till we learn to live in Babylon :-)).

That sounds promising.  It effectively creates two encodings: one is
UTF8-stringprep and the other is UTF8-newprep.

The hard part is to figure out what to do with names that are handled
differently by the two rules.  The question applies to new names (names
added after this machinery is put in) and old names.

For new names, I think you'd want to use these rules:

a. A new name is legal only if both stringprep and newprep consider it
legal
b. A name is unique (i.e., allowed to name a new object distinct from
existing objects) only if it is distinct by both the stringprep and
newprep rules. 

For example, using the example that David mentioned (German sharp s,
written here as B for ASCIIness): stringprep maps StraBe to strasse,
while newprep uses the separate Unicode character.  So if I have an
existing iSCSI name "strasse" and I propose to create a new name
"straBe" this will be rejected because it isn't unique by both
stringprep and newprep rules (only newprep calls it unique).

For existing names, a name lookup is done by the matching rules for the
encoding that was given.  (For example, a request for "straBe" when
there is an existing name "strasse" will match that names if the
requested encoding was UTF8-stringprep, and will fail (no such name) if
the requested encoding was UTF8-newprep.

	paul

---

From: Julian Satran <[email-masked]>
Date: Thu, 25 Mar 2010 08:40:02 +0200

Paul,

I think we should be slightly more lenient and to this end David's  
should may come in handy. We should not prevent an administrator that  
whishes to enforce the new naming (rules) and is prepared to pay for  
it to do so. Making/requiring the names to be unique on both or not  
should be left to the administrators. I suppose we may require the  
nameprep team to specify transliteration rules to ease the burden of  
administrators and implementors and mandate those (or one pf those)  
for iSCSI.

Regards,
Julo

---

From: <[email-masked]>
Date: Thu, 25 Mar 2010 02:48:08 -0400

Paul,

<WG chair hat off>

> the requested encoding was UTF8-newprep.

That concerns me.  One of the benefits we obtain from stringprep is that
we don't have any Unicode handling functionality on login - the iSCSI
names are just compared for equality (stringprep has to be done before
the names get to iSCSI).  I view that comparison as robust, and hence
would prefer not to move away from it at the iSCSI protocol level unless
there is no other alternative (i.e., my preference would be that if
"straBe" is allowed, then it is *always* different from "strasse").

Thanks,
--David

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Koning
> Sent: Wednesday, March 24, 2010 1:27 PM
> To: Julian Satran; Black, David
> Cc: [email-masked]
> Subject: Re: [storm] iSCSI and Unicode (newprep BOF)
>

---

From: "Paul Koning" <[email-masked]>
Date: Thu, 25 Mar 2010 18:59:12 -0400

> "straBe" is allowed, then it is *always* different from "strasse").

You're right, and my explanation was confused because I was thinking
about an implementation that does apply *prep at login.

The right way to describe it is that login passes the name and indicates
which prep was used to prep it.  So earlier (at config time) when the
user supplied name was prepped, the config machinery has to store not
just the resulting string (which is what's sent in login and compared
bitwise) but also which prep was used for it.

	paul