Network Working Group M. Bakke Request for Comments: 4018 Cisco Category: Standards Track J. Hufferd K. Voruganti IBM M. Krueger HP T. Sperry Adaptec April 2005 Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractThe iSCSI protocol provides a way for hosts to access SCSI devices over an IP network. This document defines the use of the Service Location Protocol (SLP) by iSCSI hosts, devices, and management services, along with the SLP service type templates that describe the services they provide. 1. Introduction................................................ 2 2. Notation Conventions........................................ 2 3. Terminology................................................. 3 4. Using SLP for iSCSI Service Discovery....................... 4 5. iSCSI SLP Templates......................................... 11 6. Security Considerations..................................... 18 7. IANA Considerations......................................... 19 8. Summary..................................................... 19 9. Normative References........................................ 19 10. Informative References...................................... 20 11. Acknowledgements............................................ 21
RFC3720] is a protocol used to transport SCSI [SAM2] commands, data, and status across an IP network. This protocol is connection- oriented and is currently defined over TCP. iSCSI uses a client- server relationship. The client end of the connection is an initiator, and it sends SCSI commands; the server end of the connection is called a target, and it receives and executes the commands. There are several methods an iSCSI initiator can use to find the targets to which it should connect. Two of these methods can be accomplished without the use of SLP: - Each target and its address can be statically configured on the initiator. - Each address providing targets can be configured on the initiator; iSCSI provides a mechanism by which the initiator can query the address for a list of targets. The above methods are further defined in "iSCSI Naming and Discovery Requirements" [RFC3721]. Each of the above methods requires a small amount of configuration to be done on each initiator. The ability to discover targets and name services without having to configure initiators is a desirable feature. The Service Location Protocol (SLP) [RFC2608] is an IETF standards track protocol providing several features that will simplify locating iSCSI services. This document describes how SLP can be used in iSCSI environments to discover targets, addresses providing targets, and storage management servers. RFC2119].
RFC2608] and "Finding an RSIP Server with SLP" [RFC3105]. User Agent (UA) A process working on the client's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents. Service Agent (SA) A process working on behalf of one or more services to advertise the services and their capabilities. Directory Agent (DA) A process that collects service advertisements. There can only be one DA present per given host. Scope A named set of services, typically making up a logical administrative group. Service Advertisement A URL, attributes, and a lifetime (indicating how long the advertisement is valid) providing service access information and capabilities description for a particular service. Initiator A logical entity, typically within a host, that sends SCSI commands to targets to be executed. An initiator is usually present in the form of a device driver. Target A logical entity, typically within a storage controller or gateway that receives SCSI commands from an initiator and executes them. A target includes one or more Logical Units (LUs); each LU is a SCSI device, such as a disk or tape drive. iSCSI Name A UTF-8 character string that serves as a unique identifier for iSCSI initiators and targets. Its format and usage is further defined in [RFC3721]. iSCSI Client A logical entity, typically a host that includes at least one iSCSI Initiator.
iSCSI Server A logical entity, typically a storage controller or gateway that includes at least one iSCSI Target. Storage Management Server An addressable entity that provides management services that benefit an iSCSI environment. "Storage management server" is used as a generic term and does not indicate a specific protocol or service.
+---------------------------------+ | iSCSI Client | | +-----------+ | | | iSCSI | | | | initiator | | | | "myhost" | | | +-----------+ | | | +--------------------------+------+ | iSCSI Driver | UA | +--------------------------+------+ | TCP/UDP/IP | +----------------+----------------+ | Interface 1 | Interface 2 | +----------------+----------------+ | | +------------+ | | +------------+ | SLP DA | | | | SLP DA | | (optional) |----+ IP Networks +----| (optional) | +------------+ | | +------------+ | | +-----------------+-----------------| | Interface 1 | Interface 2 | | 192.0.2.131 | 192.0.2.3 | +-----------------+-----------------+ | TCP/UDP/IP | +---------------------------+-------+ | iSCSI Driver | SA | +---------------------------+-------| | | | +--------+ +--------+ +---------+ | | | iSCSI | | iSCSI | | iSCSI | | | | target | | target | | target | | | | "one" | | "two" | | "three" | | | +--------+ +--------+ +---------+ | | iSCSI Server | +-----------------------------------+ In the above drawing, the iSCSI server has three iSCSI targets that the client could discover, named "one", "two" and "three". The iSCSI client has an iSCSI initiator with the name "myhost". The iSCSI client may use the initiator name in its SLP Service Requests as a filter to discover only targets that are configured to accept iSCSI connections from "myhost". Each iSCSI target and initiator has a unique name, called an iSCSI Name. This identifier is the same regardless of the network path (through adapter cards, networks, and interfaces on the storage
device) over which the target is discovered and accessed. For this example, the iSCSI names "one", "two", and "three" are used for the targets; the initiator uses the name "myhost". An actual iSCSI name would incorporate more structure, including a naming authority, and is not described here. Each of the iSCSI targets in the drawing can appear at two addresses, since two network interfaces are present. Each target would have two service URLs, unless a single service URL included a DNS host name mapping to both addresses. An iSCSI target URL consists of its fully qualified host name or IP address, the TCP port on which it is listening, and its iSCSI name. An iSCSI server must register each of its individual targets at each of its network addresses. The iSCSI server constructs a service advertisement of the type "service:iscsi:target" for each of the service URLs it wishes to register. The advertisement contains a lifetime, along with other attributes that are defined in the service template. If the server in the above drawing is listening at TCP port 3260 for both network addresses, the service URLs registered would be - 192.0.2.131:3260/one - 192.0.2.131:3260/two - 192.0.2.131:3260/three - 192.0.2.3:3260/one - 192.0.2.3:3260/two - 192.0.2.3:3260/three The remainder of the discovery procedure is identical to that used by any client/server pair implementing SLP: 1. If an SLP DA is found, the SA contacts the DA and registers the service advertisement. Whether or not one or more SLPv2 DAs are discovered, the SA maintains the advertisement itself and answers multicast UA queries directly. 2. When the iSCSI initiator requires contact information for an iSCSI target, the UA either contacts the DA by using unicast or the SA by using multicast. If a UA is configured with the address of the SA, it may avoid multicast and may contact an SA
by using unicast. The UA includes a query based on the attributes to indicate the characteristics of the target(s) it requires. 3. Once the UA has the host name or address of the iSCSI server, as well as the port number and iSCSI Target Name, it can begin the normal iSCSI login to the target. As information contained in the iSCSI target template may exceed common network datagram sizes, the SLP implementation for both UAs and SAs supporting this template MUST implement SLP over TCP.
3. auth-cred: This attribute contains a list of "method/identifier" credentials that will be allowed access to the target, provided they can produce the correct password or other verifier during the login process. If no specific credentials are required, the value "any" is used. The list of valid method strings for auth-cred are defined in [RFC3720], section 11.1, "AuthMethod". The identifier used after the "/" is defined by the specific AuthMethod, also in [RFC3720]. Examples showing initiator searches based on auth-xxxx attributes are shown in the target-specific template section below. Also note that the auth-xxxx attributes are considered security policy information. If these attributes are distributed, IPsec MUST be implemented as specified in the Security Implementation section below.
+---------------------------+ | iSCSI Client | | | | +-----------+ | | | iSCSI | | | | initiator | | | +-----------+ | | | +---------------+------+----+ +------------+ | iSCSI Driver | smsp | UA | | SLP DA | +---------------+------+----+ | | | TCP/UDP/IP | | (optional) | +---------------+------+----+ +------------+ | | | IP Network | ------------------------------------------ | | | | +---------------+-----------+ +---------------------+ | TCP/UDP/IP | | TCP/UDP/IP | +---------------+------+----+ +---------------------+ | iSCSI Driver | smsp | UA | | SA | smsp | +---------------+------+----+ +---------------------+ | | | | | +--------+ +--------+ | | storage mgmt server | | | iSCSI | | iSCSI | | | | | | target | | target | | +---------------------+ | | 1 | | 2 | | | +--------+ +--------+ | | | | iSCSI Server | +---------------------------+ Note the difference between the storage management server model and the previously defined target discovery model. When target discovery was used, the iSCSI Server implemented an SA, to be discovered by the initiator's UA. In the storage management server model, the iSCSI clients and servers both implement UAs, and the management server implements the SA. A storage management server's URL contains the domain name or IP address and TCP or UDP port number. No other information is required. The storage management server constructs a service advertisement of the type "service:iscsi:sms" for each of the addresses at which it appears. The advertisement contains the URL and a lifetime, along with other attributes that are defined in the service template.
The remainder of the discovery procedure is identical to that used to discover iSCSI targets, except that both initiators and targets would normally be "clients" of the storage management service. Targets that support a storage management service implement a UA in addition to the SA. A target may alternatively just implement the UA and allow the storage management service to advertise its targets appropriately by providing an SA and registering the appropriate service:iscsi:target registrations on the target's behalf: The target device would not have to advertise its own targets. This has no impact on the initiator. This allows the initiators' discovery of targets to be completely interoperable regardless of which storage management service is used, or whether one is used at all, or whether the target registrations are provided directly by the target or by the management service. RFC3722] and [RFC3491]. section 6. Template Text: -------------------------template begins here----------------------- template-type=iscsi template-version=1.0 template-description=
This is an abstract service type. The purpose of the iscsi service type is to encompass all of the services used to support the iSCSI protocol. template-url-syntax= url-path= ; Depends on the concrete service type. --------------------------template ends here------------------------
5. Find all of the iSCSI Target Names that may allow access to a given CHAP user name: Service: service:iscsi:target Scope: initiator-scope-list Query: (auth-cred=chap/my-user-name) 6. Find all of the iSCSI Target Names that may allow access to a given initiator that supports two IP addresses, a CHAP credential and SRP credential, and an initiator name: Service: service:iscsi:target Scope: initiator-scope-list Query: &(|(auth-name=iqn.com.example:host47)(auth-name=any) |(auth-addr=192.0.2.3)(auth-addr=192.0.2.131)(auth-addr=any) |(auth-cred=chap/foo)(auth-cred=srp/my-user-name) (auth-cred=any)) 7. Find the iSCSI Target Names from which the given initiator is allowed to boot: Service: service:iscsi:target Scope: initiator-scope-list Query: (boot-list=iqn.1998-03.com.example:hostid.045A7B) 8. In addition, a management service may wish to discover all targets: Service: service:iscsi:target Scope: management-server-scope-list Query: <empty-string> More details on booting from an iSCSI target are defined in [BOOT]. Name of submitter: Mark Bakke Language of service template: en Security Considerations: see section 6. Template Text: -------------------------template begins here----------------------- template-type=iscsi:target template-version=1.0 template-description= This is a concrete service type. The iscsi:target service type is used to register individual target addresses to be discovered by others. UAs will generally search for these by including one of
the following: - the iSCSI target name - iSCSI initiator identifiers (iSCSI name, credential, IP address) - the service URL template-url-syntax= url-path = hostport "/" iscsi-name [ "/" identity ] hostport = host [ ":" port ] host = hostname / hostnumber ; DNS name or IP address hostname = *( domainlabel "." ) toplabel alphanum = ALPHA / DIGIT domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum hostnumber = ipv4-number / ipv6-addr ; IPv4 or IPv6 address ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) ipv6-addr = "[" ipv6-number "]" ipv6-number = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::" ls32 = ( h16 ":" h16 ) / ipv4-number ; least-significant 32 bits of ipv6 address h16 = 1*4HEXDIG port = 1*DIGIT iscsi-name = iscsi-char ; iSCSI target name identity = iscsi-char ; optional identity string iscsi-char = ALPHA / DIGIT / escaped / ":" / "-" / "." ; Intended to allow UTF-8 encoded strings escaped = 1*("\" HEXDIG HEXDIG) ; ; The iscsi-name part of the URL is required and must be the iSCSI ; name of the target being registered. ; A device representing multiple targets must individually ; register each target/address combination with SLP. ; The identity part of the URL is optional, and is used to ; indicate an identity that is allowed to access this target. ; ; Example (split into two lines for clarity): ; service:iscsi:target://192.0.2.3:3260/ ; iqn.2001-04.com.example:sn.45678 ; ; IPv6 addresses are also supported; they use the notation
; specified above and in [RFC3513], section 2.2 iscsi-name = string # The iSCSI Name of this target. # This must match the iscsi-name in the url-path. portal-group = integer # The iSCSI portal group tag for this address. Addresses sharing # the same iscsi-name and portal-group tag can be used within the # same iSCSI session. Portal groups are described in [RFC3720]. transports = string M L tcp # This is a list of transport protocols that the registered # entity supports. iSCSI is currently supported over TCP, # but it is anticipated that it could be supported over other # transports, such as SCTP, in the future. tcp mgmt-entity = string O # The fully qualified domain name, or IP address in dotted-decimal # notation, of the management interface of the entity containing # this target. # alias = string O # The alias string contains a descriptive name of the target. auth-name = string M X # A list of iSCSI Initiator Names that can access this target. # Normal iSCSI names will be 80 characters or less; max length # is 255. # Normally, only one or a few values will be in the list. # Using the equivalence search on this will evaluate to "true" # if any one of the items in this list matches the query. # If this list contains the default name "any", any initiator # is allowed to access this target, provided it matches # the other auth-xxx attributes. # # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be implemented. auth-addr = string M X # A list of initiator IP addresses (or host names) which will # be allowed access to this target. If this list contains the # default name "any", any IP address is allowed access to this # target, provided it matches the other auth-xxx attributes.
# # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be implemented. auth-cred = string M X # A list of credentials which will be allowed access to the target # (provided they can provide the correct password or other # authenticator). Entries in this list are of the form # "method/identifier", where the currently defined methods are # "chap" and "srp", both of which take usernames as their # identifiers. # # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be implemented. boot-list = string M O # A list of iSCSI Initiator Names that can boot from this target. # This list works precisely like the auth-name attribute. A name # appearing in this list must either appear in the access-list, # or the access-list must contain the initiator name "iscsi". # Otherwise, an initiator will be unable to find its boot # target. If boot-list contains the name "iscsi", any host can boot # from it, but I am not sure if this is useful to anyone. If this # attribute is not registered, this target is not "bootable". # # Note that the LUN the host boots from is not specified here; a # host will generally attempt to boot from LUN 0. # # It is quite possible that other attributes will need to be defined # here for booting as well. # # This attribute contains security policy information. If this # attribute is distributed via an Attribute Reply message, # IPsec MUST be implemented. --------------------------template ends here------------------------
Service: service:iscsi:sms Scope: initiator-scope-list Query: (protocols=isns) Name of submitter: Mark Bakke Language of service template: en Security Considerations: see section 6. Template Text: -------------------------template begins here----------------------- template-type=iscsi:sms template-version=1.0 template-description= This is a concrete service type. The iscsi:sms service type provides the capability for entities supporting iSCSI to discover appropriate management services. template-url-syntax= url-path = ; The URL of the management service [RFC2608]. protocols = string M # The list of protocols supported by this name service. This # list may be expanded in the future. There is no default. # # "isns" - This management service supports the use of the iSNS # protocol for access management, health monitoring, and # discovery management services. This protocol is defined # in [ISNS]. isns transports = string M L tcp # This is a list of transport protocols that the registered # entity supports. tcp, udp server-priority = integer # The priority a client should give this server, when choosing # between multiple servers with the same protocol type. # When multiple servers are discovered for a given protocol type, # this parameter indicates their relative precedence. Server # precedence is protocol-specific; for some protocols, the primary # server may have the highest server-priority value, while for
# others it may have the lowest. For example, with iSNS, the primary # server has the lowest value (value 0). --------------------------template ends here------------------------ RFC2608] does not provide confidentiality but does provide an authentication mechanism for UAs to ensure that service advertisements only come from trusted SAs, with the exception that it does not provide a mechanism to authenticate "zero-result responses". See [RFC3723] for a discussion of the SLPv2 [RFC2608] security model. Once a target or management server is discovered, authentication and authorization are handled by the iSCSI protocol, or by the management server's protocol. It is the responsibility of the providers of these services to ensure that an inappropriately advertised or discovered service does not compromise their security. When no security is used for SLPv2, there is a risk of distribution of false discovery information. The primary countermeasure for this risk is authentication. When this risk is a significant concern, IPsec SAs and iSCSI in-band authentication SHOULD be used for iSCSI traffic subject to this risk to ensure that iSCSI traffic only flows between endpoints that have participated in IKE authentication and iSCSI in-band authentication. For example, if an attacker distributes discovery information falsely claiming that it is an iSCSI target, it will lack the secret information necessary to complete IKE authentication or iSCSI in-band authentication successfully and therefore will be prevented from falsely sending or receiving iSCSI traffic. A risk remains of a denial of service attack based on repeated use of false discovery information that will cause initiation of IKE negotiation. The countermeasures for this are administrative configuration of each iSCSI Target to limit the peers it is willing to communicate with (i.e., by IP address range and/or DNS domain), and maintenance of a negative authentication cache to avoid repeatedly contacting an iSCSI Target that fails to authenticate. These three measures (i.e., IP address range limits, DNS domain limits, negative authentication cache) MUST be implemented. The auth-name, auth-addr, auth-cred, and boot-list attributes comprise security policy information. When these are distributed, IPsec MUST be implemented.
RFC3723]. IPsec is mandatory-to-implement for IPS clients and servers. Thus, all IP storage clients, including those invoking SLP, can be assumed to support IPsec. SLP servers, however, cannot be assumed to implement IPsec, since there is no such requirement in standard SLP. In particular, SLP Directory Agents (DA) may be running on machines other than those running the IPS protocols. IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this includes ESP with a non-null transform to provide both authentication and confidentiality. When SLPv2 can be used to distribute auth-name, auth-addr, auth-cred, and boot-list information (see section 5.2 above), IPsec MUST be implemented, as these items are considered sensitive security policy information. If IPsec is not implemented, auth-name, auth-addr, auth-cred, and boot-list information MUST NOT be distributed via SLPv2 and MUST NOT be used if discovered via SLPv2. Because the IP storage services have their own authentication capabilities when located, SLPv2 authentication is OPTIONAL to implement and use (as discussed in more detail in [RFC3723]). RFC2609]. [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. [RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004. [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004. [RFC2614] Kempf, J. and E. Guttman, "An API for Service Location", RFC 2614, June 1999. [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004. [ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and J. Souza, "Internet Storage Name Service", Work in Progress, February 2004. [BOOT] Sarkar, P., Missimer, D. and C. Sapuntzakis, "A Standard for Bootstrapping Clients using the iSCSI Protocol", Work in Progress, March 2004. [RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with SLP", RFC 3105, October 2001.
Full Copyright Statement Copyright (C) The Internet Society (2005). 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.