Skip to main content

Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)
draft-ietf-storm-iscsi-cons-10

Yes

(Martin Stiemerling)

No Objection

(Gonzalo Camarillo)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Wesley Eddy)

Note: This ballot was opened for revision 06 and is now closed.

Martin Stiemerling Former IESG member
Yes
Yes (for -06) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-10-11 for -07) Unknown
340 pages is too much for an out-of-area AD to give a detailed review. On a light read I don't find any worries from a routing perspective, and so I am balloting "No Objection" on the understanding that this work is primarily a consolidation of pre-existing work.
Barry Leiba Former IESG member
No Objection
No Objection (2012-10-10 for -07) Unknown
I haven't been able to give this a full review.  Some non-blocking comments here, based on what I've had time to cover.  If I get more before tomorrow's telechat, I'll add them and re-send this.

-- Section 4.2.4 --
   To protect the TCP connection, an IPsec security association MAY
   be established before the Login request.

Related to Stephen's DISUCSS point (1), why is *use* of IPSec a MAY?  It's clear to me why neither authentication nor connection-level security is always needed (for example, using iSCSI to access a read-only repository of public information), so performing login is a SHOULD.  Why isn't IPSec also SHOULD?

-- Section 6.1 --
You give Unicode code points for the non-alphanumeric characters, but not for the alphanumeric ones.  Just to be complete, and to recognize that there are multiple Unicode characters that look like "a", for example, you should probably do this:

OLD
   (a-z, A-Z) - letters
   (0-9) - digits
NEW
   (a-z, A-Z) (0x61-0x7a, 0x41-0x5a) - letters
   (0-9) (0x30-0x39) - digits

Consider whether RFC 4648 would be a better reference for base64 encoding than RFC 2045.

I see that Mallikarjun and Alexey are engaged in conversation about Alexey's AppsDir review, with resultant changes.  And my esteemed colleague from Illinois has said that he's covering the stringprep stuff and related issues.  Apart from that, I don't see any App-layer issues raised here, and trust that the ADs at the lower layers will handle those.
Benoît Claise Former IESG member
No Objection
No Objection (2012-10-10 for -07) Unknown
I am voting no objection on the basis that a quick review indicates no implications for OPS for this draft, and that the OPS aspects will be covered in draft-ietf-storm-iscsimib.
Brian Haberman Former IESG member
(was Discuss) No Objection
No Objection (2013-06-30 for -09) Unknown
Thanks for resolving my discuss points.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2012-10-10 for -07) Unknown
2.2:

  - SCSI Port Name: A name made up as UTF-8 characters and includes
  the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag.

s/made up as/encoded as

4.2.3.5:

   If the issuing session is a FastAbort session, the iSCSI target	
   implementation is FastAbort-capable, and the third-party affected	
   session is an RFC 3720 session, the following behavior MUST be	
   exhibited by the iSCSI target layer: Asynchronous Message PDUs	
   MUST NOT be sent on the third-party session to prompt the	
   FastAbort behavior.

I don't understand what counts as "following" in "the following behavior MUST be exhibited". Why not simplify to:

   If the issuing session is a FastAbort session, the iSCSI target	
   implementation is FastAbort-capable, and the third-party affected	
   session is an RFC 3720 session, the iSCSI target layer MUST NOT
   send Asynchronous Message PDUs on the third-party session to prompt
   the FastAbort behavior.

Is there something else "following" that needs to be accounted for?

(The following is about text that was in the original document. Because of that, I will not put a DISCUS on this, but gee would I like to see this clarified.

4.2.7.1 says:

     - iSCSI names are composed only of displayable characters.
       iSCSI names allow the use of international character sets
       but are not case sensitive. No whitespace characters are
       used in iSCSI names.

and 4.2.7.2 says:

     - It is in Normalization Form C (see "Unicode Normalization
       Forms" [UNICODE]).

     - It only contains characters allowed by the output of the
       iSCSI stringprep template (described in [RFC3722]).

"not case sensitive" in 4.2.7.1 is weird. That would seem to imply that you *can* have uppercase characters, but that they compare equally to lowercase characters. But 4.2.7.2 (and in particular 3722) says that it's only going to be lowercase. Something seems amiss. Do you mean only ASCII characters are compared case-insensitively?


All this said, I am bummed that we didn't get PRECIS far enough along to include in this version. Ah, well.
Robert Sparks Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2013-01-15 for -08) Unknown
I'm clearing based on the new text about getting rid of CHAP in future versions.

I support Stephen's discuss positions.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2013-06-28 for -09) Unknown
Thanks for adding the Kerberos details which look good.

I didn't check these with -09, so these are comments I
made on -07 with no changes.

- There's a lot of repetition which is a pain in such a
long document. That's a pity.

- This is too long. It may have seemed like a good plan
to merge a lot into one document, but this goes beyond
what's useful IMO.

- There seem to be many cases of terms being used that are
not (well) defined.  4.2.3.2 refers to [SPC3] for "task
set" which is the basis for a bunch of definitions I can't
understand, not having access to [SPC3].  And for example,
response fencing is all over section 4 but never defined. I
think a general pass for this probably would be worthwhile.

- Can you explain how a 2nd TCP connection for a session is
as secure as the first? I think that the login phase has to
be repeated but wasn't sure.

- 4.2.5 says that a connection is in full feature phase if
some (possibly other) connection has successfully passed
through the login phase. That seems to imply that only IP
level security can work for iSCSI (since TLS would be
connection specific) and that MPTCP couldn't be just
substutited for TCP. Is that correct? Where is that stated?

- 6.3.5 - I don't quite get the security model for session
reinstatement. It appears to be the case that if any user
that can login (if that's needed) could guess and ISID then
they could take over someone else's session - is that
right?  If not, what prevents that occurring? If so, where
does it say that ISID's MUST/SHOULD be hard to guess?

- Is it clear how iSCSI names are mapped to X.509 certs
used in IPsec?

- Just wondering if anyone's look at the recovery features
to check if flipping a bit in an ecrypted packet could
trigger any bad behaviour?

- section 7: What if IPsec goes wrong? Any specific
recovery for that?

- p158/9 is it not now time to make 3DES a SHOULD and AES a
MUST?

- CHAP has some weaknesses, but MUST only be used here when
sent via IPsec, is that correct? How would an
implementation know that IPsec is in use?

From the secdir review [1]:

- 9.3.1 - RFC 2404 defines HMAC-SHA-1-96 not HMAC-SHA1.  is
the reference correct?

- 4.2.3.2. Notion of Affected Tasks, LOGICAL UNIT RESET:
All outstanding tasks from all initiators for the LU
identified by the LUN field in the LOGICAL UNIT RESET
Request PDU.  Are there any access control facilities for
this operation?

(Please also consider the other comments from the secdir
review as well.)

   [1]
http://www.ietf.org/mail-archive/web/secdir/current/msg03556.html


nitty comments

- abstract: funny use of "standardized" - isn't that what
we're doing here? 

- abstract: "difference in semantics" isn't all, I assume
this wins for all differences incl. syntax, prose etc.

- There's a lot of repetitive text. I think I read about
the direction of transfer 4-5 times in the first 30 pages.

- 2.2, initiator name: "woldwide unique" hmm, odd phrase.
What if a node is on the ISS or the Moon? Or if you have a
bad PRNG? (CHECK)

- 2.2, NAA - could I implement this without access to
[FC-FS3]? That appears to be a paywalled spec - is it?  I
guess there are others too.

- 2.2, "Recovery R2T" is defined by not R2T (and R2TSN is
used inside the definition)

- 2.2, "Third-party" - this definition is not
understandable.

- 4.2.2.3.2, "response fence" is used without definition

- 4.2.2.3.3, "I_T_L nexus" isn't defined.

- 4.2.2.3.4, what is a FastAbort? a TaskReporting key?
what are UA, TMF, ACA...

- At this point I gave up on noting use of undefined terms.
("TTT" was the straw for this camel's back:-)

- 4.2.4, saying that a security association can be built in
"many different" ways is a bad idea. Surely the only ways
are those for which you have defined mechanisms?

- 4.2.4, "The login PDU includes..." why is it enough to
say what this includes without specifying precisely what it
is? (I include carbon atoms but am not a diamond;-)

- 4.2.5, "...is authorized to do so..." is vague. I think
you mean something succeeded but you've not defined what.

- 4.2.5.2, you don't say how the length of the first
unsolicited burst can be negotiated.

- 4.6.2 is an odd section with no text and just one 4 line
subsection. So is section 5. If you're following the
structure of some other document(s) it'd be nice to say
which. (If you did, I've already forgotten;-)

- section 6, is the continuation bit "C" really needed when
sending over TCP?

- p95, "new public keys" registerded with IANA trips up the
crypto geek in me:-) suggest s/public// and the same with
"private key"

- 9.2.2: is SRP really in use with iSCSI? If not, it'd
probaly be good to say so.

- p213, I don't get what Parameter1,2,3 are.
Stewart Bryant Former IESG member
No Objection
No Objection (2012-10-07 for -07) Unknown
I am voting no objection on the basis that a quick review indicates no implications for the routing system.
Wesley Eddy Former IESG member
No Objection
No Objection (for -07) Unknown