draft-ietf-ips-iscsi-slp-02.txt   draft-ietf-ips-iscsi-slp-03.txt 
Internet Draft Mark Bakke Internet Draft Mark Bakke
<draft-ietf-ips-iscsi-slp-02.txt> Cisco <draft-ietf-ips-iscsi-slp-03.txt> Cisco
Expires May 2002 Expires September 2002
Joe Czap Joe Czap
Jim Hafner Jim Hafner
John Hufferd John Hufferd
Kaladhar Voruganti Kaladhar Voruganti
IBM IBM
Howard Hall Howard Hall
Pirus Pirus
Jack Harwood Jack Harwood
EMC EMC
Yaron Klein Yaron Klein
Sanrad Sanrad
Marjorie Krueger Marjorie Krueger
HP HP
Lawrence Lamers Lawrence Lamers
San Valley Systems San Valley Systems
Todd Sperry Todd Sperry
Adaptec Adaptec
Joshua Tseng Joshua Tseng
Nishan Nishan
November 2001 March 2002
Finding iSCSI Targets and Name Servers Using SLP Finding iSCSI Targets and Name Servers Using SLP
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 21 skipping to change at page 3, line 21
feature. The Service Location Protocol (SLP) [SLP] is an IETF feature. The Service Location Protocol (SLP) [SLP] is an IETF
standards track protocol that provides several features that will standards track protocol that provides several features that will
simplify locating iSCSI services. This document describes how SLP simplify locating iSCSI services. This document describes how SLP
can be used in iSCSI environments to discover targets, addresses can be used in iSCSI environments to discover targets, addresses
providing targets, and storage management servers. providing targets, and storage management servers.
This draft is a work in progress. Searching for the string "WORK" in This draft is a work in progress. Searching for the string "WORK" in
this document should find anything that is not considered to be this document should find anything that is not considered to be
complete. The following items are still open: complete. The following items are still open:
- Should look into Erik Guttman's serviceid scheme [SVCID] as a
slight variation to our SLP template, and see what it would take to
implement it, and whether it would change APIs.
- Need to add RFC 3082 interaction. An initiator that is already up - Need to add RFC 3082 interaction. An initiator that is already up
and running must be notified within a reasonable amount of time and running must be notified within a reasonable amount of time
when a new target becomes available to it. This may be due to a when a new target becomes available to it. This may be due to a
storage device booting, a network interface being added to the storage device booting, a network interface being added to the
device, a new target being created on the device, or the initiator device, a new target being created on the device, or the initiator
being added to the access-list of an existing device. Work is being added to the access-list of an existing device. Work is
under way to determine the best way to do this, either using the under way to determine the best way to do this, either using the
experimental RFC 3082 or some modification thereof. Note that it experimental RFC 3082 or some modification thereof. Note that it
is a non-goal for SLP to notify an initiator when a target or one is a non-goal for SLP to notify an initiator when a target or one
of its service URLs is no longer accessible; the initiator will of its service URLs is no longer accessible; the initiator will
skipping to change at page 3, line 46 skipping to change at page 3, line 50
- Add comments about lifetime of URLs and how it is used. URLs are - Add comments about lifetime of URLs and how it is used. URLs are
registered with a finite lifetime. If the lifetime is too long, a registered with a finite lifetime. If the lifetime is too long, a
lot of stale URLs may hang around; if it is too short, SLP lot of stale URLs may hang around; if it is too short, SLP
participants will spend too much time re-registering the same old participants will spend too much time re-registering the same old
URLs. There is a definite recommendation by the SLP folks to stick URLs. There is a definite recommendation by the SLP folks to stick
with the default; I have to go look it up to see what it is. with the default; I have to go look it up to see what it is.
- SLP can be set up to use either Unicast or Multicast. Add a - SLP can be set up to use either Unicast or Multicast. Add a
discussion on when to use each. discussion on when to use each.
- Storage Name Service or Storage Management Service? Need to settle The following modifications have been made in draft-02:
on a generic name for things like this.
The following modifications have been made since draft-01:
- Removed the mgmt-ipaddress attribute from the template; if FQDN is - Removed the mgmt-ipaddress attribute from the template; if FQDN is
not available, the IP address may be returned in its place as a not available, the IP address may be returned in its place as a
dotted-decimal string. dotted-decimal string.
- Added example for finding targets that will allow access to any - Added example for finding targets that will allow access to any
initiator. initiator.
- Updated Security Considerations to reference the IP storage - Updated Security Considerations to reference the IP storage
security draft. security draft.
The following modifications were made in draft-03:
- Updated non-multicast usage text in section 5.1.
- Updated references.
3. Notation Conventions 3. Notation Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
4. Terminology 4. Terminology
Here are some definitions that may aid readers that are unfamiliar Here are some definitions that may aid readers that are unfamiliar
skipping to change at page 9, line 26 skipping to change at page 9, line 26
target(s) it requires. target(s) it requires.
3. Once the UA has the host name or address of the iSCSI server 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 as well as the port number and iSCSI Target Name, it can begin the
normal iSCSI login to the target. normal iSCSI login to the target.
As information contained in the iSCSI target template may exceed As information contained in the iSCSI target template may exceed
common network datagram sizes, the SLP implementation for both UAs common network datagram sizes, the SLP implementation for both UAs
and SAs supporting this template MUST implement SLP over TCP. and SAs supporting this template MUST implement SLP over TCP.
5.1.1. Using SLP in a Non-Multicast Environment
In some networks, the use of multicast for discovery purposes is In some networks, the use of multicast for discovery purposes is
either unavailable or not allowed. Such networks include public or either unavailable or not allowed. Such networks include public or
service-provider networks that are placed in between an iSCSI client service-provider networks that are placed in between an iSCSI client
and server; these are probably most common between two iSCSI and server; these are probably most common between two iSCSI
gateways, one at a storage service provider site, and one at a gateways, one at a storage service provider site, and one at a
customer site. customer site.
In these networks, an initiator may, instead or in addition to its DA In these networks, an initiator may, instead or in addition to its DA
configuration, allow the addresses of one or more SAs to be configuration, allow the addresses of one or more SAs to be
configured. The initiator would then make unicast SLP service configured. The initiator would then make unicast SLP service
requests directly to these SAs, without the use of multicast to first requests directly to these SAs, without the use of multicast to first
discover them. discover them.
This functionality is well within the scope of the current SLP This functionality is well within the scope of the current SLP
protocol. However, it does have two consequences for implementors: protocol. However, it does have two consequences for implementors:
- A service-agent responding to requests for iSCSI targets MUST - A service-agent responding to requests for iSCSI targets MUST
implement SLP over TCP; UDP only is not enough. implement SLP over TCP; UDP only is not enough. This is not
an issue, since TCP is a requirement for iSCSI implementations
that use SLP for other reasons.
- An initiator configured to make direct, unicast requests to an - 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 SA will have to add this to the SLP API, if it is following the
service location API defined in [RFC2614]. service location API defined in [RFC2614]. This capability
is being added to the next revision of the API, in [2614BIS].
5.2. Discovering Storage Management Services using SLP 5.2. Discovering Storage Management Services using SLP
Storage management servers can be built to manage and control access Storage management servers can be built to manage and control access
to targets in a variety of ways. They can also provide extended to targets in a variety of ways. They can also provide extended
services beyond discovery, which could include storage allocation and services beyond discovery, which could include storage allocation and
management. None of these services are defined here; the intent of management. None of these services are defined here; the intent of
this document is to allow these services to be discovered by both this document is to allow these services to be discovered by both
clients and servers, in addition to the target discovery already clients and servers, in addition to the target discovery already
being performed. being performed.
skipping to change at page 13, line 8 skipping to change at page 14, line 8
familiar with SLP. familiar with SLP.
Where are the templates used? By the implementor; don't need to be Where are the templates used? By the implementor; don't need to be
installed in a DA (not like a MIB). installed in a DA (not like a MIB).
Who makes use of the templates? Who makes use of the templates?
- Implementor of iSCSI host drivers / adapters / devices - Implementor of iSCSI host drivers / adapters / devices
- Network Administrator (DHCP and DA) - Network Administrator (DHCP and DA)
- Storage Administrator (DA and SA) - Storage Administrator (DA and SA)
Integrating SLP DA or SA within a storage management server WORK - Integrating SLP DA or SA within a storage management server
When to use multicast and/or unicast WORK - When to use multicast and/or unicast
Using DHCP to bootstrap SLP discovery WORK - Using DHCP to bootstrap SLP discovery
6. iSCSI SLP Templates 6. iSCSI SLP Templates
Three templates are provided: an iSCSI target template, a management Three templates are provided: an iSCSI target template, a management
service template, and an abstract template to encapsulate the two. service template, and an abstract template to encapsulate the two.
6.1. The iSCSI Abstract Service Type Template 6.1. The iSCSI Abstract Service Type Template
This template defines the abstract service "service:iscsi". It is This template defines the abstract service "service:iscsi". It is
used as a top-level service to encapsulate all other iSCSI-related used as a top-level service to encapsulate all other iSCSI-related
skipping to change at page 16, line 8 skipping to change at page 17, line 8
# entity supports. iSCSI is currently supported over TCP, # entity supports. iSCSI is currently supported over TCP,
# but it is anticipated that it could be supported over other # but it is anticipated that it could be supported over other
# transports, such as SCTP, in the future. # transports, such as SCTP, in the future.
tcp tcp
mgmt-entity = string O mgmt-entity = string O
# The fully qualified domain name, or IP address in dotted-decimal # The fully qualified domain name, or IP address in dotted-decimal
# notation, of the management interface of the entity containing # notation, of the management interface of the entity containing
# this target. # this target.
# #
# WORK - Should this be a URL?
# snmp://10.1.1.1
# http://mydisk.ssp.com:1080/
# telnet://mydisk.ssp.com
alias = string O alias = string O
# The alias string contains a descriptive name of the target. # The alias string contains a descriptive name of the target.
access-list = string M access-list = string M
# A list of iSCSI Initiator Names that can access this target. # A list of iSCSI Initiator Names that can access this target.
# Normal iSCSI names will be 50 characters or less; max length is 255. # Normal iSCSI names will be 50 characters or less; max length is 255.
# Normally, only one or a few values will be in the list. # Normally, only one or a few values will be in the list.
# Using the equivalence search on this will evaluate to "true" # Using the equivalence search on this will evaluate to "true"
# if any one of the items in this list matches the query. # if any one of the items in this list matches the query.
skipping to change at page 17, line 50 skipping to change at page 18, line 46
7. Security Considerations 7. Security Considerations
Service type templates provide information that is used to interpret Service type templates provide information that is used to interpret
information obtained by clients through SLP. If the iSCSI templates information obtained by clients through SLP. If the iSCSI templates
are modified or if false templates are distributed, iSCSI targets and are modified or if false templates are distributed, iSCSI targets and
name servers may not correctly register themselves, or iSCSI clients name servers may not correctly register themselves, or iSCSI clients
may not be able to interpret service information. may not be able to interpret service information.
SLP provides an authentication mechanism for UAs to assure that SLP provides an authentication mechanism for UAs to assure that
service advertisments only come from trusted SAs. [RFC2608] If trust service advertisments only come from trusted SAs [RFC2608]. If trust
is an issue, particularly with respect to the information sought by is an issue then SLP authentication should be enabled in the network.
the client about IPSEC and IKE support, then SLP authentication
should be enabled in the network.
Once a target or management server is discovered, authentication and Once a target or management server is discovered, authentication and
authorization are handled by the iSCSI protocol, or by the management authorization are handled by the iSCSI protocol, or by the management
server's protocol. It is the responsibility of the providers of server's protocol. It is the responsibility of the providers of
these services to ensure that an inappropriately advertised or these services to ensure that an inappropriately advertised or
discovered service does not compromise their security. discovered service does not compromise their security.
7.1. IPsec Integration 7.1. IPsec Integration
Although SLPv2 security provides authentication, it does not provide Although SLPv2 security provides authentication, it does not provide
confidentiality. confidentiality. In many environments, confidentiality of discovery
information is important. For instance, the existence of a
particular iSCSI target name within a building can indicate that
there is an expensive/important piece of equipment in there, and its
discovery information. This may provide enough information for an
attacker to attempt a denial-of-service or other attacks on the iSCSI
device.
The use of IPsec and IKE for SLPv2 is discussed in [IPS-SEC], and is SLPv2 authentication does not provide confidentiality of discovery
a work in progress. It will be discussed further here in a information. When this is a concern, in particular when SLPv2 is
subsequent draft revision. used to distribute security policy information, IPsec MUST be used
with SLPv2 when discovering iSCSI targets. When this is not a
concern, SLPv2 security MAY be implemented and used.
The use of IPsec and IKE for SLPv2 is described in [IPS-SEC], and is
a work in progress.
8. Summary 8. Summary
This document describes how SLP can be used by iSCSI initiators to This document describes how SLP can be used by iSCSI initiators to
find iSCSI targets and storage management servers. Service type find iSCSI targets and storage management servers. Service type
templates for iSCSI targets and storage management servers are templates for iSCSI targets and storage management servers are
presented. presented.
9. References 9. References
[RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. Service [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service
Location Protocol, version 2 RFC 2608, July 1999. Location Protocol, version 2", RFC 2608, July 1999.
[RFC2609] E. Guttman, C. Perkins, J. Kempf. Service Templates and [RFC2609] E. Guttman, C. Perkins, J. Kempf. "Service Templates and
service: Schemes RFC 2609, July 1999. service: Schemes", RFC 2609, July 1999.
[RFC2614] J. Kempf, E. Guttman. An API for Service Location [RFC2614] J. Kempf, E. Guttman. "An API for Service Location", RFC
RFC 2614, June 1999. 2614, June 1999.
[RFC2119] S. Bradner. Key Words for Use in RFCs to Indicate [2614BIS] J. Kempf, E. Guttman. "An API for Service Location", draft-
Requirement Levels. RFC 2119, March 1997. kempf-svrloc-rfc2614bis-00.txt, February 2002.
[RFC3082] J. Kempf, J Goldschmidt. Notification and Subscription for [RFC2119] S. Bradner. "Key Words for Use in RFCs to Indicate
SLP. RFC 3082, March 2001. Requirement Levels", RFC 2119, March 1997.
[ISCSI] J. Satran, et. al. "iSCSI", draft-ietf-ips-iscsi-08.txt, [RFC3082] J. Kempf, J Goldschmidt. "Notification and Subscription for
September 2001. SLP", RFC 3082, March 2001.
[ISCSI] J. Satran, et. al. "iSCSI", draft-ietf-ips-iscsi-10.txt,
January 2002.
[SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000.
[NDT] K. Voruganti, et. al. "iSCSI Naming and Discovery", draft- [NDT] K. Voruganti, et. al. "iSCSI Naming and Discovery", draft-
ietf-ips-iscsi-name-disc-03, July 2001. ietf-ips-iscsi-name-disc-05, March 2002.
[ISNS] J. Tseng, et. al. "Internet Storage Name Service", [ISNS] J. Tseng, et. al. "Internet Storage Name Service",
draft-ietf-ips-isns-05, November 2001. draft-ietf-ips-isns-05, November 2001.
[BOOT] P. Sarkar, D. Missimer, C. Sapuntzakis. "A Standard for [BOOT] P. Sarkar, D. Missimer, C. Sapuntzakis. "A Standard for
Bootstrapping Clients using the iSCSI Protocol", Bootstrapping Clients using the iSCSI Protocol",
draft-ietf-ips-iscsi-boot-03, August 2001. draft-ietf-ips-iscsi-boot-04, November 2001.
[RSIP] Kempf, J., Montenegro, G., "Finding an RSIP Server with [RSIP] Kempf, J., Montenegro, G., "Finding an RSIP Server with
SLP", draft-ietf-nat-rsip-slp-00, February 2000. SLP", draft-ietf-nat-rsip-slp-00, February 2000.
[IPS-SEC] B. Aboba, et. al., "Securing iSCSI, iFCP, and FCIP", [IPS-SEC] B. Aboba, et. al., "Securing iSCSI, iFCP, and FCIP",
draft-ietf-ips-security-04, October 2001. draft-ietf-ips-security-10, February 2002.
[SVCID] E. Guttman, "The serviceid: URL Scheme for Service
Location",
draft-guttman-svrloc-serviceid-01, January 2002.
Author's Address: Author's Address:
Mark Bakke Mark Bakke
Cisco Systems, Inc. Cisco Systems, Inc.
6450 Wedgwood Road 6450 Wedgwood Road
Maple Grove, MN Maple Grove, MN
USA 55311 USA 55311
Voice: +1 763-398-1000 Voice: +1 763-398-1000
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/