idnits 2.17.1 draft-ietf-ips-iscsi-slp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 6981 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3491 (Obsoleted by RFC 5891) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3720 (Obsoleted by RFC 7143) == Outdated reference: A later version (-01) exists of draft-kempf-svrloc-rfc2614bis-00 Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mark Bakke 3 Cisco 4 Expires February 2005 5 John Hufferd 6 Kaladhar Voruganti 7 IBM 9 Marjorie Krueger 10 HP 12 Todd Sperry 13 Adaptec 15 August 2004 17 Finding Internet Small Computer Systems Interface (iSCSI) Targets 18 and Name Servers using Service Location Protocol version 2 (SLPv2) 20 Status of this Memo 22 This document is an Internet-Draft and is in full conformance with 23 all provisions of Section 10 of RFC2026. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet- Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 The iSCSI protocol provides a way for hosts to access SCSI devices 48 over an IP network. This document defines the use of the Service 49 Location Protocol (SLP) by iSCSI hosts, devices, and management 50 services, along with the SLP service type templates that describe the 51 services they provide. 53 Acknowledgements 55 This draft was produced by the iSCSI Naming and Discovery team, 56 including Joe Czap, Jim Hafner, John Hufferd, and Kaladhar Voruganti 57 (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (Sanrad), 58 Marjorie Krueger (HP), Lawrence Lamers (San Valley), Todd Sperry 59 (Adaptec), and Joshua Tseng (Nishan). Thanks also to Julian Satran 60 (IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt 61 Peterson (Caldera) and James Kempf (Sun) for reviewing the document 62 from an SLP perspective. 64 Table of Contents 66 1. Introduction.................................................2 67 2. Notation Conventions.........................................3 68 3. Terminology..................................................3 69 4. Using SLP for iSCSI Service Discovery........................4 70 5. iSCSI SLP Templates.........................................12 71 6. Security Considerations.....................................18 72 7. IANA Considerations.........................................20 73 8. Summary.....................................................20 74 9. Normative References........................................20 75 10. Informative References......................................21 76 11. Authors' Addresses..........................................21 77 12. Full Copyright Notice.......................................22 79 1. Introduction 81 iSCSI [RFC3720] is a protocol used to transport SCSI [SAM2] commands, 82 data, and status across an IP network. This protocol is connection- 83 oriented, and is currently defined over TCP. iSCSI uses a client- 84 server relationship. The client end of the connection is an 85 initiator, and sends SCSI commands; the server end of the connection 86 is called a target, and receives and executes the commands. 88 There are several methods an iSCSI initiator can use to find the 89 targets to which it should connect. Two of these methods can be 90 accomplished without the use of SLP: 92 - Each target and its address can be statically configured on the 93 initiator. 95 - Each address providing targets can be configured on the initiator; 96 iSCSI provides a mechanism by which the initiator can query the 97 address for a list of targets. 99 The above methods are further defined in "iSCSI Naming and Discovery 100 Requirements" [RFC3721]. 102 Each of the above methods requires a small amount of configuration to 103 be done on each initiator. The ability to discover targets and name 104 services without having to configure initiators is a desirable 105 feature. The Service Location Protocol (SLP) [RFC2608] is an IETF 106 standards track protocol that provides several features that will 107 simplify locating iSCSI services. This document describes how SLP 108 can be used in iSCSI environments to discover targets, addresses 109 providing targets, and storage management servers. 111 2. Notation Conventions 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 3. Terminology 119 Here are some definitions that may aid readers that are unfamiliar 120 with either SLP, SCSI, or iSCSI. Some of these definitions have been 121 reproduced from [RFC2608] and "Finding an RSIP Server with SLP" 122 [RFC3105]. 124 User Agent (UA) A process working on the client's behalf 125 to establish contact with some service. 126 The UA retrieves service information from 127 the Service Agents or Directory Agents. 129 Service Agent (SA) A process working on behalf of one or more 130 services to advertise the services and 131 their capabilities. 133 Directory Agent (DA) A process which collects service 134 advertisements. There can only be one DA 135 present per given host. 137 Scope A named set of services, typically making 138 up a logical administrative group. 140 Service Advertisement A URL, attributes, and a lifetime 141 (indicating how long the advertisement is 142 valid), providing service access 143 information and capabilities description 144 for a particular service. 146 Initiator A logical entity, typically within a host, 147 that sends SCSI commands to targets to be 148 executed. An initiator is usually present 149 in the form of a device driver. 151 Target A logical entity, typically within a 152 storage controller or gateway, that 153 receives SCSI commands from an initiator 154 and executes them. A target includes one 155 or more Logical Units (LUs); each LU is a 156 SCSI device, such as a disk or tape drive. 158 iSCSI Name A UTF-8 character string which serves as a 159 unique identifier for iSCSI initiators and 160 targets. Its format and usage is further 161 defined in [RFC3721]. 163 iSCSI Client A logical entity, typically a host, which 164 includes at least one iSCSI Initiator. 166 iSCSI Server A logical entity, typically a storage 167 controller or gateway, which includes at 168 least one iSCSI Target. 170 Storage Management Server An addressable entity that provides 171 management services that benefit an iSCSI 172 environment. "Storage management server" 173 is used as a generic term, rather than a 174 specific protocol or service. 176 4. Using SLP for iSCSI Service Discovery 178 Two entities are involved in iSCSI discovery. The end result is that 179 an iSCSI initiator (e.g. a host) discovers iSCSI targets, usually 180 provided by storage controllers or gateways. 182 iSCSI targets are registered with SLP as a set of service URLs, one 183 for each address on which the target may be accessed. Initiators 184 discover these targets using SLP service requests. Targets that do 185 not directly support SLP, or are under the control of a management 186 service, may be registered by a proxy service agent as part of the 187 software providing this service. 189 iSCSI entities may also use SLP to discover higher-level management 190 services where needed. 192 This section first describes the use of SLP for discovery of targets 193 by iSCSI initiators, and then describes the use of SLP to discover 194 storage management servers. 196 This document assumes that SLPv2 will be used when discovering iSCSI- 197 related services; no attempt is made to include support for SLPv1. 199 4.1. Discovering iSCSI Targets using SLP 201 The following diagram shows the relationship between iSCSI clients, 202 servers, initiators, and targets. An iSCSI client includes at least 203 one iSCSI initiator, and an SLP user agent (UA). An iSCSI server 204 includes at least one iSCSI target, and an SLP service agent (SA). 205 Some entities, such as extended copy engines, include both initiators 206 and targets. These include both an SA, for its targets to be 207 discovered, and a UA, for its initiator(s) to discover other targets. 209 +---------------------------------+ 210 | iSCSI Client | 211 | +-----------+ | 212 | | iSCSI | | 213 | | initiator | | 214 | | "myhost" | | 215 | +-----------+ | 216 | | 217 +--------------------------+------+ 218 | iSCSI Driver | UA | 219 +--------------------------+------+ 220 | TCP/UDP/IP | 221 +----------------+----------------+ 222 | Interface 1 | Interface 2 | 223 +----------------+----------------+ 224 | | 225 +------------+ | | +------------+ 226 | SLP DA | | | | SLP DA | 227 | (optional) |----+ IP Networks +----| (optional) | 228 +------------+ | | +------------+ 229 | | 230 +-----------------+-----------------| 231 | Interface 1 | Interface 2 | 232 | 192.0.2.131 | 192.0.2.3 | 233 +-----------------+-----------------+ 234 | TCP/UDP/IP | 235 +---------------------------+-------+ 236 | iSCSI Driver | SA | 237 +---------------------------+-------| 238 | | 239 | +--------+ +--------+ +---------+ | 240 | | iSCSI | | iSCSI | | iSCSI | | 241 | | target | | target | | target | | 242 | | "one" | | "two" | | "three" | | 243 | +--------+ +--------+ +---------+ | 244 | iSCSI Server | 245 +-----------------------------------+ 247 In the above drawing, the iSCSI server has three iSCSI targets that 248 the client could discover, named "one", "two" and "three". The iSCSI 249 client has an iSCSI initiator with the name "myhost". The iSCSI 250 client may use the initiator name in its SLP Service Requests as a 251 filter to discover only targets that are configured to accept iSCSI 252 connections from "myhost". 254 Each iSCSI target and initiator has a unique name, called an iSCSI 255 Name. This identifier is the same regardless of the network path 256 (through adapter cards, networks, interfaces on the storage device) 257 over which the target is discovered and accessed. For this example, 258 the iSCSI names "one" and "two", and "three" are used for the 259 targets; the initiator uses the name "myhost". An actual iSCSI name 260 would incorporate more structure, including a naming authority, and 261 is not described here. 263 Each of the iSCSI targets in the drawing can appear at two addresses, 264 since two network interfaces are present. Each target would have two 265 service URLs, unless a single service URL included a DNS host name 266 mapping to both addresses. 268 An iSCSI target URL consists of its fully qualified host name or IP 269 address, the TCP port on which it is listening, and its iSCSI name. 270 An iSCSI server must register each of its individual targets at each 271 of its network addresses. 273 The iSCSI server constructs a service advertisement of the type 274 "service:iscsi:target" for each of the service URLs it wishes to 275 register. The advertisement contains a lifetime, along with other 276 attributes which are defined in the service template. 278 If the server in the above drawing is listening at TCP port 3260 for 279 both network addresses, the service URLs registered would be: 281 - 192.0.2.131:3260/one 283 - 192.0.2.131:3260/two 285 - 192.0.2.131:3260/three 287 - 192.0.2.3:3260/one 289 - 192.0.2.3:3260/two 291 - 192.0.2.3:3260/three 293 The remainder of the discovery procedure is identical to that used by 294 any client/server pair implementing SLP: 296 1. If an SLP DA is found, the SA contacts the DA and registers 297 the service advertisement. Whether or not one or more SLPv2 298 DAs are discovered, the SA maintains the advertisement itself 299 and answers multicast UA queries directly. 301 2. When the iSCSI initiator requires contact information for an 302 iSCSI target, the UA either contacts the DA using unicast or 303 the SA using multicast. If a UA is configured with the address 304 of the SA, it may avoid multicast and contact an SA using 305 unicast. The UA includes a query based on 306 the attributes to indicate the characteristics of the 307 target(s) it requires. 309 3. Once the UA has the host name or address of the iSCSI server 310 as well as the port number and iSCSI Target Name, it can begin the 311 normal iSCSI login to the target. 313 As information contained in the iSCSI target template may exceed 314 common network datagram sizes, the SLP implementation for both UAs 315 and SAs supporting this template MUST implement SLP over TCP. 317 4.1.1. Finding Targets Based on Initiator Credentials 319 To be allowed access to an iSCSI target, an initiator must be 320 authenticated. The initiator may be required by the target to 321 produce one or more of the following credentials: 323 - An iSCSI Initiator Name 325 - An IP address 327 - A CHAP, SRP, or Kerberos credential 329 - Any combination of the above 331 Most iSCSI targets allow access to only one or two initiators. In 332 the ideal discovery scenario, an initiator would send an SLP request, 333 and receive responses ONLY for those targets to which the initiator 334 is guaranteed a successful login. To achieve this goal, the iSCSI 335 target template contains the following attributes, each of which 336 allows a list of values: 338 1. auth-name - This attribute contains the list of initiator names 339 allowed to access this target, or the value "any", indicating 340 that no specific initiator name is required. 342 2. auth-addr - This attribute contains the list of host names 343 and/or IP addresses which will be allowed access to this target, 344 or the value "any", indicating that no specific address or 345 host name is required. If a large number of addresses is to 346 be allowed (perhaps a subnet), this attribute may contain the 347 value "any". 349 3. auth-cred - This attribute contains a list of "method/identifier" 350 credentials that will be allowed access to the target, provided 351 they can produce the correct password or other verifier during 352 the login process. If no specific credentials are required, the 353 value "any" is used. 355 The list of valid method strings for auth-cred are defined in 356 [RFC3720], section 11.1 "AuthMethod". The identifier used after the 357 "/" is defined by the specific AuthMethod, also in [RFC3720]. 358 Examples showing initiator searches based on auth-xxxx attributes are 359 shown in the target-specific template section below. 361 Also note that the auth-xxxx attributes are considered to be security 362 policy information. If these attributes are distributed, IPsec MUST 363 be implemented as specified in the Security Implementation section 364 below. 366 4.1.2. Supporting Access by Multiple Identities to the Same Target 368 If a target is to allow access to multiple host identities, more than 369 one combination of auth-xxxx attributes will need to be allowed. In 370 some of these cases, it is not possible to express the entire set of 371 valid combinations of auth-xxxx attributes within a single registered 372 service URL. For example, if a target can be addressed by: 374 auth-name=myhost1 AND auth-cred=CHAP/user1 (identity1) 376 OR 378 auth-name-myhost2 AND auth-cred=CHAP/user2 (identity2) 380 the above cannot be specified in a single registered service URL, 381 since (auth-name=myhost1, auth-name=myhost2, auth-cred=CHAP/user1, 382 auth-cred=CHAP/user2) would allow either auth-name to be used with 383 either auth-cred. This necessitates the ability to register a target 384 and address under more than one service URL; one for (identity1) and 385 one for (identity2). 387 Since service URLs must be unique, (identity1) and (identity2) must 388 each be registered under its own unique service URL. 390 For systems that support the configuration of multiple identities to 391 access a target, the service URL must contain an additional, opaque 392 string defining the identity. This appears after the iSCSI name in 393 the URL string, and is separated by a "/". Each registered (target- 394 address, target-name, initiator-identity) tuple can then register its 395 own set of auth-xxxx attributes. 397 4.1.3. Using SLP in a Non-Multicast Environment 399 In some networks, the use of multicast for discovery purposes is 400 either unavailable or not allowed. Such networks include public or 401 service-provider networks that are placed in between an iSCSI client 402 and server; these are probably most common between two iSCSI 403 gateways, one at a storage service provider site, and one at a 404 customer site. 406 In these networks, an initiator may, instead or in addition to its DA 407 configuration, allow the addresses of one or more SAs to be 408 configured. The initiator would then make unicast SLP service 409 requests directly to these SAs, without the use of multicast to first 410 discover them. 412 This functionality is well within the scope of the current SLP 413 protocol. The main consequence for implementors is that an initiator 414 configured to make direct, unicast requests to an SA will have to add 415 this to the SLP API, if it is following the service location API 416 defined in [RFC2614]. This capability is being added to the next 417 revision of the API, in [2614BIS]. 419 4.2. Discovering Storage Management Services using SLP 421 Storage management servers can be built to manage and control access 422 to targets in a variety of ways. They can also provide extended 423 services beyond discovery, which could include storage allocation and 424 management. None of these services are defined here; the intent of 425 this document is to allow these services to be discovered by both 426 clients and servers, in addition to the target discovery already 427 being performed. 429 The following drawing shows an iSCSI client, an iSCSI server, and a 430 storage management server. To simplify the drawing, the second IP 431 network is not shown, but is assumed to exist. The storage 432 management server would use its own protocol (smsp) to provide 433 capabilities to iSCSI clients and servers; these clients and servers 434 can both use SLP to discover the storage management server. 436 +---------------------------+ 437 | iSCSI Client | 438 | | 439 | +-----------+ | 440 | | iSCSI | | 441 | | initiator | | 442 | +-----------+ | 443 | | 444 +---------------+------+----+ +------------+ 445 | iSCSI Driver | smsp | UA | | SLP DA | 446 +---------------+------+----+ | | 447 | TCP/UDP/IP | | (optional) | 448 +---------------+------+----+ +------------+ 449 | | 450 | IP Network | 451 ------------------------------------------ 452 | | 453 | | 454 +---------------+-----------+ +---------------------+ 455 | TCP/UDP/IP | | TCP/UDP/IP | 456 +---------------+------+----+ +---------------------+ 457 | iSCSI Driver | smsp | UA | | SA | smsp | 458 +---------------+------+----+ +---------------------+ 459 | | | | 460 | +--------+ +--------+ | | storage mgmt server | 461 | | iSCSI | | iSCSI | | | | 462 | | target | | target | | +---------------------+ 463 | | 1 | | 2 | | 464 | +--------+ +--------+ | 465 | | 466 | iSCSI Server | 467 +---------------------------+ 469 Note the difference between the storage management server model and 470 the previously-defined target discovery model. When target discovery 471 was used, the iSCSI Server implemented an SA, to be discovered by the 472 initiator's UA. In the storage management server model, the iSCSI 473 clients and servers both implement UAs, and the management server 474 implements the SA. 476 A storage management server's URL contains the domain name or IP 477 address and TCP or UDP port number. No other information is 478 required. 480 The storage management server constructs a service advertisement of 481 the type "service:iscsi:sms" for each of the addresses at which it 482 appears. The advertisement contains the URL, a lifetime, along with 483 other attributes which are defined in the service template. 485 The remainder of the discovery procedure is identical to that used to 486 discover iSCSI targets, except that both initiators and targets would 487 normally be "clients" of the storage management service. 489 Targets that support a storage management service implement a UA in 490 addition to the SA. A target may alternatively just implement the 491 UA, and allow the storage management service to advertise its targets 492 appropriately by providing an SA and registering the appropriate 493 service:iscsi:target registrations on the target's behalf; the target 494 device would not have to advertise its own targets. This has no 495 impact on the initiator. 497 This allows the initiators' discovery of targets to be completely 498 interoperable regardless of which storage management service is used, 499 or whether one is used at all, or whether the target registrations 500 are provided directly by the target or by the management service. 502 4.3. Internationalization Considerations 504 SLP allows internationalized strings to be registered and retrieved. 505 Attributes in the template that are not marked with an 'L' (literal) 506 will be registered in a localized manner. An "en" (English) 507 localization MUST be registered, and others MAY be registered. 509 Attributes that include non-ASCII characters will be encoded using 510 UTF-8, as discussed in [RFC3722] and [RFC3491]. 512 5. iSCSI SLP Templates 514 Three templates are provided: an iSCSI target template, a management 515 service template, and an abstract template to encapsulate the two. 517 5.1. The iSCSI Abstract Service Type Template 519 This template defines the abstract service "service:iscsi". It is 520 used as a top-level service to encapsulate all other iSCSI-related 521 services. 523 Name of submitter: Mark Bakke 524 Language of service template: en 525 Security Considerations: see section 6. 527 Template Text: 528 -------------------------template begins here----------------------- 529 template-type=iscsi 530 template-version=0.1 532 template-description= 533 This is an abstract service type. The purpose of the iscsi 534 service type is to encompass all of the services used to support 535 the iSCSI protocol. 537 template-url-syntax= 538 url-path= ; Depends on the concrete service type. 540 --------------------------template ends here------------------------ 542 5.2. The iSCSI Target Concrete Service Type Template 544 This template defines the service "service:iscsi:target". An entity 545 containing iSCSI targets that wishes them discovered via SLP would 546 register each of them, with each of their addresses, as this service 547 type. 549 Initiators (and perhaps management services) wishing to discover 550 targets in this way will generally use one of the following queries: 552 1. Find a specific target, given its iSCSI Target Name: 554 Service: service:iscsi:target 555 Scope: initiator-scope-list 556 Query: (iscsi-name=iqn.2001-04.com.example.sn.456) 558 2. Find all of the iSCSI Target Names that may allow access to a 559 given initiator: 561 Service: service:iscsi:target 562 Scope: initiator-scope-list 563 Query: (auth-name=iqn.1998-03.com.example.hostid.045A7B) 565 3. Find all of the iSCSI Target Names that may allow access to 566 any initiator: 568 Service: service:iscsi:target 569 Scope: initiator-scope-list 570 Query: (auth-name=any) 572 4. Find all of the iSCSI Target Names that may allow access to 573 this initiator, or that will allow access to any initiator: 575 Service: service:iscsi:target 576 Scope: initiator-scope-list 577 Query: &(auth-name=iqn.1998-03.com.example.hostid.045A7B) 578 (auth-name=any) 580 5. Find all of the iSCSI Target Names that may allow access to 581 a given CHAP user name: 583 Service: service:iscsi:target 584 Scope: initiator-scope-list 585 Query: (auth-cred=chap/my-user-name) 587 6. Find all of the iSCSI Target Names that may allow access to 588 a given initiator that supports two IP addresses, a CHAP 589 credential and an SRP credential, and an initiator name: 591 Service: service:iscsi:target 592 Scope: initiator-scope-list 593 Query: &(|(auth-name=iqn.com.example:host47)(auth-name=any) 594 |(auth-addr=192.0.2.3)(auth-addr=192.0.2.131)(auth-addr=any) 595 |(auth-cred=chap/foo)(auth-cred=srp/my-user-name) 596 (auth-cred=any)) 598 7. Find the iSCSI Target Names from which the given initiator is 599 allowed to boot: 601 Service: service:iscsi:target 602 Scope: initiator-scope-list 603 Query: (boot-list=iqn.1998-03.com.example.hostid.045A7B) 605 8. In addition, a management service may wish to discover all 606 targets: 608 Service: service:iscsi:target 609 Scope: management-server-scope-list 610 Query: 612 More details on booting from an iSCSI target are defined in [BOOT]. 614 Name of submitter: Mark Bakke 615 Language of service template: en 616 Security Considerations: see section 6. 618 Template Text: 619 -------------------------template begins here----------------------- 620 template-type=iscsi:target 622 template-version=0.1 624 template-description= 625 This is a concrete service type. The iscsi:target service type is 626 used to register individual target addresses to be discovered by 627 others. UAs will generally search for these by including one of 628 the following: 630 - the iSCSI target name 631 - iSCSI initiator identifiers (iSCSI name, credential, IP address) 632 - the service URL 634 template-url-syntax= 635 url-path = hostport "/" iscsi-name [ "/" identity ] 636 hostport = host [ ":" port ] 637 host = hostname / hostnumber ; DNS name or IP address 638 hostname = *( domainlabel "." ) toplabel 639 alphanum = ALPHA / DIGIT 640 domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum 641 toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum 642 hostnumber = ipv4-number / ipv6-addr ; IPv4 or IPv6 address 643 ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) 644 ipv6-addr = "[" ipv6-number "]" 645 ipv6-number = 6( h16 ":" ) ls32 646 / "::" 5( h16 ":" ) ls32 647 / [ h16 ] "::" 4( h16 ":" ) ls32 648 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 649 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 650 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 651 / [ *4( h16 ":" ) h16 ] "::" ls32 652 / [ *5( h16 ":" ) h16 ] "::" h16 653 / [ *6( h16 ":" ) h16 ] "::" 654 ls32 = ( h16 ":" h16 ) / ipv4-number 655 ; least-significant 32 bits of ipv6 address 656 h16 = 1*4HEXDIG 657 port = 1*DIGIT 658 iscsi-name = iscsi-char ; iSCSI target name 659 identity = iscsi-char ; optional identity string 660 iscsi-char = ALPHA / DIGIT / escaped / ":" / "-" / "." 661 ; Intended to allow UTF-8 encoded strings 662 escaped = 1*(`' HEXDIG HEXDIG) 663 ; 664 ; The iscsi-name part of the URL is required and must be the iSCSI 665 ; name of the target being registered. 666 ; A device representing multiple targets must individually 667 ; register each target/address combination with SLP. 668 ; The identity part of the URL is optional, and is used to 669 ; indicate an identity that is allowed to access this target. 670 ; 671 ; Example (split into two lines for clarity): 672 ; service:iscsi:target://192.0.2.3:3260/ 673 ; iqn.2001-04.com.example.sn.45678 674 ; 675 ; IPv6 addresses are also supported; they use the notation specified 676 ; above and in [RFC3513], section 2.2 678 iscsi-name = string 679 # The iSCSI Name of this target. 680 # This must match the iscsi-name in the url-path. 682 portal-group = integer 683 # The iSCSI portal group tag for this address. Addresses sharing 684 # the same iscsi-name and portal-group tag can be used within the 685 # same iSCSI session. Portal groups are described in [RFC3720]. 687 transports = string M L 688 tcp 689 # This is a list of transport protocols that the registered 690 # entity supports. iSCSI is currently supported over TCP, 691 # but it is anticipated that it could be supported over other 692 # transports, such as SCTP, in the future. 693 tcp 695 mgmt-entity = string O 696 # The fully qualified domain name, or IP address in dotted-decimal 697 # notation, of the management interface of the entity containing 698 # this target. 699 # 701 alias = string O 702 # The alias string contains a descriptive name of the target. 704 auth-name = string M X 705 # A list of iSCSI Initiator Names that can access this target. 706 # Normal iSCSI names will be 80 characters or less; max length 707 # is 255. 708 # Normally, only one or a few values will be in the list. 709 # Using the equivalence search on this will evaluate to "true" 710 # if any one of the items in this list matches the query. 711 # If this list contains the default name "any", any initiator 712 # is allowed to access this target, provided it matches the 713 # other auth-xxx attributes. 714 # 715 # This attribute contains security policy information. If this 716 # attribute is distributed via an Attribute Reply message, 717 # IPsec MUST be implemented. 719 auth-addr = string M X 720 # A list of initiator IP addresses (or host names) which will 721 # be allowed access to this target. If this list contains the 722 # default name "any", any IP address is allowed access to this 723 # target, provided it matches the other auth-xxx attributes. 724 # 725 # This attribute contains security policy information. If this 726 # attribute is distributed via an Attribute Reply message, 727 # IPsec MUST be implemented. 729 auth-cred = string M X 730 # A list of credentials which will be allowed access to the target 731 # (provided they can provide the correct password or other 732 # authenticator). Entries in this list are of the form 733 # "method/identifier", where the currently defined methods are 734 # "chap" and "srp", both of which take usernames as their 735 # identifiers. 736 # 737 # This attribute contains security policy information. If this 738 # attribute is distributed via an Attribute Reply message, 739 # IPsec MUST be implemented. 741 boot-list = string M O 742 # A list of iSCSI Initiator Names that can boot from this target. 743 # This list works precisely like the auth-name attribute. A name 744 # appearing in this list must either appear in the access-list, 745 # or the access-list must contain the initiator name "iscsi". 746 # Otherwise, an initiator will be unable to find its boot target. 747 # If boot-list contains the name "iscsi", any host can boot from it, 748 # but I am not sure if this is useful to anyone. 749 # If this attribute is not registered, this target is not "bootable". 750 # 751 # Note that the LUN the host boots from is not specified here; a 752 # host will generally attempt to boot from LUN 0. 753 # 754 # It is quite possible that other attributes will need to be defined 755 # here for booting as well. 756 # 757 # This attribute contains security policy information. If this 758 # attribute is distributed via an Attribute Reply message, 759 # IPsec MUST be implemented. 761 --------------------------template ends here------------------------ 763 5.3. iSCSI Storage Management Service Templates 765 This template defines the service "service:iscsi:sms". An entity 766 supporting one or more iSCSI management service protocols may 767 register itself with SLP as this service type. 769 iSCSI clients and servers wishing to discover storage management 770 services using SLP will usually search for them by the protocol(s) 771 they support: 773 Service: service:iscsi:sms 774 Scope: initiator-scope-list 775 Query: (protocols=isns) 777 Name of submitter: Mark Bakke 778 Language of service template: en 779 Security Considerations: see section 6. 781 Template Text: 782 -------------------------template begins here----------------------- 783 template-type=iscsi:sms 785 template-version=0.1 787 template-description= 788 This is a concrete service type. The iscsi:sms service type 789 provides the capability for entities supporting iSCSI to discover 790 appropriate management services. 792 template-url-syntax= 793 url-path = ; The URL of the management service [RFC2608]. 795 protocols = string M 796 # The list of protocols supported by this name service. This 797 # list may be expanded in the future. There is no default. 798 # 799 # "isns" - This management service supports the use of the iSNS 800 # protocol for access management, health monitoring, and 801 # discovery management services. This protocol is defined 802 # in [ISNS]. 803 isns 805 transports = string M L 806 tcp 807 # This is a list of transport protocols that the registered 808 # entity supports. 809 tcp, udp 811 server-priority = integer 812 # The priority a client should give this server, when choosing 813 # between multiple servers with the same protocol type. 814 # When multiple servers are discovered for a given protocol type, 815 # this parameter indicates their relative precedence. Server 816 # precedence is protocol-specific; for some protocols, the primary 817 # server may have the highest server-priority value, while for 818 # others it may have the lowest. For example, with iSNS, the primary 819 # server has the lowest value (value 0). 821 --------------------------template ends here------------------------ 823 6. Security Considerations 825 The SLPv2 security model as specified in [RFC2608] does not provide 826 confidentiality, but does provide an authentication mechanism for UAs 827 to assure that service advertisements only come from trusted SAs with 828 the exception that it does not provide a mechanism to authenticate 829 "zero-result responses". See [RFC3723] for a discussion of the SLPv2 830 [RFC2608] security model. 832 Once a target or management server is discovered, authentication and 833 authorization are handled by the iSCSI protocol, or by the management 834 server's protocol. It is the responsibility of the providers of 835 these services to ensure that an inappropriately advertised or 836 discovered service does not compromise their security. 838 When no security is used for SLPv2, there is a risk of distribution 839 of false discovery information. The primary countermeasure for this 840 risk is authentication. When this risk is a significant concern, 841 IPsec SAs and iSCSI in-band authentication SHOULD be used for iSCSI 842 traffic subject to this risk to ensure that iSCSI traffic only flows 843 between endpoints that have participated in IKE authentication and 844 iSCSI in-band authentication. For example, if an attacker 845 distributes discovery information falsely claiming that it is an 846 iSCSI target, it will lack the secret information necessary to 847 successfully complete IKE authentication or iSCSI in-band 848 authentication, and hence will be prevented from falsely sending or 849 receiving iSCSI traffic. 851 There remains a risk of a denial of service attack based on repeated 852 use of false discovery information that will cause initiation of IKE 853 negotiation. The countermeasures for this are administrative 854 configuration of each iSCSI Target to limit the peers that it is 855 willing to communicate with (i.e., by IP address range and/or DNS 856 domain), and maintenance of a negative authentication cache to avoid 857 repeatedly contacting an iSCSI Target that fails to authenticate. 858 These three measures (i.e., IP address range limits, DNS domain 859 limits, negative authentication cache) MUST be implemented. 861 The auth-name, auth-addr, auth-cred, and boot-list attributes 862 comprise security policy information. When these are distributed, 863 IPsec MUST be implemented. 865 6.1. Security Implementation 867 Security for SLPv2 in an IP storage environment is specified in 868 [RFC3723]. 870 IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this 871 includes ESP with a non-null transform to provide both authentication 872 and confidentiality. 874 When SLPv2 can be used to distribute auth-name, auth-addr, auth-cred, 875 boot-list information (see Section 5.2 above), IPsec MUST be 876 implemented, as these items are considered to be sensitive security 877 policy information. If IPsec is not implemented, auth-name, auth- 878 addr, auth-cred, and boot-list information MUST NOT be distributed 879 via SLPv2, and MUST NOT be used if discovered via SLPv2. 881 SLPv2 authentication is OPTIONAL to implement and use, and SLPv2 882 authentication SHOULD be implemented when IPsec is not supported. 884 7. IANA Considerations 886 This document describes three SLP Templates. When they have been 887 reviewed and approved by the IESG, they should be registered in the 888 IANA "SVRLOC Templates" registry. This process is described in the 889 IANA Considerations section of [RFC2609]. 891 8. Summary 893 This document describes how SLP can be used by iSCSI initiators to 894 find iSCSI targets and storage management servers. Service type 895 templates for iSCSI targets and storage management servers are 896 presented. 898 9. Normative References 900 [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service 901 Location Protocol, version 2", RFC 2608, June 1999. 903 [RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates 904 and service: Schemes", RFC 2609, June 1999. 906 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 907 Requirement Levels", RFC 2119, March 1997. 909 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 910 for Internationalized Domain Names", RFC 3491, March 2003. 912 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 913 (IPv6) Addressing Architecture", RFC 3513, April 2003. 915 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M. and 916 E. Zeidner, "Internet Small Computer Systems Interface 917 (iSCSI)", RFC 3720, March 2004. 919 [RFC3722] Bakke, M., "String Profile for iSCSI Names", RFC 3722, 920 March 2004. 922 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. 923 Travostino, "Securing Block Storage Protocols over IP", RFC 924 3723, March 2004. 926 10. Informative References 928 [RFC2614] Kempf, J. and E. Guttman, "An API for Service Location", 929 RFC 2614, June 1999. 931 [2614BIS] Kempf, J. and E. Guttman, "An API for Service Location", 932 draft-kempf-svrloc-rfc2614bis-00.txt, February 2002. 934 [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. 936 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. 937 Krueger, "Internet Small Computer Systems Interface (iSCSI) 938 Naming and Discovery", RFC 3721, March 2004. 940 [ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and J. 941 Souza, "Internet Storage Name Service", Work in Progress, 942 draft-ietf-ips-isns-22.txt, February 2004. 944 [BOOT] Sarkar, P., Missimer, D. and C. Sapuntzakis, "A Standard 945 for Bootstrapping Clients using the iSCSI Protocol", Work in 946 Progress, draft-ietf-ips-iscsi-boot-12.txt, March 2004. 948 [RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with 949 SLP", RFC 3105, October 2001. 951 11. Authors' Addresses 953 Mark Bakke 954 Cisco Systems, Inc. 955 6450 Wedgwood Road 956 Maple Grove, MN 55311 957 Voice: +1 763-398-1000 958 EMail: mbakke@cisco.com 960 Kaladhar Voruganti 961 IBM Almaden Research Center 962 650 Harry Road 963 San Jose, CA 95120 964 Email: kaladhar@us.ibm.com 966 John L. Hufferd 967 IBM Storage Systems Group 968 5600 Cottle Road 969 San Jose, CA 95193 970 Voice: +1 408 256-0403 971 Email: hufferd@us.ibm.com 973 Marjorie Krueger 974 Hewlett-Packard Corporation 975 8000 Foothills Blvd 976 Roseville, CA 95747-5668, USA 977 Voice: +1 916 785-2656 978 Email: marjorie_krueger@hp.com 980 Todd Sperry 981 Adaptec, Inc. 982 691 South Milpitas Boulevard 983 Milpitas, Ca. 95035 984 Voice: +1 408 957-4980 985 Email: todd_sperry@adaptec.com 987 12. Full Copyright Notice 989 Copyright (C) The Internet Society (2004). All Rights Reserved. 991 This document and translations of it may be copied and furnished to 992 others, and derivative works that comment on or otherwise explain it 993 or assist in its implementation may be prepared, copied, published 994 and distributed, in whole or in part, without restriction of any 995 kind, provided that the above copyright notice and this paragraph are 996 included on all such copies and derivative works. However, this 997 document itself may not be modified in any way, such as by removing 998 the copyright notice or references to the Internet Society or other 999 Internet organizations, except as needed for the purpose of 1000 developing Internet standards in which case the procedures for 1001 copyrights defined in the Internet Standards process must be 1002 followed, or as required to translate it into languages other than 1003 English. 1005 The limited permissions granted above are perpetual and will not be 1006 revoked by the Internet Society or its successors or assigns. 1008 This document and the information contained herein is provided on an 1009 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1010 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1011 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1012 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1013 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1015 Acknowledgement 1017 Funding for the RFC Editor function is currently provided by the 1018 Internet Society.