Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
updated by
- rfc-7146 — Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3
Extracted elements (23)
In non-multicast environments (e.g., between iSCSI gateways across provider networks), an initiator may be configured with SA addresses and use unicast SLP requests directly to those SAs, bypassing multicast discovery entirely. This is within current SLP scope.
In the storage management server model, both iSCSI clients and servers act as SLP UAs while the management server acts as SA, in contrast to the target discovery model where the iSCSI server is the SA. This allows management services to register targets on behalf of target devices.
Multiple service URL registrations per target are required when a target must allow access to multiple distinct initiator identities, because a single URL's auth-xxxx attribute lists cannot express AND-within-identity constraints across different identities without incorrectly allowing cross-identity combinations.
SLP is used for iSCSI discovery to avoid the need to statically configure initiators with target addresses or query addresses for target lists. This enables zero-configuration discovery of targets, addresses providing targets, and storage management servers.
Initiator discovery of targets remains interoperable regardless of which storage management service is used, whether one is used at all, or whether target registrations are provided directly by the target or by the management service acting as proxy SA.
This document assumes SLPv2 will be used for discovering iSCSI-related services; no attempt is made to include support for SLPv1.
An English ('en') localization of SLP attributes MUST be registered; other localizations MAY be registered. Non-ASCII attribute values are encoded in UTF-8.
IPsec SHOULD be implemented for SLPv2 as specified in RFC 3723, including ESP with a non-null transform to provide both authentication and confidentiality.
SLP implementations for both UAs and SAs supporting the iSCSI target template MUST implement SLP over TCP, because information in the iSCSI target template may exceed common network datagram sizes.
SLPv2 authentication is OPTIONAL to implement and use for iSCSI SLP discovery, because the IP storage services provide their own authentication capabilities once located.
When auth-name, auth-addr, auth-cred, or boot-list attributes are distributed via SLPv2, IPsec MUST be implemented. If IPsec is not implemented, these attributes MUST NOT be distributed via SLPv2 and MUST NOT be used if discovered via SLPv2.
The abstract service type 'service:iscsi' encapsulates all iSCSI-related SLP services. It is the top-level type under which concrete types 'service:iscsi:target' and 'service:iscsi:sms' are defined.
The 'auth-addr' attribute is a multi-valued list of initiator IP addresses or host names allowed access, or 'any' for unrestricted address-based access. It is security policy information requiring IPsec when distributed.
The 'auth-cred' attribute is a multi-valued list of 'method/identifier' credentials (e.g., 'chap/username', 'srp/username') allowed access to the target. It is security policy information requiring IPsec when distributed.
The 'auth-name' attribute is a multi-valued list of iSCSI Initiator Names allowed to access the target, or the value 'any' for unrestricted name-based access. It is security policy information requiring IPsec protection when distributed.
The 'boot-list' attribute lists iSCSI Initiator Names allowed to boot from the target. If absent, the target is not bootable. LUN 0 is the assumed boot LUN. This is security policy information requiring IPsec when distributed.
The concrete service type 'service:iscsi:sms' is used to register storage management servers. Its template includes 'protocols' (e.g., 'isns'), 'transports' (tcp, udp), and 'server-priority' attributes.
The concrete service type 'service:iscsi:target' is used to register individual iSCSI target addresses with SLP. Each target/address combination is registered separately, and the service URL encodes host, port, iSCSI name, and optional identity string.
The 'iscsi-name' attribute in the target template is the iSCSI Name of the target and MUST match the iscsi-name in the URL path. The 'portal-group' attribute identifies the portal group tag; addresses sharing the same iscsi-name and portal-group tag can be used within the same iSCSI session.
Three SLP service type templates are registered in the IANA 'SVRLOC Templates' registry: 'service:iscsi' (abstract), 'service:iscsi:target' (concrete, for iSCSI targets), and 'service:iscsi:sms' (concrete, for storage management servers). Registration process is per RFC 2609.
SLPv2 provides authentication for service advertisements but not confidentiality, and does not authenticate zero-result responses. When false discovery information is a risk, IPsec SAs and iSCSI in-band authentication SHOULD be used so only authenticated endpoints exchange iSCSI traffic.
To counter denial-of-service attacks via false discovery information triggering repeated IKE negotiation, implementations MUST enforce IP address range limits, DNS domain limits, and maintain a negative authentication cache. These three countermeasures are all mandatory.
The iSCSI target service URL path has the form: hostport '/' iscsi-name ['/' identity], where hostport is a DNS hostname or IPv4/IPv6 address with optional port, iscsi-name is the iSCSI target name, and identity is an optional opaque string for multi-identity access control.