RFC 4018
Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2)
RFC 4018 Part 1 of 5 🎀
Okay bestie, this one is RFC 4018 and it's all about how iSCSI devices find each other using SLPv2 🦋. The title is Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLPv2) ✨
Here's the header info, lined up nicely:
- Stream: Network Working Group 🌸
- Authors: M. Bakke (Cisco), J. Hufferd (IBM), K. Voruganti (IBM), M. Krueger (HP), and T. Sperry (Adaptec) 👑
- Category: Standards Track 💅
- Date: April 2005 🍓
- Obsoletes / Updates: The header doesn't list either one, so this RFC doesn't obsolete or update anything 🧚
Status of This Memo 💖
This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🫶
Copyright Notice 🌈
Copyright (C) The Internet Society (2005).
Abstract ✨
So the iSCSI protocol lets hosts access SCSI devices over an IP network 🔥. This document defines how iSCSI hosts, devices, and management services use the Service Location Protocol (SLP), and it also defines the SLP service type templates that describe the services they provide 💜.
Table of Contents 🦋
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............................................ 211. Introduction 🌸
Okay so, iSCSI [RFC3720] is a protocol for moving SCSI [SAM2] commands, data, and status across an IP network 🌐. It's connection-oriented and it's currently defined over TCP 💅. iSCSI works on a client-server setup: the client end is an initiator, which sends SCSI commands, and the server end is called a target, which receives and executes those commands 👑.
Initiators have a few ways to figure out which targets to connect to 🧚. Two of those ways don't need SLP at all:
- Each target and its address can be statically configured on the initiator.
- Each address providing targets can be configured on the initiator. iSCSI gives the initiator a mechanism to ask that address for a list of targets.
Those methods are explained more fully in "iSCSI Naming and Discovery Requirements" [RFC3721] 📖.
Here's the tea 🫖: each of those methods means you have to set up a little config on every single initiator. Being able to discover targets and name services without configuring every initiator is a seriously desirable feature 💖. The Service Location Protocol (SLP) [RFC2608] is an IETF standards track protocol with several features that make finding iSCSI services way easier 🦋. This document describes how SLP can be used in iSCSI environments to discover targets, addresses providing targets, and storage management servers ✨.
2. Notation Conventions 💜
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] 🎀.
3. Terminology 🍓
These definitions are for anyone who's new to SLP, SCSI, or iSCSI, so no judgment if you need them 🫶. Some of them were pulled from [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.4. Using SLP for iSCSI Service Discovery 🧚
Two entities are involved in iSCSI discovery 👯. The end goal is that an iSCSI initiator (for example, a host) discovers iSCSI targets, which are usually provided by storage controllers or gateways 💅.
iSCSI targets get registered with SLP as a set of service URLs, one for each address where the target can be accessed 🌈. Initiators find these targets by sending SLP service requests 🔥. Targets that don't directly support SLP, or that are under the control of a management service, may be registered by a proxy service agent as part of the software providing this service 🫶.
iSCSI entities can also use SLP to find higher-level management services when they need them 💖.
This section first covers how initiators use SLP to discover targets, and then it covers how SLP is used to discover storage management servers 🦋.
This document assumes that SLPv2 will be used for discovering iSCSI-related services, and no attempt is made to include support for SLPv1 🌸.
4.1. Discovering iSCSI Targets with SLP ✨
okay so this diagram is giving everything 🎀 It shows how iSCSI clients, servers, initiators, and targets all fit together. An iSCSI client includes at least one iSCSI initiator and an SLP user agent (UA) 💅 An iSCSI server includes at least one iSCSI target and an SLP service agent (SA) 🦋 Some entities, like extended copy engines, include both initiators and targets 👑 These get both an SA, so their targets can be discovered, and a UA, so their initiator(s) can discover other targets 🧚
+---------------------------------+
| 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". so smart, right? 💖
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, and 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. this part is literally the whole point 🔥
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/one192.0.2.131:3260/two192.0.2.131:3260/three192.0.2.3:3260/one192.0.2.3:3260/two192.0.2.3:3260/three
The remainder of the discovery procedure is identical to that used by any client/server pair implementing SLP 💅
- 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.
- 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.
- 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. this one is a must, no debate 😭
4.1.1. Finding Targets Based on Initiator Credentials
To be allowed access to an iSCSI target, an initiator must be authenticated. The initiator may be required by the target to produce one or more of the following credentials:
- An iSCSI Initiator Name
- An IP address
- A CHAP, SRP, or Kerberos credential
- Any combination of the above
Most iSCSI targets allow access to only one or two initiators. In the ideal discovery scenario, an initiator would send an SLP request and receive responses ONLY for targets to which the initiator is guaranteed a successful login 🎯 To achieve this goal, the iSCSI target template contains the following attributes, each of which allows a list of values:
auth-name: This attribute contains the list of initiator names allowed to access this target, or the value"any", indicating that no specific initiator name is required.auth-addr: This attribute contains the list of host names and/or IP addresses that will be allowed access to this target, or the value"any", indicating that no specific address or host name is required. If a large number of addresses is to be allowed (perhaps a subnet), this attribute may contain the value"any".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.
⚠️ security policy info is not a toy. if these attributes get distributed, IPsec MUST be in place. no shortcuts, bestie 💀
4.1.2. Supporting Access by Multiple Identities to the Same Target
If a target is to allow access to multiple host identities, more than one combination of auth-xxxx attributes will have to be allowed. In some of these cases, it is not possible to express the entire set of valid combinations of auth-xxxx attributes within a single registered service URL. For example, if a target can be addressed by:
auth-name=myhost1 AND auth-cred=CHAP/user1 (identity1)
OR
auth-name-myhost2 AND auth-cred=CHAP/user2 (identity2)the above cannot be specified in a single registered service URL, since (auth-name=myhost1, auth-name=myhost2, auth-cred=CHAP/user1, auth-cred=CHAP/user2) would allow either auth-name to be used with either auth-cred. This necessitates the ability to register a target and address under more than one service URL: one for (identity1) and one for (identity2). the mix-and-match problem is so real 🙈
Because service URLs must be unique, (identity1) and (identity2) must each be registered under a unique service URL. For systems that support the configuration of multiple identities to access a target, the service URL must contain an additional, opaque string defining the identity. This appears after the iSCSI name in the URL string and is separated by a "/". Each registered (target-address, target-name, initiator-identity) tuple can then register a set of auth-xxxx attributes 🫶
4.1.3. Using SLP in a Non-multicast Environment
In some networks, the use of multicast for discovery purposes is either unavailable or not allowed. These include public or service-provider networks that are placed between an iSCSI client and a server. These are probably most common between two iSCSI gateways, one at a storage service provider site, and one at a customer site 🌈
In these networks, an initiator may allow the addresses of one or more SAs to be configured instead of or in addition to its DA configuration. The initiator would then make unicast SLP service requests directly to these SAs, without the use of multicast to discover them first 🧚
This functionality is well within the scope of the current SLP protocol. The main consequence for implementors is that an initiator configured to make direct unicast requests to an SA will have to add this to the SLP API, if it is following the service location API defined in [RFC2614]. so yeah, that's the non-multicast story, babe 💜
4.2. Discovering Storage Management Services with SLP 🧚
okay so storage management servers can be built to manage and control access to targets in a bunch of different ways 🫶 they can do more than discovery, like storage allocation and management. none of those extra services are defined here though. the goal is just to let clients and servers discover these services, on top of the target discovery we already do 💖
here's the vibe. there's an iSCSI client, an iSCSI server, and a storage management server. the second IP network isn't drawn (to keep it simple) but yes, it exists 🙈 the storage management server talks to clients and servers using its own protocol, called smsp ✨ and both the clients and the servers can use SLP to find the storage management server 🔥
+---------------------------+
| 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 |
+---------------------------+ooh, but note the difference between this storage management server model and the target discovery model we already covered 👀 in target discovery, the iSCSI Server was the one running an SA, which the initiator's UA found. in the storage management server model, the iSCSI clients and servers both run UAs, and the management server is the one running the SA 💅
the storage management server's URL has the domain name or IP address, plus the TCP or UDP port number. that's literally it, no other info needed 🍓
the storage management server builds a service advertisement of the type service:iscsi:sms for each address it shows up at. the advertisement holds the URL and a lifetime, plus other attributes from the service template 🌸
everything after that is basically the same as discovering iSCSI targets, except that both initiators and targets would usually be "clients" of the storage management service 🦋
targets that support a storage management service run a UA alongside the SA ✨ but a target can also just run the UA and let the storage management service advertise its targets for it. the management service does this by running an SA and registering the right service:iscsi:target registrations on the target's behalf 💜 so the target device doesn't have to advertise its own targets. none of this changes anything for the initiator 🫶
the best part is that initiators can keep discovering targets in a totally interoperable way, no matter which storage management service is used (or if one is used at all), and no matter whether the target registrations come straight from the target or from the management service 👑 iconic, honestly.
4.3. Internationalization Considerations 🌍
SLP lets you register and retrieve internationalized strings 🌈 attributes in the template that aren't marked with an 'L' (literal) get registered in a localized way. an "en" (English) localization MUST be registered, and others MAY be registered 🇬🇧
attributes that have non-ASCII characters get encoded with UTF-8, as discussed in [RFC3722] and [RFC3491] 💖
5. iSCSI SLP Templates 🎀
there are three templates: an iSCSI target template, a management service template, and an abstract template that wraps up the other two ✨
5.1. The iSCSI Abstract Service Type Template 💅
this template defines the abstract service service:iscsi 🦋 it's used as the top-level service that encapsulates all the other iSCSI-related services, so it's the big umbrella ☂️
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 ✨
okay bestie, this template defines the service service:iscsi:target 🎀 If an entity has iSCSI targets and wants them discovered through SLP, it registers each target, with each of its addresses, as this service type 💖
Initiators (and maybe management services) that want to find targets this way will usually run one of these queries 👀
- 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)- 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)- 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)- 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)- 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)- 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))- 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)- Also, a management service may want to discover all targets:
Service: service:iscsi:target
Scope: management-server-scope-list
Query: <empty-string>For all the booting deets, check out [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 🌈
okay so this template defines the service service:iscsi:sms 💅 An entity that supports one or more iSCSI management service protocols can register itself with SLP as this service type. iSCSI clients and servers that want to find storage management services through SLP will usually search 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 🔒
okay so security, bestie 🫶. SLPv2 as specified in [RFC2608] doesn't give you confidentiality 🙅, but it does have an authentication mechanism so UAs can make sure service advertisements only come from trusted SAs ✨. The one gap is that it can't authenticate "zero-result responses" 💀. For the full tea on the SLPv2 [RFC2608] security model, go read [RFC3723] 📚.
Once you've discovered a target or management server, authentication and authorization are handled by the iSCSI protocol, or by the management server's protocol 💅. The providers of these services are responsible for making sure that an inappropriately advertised or discovered service can't wreck their security 😤.
When SLPv2 has no security turned on, there's a risk of false discovery info getting passed around 😭. The main countermeasure is authentication. When that risk is a real concern, IPsec SAs and iSCSI in-band authentication SHOULD be used for the iSCSI traffic that's exposed to it 🔐. This makes sure iSCSI traffic only flows between endpoints that went through IKE authentication and iSCSI in-band authentication. For example, if an attacker spreads discovery info falsely claiming to be an iSCSI target, they won't have the secret information needed to complete IKE authentication or iSCSI in-band authentication successfully, so they're locked out of sending or receiving iSCSI traffic 🚫.
Heads up, this next one is a lil scary 😱. A risk remains of a denial of service attack based on repeated use of false discovery information that makes initiation of IKE negotiation happen over and over 💀. The countermeasures are administrative configuration of each iSCSI Target to limit the peers it's willing to communicate with (by IP address range and/or DNS domain), plus a negative authentication cache so it stops 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 are security policy information 🗝️. When these get 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, so all IP storage clients, including the ones invoking SLP, can be assumed to support IPsec 💜. SLP servers, however, can't be assumed to implement IPsec, since standard SLP has no such requirement. In particular, SLP Directory Agents (DA) may be running on machines other than the ones 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, because 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. Hard no, periodt 🙅♀️💀.
Because the IP storage services have their own authentication capabilities once located, SLPv2 authentication is OPTIONAL to implement and use. You can read more about that in [RFC3723] 🌸.
7. IANA Considerations 🗂️
This document describes three SLP Templates. They've been reviewed and approved by the IESG and registered in the IANA's "SVRLOC Templates" registry ✅. The 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, and it presents service type templates for iSCSI targets and storage management servers. That's the whole vibe 💖.
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 👯♀️. The squad includes 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
Phone: +1 408 997-6136
EMail: jlhufferd@comcast.net
Marjorie Krueger
Hewlett-Packard Corporation
8000 Foothills Blvd
Roseville, CA 95747-5668, USA
Phone: +1 916 785-2656
EMail: marjorie_krueger@hp.com
Todd Sperry
Adaptec, Inc.
691 South Milpitas Boulevard
Milpitas, Ca. 95035
Phone: +1 408 957-4980
EMail: todd_sperry@adaptec.comFull 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. It also doesn't 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-ipr@ietf.org 📨.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, internet 🫶✨
📦 where this page comes from
- ietf: rfc4018 2005-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms