RFC 3721

Internet Small Computer Systems Interface (iSCSI) Naming and Discovery

📅 published April 2004, from ietf

RFC 3721: Internet Small Computer Systems Interface (iSCSI) Naming and Discovery 💖

Okay bestie, this one's the iSCSI naming and discovery doc, so it's all about how storage gear gets its name and how it finds other storage gear. Here's the title block tea ☕:

  • Number: RFC 3721
  • Category: Informational 🌸
  • Date: April 2004
  • Authors: M. Bakke (Cisco), J. Hafner, J. Hufferd, K. Voruganti (IBM), and M. Krueger (Hewlett-Packard)
  • Obsoletes / Updates: Nothing listed. This doc doesn't say it obsoletes or updates any other RFC. 🙅‍♀️

Status of this Memo

Okay so, this memo is just here to inform the Internet community. It is NOT an Internet standard of any kind, so don't go treating it like one 🙈 Distribution is totally unlimited, so share away 💅

© The Internet Society (2004). All Rights Reserved. The rights are reserved, periodt 💜

Abstract

So this doc gives you examples of how to build iSCSI names (iSCSI is SCSI over TCP, iykyk 🦋) and talks through how initiators find targets. It's the sidekick to the main iSCSI protocol doc, so think of it as the cute companion piece ✨

The big vibe here is flexibility 🎀 The goal is to work for both tiny, chill setups and huge environments that need serious security and scale. No one gets left out, that's the energy 🫶

Table of Contents

1. iSCSI Names and Addresses. . . . . . . . . . . . . . . . . . .   3
   1.1.  Constructing iSCSI names using the iqn. format . . . . .   5
   1.2.  Constructing iSCSI names using the eui. format . . . . .   8
2. iSCSI Alias. . . . . . . . . . . . . . . . . . . . . . . . . .   8
   2.1.  Purpose of an Alias. . . . . . . . . . . . . . . . . . .   8
   2.2.  Target Alias . . . . . . . . . . . . . . . . . . . . . .   9
   2.3.  Initiator Alias. . . . . . . . . . . . . . . . . . . . .  10
3. iSCSI Discovery. . . . . . . . . . . . . . . . . . . . . . . .  12
4. Security Considerations. . . . . . . . . . . . . . . . . . . .  13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   5.1.  Normative References . . . . . . . . . . . . . . . . . .  13
   5.2.  Informative References . . . . . . . . . . . . . . . . .  14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  14
Appendix A: iSCSI Naming Notes. . . . . . . . . . . . . . . . . .  15
Appendix B: Interaction with Proxies and Firewalls. . . . . . . .  16
            B.1.  Port Redirector . . . . . . . . . . . . . . . .  16
            B.2.  SOCKS server. . . . . . . . . . . . . . . . . .  17
            B.3.  SCSI gateway. . . . . . . . . . . . . . . . . .  17
            B.4.  iSCSI Proxy . . . . . . . . . . . . . . . . . .  18
            B.5.  Stateful Inspection Firewall. . . . . . . . . .  18
Appendix C: iSCSI Names and Security Identifiers. . . . . . . . .  19
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . .  21
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .  22

1. iSCSI Names and Addresses ✨

Okay, the main thing you can address and discover in iSCSI is an iSCSI Node 🧚 A node can be an initiator, a target, or both (multitasking queen 👑). The rules for building an iSCSI name live in [RFC3720].

This doc gives you examples of name construction that a naming authority might use 💅

Both targets and initiators need names so you can identify them and manage storage no matter where they live (their address). An iSCSI name is the unique ID for a node, and it doubles as the SCSI device name [SAM2] for an iSCSI device. It's also the main thing used to authenticate targets to initiators and initiators to targets, and it's how you manage storage resources. Main character energy, honestly 🎀

Here's a fun detail: iSCSI names belong to nodes, not to network adapter cards 🦋 That means you can move network HBAs between hosts freely without losing SCSI state info (reservations, mode page settings, etc.) or your authorization config. Iconic 😭

An iSCSI node also has one or more addresses. An iSCSI address points to a single path to a node, and it's made of the iSCSI name plus a transport (TCP) address in this format:

<domain-name>[:<port>]

Where <domain-name> is one of these:

  • An IPv4 address in dotted decimal notation. It's assumed when the name has exactly four numbers separated by dots (.), with each number in the range 0..255.
  • An IPv6 address in colon-separated hexadecimal notation, as specified in [RFC3513] and wrapped in "[" and "]" characters, as specified in [RFC2732]. 🌈
  • A Fully Qualified Domain Name (host name). It's assumed when the <domain-name> is neither an IPv4 nor an IPv6 address.

For iSCSI targets, the <port> is optional. If you include it, it's the TCP port the target is listening on for connections. If you leave it out, the default port 3260 (assigned by IANA) gets assumed. For iSCSI initiators, the <port> is omitted entirely 💖

Here are some address examples, so cute:

192.0.2.2
192.0.2.23:5003
[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]
[1080:0:0:0:8:800:200C:417A]
[3ffe:2a00:100:7031::1]
[1080::8:800:200C:417A]
[1080::8:800:200C:417A]:3260
[::192.0.2.5]
mydisks.example.com
moredisks.example.com:5003

Now the big idea: iSCSI keeps names and addresses carefully separate 🫶

  • An iSCSI Name is a location-independent, permanent identifier for an iSCSI node. Each node has exactly one iSCSI name, and it stays the same for the whole life of the node. The terms "initiator name" and "target name" also mean an iSCSI name.
  • An iSCSI Address tells you not just the iSCSI name of a node but also where that node is. It's made of a host name or IP address, a TCP port number (for the target), and the node's iSCSI Name. A node can have any number of addresses, and those can change at any time, especially if they're handed out by DHCP 🙈

Think of it like people 🌸 Say someone in the USA looks like this:

Robert Smith
SSN+DateOfBirth: 333-44-5555 14-MAR-1960
Phone: +1 (763) 555.1212
Home Address: 555 Big Road, Minneapolis, MN 55444
Work Address: 222 Freeway Blvd, St. Paul, MN 55333

So Robert's globally unique name is really his Social Security Number plus his Date of Birth. "Robert Smith" on its own isn't guaranteed to be unique, because lots of people share that name 😭 Robert can be reached at three locations: two physical addresses and a phone number.

Mapping that onto iSCSI: Robert's SSN+DOB is like the iSCSI Name (the date of birth is needed to tell apart SSNs that got reused). His phone number and addresses are like a node's TCP addresses. And "Robert Smith" is the human-friendly label, like a nickname 💜

Last thing for this part: devices with iSCSI targets and initiators can give those things a more human-readable name, called an alias ✨ An alias is a simple UTF-8 string. It's not globally unique, and it's never used to identify an initiator or device inside the iSCSI protocol, so it's just for vibes and readability. More on how aliases work in section 2 🎀

1.1. Constructing iSCSI names using the iqn. format 💅✨

okay so the iSCSI naming scheme was built to give an organizational naming authority the flexibility to split up the job of making names and hand pieces of it to subordinate naming authorities 🫶. the iSCSI qualified name format is defined in [RFC3720] and goes, in order:

  • The string "iqn."
  • A date code for the year and month in which the organization registered the domain or sub-domain name used as the naming authority string 📅
  • The organizational naming authority string, which is a valid, reversed domain or subdomain name 🔄
  • Optionally, a ':' followed by a string the assigning organization picks, which must make each assigned iSCSI name unique 🔑

here's an example from an equipment vendor, and it's giving main character energy 👑:

     Organizational      Subgroup Naming Authority
             Naming      and/or string Defined by
Type  Date     Auth      Org. or Local Naming Authority
+--++-----+ +---------+ +--------------------------------+
|  ||     | |         | |                                |

iqn.2001-04.com.example:diskarrays-sn-a8675309

Where:

  • "iqn" means the iSCSI qualified name is being used as the authority 🎀
  • "2001-04" is the year and month the naming authority got the domain name used in this iSCSI name. this is there so that when domain names get sold or transferred to another organization, the iSCSI names those organizations make will still be unique 🦋
  • "com.example" is a reversed DNS name and defines the organizational naming authority. the owner of "example.com" has the sole right to use that as this part of an iSCSI name, and also the job of keeping the rest of the iSCSI name unique. in this case example.com makes disk arrays 💾
  • "diskarrays" was picked arbitrarily by example.com to identify the disk arrays they make. another product that ACME makes might use a different name and have its own namespace, separate from the disk array group. the owner of "example.com" is responsible for keeping this structure unique 🧚
  • "sn" was picked by ACME's disk array group to show that what comes next is a serial number. they could have just assumed every iSCSI Name is based on serial numbers, but they figured later products might be better identified by something else, so adding "sn" was a future-proof move 🔮
  • "a8675309" is the serial number of the disk array, which uniquely identifies it from all the other arrays 🍓

another example shows how the ':' separator helps sub-domain owners keep their namespaces unique 🌸:

              Naming            Defined by
Type  Date     Authority         Naming Authority
+--++-----+ +-----------------+ +-----------+
|  ||     | |                 | |           |

iqn.2001-04.com.example.storage:tape.sys1.xyz

              Naming                Defined by
Type  Date     Authority             Naming Authority
+--++-----+ +----------------------+ +-----------+
|  ||     | |                      | |           |

iqn.2001-04.com.example.storage.tape:sys1.xyz

note that, apart from the ':' separator, both names are identical 👯. the first was assigned by the owner of the subdomain "storage.example.com", and the second by the owner of "tape.storage.example.com". these are both legal names and both are unique ✨.

here's a name a research organization might build 🔬:

            Naming        Defined by  Defined by
Type  Date    Authority      cs dept    User "oaks"
 +-+ +-----+ +------------+ +--------+ +-----------+
 | | |     | |            | |        | |           |
 iqn.2000-02.edu.example.cs:users.oaks:proto.target4

so in this one, Professor Oaks of Example University is building research prototypes of iSCSI targets 🧪. EU's computer science department lets each user use their user name as a naming authority for this kind of work, by attaching "users.<username>" after the ':', then another ':', followed by a string the user picks (the user is responsible for making that part unique). Professor Oaks went with "proto.target4" for this particular target 🥰.

next up is a name string from a storage service provider 🏢:

            Organization            String
               Naming            Defined by Org.
Type  Date    Authority          Naming Authority
 +-+ +-----+ +-------------+ +----------------------+
 | | |     | |             | |                      |
 iqn.1995-11.com.example.ssp:customers.4567.disks.107

in this case a storage service provider (ssp.example.com) decided to rename the targets from the manufacturer, so it has the flexibility to move a customer's data to a different storage subsystem if it ever needs to 🚚. the SSP configured the iSCSI Name on this target for one of its customers, and decided it made the most sense to track targets by Customer ID number and a disk number. this target was made for customer #4567, and it's the 107th target set up for that customer 💖.

Heads up bestie: when reversing these domain names, the first component (after the "iqn.") will always be a top-level domain name. that includes "com", "edu", "gov", "org", "net", "mil", or one of the two-letter country codes. using anything else as the first component is not allowed. and companies generating these names must not drop their "com." from the string 🚫.

and again, these iSCSI names are NOT addresses 🙅‍♀️. even though they use DNS domain names, they're only used to specify the naming authority. an iSCSI name contains no implications about where the iSCSI target or initiator is located. using the domain name is just a way of reusing a name space that's already everywhere 🌈.

1.2. Constructing iSCSI names using the eui. format 🧚‍♀️

the iSCSI eui. naming format lets a naming authority use IEEE EUI-64 identifiers when building iSCSI names 🔧. the details of building EUI-64 identifiers are specified by the IEEE Registration Authority (see [EUI64]).

example iSCSI name:

Type  EUI-64 identifier (ASCII-encoded hexadecimal)
+--++--------------+
|  ||              |
eui.02004567A425678D

2. iSCSI Alias 🎀✨

the iSCSI alias is a UTF-8 text string that can be used as an extra descriptive name for an initiator and a target 💅. it may not be used to identify a target or initiator during login, and it doesn't have to follow the uniqueness or other requirements of the iSCSI name. alias strings get communicated between the initiator and target at login, and a user interface on either end can display them, which helps the user tell at a glance whether the initiators and/or targets on the other end look right 👀. the alias must NOT be used to identify, address, or authenticate initiators and targets 🚨.

the alias is a variable-length string, between 0 and 255 characters, and it's terminated with at least one NULL (0x00) character, as defined in [RFC3720]. no other structure is imposed on this string 🫧.

2.1. Purpose of an Alias 🦄

initiators and targets are uniquely identified by an iSCSI Name 🪪. those identifiers can be assigned by a hardware or software manufacturer, a service provider, or even the customer. even though they're nominally human-readable, they're likely to be assigned from a point of view that's different from the other side of the connection 🙃. for instance, a target name for a disk array might be built from the array's serial number and some sort of internal target ID. that's still human-readable and transcribable, but it offers little assurance to someone at a user interface who wants to see "at-a-glance" whether this target is really the right one 😭.

that's where an alias comes in 💜. an alias is simply a descriptive name that can be assigned to an initiator or target. it's independent of the name and doesn't have to be unique. since it isn't unique, the alias must be used in a purely informational way. it may not be used to specify a target at login, or used during authentication 🙅.

both targets and initiators can have aliases 🌸.

2.2. Target Alias 🍓

let's look at an example of an alias for an iSCSI target, because it's so useful 🤩.

imagine sitting at a desktop station that's using some iSCSI devices over a network. the user needs another iSCSI disk, so they call the storage services person (internal or external) and give them whatever authentication info the storage device will need for the host 📞. the services person allocates a new target for the host, and sends the Target Name for the new target, and probably an address, back to the user. the user then adds this Target Name to the configuration file on the host, and the new device shows up 🎉.

without an alias, a user managing an iSCSI host would click some kind of management "show targets" button to see the targets the host is currently connected to 🫠.

+--Connected-To-These-Targets----------------------
|
|  Target Name
|
|  iqn.1995-04.com.example:sn.5551212.target.450
|  iqn.1995-04.com.example:sn.5551212.target.489
|  iqn.1995-04.com.example:sn.8675309
|  iqn.2001-04.com.example.storage:tape.sys1.xyz
|  iqn.2001-04.com.example.storage.tape:sys1.xyz
|
+--------------------------------------------------

in the example above, the user sees a bunch of iSCSI Names with no real description of what they're for 😵‍💫. they'll map to a system-dependent device file or drive letter, of course, but it's not easy to look at numbers and quickly tell if everything is there.

if a storage administrator sets up an alias for each target name, the alias can give a much more descriptive name ✨. that alias can be sent back to the initiator as part of the login response, or found in the iSCSI MIB. then it might show up in a display like this 👇:

+--Connected-To-These-Targets----------------------
|
|  Alias          Target Name
|
|  Oracle 1       iqn.1995-04.com.example:sn.5551212.target.450
|  Local Disk     iqn.1995-04.com.example:sn.5551212.target.489
|  Exchange 2     iqn.1995-04.com.example:sn.8675309
|
+--------------------------------------------------

that gives the user a way better idea of what's actually there 🥹.

in general, flexible, configured aliases will probably be supported by larger storage subsystems and configurable gateways 🏗️. simpler devices likely won't keep configuration data around for things like an alias. the TargetAlias string could be either left unsupported (not given to the initiator during login), or it could be returned as whatever "next best thing" the target has that might describe it better. since it doesn't have to be unique, it could even return SCSI inquiry string data 🧃.

Note, bestie: if a simple initiator doesn't want to keep or display alias information, it can just ignore it if it shows up in the login response 🙆‍♀️.

2.3. Initiator Alias

okay so initiator aliases work just like target aliases 💅 An initiator can send its alias in a login request, right alongside its iSCSI Initiator Name ✨ The alias isn't used for authentication (it's not the bouncer 🙅‍♀️). It just hangs out with the session info so it can show up in a management GUI, a command-line interface (for a more complex subsystem or gateway), or through the iSCSI MIB 🎀

Also, a simple target can totally ignore the Initiator Alias if it doesn't have a management interface to display it on. No shade 🫶

Usually the hostname is enough for an initiator alias, but a custom alias can be set up for the sake of the service provider if needed 🌸 Even better is a description of what the machine is actually used for, like "Exchange Server 1" or "User Web Server" 💖

Here's what a management interface looks like when it's showing a list of sessions on an iSCSI target network entity. The targets are using an internal target number, which is a made-up field with purely internal meaning 🧚

+--Connected-To-These-Initiators-------------------
|
|  Target   Initiator Name
|
|  450      iqn.1995-04.com.example.sw:cd.12345678-OEM-456
|  451      iqn.1995-04.com.example.os:hostid.A598B45C
|  309      iqn.1995-04.com.example.sw:cd.87654321-OEM-259
|
+--------------------------------------------------

And now with the initiator alias displayed 👀

+--Connected-To-These-Initiators-------------------
|
|  Target Alias               Initiator Name
|
|  450    Web Server 4        iqn.1995-04.com.example.sw:cd.12...
|  451    scsigw.example.com  iqn.1995-04.com.example.os:hosti...
|  309    Exchange Server     iqn.1995-04.com.example.sw:cd.87...
|
+--------------------------------------------------

Way more helpful for the storage admin! 💅 They can actually see who's connected to their targets without squinting at a wall of names 🙈 Sure, you could always do a reverse DNS lookup on the incoming IP address to get a host name, but simpler devices really don't handle that well because of blocking problems, and it won't always work if there's a firewall or iSCSI gateway involved 💀

Again, these are purely informational and optional, and they need a management application to show up at all 🍓

Aliases are super easy to implement ✨ Targets just send a TargetAlias whenever they send a TargetName. Initiators just send an InitiatorAlias whenever they send an InitiatorName. If an alias comes in that doesn't fit or seems invalid in any way, it gets ignored 🫶

3. iSCSI Discovery 🔍

The whole goal of iSCSI discovery is to let an initiator find the targets it has access to, plus at least one address where each target can be reached 🦋 This should generally be done with as little configuration as possible. This section only defines the discovery mechanism. It doesn't try to specify central management of iSCSI devices, so that's not in this doc 🙅‍♀️ Also, the discovery mechanisms listed here only find targets, so you still need the SCSI protocol for LUN discovery 💅

For an iSCSI initiator to start an iSCSI session with an iSCSI target, the initiator needs the IP address, the TCP port number, and the iSCSI target name 🧚 The discovery mechanisms are meant to give low overhead support for small iSCSI setups, plus scalable discovery for big enterprise setups 👑 So there are a bunch of methods to pick from. They range from listing targets and addresses on every initiator and doing no discovery at all, all the way to configuring nothing on each initiator and letting the initiator discover targets dynamically ✨ The different mechanisms differ in what they assume the initiators already know and what still needs to be discovered 🌈

iSCSI supports the following discovery mechanisms:

a. Static Configuration: This one assumes the IP address, TCP port, and iSCSI target name are already available to the initiator 💖 The initiator doesn't have to do any discovery here. It uses the IP address and TCP port to open a TCP connection, and it uses the iSCSI target name to set up an iSCSI session. This option is convenient for small iSCSI setups 🎀

b. SendTargets: This one assumes the target's IP address and TCP port are already known to the initiator 🌸 The initiator uses that info to set up a discovery session with the Network Entity. Then it sends the SendTargets text command to ask about the iSCSI targets available at that particular Network Entity (IP address). You can find the SendTargets command details in the iSCSI document [RFC3720] 📖 This option is convenient for iSCSI gateways and routers 🫶

c. Zero-Configuration: This one assumes the initiator doesn't know anything about the target at all 😭 The initiator can either multicast discovery messages directly to the targets, or send discovery messages to storage name servers. There are lots of general purpose discovery frameworks out there already, like Salutation [John], Jini [John], UPnP [John], SLP [RFC2608], and iSNS [iSNS] 🌈 For iSCSI specifically, SLP can clearly do the needed discovery functions [iSCSI-SLP], while iSNS [iSNS] can provide related management functions like notification, access management, configuration, and discovery management 👑 iSCSI equipment that needs discovery beyond SendTargets should at least implement SLP. Then it should consider iSNS when it needs extended discovery management, like in larger storage networks 💅 And since iSNS will support SLP, iSNS can be used to help manage the discovery information SLP returns 🦋

4. Security Considerations 🔐

Okay this part is serious, bestie 😭 Security issues are a big deal, so read this section carefully!

Most security issues relating to iSCSI naming are covered in the main iSCSI document [RFC3720] and the iSCSI security document [RFC3723] 🔐

Appendix B also talks about naming and discovery issues when gateways, proxies, and firewalls are used to solve security or discovery problems in some situations where iSCSI is deployed 🛡️

iSCSI lets you use several different authentication methods. For a lot of these methods, an authentication identifier is used, and it may be different from the iSCSI node name of the entity being authenticated 🫣 This is covered in more detail in Appendix C.

5. References 📚

5.1. Normative References

  • [RFC3720] Satran, J., Meth, K., Sapuntzakis, C. Chadalapaka, M. and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
  • [EUI64] EUI - "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority, http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
  • [SAM2] R. Weber et al, INCITS T10 Project 1157-D revision 24, "SCSI Architectural Model - 2 (SAM-2)", Section 4.7.6 "SCSI device name", September 2002.

5.2. Informative References

  • [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "SLP Version 2", RFC 2608, June 1999.
  • [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
  • [RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
  • [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox Communication Architecture and Framework", RFC 3303, August 2002.
  • [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 Addressing Architecture", RFC 3513, April 2003.
  • [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
  • [iSCSI-SLP] Bakke, M., et al., "Finding iSCSI Targets and Name Servers using SLP", Work in Progress, March 2003.
  • [iSNS] Tseng, J., et al., "Internet Storage Name Service (iSNS)", Work in Progress, January 2003.
  • [John] R. John, "UPnP, Jini and Salutation- A look at some popular coordination frameworks for future networked devices", http://www.cswl.com/whiteppr/tech/upnp.html", June 17, 1999.

6. Acknowledgements 🫶

Joe Czap (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (SANRAD), Larry Lamers (Adaptec), Josh Tseng (Nishan Systems), and Todd Sperry (Adaptec) all participated and made contributions while this document was being developed 🌟

Appendix A: iSCSI Naming Notes 🧁

Some iSCSI Name Examples for Targets:

  • Assign to a target based on controller serial number
iqn.2001-04.com.example:diskarray.sn.8675309
  • Assign to a target based on serial number
iqn.2001-04.com.example:diskarray.sn.8675309.oracle-db-1

Where oracle-db-1 might be a target label assigned by a user 🏷️

This would be useful for a controller that can present different logical targets to different hosts 💻

Obviously, any naming authority may come up with its own scheme and hierarchy for these names, and be just as valid 🙌

A target iSCSI Name should never be assigned based on interface hardware, or other hardware that can be swapped and moved to other devices. 🚫

Some iSCSI Name Examples for Initiators:

  • Assign to the OS image by fully qualified host name
iqn.2001-04.com.example.os:dns.com.customer1.host-four

Note the use of two FQDNs: that of the naming authority and also that of the host being named. This can cause problems due to limitations imposed on the size of the iSCSI Name 🥲

  • Assign to the OS image by OS install serial number
iqn.2001-04.com.example.os:newos5.12345-OEM-0067890-23456

Note that this breaks if an install CD is used more than once. Depending on the O/S vendor's philosophy, this might be a feature 🤷‍♀️

  • Assign to the Raid Array by a service provider
iqn.2001-04.com.example.myssp:users.mbakke05657

Appendix B: Interaction with Proxies and Firewalls 🧱

iSCSI was designed to let SCSI initiators and targets communicate over an arbitrary IP network 🌍 In theory, if you make some assumptions about authentication and security, the whole internet could be used as one giant storage network 🤯

However, there are many access and scaling problems that would come up when someone tries this 😬

  1. Most iSCSI targets may only be meant to be accessed by one or a few initiators. Discovering everything would be unnecessary.
  2. The initiator and target may be owned by separate entities, each with their own directory services, authentication, and other schemes. An iSCSI-aware proxy may be required to map between these things.
  3. Many environments use non-routable IP addresses, such as the "10." network.

For these reasons and others, various types of firewalls [RFC2979] and proxies will be deployed for iSCSI, similar in nature to those already handling protocols such as HTTP and FTP 🦋

B.1. Port Redirector 🎀

okay so a port redirector is a stateless device that is totally not aware of iSCSI 🙈 its whole job is Network Address Translation (NAT), which can map IP addresses between routable and non-routable domains, plus map TCP ports. devices with these powers can often filter based on IP addresses and TCP ports, but they generally do not provide meaningful security. they're used instead to sort out internal network routing issues 🧚

since these devices can totally act as routers and/or aggregators between a firewall and an iSCSI initiator or target, iSCSI connections have to stay operable through them. it's giving "must work anyway" 💅

Effects on iSCSI:

  • iSCSI-level data integrity checks must not include information from the TCP or IP headers, as these may be changed in between the initiator and target. 🫶
  • iSCSI messages that specify a particular initiator or target, such as login requests and third party requests, should specify the initiator or target in a location-independent manner. This is accomplished using the iSCSI Name. 💖
  • When an iSCSI discovery connection is to be used through a port redirector, a target will have to be configured to return a domain name instead of an IP address in a SendTargets response, since the port redirector will not be able to map the IP address(es) returned in the iSCSI message. It is a good practice to do this anyway. 🌸

B.2. SOCKS server ✨

a SOCKS server can map TCP connections from one network domain to another, and it is aware of the state of each TCP connection. main character energy 👑

the SOCKS server gives authenticated firewall traversal for applications that aren't firewall-aware. conceptually, SOCKS is a "shim-layer" that sits between the application (aka iSCSI) and TCP 🦋

to use SOCKS, the iSCSI initiator has to be modified to use the encapsulation routines in the SOCKS library. the initiator then opens up a TCP connection to the SOCKS server, typically on the canonical SOCKS port 1080. next comes a sub-negotiation, where the initiator is either authenticated or denied the connection request. if it's authenticated, the SOCKS server opens a TCP connection to the iSCSI target using the addressing information the initiator sent in the SOCKS shim. then the SOCKS server forwards iSCSI commands, data, and responses between the iSCSI initiator and target 🔥

use of the SOCKS server needs special modifications to the iSCSI initiator. no modifications are required to the iSCSI target. 💀

and since a SOCKS server can map most of the addresses and information in the IP and TCP headers, including sequence numbers, its effects on iSCSI are identical to those in the port redirector 🍓

B.3. SCSI gateway 🧚

this gateway presents logical targets (iSCSI Names) to the initiators, and maps them to SCSI targets however it likes. the initiator sees the gateway as a real iSCSI target and is totally unaware of any proxy or gateway behaviour 🙈 the gateway can manufacture its own iSCSI Names, or map the iSCSI names using info from the physical SCSI devices. it's the gateway's responsibility to make sure the uniqueness of any iSCSI name it manufactures is kept. the gateway may also have to account for multiple gateways having access to a single physical device. this type of gateway is used to present parallel SCSI, Fibre Channel, SSA, or other devices as iSCSI devices 💜

Effects on iSCSI:

  • Since the initiator is unaware of any addresses beyond the gateway, the gateway's own address is for all practical purposes the real address of a target. Only the iSCSI Name needs to be passed. This is already done in iSCSI, so there are no further requirements to support SCSI gateways. ✨

B.4. iSCSI Proxy 🦋

an iSCSI proxy is a gateway that terminates the iSCSI protocol on both sides, rather than translating between iSCSI and some other transport. the proxy knows both sides are iSCSI, so it can take advantage of optimizations, like preserving data integrity checks 🔥

here's the lowkey genius part: since an iSCSI initiator's discovery or configuration of a set of targets uses address-independent iSCSI names, iSCSI doesn't have the same proxy addressing problems as HTTP, which puts address info right into its URLs 🙌 if a proxy is providing services to an initiator on behalf of a target, the proxy lets the initiator discover its address for the target, and the actual target device is discovered only by the proxy. neither the initiator nor the iSCSI protocol needs to be aware the proxy exists 🫶 also, a SCSI gateway may provide iSCSI proxy functionality when mapping targets between two iSCSI interfaces 🌈

Effects on iSCSI:

  • Same as a SCSI gateway. The only other effect is that iSCSI must separate data integrity checking on iSCSI headers and iSCSI data, to allow the data integrity check on the data to be propagated end-to-end through the proxy. 🌸

B.5. Stateful Inspection Firewall (stealth iSCSI firewall) 🫣

the stealth model would exist as an iSCSI-aware firewall that is invisible to the initiator, but still provides the capabilities found in the iSCSI proxy. it's ghost mode 👻

Effects on iSCSI:

  • Since this is invisible, there are no additional requirements on the iSCSI protocol for this one. ✨

this one is more difficult in some ways to implement, simply because it has to be part of a standard firewall product, rather than part of an iSCSI-type product 🔧

also, note that this type of firewall is only effective in the outbound direction (allowing an initiator behind the firewall to connect to an outside target), unless the iSCSI target is located in a DMZ (De-Militarized Zone) [RFC3303]. it does not provide adequate security otherwise. 🚨

Appendix C: iSCSI Names and Security Identifiers 🔐

this document has described the creation and use of iSCSI Node Names. there will be trusted environments where that's a sufficient form of identification. in these environments, the iSCSI Target may have an Access Control List (ACL), which contains a list of authorized entities that are permitted to access a restricted resource (in this case a Target Storage Controller). the iSCSI Target then uses that ACL to permit (or not) certain iSCSI Initiators to access the storage at the iSCSI Target Node. this form of ACL is used to prevent trusted initiators from making a mistake and connecting to the wrong storage controller 🙈

it's also possible that the ACL and the iSCSI Initiator Node Name can be used in conjunction with the SCSI layer for the appropriate SCSI association of LUNs with the Initiator. the SCSI layer's use of the ACL won't be discussed further in this document 💅

there will be situations where the iSCSI Nodes exist in untrusted environments. that is, some iSCSI Initiator Nodes may be authorized to access an iSCSI Target Node, however, because of the untrusted environment, nodes on the network cannot be trusted to give the correct iSCSI Initiator Node Names 😭

in untrusted environments, an additional type of identification is required to assure the target that it really knows the identity of the requesting entity 🔒

the authentication and authorization in the iSCSI layer is independent of anything that IPSec might handle, underneath or around the TCP layer. this means that the initiator node needs to pass some type of security related identification information (e.g., userid) to a security authentication process such as SRP, CHAP, Kerberos etc. (These authentication processes will not be discussed in this document.) 🫶

upon completion of the iSCSI security authentication, the installation knows "who" sent the request for access. the installation must then check to ensure that such a request, from the identified entity, is permitted/authorized. this form of Authorization is generally accomplished via an Access Control List (ACL) as described above. using this authorization process, the iSCSI target will know that the entity is authorized to access the iSCSI Target Node 👑

it may be possible for an installation to set a rule that the security identification information (e.g., UserID) be equal to the iSCSI Initiator Node Name. in that case, the ACL approach described above should be all the authorization that is needed 🍓

if, however, the iSCSI Initiator Node Name is not used as the security identifier, there's a need for more elaborate ACL functionality. this means the target requires a mechanism to map the security identifier (e.g., UserID) information to the iSCSI Initiator Node Name. that is, the target must be sure that the entity requesting access is authorized to use the name, which was specified with the Login Keyword InitiatorName=. for example, if security identifier 'Frank' is authorized to access the target via iSCSI InitiatorName=xxxx, but 'Frank' tries to access the target via iSCSI InitiatorName=yyyy, then this login should be rejected 🚫

on the other hand, it is possible that 'Frank' is a roaming user (or a Storage Administrator) that "owns" several different systems, and thus, could be authorized to access the target via multiple different iSCSI initiators. in this case, the ACL needs to have the names of all the initiators through which 'Frank' can access the target. 🧳

there may be other, more elaborate ACL approaches, which can also be deployed to provide the installation/user with even more security with flexibility ✨

the above discussion is trying to inform the reader that not only is there a need for access control dealing with iSCSI Initiator Node Names, but in certain iSCSI environments there might also be a need for other complementary security identifiers 🌈

Authors' Addresses 💌

Kaladhar Voruganti
IBM Almaden Research Center
650 Harry Road
San Jose, CA 95120

EMail: kaladhar@us.ibm.com
Mark Bakke
Cisco Systems, Inc.
6450 Wedgwood Road
Maple Grove, MN 55311

Phone: +1 763 398-1054
EMail: mbakke@cisco.com
Jim Hafner
IBM Almaden Research Center
650 Harry Road
San Jose, CA 95120

Phone: +1 408 927-1892
EMail: hafner@almaden.ibm.com
John L. Hufferd
IBM Storage Systems Group
5600 Cottle Road
San Jose, CA 95193

Phone: +1 408 256-0403
EMail: hufferd@us.ibm.com
Marjorie Krueger
Hewlett-Packard Corporation
8000 Foothills Blvd
Roseville, CA 95747-5668, USA

Phone: +1 916 785-2656
EMail: marjorie_krueger@hp.com

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ✨

okay bestie, so the IETF is basically like "we're not picking sides 🙅‍♀️" when it comes to who owns what. 💅 They take no position on whether any Intellectual Property Rights or other rights that someone might claim over the tech in this doc are valid or in scope, and they don't say whether any license for those rights is or isn't available. They also didn't go hunting for those rights themselves 🙈 ngl. If you want the full lowdown on how rights work for RFCs, check out BCP 78 and BCP 79 💖

Copies of IPR disclosures made to the IETF Secretariat are a whole thing too 🦋 Any assurances of licenses that are gonna be made available can be found there, and so can the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights. It all lives in the IETF online IPR repository at http://www.ietf.org/ipr, so go check it out 👑

The IETF also invites any interested party to bring anything to its attention, like copyrights, patents or patent applications, or other proprietary rights that might cover tech you need to implement this standard. Just send it to ietf-ipr@ietf.org 🫶 the people have spoken, and the IETF is listening 🌈

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society. 💜 Shoutout to them for keeping the lights on, periodt ✨

📦 where this page comes from