+---------------+------+----+ +------------+
| |
| 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.
4.3. Internationalization Considerations
SLP allows internationalized strings to be registered and retrieved.
Attributes in the template that are not marked with an ’L’ (literal)
will be registered in a localized manner. An "en" (English)
localization MUST be registered, and others MAY be registered.
Attributes that include non-ASCII characters will be encoded by using
UTF-8, as discussed in [RFC3722] and [RFC3491].
5. iSCSI SLP Templates
Three templates are provided: an iSCSI target template, a management
service template, and an abstract template to encapsulate the two.
5.1. The iSCSI Abstract Service Type Template
This template defines the abstract service "service:iscsi". It is
used as a top-level service to encapsulate all other iSCSI-related
services.
Name of submitter: Mark Bakke
Language of service template: en
Security Considerations: See 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.2. The iSCSI Target Concrete Service Type Template
This template defines the service "service:iscsi:target". An entity
containing iSCSI targets that wishes them discovered via SLP would
register each of them, with each of their addresses, as this service
type.
Initiators (and perhaps management services) wishing to discover
targets in this way will generally use one of the following queries:
1. Find a specific target, given its iSCSI Target Name:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (iscsi-name=iqn.2001-04.com.example:sn.456)
2. Find all of the iSCSI Target Names that may allow access to a
given initiator:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (auth-name=iqn.1998-03.com.example:hostid.045A7B)
3. Find all of the iSCSI Target Names that may allow access to
any initiator:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: (auth-name=any)
4. Find all of the iSCSI Target Names that may allow access to
this initiator, or that will allow access to any initiator:
Service: service:iscsi:target
Scope: initiator-scope-list
Query: &(auth-name=iqn.1998-03.com.example:hostid.045A7B)
(auth-name=any)
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------------------------
5.3. iSCSI Storage Management Service Templates
This template defines the service "service:iscsi:sms". An entity
supporting one or more iSCSI management service protocols may
register itself with SLP as this service type. iSCSI clients and
servers wishing to discover storage management services using SLP
will usually search for them by the protocol(s) they support:
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------------------------
6. Security Considerations
The SLPv2 security model as specified in [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.
6.1. Security Implementation
Security for SLPv2 in an IP storage environment is specified in
[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]).
7. IANA Considerations
This document describes three SLP Templates. They have been reviewed
and approved by the IESG and registered in the IANA’s "SVRLOC
Templates" registry. This process is described in the IANA
Considerations section of [RFC2609].
8. Summary
This document describes how SLP can be used by iSCSI initiators to
find iSCSI targets and storage management servers. Service type
templates for iSCSI targets and storage management servers are
presented.
9. Normative References
[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.
10. Informative References
[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.
11. Acknowledgements
This document was produced by the iSCSI Naming and Discovery team,
including Joe Czap, Jim Hafner, John Hufferd, and Kaladhar Voruganti
(IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (Sanrad),
Marjorie Krueger (HP), Lawrence Lamers (San Valley), Todd Sperry
(Adaptec), and Joshua Tseng (Nishan). Thanks also to Julian Satran
(IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt
Peterson (Caldera) and James Kempf (Sun) for reviewing the document
from an SLP perspective.
Authors’ Addresses
Mark Bakke
Cisco Systems, Inc.
7900 International Drive, Suite 400
Bloomington, MN
USA 55425
EMail: mbakke@cisco.com
Kaladhar Voruganti
IBM Almaden Research Center
650 Harry Road
San Jose, CA 95120
EMail: kaladhar@us.ibm.com
John L. Hufferd
IBM Storage Systems Group
5600 Cottle Road
San Jose, CA 95193