tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3720

 
 
 

Internet Small Computer Systems Interface (iSCSI)

Part 5 of 9, p. 99 to 128
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 99 
8.  Security Considerations

   Historically, native storage systems have not had to consider
   security because their environments offered minimal security risks.
   That is, these environments consisted of storage devices either
   directly attached to hosts or connected via a Storage Area Network
   (SAN) distinctly separate from the communications network.  The use
   of storage protocols, such as SCSI, over IP-networks requires that
   security concerns be addressed.  iSCSI implementations MUST provide
   means of protection against active attacks (e.g., pretending to be
   another identity, message insertion, deletion, modification, and
   replaying) and passive attacks (e.g., eavesdropping, gaining
   advantage by analyzing the data sent over the line).

Top      Up      ToC       Page 100 
   Although technically possible, iSCSI SHOULD NOT be configured without
   security.  iSCSI configured without security should be confined, in
   extreme cases, to closed environments without any security risk.
   [RFC3723] specifies the mechanisms that must be used in order to
   mitigate risks fully described in that document.

   The following section describes the security mechanisms provided by
   an iSCSI implementation.

8.1.  iSCSI Security Mechanisms

   The entities involved in iSCSI security are the initiator, target,
   and the IP communication end points.  iSCSI scenarios in which
   multiple initiators or targets share a single communication end point
   are expected.  To accommodate such scenarios, iSCSI uses two separate
   security mechanisms: In-band authentication between the initiator and
   the target at the iSCSI connection level (carried out by exchange of
   iSCSI Login PDUs), and packet protection (integrity, authentication,
   and confidentiality) by IPsec at the IP level.  The two security
   mechanisms complement each other.  The in-band authentication
   provides end-to-end trust (at login time) between the iSCSI initiator
   and the target while IPsec provides a secure channel between the IP
   communication end points.

   Further details on typical iSCSI scenarios and the relation between
   the initiators, targets, and the communication end points can be
   found in [RFC3723].

8.2.  In-band Initiator-Target Authentication

   During login, the target MAY authenticate the initiator and the
   initiator MAY authenticate the target.  The authentication is
   performed on every new iSCSI connection by an exchange of iSCSI Login
   PDUs using a negotiated authentication method.

   The authentication method cannot assume an underlying IPsec
   protection, because IPsec is optional to use.  An attacker should
   gain as little advantage as possible by inspecting the authentication
   phase PDUs.  Therefore, a method using clear text (or equivalent)
   passwords is not acceptable; on the other hand, identity protection
   is not strictly required.

   The authentication mechanism protects against an unauthorized login
   to storage resources by using a false identity (spoofing).  Once the
   authentication phase is completed, if the underlying IPsec is not
   used, all PDUs are sent and received in clear.  The authentication

Top      Up      ToC       Page 101 
   mechanism alone (without underlying IPsec) should only be used when
   there is no risk of eavesdropping, message insertion, deletion,
   modification, and replaying.

   Section 11 iSCSI Security Text Keys and Authentication Methods
   defines several authentication methods and the exact steps that must
   be followed in each of them, including the iSCSI-text-keys and their
   allowed values in each step.  Whenever an iSCSI initiator gets a
   response whose keys, or their values, are not according to the step
   definition, it MUST abort the connection.  Whenever an iSCSI target
   gets a response whose keys, or their values, are not according to the
   step definition, it MUST answer with a Login reject with the
   "Initiator Error" or "Missing Parameter" status.  These statuses are
   not intended for cryptographically incorrect values such as the CHAP
   response, for which "Authentication Failure" status MUST be
   specified.  The importance of this rule can be illustrated in CHAP
   with target authentication (see Section 11.1.4 Challenge Handshake
   Authentication Protocol (CHAP)) where the initiator would have been
   able to conduct a reflection attack by omitting his response key
   (CHAP_R) using the same CHAP challenge as the target and reflecting
   the target's response back to the target.  In CHAP, this is prevented
   because the target must answer the missing CHAP_R key with a Login
   reject with the "Missing Parameter" status.

   For some of the authentication methods, a key specifies the identity
   of the iSCSI initiator or target for authentication purposes.  The
   value associated with that key MAY be different from the iSCSI name
   and SHOULD be configurable.  (CHAP_N, see Section 11.1.4 Challenge
   Handshake Authentication Protocol (CHAP) and SRP_U, see Section
   11.1.3 Secure Remote Password (SRP)).

8.2.1.  CHAP Considerations

   Compliant iSCSI initiators and targets MUST implement the CHAP
   authentication method [RFC1994] (according to Section 11.1.4
   Challenge Handshake Authentication Protocol (CHAP) including the
   target authentication option).

   When CHAP is performed over a non-encrypted channel, it is vulnerable
   to an off-line dictionary attack.  Implementations MUST support use
   of up to 128 bit random CHAP secrets, including the means to generate
   such secrets and to accept them from an external generation source.
   Implementations MUST NOT provide secret generation (or expansion)
   means other than random generation.

   An administrative entity of an environment in which CHAP is used with
   a secret that has less than 96 random bits MUST enforce IPsec
   encryption (according to the implementation requirements in Section

Top      Up      ToC       Page 102 
   8.3.2 Confidentiality) to protect the connection.  Moreover, in this
   case IKE authentication with group pre-shared cryptographic keys
   SHOULD NOT be used unless it is not essential to protect group
   members against off-line dictionary attacks by other members.

   CHAP secrets MUST be an integral number of bytes (octets). A
   compliant implementation SHOULD NOT continue with the login step in
   which it should send a CHAP response (CHAP_R, Section 11.1.4
   Challenge Handshake Authentication Protocol (CHAP)) unless it can
   verify that the CHAP secret is at least 96 bits, or that IPsec
   encryption is being used to protect the connection.

   Any CHAP secret used for initiator authentication MUST NOT be
   configured for authentication of any target, and any CHAP secret used
   for target authentication MUST NOT be configured for authentication
   of any initiator.  If the CHAP response received by one end of an
   iSCSI connection is the same as the CHAP response that the receiving
   endpoint would have generated for the same CHAP challenge, the
   response MUST be treated as an authentication failure and cause the
   connection to close (this ensures that the same CHAP secret is not
   used for authentication in both directions).  Also, if an iSCSI
   implementation can function as both initiator and target, different
   CHAP secrets and identities MUST be configured for these two roles.
   The following is an example of the attacks prevented by the above
   requirements:

     Rogue wants to impersonate Storage to Alice, and knows that a
      single secret is used for both directions of Storage-Alice
      authentication.

     Rogue convinces Alice to open two connections to Rogue, and Rogue
      identifies itself as Storage on both connections.

     Rogue issues a CHAP challenge on connection 1, waits for Alice to
      respond, and then reflects Alice's challenge as the initial
      challenge to Alice on connection 2.

     If Alice doesn't check for the reflection across connections,
      Alice's response on connection 2 enables Rogue to impersonate
      Storage on connection 1, even though Rogue does not know the
      Alice-Storage CHAP secret.

   Originators MUST NOT reuse the CHAP challenge sent by the Responder
   for the other direction of a bidirectional authentication.
   Responders MUST check for this condition and close the iSCSI TCP
   connection if it occurs.

Top      Up      ToC       Page 103 
   The same CHAP secret SHOULD NOT be configured for authentication of
   multiple initiators or multiple targets, as this enables any of them
   to impersonate any other one of them, and compromising one of them
   enables the attacker to impersonate any of them.  It is recommended
   that iSCSI implementations check for use of identical CHAP secrets by
   different peers when this check is feasible, and take appropriate
   measures to warn users and/or administrators when this is detected.

   When an iSCSI initiator or target authenticates itself to
   counterparts in multiple administrative domains, it SHOULD use a
   different CHAP secret for each administrative domain to avoid
   propagating security compromises across domains.

   Within a single administrative domain:
   - A single CHAP secret MAY be used for authentication of an initiator
   to multiple targets.
   - A single CHAP secret MAY be used for an authentication of a target
   to multiple initiators when the initiators use an external server
   (e.g., RADIUS) to verify the target's CHAP responses and do not know
   the target's CHAP secret.

   If an external response verification server (e.g., RADIUS) is not
   used, employing a single CHAP secret for authentication of a target
   to multiple initiators requires that all such initiators know that
   target secret.  Any of these initiators can impersonate the target to
   any other such initiator, and compromise of such an initiator enables
   an attacker to impersonate the target to all such initiators.
   Targets SHOULD use separate CHAP secrets for authentication to each
   initiator when such risks are of concern; in this situation it may be
   useful to configure a separate logical iSCSI target with its own
   iSCSI Node Name for each initiator or group of initiators among which
   such separation is desired.

8.2.2.  SRP Considerations

   The strength of the SRP authentication method (specified in
   [RFC2945]) is dependent on the characteristics of the group being
   used (i.e., the prime modulus N and generator g).  As described in
   [RFC2945], N is required to be a Sophie-German prime (of the form
   N = 2q + 1, where q is also prime) and the generator g is a primitive
   root of GF(n).  In iSCSI authentication, the prime modulus N MUST be
   at least 768 bits.

   The list of allowed SRP groups is provided in [RFC3723].

Top      Up      ToC       Page 104 
8.3.  IPsec

   iSCSI uses the IPsec mechanism for packet protection (cryptographic
   integrity, authentication, and confidentiality) at the IP level
   between the iSCSI communicating end points.  The following sections
   describe the IPsec protocols that must be implemented for data
   integrity and authentication, confidentiality, and cryptographic key
   management.

   An iSCSI initiator or target may provide the required IPsec support
   fully integrated or in conjunction with an IPsec front-end device.
   In the latter case, the compliance requirements with regard to IPsec
   support apply to the "combined device".  Only the "combined device"
   is to be considered an iSCSI device.

   Detailed considerations and recommendations for using IPsec for iSCSI
   are provided in [RFC3723].

8.3.1.  Data Integrity and Authentication

   Data authentication and integrity is provided by a cryptographic
   keyed Message Authentication Code in every sent packet.  This code
   protects against message insertion, deletion, and modification.
   Protection against message replay is realized by using a sequence
   counter.

   An iSCSI compliant initiator or target MUST provide data integrity
   and authentication by implementing IPsec [RFC2401] with ESP [RFC2406]
   in tunnel mode and MAY provide data integrity and authentication by
   implementing IPsec with ESP in transport mode.  The IPsec
   implementation MUST fulfill the following iSCSI specific
   requirements:

     - HMAC-SHA1 MUST be implemented [RFC2404].
     - AES CBC MAC with XCBC extensions SHOULD be implemented
       [RFC3566].

   The ESP anti-replay service MUST also be implemented.

   At the high speeds iSCSI is expected to operate, a single IPsec SA
   could rapidly cycle through the 32-bit IPsec sequence number space.
   In view of this, it may be desirable in the future for an iSCSI
   implementation that operates at speeds of 1 Gbps or greater to
   implement the IPsec sequence number extension [SEQ-EXT].

Top      Up      ToC       Page 105 
8.3.2.  Confidentiality

   Confidentiality is provided by encrypting the data in every packet.
   When confidentiality is used it MUST be accompanied by data integrity
   and authentication to provide comprehensive protection against
   eavesdropping, message insertion, deletion, modification, and
   replaying.

   An iSCSI compliant initiator or target MUST provide confidentiality
   by implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and
   MAY provide confidentiality by implementing IPsec with ESP in
   transport mode, with the following iSCSI specific requirements:

     - 3DES in CBC mode MUST be implemented [RFC2451].
     - AES in Counter mode SHOULD be implemented [RFC3686].

   DES in CBC mode SHOULD NOT be used due to its inherent weakness.  The
   NULL encryption algorithm MUST also be implemented.

8.3.3.  Policy, Security Associations, and Cryptographic Key Management

   A compliant iSCSI implementation MUST meet the cryptographic key
   management requirements of the IPsec protocol suite.  Authentication,
   security association negotiation, and cryptographic key management
   MUST be provided by implementing IKE [RFC2409] using the IPsec DOI
   [RFC2407] with the following iSCSI specific requirements:

    -  Peer authentication using a pre-shared cryptographic key MUST be
       supported.  Certificate-based peer authentication using digital
       signatures MAY be supported.  Peer authentication using the
       public key encryption methods outlined in IKE sections 5.2 and
       5.3[7] SHOULD NOT be used.

    -  When digital signatures are used to achieve authentication, an
       IKE negotiator SHOULD use IKE Certificate Request Payload(s) to
       specify the certificate authority.  IKE negotiators SHOULD check
       the pertinent Certificate Revocation List (CRL) before accepting
       a PKI certificate for use in IKE authentication procedures.

    -  Conformant iSCSI implementations MUST support IKE Main Mode and
       SHOULD support Aggressive Mode.  IKE main mode with pre-shared
       key authentication method SHOULD NOT be used when either the
       initiator or the target uses dynamically assigned IP addresses.
       While in many cases pre-shared keys offer good security,
       situations in which dynamically assigned addresses are used force
       the use of a group pre-shared key, which creates vulnerability to
       a man-in-the-middle attack.

Top      Up      ToC       Page 106 
    -  In the IKE Phase 2 Quick Mode, exchanges for creating the Phase 2
       SA, the Identity Payload, fields MUST be present.  ID_IPV4_ADDR,
       ID_IPV6_ADDR (if the protocol stack supports IPv6) and ID_FQDN
       Identity payloads MUST be supported; ID_USER_FQDN SHOULD be
       supported.  The IP Subnet, IP Address Range, ID_DER_ASN1_DN, and
       ID_DER_ASN1_GN formats SHOULD NOT be used.  The ID_KEY_ID
       Identity Payload MUST NOT be used.

   Manual cryptographic keying MUST NOT be used because it does not
   provide the necessary re-keying support.

   When IPsec is used, the receipt of an IKE Phase 2 delete message
   SHOULD NOT be interpreted as a reason for tearing down the iSCSI TCP
   connection.  If additional traffic is sent on it, a new IKE Phase 2
   SA will be created to protect it.

   The method used by the initiator to determine whether the target
   should be connected using IPsec is regarded as an issue of IPsec
   policy administration, and thus not defined in the iSCSI standard.

   If an iSCSI target is discovered via a SendTargets request in a
   discovery session not using IPsec, the initiator should assume that
   it does not need IPsec to establish a session to that target.  If an
   iSCSI target is discovered using a discovery session that does use
   IPsec, the initiator SHOULD use IPsec when establishing a session to
   that target.

9.  Notes to Implementers

   This section notes some of the performance and reliability
   considerations of the iSCSI protocol.  This protocol was designed to
   allow efficient silicon and software implementations.  The iSCSI task
   tag mechanism was designed to enable Direct Data Placement (DDP - a
   DMA form) at the iSCSI level or lower.

   The guiding assumption made throughout the design of this protocol is
   that targets are resource constrained relative to initiators.

   Implementers are also advised to consider the implementation
   consequences of the iSCSI to SCSI mapping model as outlined in
   Section 3.4.3 Consequences of the Model.

9.1.  Multiple Network Adapters

   The iSCSI protocol allows multiple connections, not all of which need
   to go over the same network adapter.  If multiple network connections
   are to be utilized with hardware support, the iSCSI protocol

Top      Up      ToC       Page 107 
   command-data-status allegiance to one TCP connection ensures that
   there is no need to replicate information across network adapters or
   otherwise require them to cooperate.

   However, some task management commands may require some loose form of
   cooperation or replication at least on the target.

9.1.1.  Conservative Reuse of ISIDs

   Historically, the SCSI model (and implementations and applications
   based on that model) has assumed that SCSI ports are static, physical
   entities.  Recent extensions to the SCSI model have taken advantage
   of persistent worldwide unique names for these ports.  In iSCSI
   however, the SCSI initiator ports are the endpoints of dynamically
   created sessions, so the presumptions of "static and physical" do not
   apply.  In any case, the model clauses (particularly, Section 3.4.2
   SCSI Architecture Model) provide for persistent, reusable names for
   the iSCSI-type SCSI initiator ports even though there does not need
   to be any physical entity bound to these names.

   To both minimize the disruption of legacy applications and to better
   facilitate the SCSI features that rely on persistent names for SCSI
   ports, iSCSI implementations SHOULD attempt to provide a stable
   presentation of SCSI Initiator Ports (both to the upper OS-layers and
   to the targets to which they connect).  This can be achieved in an
   initiator implementation by conservatively reusing ISIDs.  In other
   words, the same ISID should be used in the Login process to multiple
   target portal groups (of the same iSCSI Target or different iSCSI
   Targets).  The ISID RULE (Section 3.4.3 Consequences of the Model)
   only prohibits reuse to the same target portal group.  It does not
   "preclude" reuse to other target portal groups.  The principle of
   conservative reuse "encourages" reuse to other target portal groups.
   When a SCSI target device sees the same (InitiatorName, ISID) pair in
   different sessions to different target portal groups, it can identify
   the underlying SCSI Initiator Port on each session as the same SCSI
   port.  In effect, it can recognize multiple paths from the same
   source.

9.1.2.  iSCSI Name, ISID, and TPGT Use

   The designers of the iSCSI protocol envisioned there being one iSCSI
   Initiator Node Name per operating system image on a machine.  This
   enables SAN resource configuration and authentication schemes based
   on a  system's identity.  It supports the notion that it should be
   possible to assign access to storage resources based on "initiator
   device" identity.

Top      Up      ToC       Page 108 
   When there are multiple hardware or software components coordinated
   as a single iSCSI Node, there must be some (logical) entity that
   represents the iSCSI Node that makes the iSCSI Node Name available to
   all components involved in session creation and login.  Similarly,
   this entity that represents the iSCSI Node must be able to coordinate
   session identifier resources (ISID for initiators) to enforce both
   the ISID and TSIH RULES (see Section 3.4.3 Consequences of the
   Model).

   For targets, because of the closed environment, implementation of
   this entity should be straightforward.  However, vendors of iSCSI
   hardware (e.g., NICs or HBAs) intended for targets, SHOULD provide
   mechanisms for configuration of the iSCSI Node Name across the portal
   groups instantiated by multiple instances of these components within
   a target.

   However, complex targets making use of multiple Target Portal Group
   Tags may reconfigure them to achieve various quality goals.  The
   initiators have two mechanisms at their disposal to discover and/or
   check reconfiguring targets - the discovery session type and a key
   returned by the target during login to confirm the TPGT.  An
   initiator should attempt to "rediscover" the target configuration
   anytime a session is terminated unexpectedly.

   For initiators, in the long term, it is expected that operating
   system vendors will take on the role of this entity and provide
   standard APIs that can inform components of their iSCSI Node Name and
   can configure and/or coordinate ISID allocation, use, and reuse.

   Recognizing that such initiator APIs are not available today, other
   implementations of the role of this entity are possible.  For
   example, a human may instantiate the (common) Node name as part of
   the installation process of each iSCSI component involved in session
   creation and login.  This may be done either by pointing the
   component to a vendor-specific location for this datum or to a
   system-wide location.  The structure of the ISID namespace (see
   Section 10.12.5 ISID and [RFC3721]) facilitates implementation of the
   ISID coordination by allowing each component vendor to independently
   (of other vendor's components) coordinate allocation, use, and reuse
   of its own partition of the ISID namespace in a vendor-specific
   manner.  Partitioning of the ISID namespace within initiator portal
   groups managed by that vendor allows each such initiator portal group
   to act independently of all other portal groups when selecting an
   ISID for a login; this facilitates enforcement of the ISID RULE (see
   Section 3.4.3 Consequences of the Model) at the initiator.

Top      Up      ToC       Page 109 
   A vendor of iSCSI hardware (e.g., NICs or HBAs) intended for use in
   initiators MUST implement a mechanism for configuring the iSCSI Node
   Name.  Vendors, and administrators must ensure that iSCSI Node Names
   are unique worldwide.  It is therefore important that when one
   chooses to reuse the iSCSI Node Name of a disabled unit, not to
   re-assign that name to the original unit unless its worldwide
   uniqueness can be ascertained again.

   In addition, a vendor of iSCSI hardware must implement a mechanism to
   configure and/or coordinate ISIDs for all sessions managed by
   multiple instances of that hardware within a given iSCSI Node.  Such
   configuration might be either permanently pre-assigned at the factory
   (in a necessarily globally unique way), statically assigned (e.g.,
   partitioned across all the NICs at initialization in a locally unique
   way), or dynamically assigned (e.g., on-line allocator, also in a
   locally unique way).  In the latter two cases, the configuration may
   be via public APIs (perhaps driven by an independent vendor's
   software, such as the OS vendor) or via private APIs driven by the
   vendor's own software.

9.2.  Autosense and Auto Contingent Allegiance (ACA)

   Autosense refers to the automatic return of sense data to the
   initiator in case a command did not complete successfully.  iSCSI
   initiators and targets MUST support and use autosense.

   ACA helps preserve ordered command execution in the presence of
   errors.  As iSCSI can have many commands in-flight between initiator
   and target, iSCSI initiators and targets SHOULD support ACA.

9.3.  iSCSI Timeouts

   iSCSI recovery actions are often dependent on iSCSI time-outs being
   recognized and acted upon before SCSI time-outs.  Determining the
   right time-outs to use for various iSCSI actions (command
   acknowledgements expected, status acknowledgements, etc.) is very
   much dependent on infrastructure (hardware, links, TCP/IP stack,
   iSCSI driver).  As a guide, the implementer may use an average
   Nop-Out/Nop-In turnaround delay multiplied by a "safety factor"
   (e.g., 4) as a good estimate for the basic delay of the iSCSI stack
   for a given connection.  The safety factor should account for the
   network load variability.  For connection teardown the implementer
   may want to consider also the TCP common practice for the given
   infrastructure.

Top      Up      ToC       Page 110 
   Text negotiations MAY also be subject to either time-limits or limits
   in the number of exchanges.  Those SHOULD be generous enough to avoid
   affecting interoperability (e.g., allowing each key to be negotiated
   on a separate exchange).

   The relation between iSCSI timeouts and SCSI timeouts should also be
   considered.  SCSI timeouts should be longer than iSCSI timeouts plus
   the time required for iSCSI recovery whenever iSCSI recovery is
   planned.  Alternatively, an implementer may choose to interlock iSCSI
   timeouts and recovery with SCSI timeouts so that SCSI recovery will
   become active only where iSCSI is not planned to, or failed to,
   recover.

   The implementer may also want to consider the interaction between
   various iSCSI exception events - such as a digest failure - and
   subsequent timeouts.  When iSCSI error recovery is active, a digest
   failure is likely to result in discovering a missing command or data
   PDU.  In these cases, an implementer may want to lower the timeout
   values to enable faster initiation for recovery procedures.

9.4.  Command Retry and Cleaning Old Command Instances

   To avoid having old, retried command instances appear in a valid
   command window after a command sequence number wrap around, the
   protocol requires (see Section 3.2.2.1 Command Numbering and
   Acknowledging) that on every connection on which a retry has been
   issued, a non-immediate command be issued and acknowledged within a
   2**31-1 commands interval from the CmdSN of the retried command.
   This requirement can be fulfilled by an implementation in several
   ways.

   The simplest technique to use is to send a (non-retry) non-immediate
   SCSI command (or a NOP if no SCSI command is available for a while)
   after every command retry on the connection on which the retry was
   attempted.  As errors are deemed rare events, this technique is
   probably the most effective, as it does not involve additional checks
   at the initiator when issuing commands.

9.5.  Synch and Steering Layer and Performance

   While a synch and steering layer is optional, an initiator/target
   that does not have it working against a target/initiator that demands
   synch and steering may experience performance degradation caused by
   packet reordering and loss.  Providing a synch and steering mechanism
   is recommended for all high-speed implementations.

Top      Up      ToC       Page 111 
9.6.  Considerations for State-dependent Devices and Long-lasting SCSI
      Operations

   Sequential access devices operate on the principle that the position
   of the device is based on the last command processed.  As such,
   command processing order and knowledge of whether or not the previous
   command was processed is of the utmost importance to maintain data
   integrity.  For example, inadvertent retries of SCSI commands when it
   is not known if the previous SCSI command was processed is a
   potential data integrity risk.

   For a sequential access device, consider the scenario in which a SCSI
   SPACE command to backspace one filemark is issued and then re-issued
   due to no status received for the command.  If the first SPACE
   command was actually processed, the re-issued SPACE command, if
   processed, will cause the position to change.  Thus, a subsequent
   write operation will write data to the wrong position and any
   previous data at that position will be overwritten.

   For a medium changer device, consider the scenario in which an
   EXCHANGE MEDIUM command (the SOURCE ADDRESS and DESTINATION ADDRESS
   are the same thus performing a swap) is issued and then re-issued due
   to no status received for the command.  If the first EXCHANGE MEDIUM
   command was actually processed, the re-issued EXCHANGE MEDIUM
   command, if processed, will perform the swap again.  The net effect
   is that a swap was not performed thus leaving a data integrity
   exposure.

   All commands that change the state of the device (as in SPACE
   commands for sequential access devices, and EXCHANGE MEDIUM for
   medium changer device), MUST be issued as non-immediate commands for
   deterministic and in order delivery to iSCSI targets.

   For many of those state changing commands, the execution model also
   assumes that the command is executed exactly once.  Devices
   implementing READ POSITION and LOCATE provide a means for SCSI level
   command recovery and new tape-class  devices should support those
   commands.  In their absence a retry at SCSI level is difficult and
   error recovery at iSCSI level is advisable.

   Devices operating on long latency delivery subsystems and performing
   long lasting SCSI operations may need mechanisms that enable
   connection replacement while commands are running (e.g., during an
   extended copy operation).

Top      Up      ToC       Page 112 
9.6.1.  Determining the Proper ErrorRecoveryLevel

   The implementation and use of a specific ErrorRecoveryLevel should be
   determined based on the deployment scenarios of a given iSCSI
   implementation.  Generally, the following factors must be considered
   before deciding on the proper level of recovery:

      a)  Application resilience to I/O failures.
      b)  Required level of availability in the face of transport
          connection failures.
      c)  Probability of transport layer "checksum escape".  This in
          turn decides the iSCSI digest failure frequency, and thus the
          criticality of iSCSI-level error recovery.  The details of
          estimating this probability are outside the scope of this
          document.


   A consideration of the above factors for SCSI tape devices as an
   example suggests that implementations SHOULD use ErrorRecoveryLevel=1
   when transport connection failure is not a concern and SCSI level
   recovery is unavailable, and ErrorRecoveryLevel=2 when the connection
   failure is also of high likelihood during a backup/retrieval.

   For extended copy operations, implementations SHOULD use
   ErrorRecoveryLevel=2 whenever there is a relatively high likelihood
   of connection failure.

10.  iSCSI PDU Formats

   All multi-byte integers that are specified in formats defined in this
   document are to be represented in network byte order (i.e., big
   endian).  Any field that appears in this document assumes that the
   most significant byte is the lowest numbered byte and the most
   significant bit (within byte or field) is the lowest numbered bit
   unless specified otherwise.

   Any compliant sender MUST set all bits not defined and all reserved
   fields to zero unless specified otherwise.  Any compliant receiver
   MUST ignore any bit not defined and all reserved fields unless
   specified otherwise.  Receipt of reserved code values in defined
   fields MUST be reported as a protocol error.

   Reserved fields are marked by the word "reserved", some abbreviation
   of "reserved", or by "." for individual bits when no other form of
   marking is technically feasible.

Top      Up      ToC       Page 113 
10.1.  iSCSI PDU Length and Padding

   iSCSI PDUs are padded to the closest integer number of four byte
   words.  The padding bytes SHOULD be sent as 0.

10.2.  PDU Template, Header, and Opcodes

   All iSCSI PDUs have one or more header segments and, optionally, a
   data segment.  After the entire header segment group a header-digest
   MAY follow.  The data segment MAY also be followed by a data-digest.

   The Basic Header Segment (BHS) is the first segment in all of the
   iSCSI PDUs.  The BHS is a fixed-length 48-byte header segment.  It
   MAY be followed by Additional Header Segments (AHS), a Header-Digest,
   a Data Segment, and/or a Data-Digest.

Top      Up      ToC       Page 114 
   The overall structure of an iSCSI  PDU is as follows:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0/ Basic Header Segment (BHS)                                    /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48/ Additional Header Segment 1 (AHS)  (optional)                 /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
     / Additional Header Segment 2 (AHS)  (optional)                 /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   ----
     +---------------+---------------+---------------+---------------+
     / Additional Header Segment n (AHS)  (optional)                 /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   ----
     +---------------+---------------+---------------+---------------+
    k/ Header-Digest (optional)                                      /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    l/ Data Segment(optional)                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    m/ Data-Digest (optional)                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+

   All PDU segments and digests are padded to the closest integer number
   of four byte words.  For example, all PDU segments and digests start
   at a four byte word boundary and the padding ranges from 0 to 3
   bytes.  The padding bytes SHOULD be sent as 0.

   iSCSI response PDUs do not have AH Segments.

10.2.1.  Basic Header Segment (BHS)

   The BHS is 48 bytes long.  The Opcode and DataSegmentLength fields
   appear in all iSCSI PDUs.  In addition, when used, the Initiator Task
   Tag and Logical Unit Number always appear in the same location in the
   header.

Top      Up      ToC       Page 115 
   The format of the BHS is:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|I| Opcode    |F|  Opcode-specific fields                     |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| LUN or Opcode-specific fields                                 |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20/ Opcode-specific fields                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48

10.2.1.1  I

   For request PDUs, the I bit set to 1 is an immediate delivery marker.

10.2.1.2.  Opcode

   The Opcode indicates the type of iSCSI PDU the header encapsulates.

   The Opcodes are divided into two categories: initiator opcodes and
   target opcodes.  Initiator opcodes are in PDUs sent by the initiator
   (request PDUs).  Target opcodes are in PDUs sent by the target
   (response PDUs).

   Initiators MUST NOT use target opcodes and targets MUST NOT use
   initiator opcodes.

   Initiator opcodes defined in this specification are:

     0x00 NOP-Out
     0x01 SCSI Command (encapsulates a SCSI Command Descriptor Block)
     0x02 SCSI Task Management function request
     0x03 Login Request
     0x04 Text Request
     0x05 SCSI Data-Out (for WRITE operations)
     0x06 Logout Request
     0x10 SNACK Request
     0x1c-0x1e Vendor specific codes

Top      Up      ToC       Page 116 
   Target opcodes are:

     0x20 NOP-In
     0x21 SCSI Response - contains SCSI status and possibly sense
      information or other response information.
     0x22 SCSI Task Management function response
     0x23 Login Response
     0x24 Text Response
     0x25 SCSI Data-In - for READ operations.
     0x26 Logout Response
     0x31 Ready To Transfer (R2T) - sent by target when it is ready
      to receive data.
     0x32 Asynchronous Message - sent by target to indicate certain
      special conditions.
     0x3c-0x3e Vendor specific codes
     0x3f Reject

   All other opcodes are reserved.

10.2.1.3.  Final (F) bit

   When set to 1 it indicates the final (or only) PDU of a sequence.

10.2.1.4.  Opcode-specific Fields

   These fields have different meanings for different opcode types.

10.2.1.5.  TotalAHSLength

   Total length of all AHS header segments in units of four byte words
   including padding, if any.

   The TotalAHSLength is only used in PDUs that have an AHS and MUST be
   0 in all other PDUs.

10.2.1.6.  DataSegmentLength

   This is the data segment payload length in bytes (excluding padding).
   The DataSegmentLength MUST be 0 whenever the PDU has no data segment.

10.2.1.7.  LUN

   Some opcodes operate on a specific Logical Unit.  The Logical Unit
   Number (LUN) field identifies which Logical Unit.  If the opcode does
   not relate to a Logical Unit, this field is either ignored or may be
   used in an opcode specific way.  The LUN field is 64-bits and should

Top      Up      ToC       Page 117 
   be formatted in accordance with [SAM2].  For example, LUN[0] from
   [SAM2] is BHS byte 8 and so on up to LUN[7] from [SAM2], which is BHS
   byte 15.

10.2.1.8.  Initiator Task Tag

   The initiator assigns a Task Tag to each iSCSI task it issues.  While
   a task exists, this tag MUST uniquely identify the task session-wide.
   SCSI may also use the initiator task tag as part of the SCSI task
   identifier when the timespan during which an iSCSI initiator task tag
   must be unique extends over the timespan during which a SCSI task tag
   must be unique.  However, the iSCSI Initiator Task Tag must exist and
   be unique even for untagged SCSI commands.

10.2.2.  Additional Header Segment (AHS)

   The general format of an AHS is:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0| AHSLength                     | AHSType       | AHS-Specific  |
     +---------------+---------------+---------------+---------------+
    4/ AHS-Specific                                                  /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    x

10.2.2.1.  AHSType

   The AHSType field is coded as follows:

       bit 0-1 - Reserved

       bit 2-7 - AHS code

        0 - Reserved
        1 - Extended CDB
        2 - Expected Bidirectional Read Data Length
        3 - 63 Reserved

10.2.2.2.  AHSLength

   This field contains the effective length in bytes of the AHS
   excluding AHSType and AHSLength and padding, if any.  The AHS is
   padded to the smallest integer number of 4 byte words (i.e., from 0
   up to 3 padding bytes).

Top      Up      ToC       Page 118 
10.2.2.3.  Extended CDB AHS

   The format of the Extended CDB AHS is:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0| AHSLength (CDBLength-15)      | 0x01          | Reserved      |
     +---------------+---------------+---------------+---------------+
    4/ ExtendedCDB...+padding                                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    x

   This type of AHS MUST NOT be used if the CDBLength is less than 17.
   The length includes the reserved byte 3.

10.2.2.4.  Bidirectional Expected Read-Data Length AHS

   The format of the Bidirectional Read Expected Data Transfer Length
   AHS is:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0| AHSLength (0x0005)            | 0x02          | Reserved      |
     +---------------+---------------+---------------+---------------+
    4| Expected Read-Data Length                                     |
     +---------------+---------------+---------------+---------------+
    8

10.2.3.  Header Digest and Data Digest

   Optional header and data digests protect the integrity of the header
   and data, respectively.  The digests, if present, are located,
   respectively, after the header and PDU-specific data, and cover
   respectively the header and the PDU data, each including the padding
   bytes, if any.

   The existence and type of digests are negotiated during the Login
   Phase.

   The separation of the header and data digests is useful in iSCSI
   routing applications, in which only the header changes when a message
   is forwarded.  In this case, only the header digest should be
   recalculated.

Top      Up      ToC       Page 119 
   Digests are not included in data or header length fields.

   A zero-length Data Segment also implies a zero-length data-digest.

10.2.4.  Data Segment

   The (optional) Data Segment contains PDU associated data.  Its
   payload effective length is provided in the BHS field -
   DataSegmentLength.  The Data Segment is also padded to an integer
   number of 4 byte words.

10.3.  SCSI Command

   The format of the SCSI Command PDU is:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|I| 0x01      |F|R|W|. .|ATTR | Reserved                      |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Logical Unit Number (LUN)                                     |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| Expected Data Transfer Length                                 |
     +---------------+---------------+---------------+---------------+
   24| CmdSN                                                         |
     +---------------+---------------+---------------+---------------+
   28| ExpStatSN                                                     |
     +---------------+---------------+---------------+---------------+
   32/ SCSI Command Descriptor Block (CDB)                           /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
   48/ AHS (Optional)                                                /
     +---------------+---------------+---------------+---------------+
    x/ Header Digest (Optional)                                      /
     +---------------+---------------+---------------+---------------+
    y/ (DataSegment, Command Data) (Optional)                        /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
    z/ Data Digest (Optional)                                        /
     +---------------+---------------+---------------+---------------+

Top      Up      ToC       Page 120 
10.3.1.  Flags and Task Attributes (byte 1)

   The flags for a SCSI Command are:

   bit 0   (F) is set to 1 when no unsolicited SCSI Data-Out PDUs follow
            this PDU.  When F=1 for a write and if Expected Data
            Transfer Length is larger than the DataSegmentLength, the
            target may solicit additional data through R2T.

   bit 1   (R) is set to 1 when the command is expected to input data.

   bit 2   (W) is set to 1 when the command is expected to output data.

   bit 3-4 Reserved.

   bit 5-7 contains Task Attributes.

   Task Attributes (ATTR) have one of the following integer values (see
   [SAM2] for details):

     0 - Untagged
     1 - Simple
     2 - Ordered
     3 - Head of Queue
     4 - ACA
     5-7 - Reserved

   Setting both the W and the F bit to 0 is an error.  Either or both of
   R and W MAY be 1 when either the Expected Data Transfer Length and/or
   Bidirectional Read Expected Data Transfer Length are 0, but they MUST
   NOT both be 0 when the Expected Data Transfer Length and/or
   Bidirectional Read Expected Data Transfer Length are not 0 (i.e.,
   when some data transfer is expected the transfer direction is
   indicated by the R and/or W bit).

10.3.2.  CmdSN - Command Sequence Number

   Enables ordered delivery across multiple connections in a single
   session.

10.3.3.  ExpStatSN

   Command responses up to ExpStatSN-1 (mod 2**32) have been received
   (acknowledges status) on the connection.

Top      Up      ToC       Page 121 
10.3.4.  Expected Data Transfer Length

   For unidirectional operations, the Expected Data Transfer Length
   field contains the number of bytes of data involved in this SCSI
   operation.  For a unidirectional write operation (W flag set to 1 and
   R flag set to 0), the initiator uses this field to specify the number
   of bytes of data it expects to transfer for this operation.  For a
   unidirectional read operation (W flag set to 0 and R flag set to 1),
   the initiator uses this field to specify the number of bytes of data
   it expects the target to transfer to the initiator.  It corresponds
   to the SAM2 byte count.

   For bidirectional operations (both R and W flags are set to 1), this
   field contains the number of data bytes involved in the write
   transfer.  For bidirectional operations, an additional header segment
   MUST be present in the header sequence that indicates the
   Bidirectional Read Expected Data Transfer Length.  The Expected Data
   Transfer Length field and the Bidirectional Read Expected Data
   Transfer Length field correspond to the SAM2 byte count

   If the Expected Data Transfer Length for a write and the length of
   the immediate data part that follows the command (if any) are the
   same, then no more data PDUs are expected to follow.  In this case,
   the F bit MUST be set to 1.

   If the Expected Data Transfer Length is higher than the
   FirstBurstLength (the negotiated maximum amount of unsolicited data
   the target will accept), the initiator MUST send the maximum amount
   of unsolicited data OR ONLY the immediate data, if any.

   Upon completion of a data transfer, the target informs the initiator
   (through residual counts) of how many bytes were actually processed
   (sent and/or received) by the target.

10.3.5.  CDB - SCSI Command Descriptor Block

   There are 16 bytes in the CDB field to accommodate the commonly used
   CDBs.  Whenever the CDB is larger than 16 bytes, an Extended CDB AHS
   MUST be used to contain the CDB spillover.

10.3.6.  Data Segment - Command Data

   Some SCSI commands require additional parameter data to accompany the
   SCSI command.  This data may be placed beyond the boundary of the
   iSCSI header in a data segment.  Alternatively, user data (e.g., from
   a WRITE operation) can be placed in the data segment (both cases are

Top      Up      ToC       Page 122 
   referred to as immediate data).  These data are governed by the rules
   for solicited vs. unsolicited data outlined in Section 3.2.4.2 Data
   Transfer Overview.

10.4.  SCSI Response

   The format of the SCSI Response PDU is:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|.|.| 0x21      |1|. .|o|u|O|U|.| Response      | Status        |
     +---------------+---------------+---------------+---------------+
    4|TotalAHSLength | DataSegmentLength                             |
     +---------------+---------------+---------------+---------------+
    8| Reserved                                                      |
     +                                                               +
   12|                                                               |
     +---------------+---------------+---------------+---------------+
   16| Initiator Task Tag                                            |
     +---------------+---------------+---------------+---------------+
   20| SNACK Tag or Reserved                                         |
     +---------------+---------------+---------------+---------------+
   24| StatSN                                                        |
     +---------------+---------------+---------------+---------------+
   28| ExpCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   32| MaxCmdSN                                                      |
     +---------------+---------------+---------------+---------------+
   36| ExpDataSN or Reserved                                         |
     +---------------+---------------+---------------+---------------+
   40| Bidirectional Read Residual Count or Reserved                 |
     +---------------+---------------+---------------+---------------+
   44| Residual Count or Reserved                                    |
     +---------------+---------------+---------------+---------------+
   48| Header-Digest (Optional)                                      |
     +---------------+---------------+---------------+---------------+
     / Data Segment (Optional)                                       /
    +/                                                               /
     +---------------+---------------+---------------+---------------+
     | Data-Digest (Optional)                                        |
     +---------------+---------------+---------------+---------------+

Top      Up      ToC       Page 123 
10.4.1.  Flags (byte 1)

     bit 1-2 Reserved.

     bit 3 - (o) set for Bidirectional Read Residual Overflow.  In this
       case, the Bidirectional Read Residual Count indicates the number
       of bytes that were not transferred to the initiator because the
       initiator's Expected Bidirectional Read Data Transfer Length was
       not sufficient.

     bit 4 - (u) set for Bidirectional Read Residual Underflow.  In this
       case, the Bidirectional Read Residual Count indicates the number
       of bytes that were not transferred to the initiator out of the
       number of bytes expected to be transferred.

     bit 5 - (O) set for Residual Overflow.  In this case, the Residual
       Count indicates the number of bytes that were not transferred
       because the initiator's Expected Data Transfer Length was not
       sufficient.  For a bidirectional operation, the Residual Count
       contains the residual for the write operation.

     bit 6 - (U) set for Residual Underflow.  In this case, the Residual
       Count indicates the number of bytes that were not transferred out
       of the number of bytes that were expected to be transferred.  For
       a bidirectional operation, the Residual Count contains the
       residual for the write operation.

     bit 7 - (0) Reserved.

   Bits O and U and bits o and u are mutually exclusive (i.e., having
   both o and u or O and U set to 1 is a protocol error).  For a
   response other than "Command Completed at Target", bits 3-6 MUST be
   0.

10.4.2.  Status

   The Status field is used to report the SCSI status of the command (as
   specified in [SAM2]) and is only valid if the Response Code is
   Command Completed at target.

Top      Up      ToC       Page 124 
   Some of the status codes defined in [SAM2] are:

     0x00 GOOD
     0x02 CHECK CONDITION
     0x08 BUSY
     0x18 RESERVATION CONFLICT
     0x28 TASK SET FULL
     0x30 ACA ACTIVE
     0x40 TASK ABORTED

   See [SAM2] for the complete list and definitions.

   If a SCSI device error is detected while data from the initiator is
   still expected (the command PDU did not contain all the data and the
   target has not received a Data PDU with the final bit Set), the
   target MUST wait until it receives a Data PDU with the F bit set in
   the last expected sequence before sending the Response PDU.

10.4.3.  Response

   This field contains the iSCSI service response.

   iSCSI service response codes defined in this specification are:

     0x00 - Command Completed at Target
     0x01 - Target Failure
     0x80-0xff - Vendor specific

   All other response codes are reserved.

   The Response is used to report a Service Response.  The mapping of
   the response code into a SCSI service response code value, if needed,
   is outside the scope of this document.  However, in symbolic terms
   response value 0x00 maps to the SCSI service response (see [SAM2] and
   [SPC3]) of TASK COMPLETE or LINKED COMMAND COMPLETE.  All other
   Response values map to the SCSI service response of SERVICE DELIVERY
   OR TARGET FAILURE.

   If a PDU that includes SCSI status (Response PDU or Data-In PDU
   including status) does not arrive before the session is terminated,
   the SCSI service response is SERVICE DELIVERY OR TARGET FAILURE.

   A non-zero Response field indicates a failure to execute the command
   in which case the Status and Flag fields are undefined.

Top      Up      ToC       Page 125 
10.4.4.  SNACK Tag

   This field contains a copy of the SNACK Tag of the last SNACK Tag
   accepted by the target on the same connection and for the command for
   which the response is issued.  Otherwise it is reserved and should be
   set to 0.

   After issuing a R-Data SNACK the initiator must discard any SCSI
   status unless contained in an SCSI Response PDU carrying the same
   SNACK Tag as the last issued R-Data SNACK for the SCSI command on the
   current connection.

   For a detailed discussion on R-Data SNACK see Section 10.16 SNACK
   Request.

10.4.5.  Residual Count

   The Residual Count field MUST be valid in the case where either the U
   bit or the O bit is set.  If neither bit is set, the Residual Count
   field is reserved.  Targets may set the residual count and initiators
   may use it when the response code is "completed at target" (even if
   the status returned is not GOOD).  If the O bit is set, the Residual
   Count indicates the number of bytes that were not transferred because
   the initiator's Expected Data Transfer Length was not sufficient.  If
   the U bit is set, the Residual Count indicates the number of bytes
   that were not transferred out of the number of bytes expected to be
   transferred.

10.4.6.  Bidirectional Read Residual Count

   The Bidirectional Read Residual Count field MUST be valid in the case
   where either the u bit or the o bit is set.  If neither bit is set,
   the Bidirectional Read Residual Count field is reserved.  Targets may
   set the Bidirectional Read Residual Count and initiators may use it
   when the response code is "completed at target".  If the o bit is
   set, the Bidirectional Read Residual Count indicates the number of
   bytes that were not transferred to the initiator because the
   initiator's Expected Bidirectional Read Transfer Length was not
   sufficient.  If the u bit is set, the Bidirectional Read Residual
   Count indicates the number of bytes that were not transferred to the
   initiator out of the number of bytes expected to be transferred.

10.4.7.  Data Segment - Sense and Response Data Segment

   iSCSI targets MUST support and enable autosense.  If Status is CHECK
   CONDITION (0x02), then the Data Segment MUST contain sense data for
   the failed command.

Top      Up      ToC       Page 126 
   For some iSCSI responses, the response data segment MAY contain some
   response related information, (e.g., for a target failure, it may
   contain a vendor specific detailed description of the failure).

   If the DataSegmentLength is not 0, the format of the Data Segment is
   as follows:

   Byte/     0       |       1       |       2       |       3       |
      /              |               |               |               |
     |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
     +---------------+---------------+---------------+---------------+
    0|SenseLength                    | Sense Data                    |
     +---------------+---------------+---------------+---------------+
    x/ Sense Data                                                    /
     +---------------+---------------+---------------+---------------+
    y/ Response Data                                                 /
     /                                                               /
     +---------------+---------------+---------------+---------------+
    z|

10.4.7.1.  SenseLength

   Length of Sense Data.

10.4.7.2.  Sense Data

   The Sense Data contains detailed information about a check condition
   and [SPC3] specifies the format and content of the Sense Data.

   Certain iSCSI conditions result in the command being terminated at
   the target (response Command Completed at Target) with a SCSI Check
   Condition Status as outlined in the next table:

Top      Up      ToC       Page 127 
   +--------------------------+----------+---------------------------+
   | iSCSI Condition          |Sense     | Additional Sense Code &   |
   |                          |Key       | Qualifier                 |
   +--------------------------+----------+---------------------------+
   | Unexpected unsolicited   |Aborted   | ASC = 0x0c ASCQ = 0x0c    |
   | data                     |Command-0B| Write Error               |
   +--------------------------+----------+---------------------------+
   | Incorrect amount of data |Aborted   | ASC = 0x0c ASCQ = 0x0d    |
   |                          |Command-0B| Write Error               |
   +--------------------------+----------+---------------------------+
   | Protocol Service CRC     |Aborted   | ASC = 0x47 ASCQ = 0x05    |
   | error                    |Command-0B| CRC Error Detected        |
   +--------------------------+----------+---------------------------+
   | SNACK rejected           |Aborted   | ASC = 0x11 ASCQ = 0x13    |
   |                          |Command-0B| Read Error                |
   +--------------------------+----------+---------------------------+

   The target reports the "Incorrect amount of data" condition if during
   data output the total data length to output is greater than
   FirstBurstLength and the initiator sent unsolicited non-immediate
   data but the total amount of unsolicited data is different than
   FirstBurstLength.  The target reports the same error when the amount
   of data sent as a reply to an R2T does not match the amount
   requested.

10.4.8.  ExpDataSN

   The number of R2T and Data-In (read) PDUs the target has sent for the
   command.

   This field MUST be 0 if the response code is not Command Completed at
   Target or the target sent no Data-In PDUs for the command.

10.4.9.  StatSN - Status Sequence Number

   StatSN is a Sequence Number that the target iSCSI layer generates per
   connection and that in turn, enables the initiator to acknowledge
   status reception.  StatSN is incremented by 1 for every
   response/status sent on a connection except for responses sent as a
   result of a retry or SNACK.  In the case of responses sent due to a
   retransmission request, the StatSN MUST be the same as the first time
   the PDU was sent unless the connection has since been restarted.

Top      Up      ToC       Page 128 
10.4.10.  ExpCmdSN - Next Expected CmdSN from this Initiator

   ExpCmdSN is a Sequence Number that the target iSCSI returns to the
   initiator to acknowledge command reception.  It is used to update a
   local variable with the same name.  An ExpCmdSN equal to MaxCmdSN+1
   indicates that the target cannot accept new commands.

10.4.11.  MaxCmdSN - Maximum CmdSN from this Initiator

   MaxCmdSN is a Sequence Number that the target iSCSI returns to the
   initiator to indicate the maximum CmdSN the initiator can send.  It
   is used to update a local variable with the same name.  If MaxCmdSN
   is equal to ExpCmdSN-1, this indicates to the initiator that the
   target cannot receive any additional commands.  When MaxCmdSN changes
   at the target while the target has no pending PDUs to convey this
   information to the initiator, it MUST generate a NOP-IN to carry the
   new MaxCmdSN.


Next RFC Part