iSCSI

Most Intel Ethernet controllers for servers support iSCSI boot.[9]

iSCSI uses TCP (typically

iSCSI Qualified Name (IQN)

Format: The iSCSI Qualified Name is documented in RFC 3720, with further examples of names in RFC 3721. Briefly, the fields are:

• literal iqn (iSCSI Qualified Name)
• date (yyyy-mm) that the naming authority took ownership of the domain
• reversed domain name of the authority (e.g. org.alpinelinux, com.example, to.yp.cr)
• Optional ":" prefixing a storage target name specified by the naming authority.

From the RFC:^[10]

Extended Unique Identifier (EUI)

Format: eui.{EUI-64 bit address} (e.g. eui.02004567A425678D)

T11 Network Address Authority (NAA)

Format: naa.{NAA 64 or 128 bit identifier} (e.g. naa.52004567BA64678D)

IQN format addresses occur most commonly. They are qualified by a date (yyyy-mm) because domain names can expire or be acquired by another entity.

The IEEE Registration authority provides EUI in accordance with the EUI-64 standard. NAA is part OUI which is provided by the IEEE Registration Authority. NAA name formats were added to iSCSI in RFC 3980, to provide compatibility with naming conventions used in Fibre Channel and Serial Attached SCSI (SAS) storage technologies.

Usually, an iSCSI participant can be defined by three or four fields:

1. Hostname or IP Address (e.g., "iscsi.example.com")
2. Port Number (e.g., 3260)
3. iSCSI Name (e.g., the IQN "iqn.2003-01.com.ibm:00.fcd0ab21.shark128")
4. An optional
   CHAP
   Secret (e.g., "secretsarefun")

iSCSI initiators can locate appropriate storage resources using the Internet Storage Name Service (iSNS) protocol. In theory, iSNS provides iSCSI SANs with the same management model as dedicated Fibre Channel SANs. In practice, administrators can satisfy many deployment goals for iSCSI without using iSNS.

iSCSI initiators and targets prove their identity to each other using

Additionally, as with all IP-based protocols, IPsec can operate at the network layer. The iSCSI negotiation protocol is designed to accommodate other authentication schemes, though interoperability issues limit their deployment.

To ensure that only valid initiators connect to storage arrays, administrators most commonly run iSCSI only over logically isolated backchannel networks. In this deployment architecture, only the management ports of storage arrays are exposed to the general-purpose internal network, and the iSCSI protocol itself is run over dedicated network segments or

problem, in that a single compromised host with an iSCSI disk can be used to attack storage resources for other hosts.

Physical network isolation

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (November 2013) (Learn how and when to remove this message)

While iSCSI can be logically isolated from the general network using VLANs only, it is still no different from any other network equipment and may use any cable or port as long as there is a completed signal path between source and target. Just a single cabling mistake by a network technician can compromise the barrier of logical separation, and an accidental bridging may not be immediately detected because it does not cause network errors.

In order to further differentiate iSCSI from the regular network and prevent cabling mistakes when changing connections, administrators may implement self-defined color-coding and labeling standards, such as only using yellow-colored cables for the iSCSI connections and only blue cables for the regular network, and clearly labeling ports and switches used only for iSCSI.

While iSCSI could be implemented as just a VLAN cluster of ports on a large multi-port switch that is also used for general network usage, the administrator may instead choose to use physically separate switches dedicated to iSCSI VLANs only, to further prevent the possibility of an incorrectly connected cable plugged into the wrong port bridging the logical barrier.

Authorization

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (November 2013) (Learn how and when to remove this message)

Because iSCSI aims to consolidate storage for many servers into a single storage array, iSCSI deployments require strategies to prevent unrelated initiators from accessing storage resources. As a pathological example, a single enterprise storage array could hold data for servers variously regulated by the

PCI DSS

for credit card processing. During an audit, storage systems must demonstrate controls to ensure that a server under one regime cannot access the storage assets of a server under another.

Typically, iSCSI storage arrays explicitly map initiators to specific target LUNs; an initiator authenticates not to the storage array, but to the specific storage asset it intends to use. However, because the target LUNs for SCSI commands are expressed both in the iSCSI negotiation protocol and in the underlying SCSI protocol, care must be taken to ensure that access control is provided consistently.

Confidentiality and integrity

For the most part, iSCSI operates as a cleartext protocol that provides no cryptographic protection for data in motion during SCSI transactions. As a result, an attacker who can listen in on iSCSI Ethernet traffic can:[12]

• Reconstruct and copy the files and filesystems being transferred on the wire
• Alter the contents of files by injecting fake iSCSI frames
• Corrupt filesystems being accessed by initiators, exposing servers to software flaws in poorly tested filesystem code.

These problems do not occur only with iSCSI, but rather apply to any SAN protocol without cryptographic security. IP-based security protocols, such as IPsec, can provide standards-based cryptographic protection to this traffic.

The dates in the following table denote the first appearance of a native driver in each operating system. Third-party drivers for Windows and Linux were available as early as 2001, specifically for attaching IBM's IP Storage 200i appliance.^[13]

Most iSCSI targets involve disk, though iSCSI tape and medium-changer targets are popular as well. So far, physical devices have not featured native iSCSI interfaces on a component level. Instead, devices with Parallel SCSI or Fibre Channel interfaces are bridged by using iSCSI target software, external bridges, or controllers internal to the device enclosure.

Alternatively, it is possible to virtualize disk and tape targets. Rather than representing an actual physical device, an emulated virtual device is presented. The underlying implementation can deviate drastically from the presented target as is done with virtual tape library (VTL) products. VTLs use disk storage for storing data written to virtual tapes. As with actual physical devices, virtual targets are presented by using iSCSI target software, external bridges, or controllers internal to the device enclosure.

In the security products industry, some manufacturers use an iSCSI RAID as a target, with the initiator being either an IP-enabled encoder or camera.

Multiple systems exist that allow Fibre Channel, SCSI and SAS devices to be attached to an IP network for use via iSCSI. They can be used to allow migration from older storage technologies, access to SANs from remote servers and the linking of SANs over IP networks. An iSCSI gateway bridges IP servers to Fibre Channel SANs. The TCP connection is terminated at the gateway, which is implemented on a Fibre Channel switch or as a standalone appliance.