Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations
Extracted elements (30)
Direct data placement ('zero-copy') is an important implementation goal: iSCSI data placed directly off the wire into allocated memory with no intermediate copies reduces memory bus loading, improves performance, and reduces NIC memory requirements. The protocol SHOULD permit such architectures.
Framing is needed for two distinct reasons: interfacing needs (locating PDU boundaries in a TCP byte stream) and accelerated processing needs (direct data placement even when packets are temporarily missing). A length field in the header alone is insufficient for zero-copy; the framing mechanism must allow resynchronization when a packet is temporarily missing.
iSCSI protocol documents MUST NOT define the management architecture or make explicit references to MIB variables or management objects, because management data and protocols change with environment needs and business models of management applications.
TCP was chosen as the initial transport because it is widely deployed, well-understood, and has proven congestion avoidance behavior. Using TCP minimizes new invention, enables rapid adoption, and provides the greatest compatibility with Internet architecture.
The symmetric connection binding approach (connection allegiance) was chosen over the asymmetric approach (all commands on one connection, data on another). Symmetric allegiance keeps command, data, and status on the same connection, guarantees status is received after data via TCP ordering, and reduces inter-processor communication when connections span processors.
Any feature SAM-2 requires in a valid transport mapping MUST be specified by iSCSI, and the iSCSI protocol document MUST specify for each feature whether it is OPTIONAL, RECOMMENDED, or REQUIRED to implement and/or use.
iSCSI's use of IP addresses and TCP port numbers MUST be firewall-friendly: all connection requests should normally be addressed to a specific well-known TCP port, allowing firewalls to filter on source/destination IP and destination port number.
iSCSI SHOULD allow deployment where functional and optimizing middle-boxes such as firewalls, proxy servers, and NATs are present. URL syntax for iSCSI resource connection allows an initiator to address a target both directly and through an iSCSI proxy server or NAT.
An iSCSI implementation MUST provide for the use of a data encryption protocol such as TLS or IPsec ESP to provide data confidentiality between iSCSI endpoints.
Authenticated login MUST be resilient against attacks since many IP networks are vulnerable to packet inspection. iSCSI MUST also support data origin authentication of its communications; its use MAY be optional.
iSCSI MUST allow for the construction of gateways to other SCSI transports including parallel SCSI and SCSI FCP. These are true application protocol gateways, not mere packet forwarders, sharing only the SCSI-3 command set layer.
iSCSI MUST allow implementations to equal or improve on the current state of the art for SCSI interconnects, and MUST enable cost-competitive implementations compared to other SCSI transports such as Fibre Channel.
iSCSI MUST be a good network citizen with TCP-compatible congestion control as defined in RFC 2914. iSCSI implementations MUST NOT use multiple connections as a means to avoid transport-layer congestion control.
iSCSI MUST be compatible with both IPv4 and IPv6, MUST NOT require changes to existing Internet protocols, and SHOULD minimize required changes to existing TCP/IP implementations.
iSCSI MUST be designed to allow future substitution of SCTP for TCP as an IP transport protocol with minimal changes to iSCSI protocol operation, PDU structures and formats.
iSCSI MUST make it possible to build I/O adapters that handle an entire SCSI task. The protocol MUST NOT impose complex operations on host software that would increase host instruction path length relative to alternatives.
iSCSI MUST NOT require changes to the SCSI-3 command sets and SCSI client code except where SCSI specifications point to 'transport dependent' fields and behavior. iSCSI MUST be capable of supporting all SCSI-3 command sets and device types.
iSCSI MUST provide a method of discovering, given an IP endpoint on its well-known port, the list of SCSI targets available to the requestor. The use of this discovery service MUST be optional.
iSCSI MUST provide for full utilization of available link bandwidth and MUST allow an implementation to exploit parallelism (multiple connections) at device interfaces and within the interconnect fabric.
iSCSI MUST provide for strong authentication when increased security is required. The protocol MUST support private authenticated login, where 'private' mandates protected identity exchange with no clear-text passwords at minimum.
iSCSI MUST reliably transport SCSI commands from initiator to target and MUST correctly deal with iSCSI packet drop, duplication, corruption, stale packets, and re-ordering.
iSCSI MUST specify feature negotiation at session establishment (login) and MUST operate correctly when no optional features are negotiated as well as when individual option negotiations are unsuccessful.
iSCSI MUST specify mechanisms to recover in a timely fashion from failures on the initiator, target, or connecting infrastructure, and MUST specify recovery methods for non-idempotent requests such as operations on tape drives.
iSCSI MUST specify strictly ordered delivery of SCSI commands over an iSCSI session between an initiator/target pair, even in the presence of transport errors, as required by SAM-2.
iSCSI MUST support a data integrity check format (CRC or other digest mechanism) computed on the SCSI data block itself, as well as on each command and status message, to protect against data corruption undetected by the TCP checksum.
iSCSI MUST support the SAM-2 naming architecture and MUST provide a means of identifying an iSCSI storage device by a unique identifier independent of the path on which it is found. The format for iSCSI names MUST use existing naming authorities.
The iSCSI protocol MUST operate over a single TCP connection to accommodate lower-cost implementations. Connection binding (multiple TCP connections appearing as one SCSI transport) SHOULD be supported but MUST be optional to implement.
All aspects of the iSCSI protocol SHOULD be scrutinized for potential denial of service issues and guarded against as much as possible. Firewall deployment is an important defense; iSCSI SHOULD operate through a firewall to defend against DoS from less-trusted network areas.
Data origin authentication is critical since IP networks are vulnerable to source spoofing, where a malicious third party pretends to send packets from the initiator's IP address. Authentication requirements SHOULD be met using standard Internet protocols such as IPsec or TLS.
Transporting block storage (SCSI) over IP opens a whole new opportunity for malicious attacks. Attacks can take the active form (identity spoofing, man-in-the-middle) or the passive form (eavesdropping), unlike directly-attached storage where physical connections offered little attack surface.