Network Working Group M. Bakke Request for Comments: 3721 Cisco Category: Informational J. Hafner J. Hufferd K. Voruganti IBM M. Krueger Hewlett-Packard April 2004 Internet Small Computer Systems Interface (iSCSI) Naming and Discovery Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved.
AbstractThis document provides examples of the Internet Small Computer Systems Interface (iSCSI; or SCSI over TCP) name construction and discussion of discovery of iSCSI resources (targets) by iSCSI initiators. This document complements the iSCSI protocol document. Flexibility is the key guiding principle behind this document. That is, an effort has been made to satisfy the needs of both small isolated environments, as well as large environments requiring secure/scalable solutions.
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
RFC3720]. This document provides examples of name construction that might be used by a naming authority. Both targets and initiators require names for the purpose of identification, so that iSCSI storage resources can be managed regardless of location (address). An iSCSI name is the unique identifier for an iSCSI node, and is also the SCSI device name [SAM2] of an iSCSI device. The iSCSI name is the principal object used in authentication of targets to initiators and initiators to targets. This name is also used to identify and manage iSCSI storage resources. Furthermore, iSCSI names are associated with iSCSI nodes instead of with network adapter cards to ensure the free movement of network HBAs between hosts without loss of SCSI state information (reservations, mode page settings etc) and authorization configuration. An iSCSI node also has one or more addresses. An iSCSI address specifies a single path to an iSCSI node and consists of the iSCSI name, plus a transport (TCP) address which uses the following format: <domain-name>[:<port>] Where <domain-name> is one of: - IPv4 address, in dotted decimal notation. Assumed if the name contains exactly four numbers, separated by dots (.), where each number is in the range 0..255. - IPv6 address, in colon-separated hexadecimal notation, as specified in [RFC3513] and enclosed in "[" and "]" characters, as specified in [RFC2732]. - Fully Qualified Domain Name (host name). Assumed if the <domain- name> is neither an IPv4 nor an IPv6 address. For iSCSI targets, the <port> in the address is optional; if specified, it is the TCP port on which the target is listening for connections. If the <port> is not specified, the default port 3260, assigned by IANA, will be assumed. For iSCSI initiators, the <port> is omitted.
Examples of addresses: 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 The concepts of names and addresses have been carefully separated in iSCSI: - An iSCSI Name is a location-independent, permanent identifier for an iSCSI node. An iSCSI node has one iSCSI name, which stays constant for the life of the node. The terms "initiator name" and "target name" also refer to an iSCSI name. - An iSCSI Address specifies not only the iSCSI name of an iSCSI node, but also a location of that node. The address consists of a host name or IP address, a TCP port number (for the target), and the iSCSI Name of the node. An iSCSI node can have any number of addresses, which can change at any time, particularly if they are assigned via DHCP. A similar analogy exists for people. A person in the USA might be: 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 In this case, Robert's globally unique name is really his Social Security Number plus Date of Birth. His common name, "Robert Smith", is not guaranteed to be unique. Robert has three locations at which he may be reached; two Physical addresses, and a phone number. In this example, Robert's SSN+DOB is like the iSCSI Name (date of birth is required to disambiguate SSNs that have been reused), his phone number and addresses are analogous to an iSCSI node's TCP addresses, and "Robert Smith" would be a human-friendly label for this person.
To assist in providing a more human-readable user interface for devices that contain iSCSI targets and initiators, a target or initiator may also provide an alias. This alias is a simple UTF-8 string, is not globally unique, and is never interpreted or used to identify an initiator or device within the iSCSI protocol. Its use is described further in section 2. RFC3720] and contains (in order): - The string "iqn." - A date code specifying 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 consists of a valid, reversed domain or subdomain name. - Optionally, a ':', followed by a string of the assigning organization's choosing, which must make each assigned iSCSI name unique. The following is an example of an iSCSI qualified name from an equipment vendor: 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" specifies the use of the iSCSI qualified name as the authority.
"2001-04" is the year and month on which the naming authority acquired the domain name used in this iSCSI name. This is used to ensure that when domain names are sold or transferred to another organization, iSCSI names generated by these organizations will be unique. "com.example" is a reversed DNS name, and defines the organizational naming authority. The owner of the DNS name "example.com" has the sole right of use of this name as this part of an iSCSI name, as well as the responsibility to keep the remainder of the iSCSI name unique. In this case, example.com happens to manufacture disk arrays. "diskarrays" was picked arbitrarily by example.com to identify the disk arrays they manufacture. Another product that ACME makes might use a different name, and have its own namespace independent of the disk array group. The owner of "example.com" is responsible for keeping this structure unique. "sn" was picked by the disk array group of ACME to show that what follows is a serial number. They could have just assumed that all iSCSI Names are based on serial numbers, but they thought that perhaps later products might be better identified by something else. Adding "sn" was a future-proof measure. "a8675309" is the serial number of the disk array, uniquely identifying it from all other arrays. Another example shows how the ':' separator helps owners of sub- domains to keep their name spaces 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, except for the ':' separator, both names are identical. The first was assigned by the owner of the subdomain "storage.example.com"; the second was assigned by the owner of "tape.storage.example.com". These are both legal names, and are unique. The following is an example of a name that might be constructed by a research organization: Naming Defined by Defined by Type Date Authority cs dept User "oaks" +-+ +-----+ +------------+ +--------+ +-----------+ | | | | | | | | | | iqn.2000-02.edu.example.cs:users.oaks:proto.target4 In the above example, Professor Oaks of Example University is building research prototypes of iSCSI targets. EU's computer science department allows each user to use his or her user name as a naming authority for this type of work, by attaching "users.<username>" after the ':', and another ':', followed by a string of the user's choosing (the user is responsible for making this part unique). Professor Oaks chose to use "proto.target4" for this particular target. The following is an example of an iSCSI 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) has decided to re-name the targets from the manufacturer, to provide the flexibility to move the customer's data to a different storage subsystem should the need arise. The Storage Service Provider (SSP) has configured the iSCSI Name on this particular target for one of its customers, and has determined that it made the most sense to track these targets by their Customer ID number and a disk number. This target was created for use by customer #4567, and is the 107th target configured for this customer. Note that when reversing these domain names, the first component (after the "iqn.") will always be a top-level domain name, which includes "com", "edu", "gov", "org", "net", "mil", or one of the
two-letter country codes. The use of anything else as the first component of these names is not allowed. In particular, companies generating these names must not eliminate their "com." from the string. Again, these iSCSI names are NOT addresses. Even though they make use of DNS domain names, they are used only to specify the naming authority. An iSCSI name contains no implications of the iSCSI target or initiator's location. The use of the domain name is only a method of re-using an already ubiquitous name space. EUI64]). Example iSCSI name: Type EUI-64 identifier (ASCII-encoded hexadecimal) +--++--------------+ | || | eui.02004567A425678D RFC3720]. No other structure is imposed upon this string.
of the connection. For instance, a target name for a disk array may be built from the array's serial number, and some sort of internal target ID. Although this would still be human-readable and transcribable, it offers little assurance to someone at a user interface who would like to see "at-a-glance" whether this target is really the correct one. The use of an alias helps solve that problem. An alias is simply a descriptive name that can be assigned to an initiator or target, that is independent of the name, and does not have to be unique. Since it is not 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 may have aliases.
In the above example, the user sees a collection of iSCSI Names, but with no real description of what they are for. They will, of course, map to a system-dependent device file or drive letter, but it's not easy looking at numbers quickly to see if everything is there. If a storage administrator configures an alias for each target name, the alias can provide a more descriptive name. This alias may be sent back to the initiator as part of the login response, or found in the iSCSI MIB. It then might be used in a display such as the following: +--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 | +-------------------------------------------------- This would give the user a better idea of what's really there. In general, flexible, configured aliases will probably be supported by larger storage subsystems and configurable gateways. Simpler devices will likely not keep configuration data around for things such as an alias. The TargetAlias string could be either left unsupported (not given to the initiator during login) or could be returned as whatever the "next best thing" that the target has that might better describe it. Since it does not have to be unique, it could even return SCSI inquiry string data. Note that if a simple initiator does not wish to keep or display alias information, it can be simply ignored if seen in the login response.
Usually just the hostname would be sufficient for an initiator alias, but a custom alias could be configured for the sake of the service provider if needed. Even better would be a description of what the machine was used for, such as "Exchange Server 1", or "User Web Server". Here's an example of a management interface showing a list of sessions on an iSCSI target network entity. For this display, the targets are using an internal target number, which is a fictional field that has purely internal significance. +--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 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... | +-------------------------------------------------- This gives the storage administrator a better idea of who is connected to their targets. Of course, one could always do a reverse DNS lookup of the incoming IP address to determine a host name, but simpler devices really don't do well with that particular feature due to blocking problems, and it won't always work if there is a firewall or iSCSI gateway involved. Again, these are purely informational and optional and require a management application. Aliases are extremely 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 is received that does not fit, or seems invalid in any way, it is ignored.
RFC3720]. This discovery option is convenient for iSCSI gateways and routers. c. Zero-Configuration: This mechanism assumes that the initiator does not have any information about the target. In this option, the initiator can either multicast discovery messages directly to the
targets or it can send discovery messages to storage name servers. Currently, there are many general purpose discovery frameworks available such as Salutation [John], Jini [John], UPnP [John], SLP [RFC2608] and iSNS [iSNS]. However, with respect to iSCSI, SLP can clearly perform the needed discovery functions [iSCSI-SLP], while iSNS [iSNS] can be used to provide related management functions including notification, access management, configuration, and discovery management. iSCSI equipment that need discovery functions beyond SendTargets should at least implement SLP, and then consider iSNS when extended discovery management capabilities are required such as in larger storage networks. It should be noted that since iSNS will support SLP, iSNS can be used to help manage the discovery information returned by SLP. RFC3720] and the iSCSI security document [RFC3723]. In addition, Appendix B discusses naming and discovery issues when gateways, proxies, and firewalls are used to solve security or discovery issues in some situations where iSCSI is deployed. iSCSI allows several different authentication methods to be used. For many of these methods, an authentication identifier is used, which may be different from the iSCSI node name of the entity being authenticated. This is discussed in more detail in Appendix C. [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.
[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.
RFC2979] and proxies will be deployed for iSCSI, similar in nature to those already handling protocols such as HTTP and FTP.
- 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.
ensure the uniqueness of any iSCSI name it manufactures. The gateway may 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.
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.
Upon the 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 is a need for more elaborate ACL functionality. This means that 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.
Full Copyright Statement 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 The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.