|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: iSCSI: comments on draftJim, Thanks for your careful reading. On most of the editorial changes I will not comment here - I will correct as much as I can up to the end of next week. Some non-editorial comments: timers - I am aware that they are not a proper protocol issue as they don't appear on the wire. They are somewhat similar to TCP timers. The intent was to help gateways to FCP do some stateless recovery. I think we should consider them carefully and decide how many of them we want, if the values have to be agreed by initiator and target (I had a private mail suggesting that) or that, in extremis, we can live without them at all (as Matt suggested). If we include them we have to make their implementation mandatory - if gateway recovery can't assume they are implemented then they are worthless. At connection termination the finish was meant to convey "wait until they finish" - I did not mean abort. I will try a formulation that clearly expresses this intent. On Bidi as I said in a previous note - I am still considering how to fit it in On the AE for abort - it was optional and I heard a strong voice for making it mandatory (of the sort we call in this group consensus) so I did. I personally consider that a check condition and ACA are required anyhow and AE will give you the "management trigger" for initiators otherwise idle. Loging Resets - the place IP devices today log is in MIB that can be retrieved through SNMP. I will try to clarify this - but I will not make any specific reference to a MIB field as this group has not yet work on the proposed MIB LUN or Reserved in data out. The LUN is required for solicited data as the target task tag is not required to be unique target-wide. I will attempt to spell it out. The 8 byte descriptors apply to the unmap function I will try to spell it out. The purpose of map and unmap is to enable target addressing in all IP formats in binary as well as DNS style formats. When T10 will have it we can make the commands obsolete. Maps implementation is a entirely up to the target. However values mapped are assumed to be persistent until unmapped. In the text I a working on I state that no third party address can be used if it was not mapped and appropriate error will be returned if this rule is violated or the target has lost the maps due to a power down or reset. As for proxy tokens - how are they covered in third party commands? I will clean-up a bit the wording and will add a statement about table reset. However the mechanisms used by the target to implement the mapping and to keep it are implementation specific. The clarification we have to add is that SRAs are guaranteed walid only on a given session (you are not supposed to hand them from initiator to initiator) bu the target is not required to check the SRA ownership validity The IP in IPsec might lead you to think that it provides only link level security but IPsec provides (depending on the policy) end-to-end security For errors in format we will introduce a specific sense - iSCSI format error I value your insight in SCSI working and you helping us out on this - and it was from this that the team realized during the drafting meeting in Haifa that if an OS+CPU has already a signature, the AccessID, we could as well use it and not invent a new one. I don't see exactly what layering principles are violated here - an ID is an ID and it does not make sense to have 10 of them. The principals involved are the same. I can hardly understand the rest of your comment. Isn't the AccessID identifying the initiator to the target? Why should we maintain different IDs for the same principals? (layering is an abstraction techniquue that does hardly apply here ) Thanks again, Julo Please respond to "Jim Hafner/Almaden/IBM" <hafner@almaden.ibm.com> To: ips@ece.cmu.edu cc: Subject: iSCSI: comments on draft Folks, Here's some rather extensive comments on the draft. Some are editorial, some are technical (minor and major) and some are questions. My apologies for the length. I tried to <snip> as much as possible and still leave enough context. <JIM> The naming and discovery team (NDT) is moving in the direction that targets may also listen on other TCP ports, so if that is adopted, this will need to be reworded (as will other parts of this document when NDT is done. </JIM> 1.1 <snip> A “SCSI transportź maps the client-server SCSI protocol to a specific interconnect. Initiators are one endpoint of a SCSI transport. The “targetź is the other endpoint. A “targetź can have multiple LUs behind it. Each logical unit has a number called a LUN. <JIM> I would rephrase this as "Each logical unit has an address within a target called a LUN". </JIM> A SCSI task is a SCSI command or possibly a linked set of SCSI commands. Some LUNs support multiple pending (queued) tasks. The queue of tasks is managed by the target, though. The target uses an initiator provided "task tag" to distinguish between tasks. Only one command in a task can be outstanding at any given time. <JIM> I would also be careful throughout to not use the term LUN for logical unit; I would replace "LUNs" in the second sentence above by "logical units". [There is one other occurence noted below for this colloqueal misuse of the term LUN.] </JIM> <snip> (still 1.1) Each SCSI command results in an optional data phase and a response phase. In the data phase, information can travel from the initiator to target (e.g. WRITE), target to initiator (e.g. READ), or in both directions. In the response phase, the target returns the final status of the operation, including any errors. A response terminates a SCSI command. <JIM> The first sentence can be interpreted that the response phase is optional. Is this intended or do we want something like "involves an optional data phase and a required response phase". [Note: is the word "results" the right one here?] </JIM> Command Data Blocks (CDB) are the data structures used to contain the command parameters to be handed by an initiator to a target. The CDB content and structure is defined by [SAM] and device class specific SCSI standards. <JIM> "device-type specific" to use the SAM words. </JIM> 1.2.3 Timers and timeouts <snip> <JIM> Why are the initiator timers mandatory? Isn't it up to the implementation to decide if there are timing requirements. There is no target requirement here, so how do you even know this is working? </JIM> <snip> 1.2.6 iSCSI Full Feature Phase Once the initiator is authorized to do so, the iSCSI session is in iSCSI full feature phase. The initiator may send SCSI commands and data to the various LUNs on the target by wrapping them in iSCSI <JIM> LUNs->logical units </JIM> <snip> An initiator MAY request, at login, to send immediate data blocks of any size. If the initiator requests a specific block size the target MUST indicate the size of immediate data blocks it is ready to accept in its response. Beside iSCSI, SCSI also imposes a limit on the amount of unsolicited data a target is willing to accept. The iSCSI immediate data limit MUST not exceed the SCSI limit. <JIM> We should give a reference to where this limit is defined and specified in the SCSI world (Mode Page 02h, disconnect/reconnect page, First Burst Size) in SPC-2. </JIM> 1.2.7 iSCSI Connection Termination Connection termination is assumed an exceptional event. Graceful TCP connection shutdowns are done by sending TCP FINs. Graceful connection shutdowns MUST only occur when there are no outstanding tasks that have allegiance to the connection. A target SHOULD respond rapidly to a FIN from the initiator by closing it's half of the connection as soon as it has finished all outstanding tasks that have allegiance to the connection. Connection termination with outstanding tasks may require recovery actions. <JIM> Can/should this have some definition of what "finish all outstanding tasks means"? E.g., Abort tasks -- if you don't abort, where are you going to send status? </JIM> 2.2 SCSI Command <snip> <JIM> Is there a strong reason to put the Bidi stuff AFTER all the other stuff and not within the context of the main header (similar question as here in the context of the response PDU) or to not have it like FCP-2 where the DL field is *after* the CDB and the proposed FCP-2 has the Bidi-READ DL field after that normal DL field? It looks kludgy (spelling?) to have a separation of the two DL fields by other stuff. </JIM> 2.2.6 CDB - SCSI Command Descriptor Block There are 16 bytes in the CDB field to accommodate the largest currently defined CDB. Whenever larger CDBs are used, the CDB spillover MAY extend beyond the 48-byte header. <JIM> There are larger than 16byte CDBs defined already (see SPC-2 and SBC-2). Perhaps a better phrasing is "to accomodate the size of the most commonly used CDBs". </JIM> 2.3.1 Byte 1 - Flags <snip> b4-6 not used (SHOULD be set to 0) <JIM> Should we use the T10 style "reserved" model for unused bits and require that the target check that these are zero, so that in the future, if a definition is given to them, we won't have to worry about bad initiators that didn't initialize these bits correctly? Related, what's the error path for the target if something is wrong (like "o" and "u" both set? (See next item.) Note: initiator's don't need to care about bad fields because there's nothing they can do about it! </JIM> <snip> (this next is on Task Management) 2.6.1 Function <snip> For the <Clear Task Set> the target MUST send an Asynchronous Event to all other attached initiators to inform them that all pending tasks are cancelled and then enter the ACA state for any initiator for which it had pending tasks. <JIM> So we are requiring AE? All other protocols don't (AFAIK). Also, we should be aware of the new SCSI status that has been approved for SAM-2, called TASK ABORTED. This is used (under certain conditions to deal with legacy hosts) to inform an initiator that its tasks were aborted by the actions of another initiator. I think that an initiator that has requested the TASK ABORTED status (via Control Mode Page) should NOT be given the AE and it should be handled by this new status. I'd like to hear from other people (particularly others who are closer to SAM-2) on the need for AE in this case as well. </JIM> <snip> In addition, for the <Target Cold Reset> the target then MUST terminate all of its TCP connections to all initiators (all sessions are terminated). However, if the target finds that it cannot send the required response or AE it MUST continue the reset operation and it SHOULD log the condition for later retrieval. <JIM> Are we spec'ing specifics on the content of this "log" and on the methods for retrieving that log? And who can ask for the log? </JIM> 2.8 SCSI Data <snip> Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|F| 0x05 |1|0| Reserved (0) | +---------------+---------------+---------------+---------------+ 4| Length | +---------------+---------------+---------------+---------------+ 8| LUN or Reserved (0) | 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Target Task Tag (solicited) or Reserved (0) (unsolicited) | +---------------+---------------+---------------+---------------+ 24| Reserved (0) | +---------------+---------------+---------------+---------------+ 28| ExpStatRN | +---------------+---------------+---------------+---------------+ 32/ Reserved (0) / / / +---------------+---------------+---------------+---------------+ 40| Buffer Offset | +---------------+---------------+---------------+---------------+ 44| Reserved (0) | +---------------+---------------+---------------+---------------+ 48/ Payload / +/ / +---------------+---------------+---------------+---------------+ <JIM> This specifies that bytes 8-15 are LUN or Reserved (0). Which is it? Under what conditions is the LUN required? What happens if the LUN doesn't match the one that task tag implies (or is that not a problem?)? </JIM> <snip> 2.15 Map Command Byte / 0 | 1 | 2 | 3 | / | | | | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0|F| 0x07 |1|0| Function | Reserved (0) | +---------------+---------------+---------------+---------------+ 4| Length | +---------------+---------------+---------------+---------------+ 8| Reserved (0) | + + 12| | +---------------+---------------+---------------+---------------+ 16| Initiator Task Tag | +---------------+---------------+---------------+---------------+ 20| Reserved (0) | +---------------+---------------+---------------+---------------+ 24| CmdRN | +---------------+---------------+---------------+---------------+ 28| ExpStatRN | +---------------+---------------+---------------+---------------+ 32/ Reserved (0) / +/ / +---------------+---------------+---------------+---------------+ 48| Descriptor Type | Descriptor Length | +---------------+---------------+---------------+---------------+ 52/ Descriptor / +/ / +---------------+---------------+---------------+---------------+ --------------------------------------------------------------------- +---------------+---------------+---------------+---------------+ | Descriptor Type | Descriptor Length | +---------------+---------------+---------------+---------------+ / Descriptor / +/ / +---------------+---------------+---------------+---------------+ or +---------------+---------------+---------------+---------------+ 48| 8 byte Descriptor | +| | +---------------+---------------+---------------+---------------+ --------------------------------------------------------------------- +---------------+---------------+---------------+---------------+ N | 8 byte Descriptor | +| | +---------------+---------------+---------------+---------------+ <JIM> I don't understand the format of this command, especially in the "or" case. This looks like just a list of 8 byte descriptors. To what do they MAP? </JIM> <snip> 2.15.1 Function <snip> Address/access control descriptors follow the header. For the map function the following descriptor types are defined: 0 Binary IP Version 4 TCP address (IP+Port) followed by a selector string; length should be 6+the selector length+1 1 Binary IP Version 6 TCP address (IP+Port) followed by a selector string; length should be 18+the selector length+1 2 iSCSI URL (domain name terminated with null followed by a selector followed by null) 3 FC address & port - in case access control is based on transport ID 4 access proxy token Details for 3 & 4 have to be coordinated with T10 For the unmap function the descriptors are standard 8 byte SRAs (SCSI Reference Address) <JIM> Where are the SRA's specified in this format? Am I really missing something? There is only one reason for this Map command (AFAIK). Namely, to map long ipstyle addressing mechanisms (e.g., IPv6) to a smaller 8byte alias for the purposes of third party addressing in SCSI commands like EXTENDED COPY and some of the XOR commands. The limitation of the current spec (SPC-2) on those commands is that the Target identifier is only 8 bytes long (and cannot be extended). Specifically, the only need is for name or address resolution of the Target Device and NOT for the logical unit (that is already handled by other 8 byte fields in the target descriptors). SPC-2 and SPC-3 already have descriptors for FC address & port (SPC-2) and IPv4 (just approved for SPC-3) so there is no need for that here. Note also that the IPv4 target descriptor included a 2byte field for "Protocol" (that is, UDP, TCP, etc.). I firmly believe that T10 will approve a SCSI version of this command (very soon; there is definite movement in this direction as there is need for this both in iSCSI and in SRP (formerly known as SVP)) so that this is NOT needed at all; I personally recommend removing this so as not to create confusion later. I may be uninformed, but what is a "selector string"? Are maps initiator specific or global for the target? Are they volatile? Under what conditions can the target clean out its map table? Can I blow away someone else's map values? Can I query the mapping table, either for the entire table or for the specific mapping of a particular SRA? I don't know what access control information is relevant here. In particular: -- What does FC address & port mean in this context for access controls based on TransportID (note the spelling as well)? -- There is *no need* or value in access proxy token in this context. That is handled *completely* in the SCSI Access Controls as approved by T10. Proxy Tokens are indirect handles to identify a logical unit and NOT for identification of a Target Device. </JIM> <snip> 2.21 Third Party Commands There are some third-party SCSI commands, such as (EXTENDED) COPY and COMPARE that involve more than one target. In it's most general form those commands involve the "original target" called the COPY-Manager and a (variable) number of other machines called source and destination. The whole operation is described by one "master CDB" delivered to the Copy manager and a series of descriptor blocks; each descriptor block addresses a source and destination target and LU and a description of the work to be done in terms of blocks or bytes as required by the device types. The relevant SCSI standards do not require full support of the (EXTENDED) COPY or COMPARE nor do they provide a detailed execution model. We will assume, in the spirit of [SPC-2], that a COPY manager will read data from a source and write them to a destination. To address them an iSCSI COPY manager will use information provided to it through map commands and the SRAs and flags provided in the descriptors - allowing for iSCSI and FC sources and destinations. Enabling a FC COPY manager to support iSCSI sources and destinations is subject to coordination with T10. <JIM> Note that COPY and COMPARE have now been made Obsolete in SPC-2 so there probably isn't a reason to mention them here. The language of the first paragraph reads to me like an editorial comment on SPC-2. I would suggest wording for this section that more closely resembles that of FCP-2. </JIM> <snip> 6.2.2.4 Encryption This mode provides for the end-to-end encryption (e.g. IPsec). In addition to authenticating the client, it provides end-to-end data integrity and protects against man-in-the-middle attacks, eavesdropping, message insertion, deletion, and modification. <JIM> I thought IPsec provides only link-level security and NOT end-to-end. Am I wrong? </JIM> <snip> Appendix A 02 Authentication <snip> The authentication methods to be used are public key, user/password or challenge/response. <JIM> We don't allow for Kerberos in here (or something like that)? </JIM> If public key is selected then each party MUST use: authenticate:<user-id>,<blob> where user-id is the SCSI access-id of the host-OS for the initiator or the World-Wide-Name for the target and blob is the public-key blob. <JIM> As the author of the SCSI access controls, I am personally not comfortable with use of the AccessID (note the spelling) in this context for authentication. Note that AccessIDs are NOT used for security in SCSI, only for identification. For layering reasons and others, I feel that iSCSI security should be based on independent principles between the iSCSI entities and NOT on SCSI related concepts. Additionally, AccessIDs are NOT required for initiators in SCSI and so cannot (should not?) be required here. Finally, let me mention that a (weak) reason to use AccessIDs in this context is that a given target may decide to reject a login for a particular AccessID if that initiator has no accessible logical units. On the other hand, the initiator may have two other reasons (in the context of SCSI access controls) for connecting to a target *even if* that initiator has no accessible logical units. These include: 1) the initiator needs to deliver a SCSI ACCESS CONTROL IN/OUT command to that target to query or change access controls (weak authentication of the CDB itself is done with a "key" embedded in the command or the parameter data). 2) the initiator holds a proxy token that (indirectly) references a logical unit on that target (this token is also embedded in the CDB or parameter data). So, either we include these additional tags in parallel with AccessID for the purposes of authentication OR we don't use any of them. I vote for not using any of them for this purpose. I don't object to including a key:value for these three things as additional data in login (especially after the security context has been established) but I think they need to be divorced from the authentication proceedure completely. </JIM> Jim Hafner IBM Research
Home Last updated: Tue Sep 04 01:06:27 2001 6315 messages in chronological order |