idnits 2.17.1 draft-ietf-ips-iscsi-slp-08.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 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 (October 2004) is 7126 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 3720 (Obsoleted by RFC 7143) == Outdated reference: A later version (-01) exists of draft-kempf-svrloc-rfc2614bis-00 == Outdated reference: A later version (-08) exists of draft-ietf-ips-auth-mib-04 -- Obsolete informational reference (is this intentional?): RFC 3491 (Obsoleted by RFC 5891) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Mark Bakke 3 Cisco 4 Expires October 2004 5 John Hufferd 6 Kaladhar Voruganti 7 IBM 9 Marjorie Krueger 10 HP 12 Todd Sperry 13 Adaptec 15 April 2004 17 Finding iSCSI Targets and Name Servers Using SLP 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet- Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 The iSCSI protocol provides a way for hosts to access SCSI devices 47 over an IP network. This document defines the use of the Service 48 Location Protocol (SLP) by iSCSI hosts, devices, and management 49 services, along with the SLP service type templates that describe the 50 services they provide. 52 Acknowledgements 54 This draft was produced by the iSCSI Naming and Discovery team, 55 including Joe Czap, Jim Hafner, John Hufferd, and Kaladhar Voruganti 56 (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (Sanrad), 57 Marjorie Krueger (HP), Lawrence Lamers (San Valley), Todd Sperry 58 (Adaptec), and Joshua Tseng (Nishan). Thanks also to Julian Satran 59 (IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt 60 Peterson (Caldera) and James Kempf (Sun) for reviewing the document 61 from an SLP perspective. 63 Table of Contents 65 1. Introduction.................................................2 66 2. Notation Conventions.........................................3 67 3. Terminology..................................................3 68 4. Using SLP for iSCSI Service Discovery........................4 69 5. iSCSI SLP Templates.........................................13 70 6. Security Considerations.....................................19 71 7. IANA Considerations.........................................20 72 8. Summary.....................................................20 73 9. Normative References........................................20 74 10. Informative References......................................21 75 11. Authors' Addresses..........................................22 76 12. Full Copyright Notice.......................................22 78 1. Introduction 80 iSCSI [RFC3720] is a protocol used to transport SCSI [SAM2] commands, 81 data, and status across an IP network. This protocol is connection- 82 oriented, and is currently defined over TCP. iSCSI uses a client- 83 server relationship. The client end of the connection is an 84 initiator, and sends SCSI commands; the server end of the connection 85 is called a target, and receives and executes the commands. 87 There are several methods an iSCSI initiator can use to find the 88 targets to which it should connect. Two of these methods can be 89 accomplished without the use of SLP: 91 - Each target and its address can be statically configured on the 92 initiator. 94 - Each address providing targets can be configured on the initiator; 95 iSCSI provides a mechanism by which the initiator can query the 96 address for a list of targets. 98 The above methods are further defined in "iSCSI Naming and Discovery 99 Requirements" [RFC3721]. 101 Each of the above methods requires a small amount of configuration to 102 be done on each initiator. The ability to discover targets and name 103 services without having to configure initiators is a desirable 104 feature. The Service Location Protocol (SLP) [RFC2608] is an IETF 105 standards track protocol that provides several features that will 106 simplify locating iSCSI services. This document describes how SLP 107 can be used in iSCSI environments to discover targets, addresses 108 providing targets, and storage management servers. 110 2. Notation Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 3. Terminology 118 Here are some definitions that may aid readers that are unfamiliar 119 with either SLP, SCSI, or iSCSI. Some of these definitions have been 120 reproduced from [RFC2608] and "Finding an RSIP Server with SLP" 121 [RFC3105]. 123 User Agent (UA) A process working on the client's behalf 124 to establish contact with some service. 125 The UA retrieves service information from 126 the Service Agents or Directory Agents. 128 Service Agent (SA) A process working on behalf of one or more 129 services to advertise the services and 130 their capabilities. 132 Directory Agent (DA) A process which collects service 133 advertisements. There can only be one DA 134 present per given host. 136 Scope A named set of services, typically making 137 up a logical administrative group. 139 Service Advertisement A URL, attributes, and a lifetime 140 (indicating how long the advertisement is 141 valid), providing service access 142 information and capabilities description 143 for a particular service. 145 Initiator A logical entity, typically within a host, 146 that sends SCSI commands to targets to be 147 executed. An initiator is usually present 148 in the form of a device driver. 150 Target A logical entity, typically within a 151 storage controller or gateway, that 152 receives SCSI commands from an initiator 153 and executes them. A target includes one 154 or more Logical Units (LUs); each LU is a 155 SCSI device, such as a disk or tape drive. 157 iSCSI Name A UTF-8 character string which serves as a 158 unique identifier for iSCSI initiators and 159 targets. Its format and usage is further 160 defined in [RFC3721]. 162 iSCSI Client A logical entity, typically a host, which 163 includes at least one iSCSI Initiator. 165 iSCSI Server A logical entity, typically a storage 166 controller or gateway, which includes at 167 least one iSCSI Target. 169 Storage Management Server An addressable entity that provides 170 management services that benefit an iSCSI 171 environment. "Storage management server" 172 is used as a generic term, rather than a 173 specific protocol or service. 175 4. Using SLP for iSCSI Service Discovery 177 Two entities are involved in iSCSI discovery. The end result is that 178 an iSCSI initiator (e.g. a host) discovers iSCSI targets, usually 179 provided by storage controllers or gateways. 181 iSCSI targets are registered with SLP as a set of service URLs, one 182 for each address on which the target may be accessed. Initiators 183 discover these targets using SLP service requests. Targets that do 184 not directly support SLP, or are under the control of a management 185 service, may be registered by a proxy service agent as part of the 186 software providing this service. 188 iSCSI entities may also use SLP to discover higher-level management 189 services where needed. 191 This section first describes the use of SLP for discovery of targets 192 by iSCSI initiators, and then describes the use of SLP to discover 193 storage management servers. 195 This document assumes that SLPv2 will be used when discovering iSCSI- 196 related services; no attempt is made to include support for SLPv1. 198 4.1. Discovering iSCSI Targets using SLP 200 The following diagram shows the relationship between iSCSI clients, 201 servers, initiators, and targets. An iSCSI client includes at least 202 one iSCSI initiator, and an SLP user agent (UA). An iSCSI server 203 includes at least one iSCSI target, and an SLP service agent (SA). 204 Some entities, such as extended copy engines, include both initiators 205 and targets. These include both an SA, for its targets to be 206 discovered, and a UA, for its initiator(s) to discover other targets. 208 +---------------------------------+ 209 | iSCSI Client | 210 | +-----------+ | 211 | | iSCSI | | 212 | | initiator | | 213 | | "myhost" | | 214 | +-----------+ | 215 | | 216 +--------------------------+------+ 217 | iSCSI Driver | UA | 218 +--------------------------+------+ 219 | TCP/UDP/IP | 220 +----------------+----------------+ 221 | Interface 1 | Interface 2 | 222 +----------------+----------------+ 223 | | 224 +------------+ | | +------------+ 225 | SLP DA | | | | SLP DA | 226 | (optional) |----+ IP Networks +----| (optional) | 227 +------------+ | | +------------+ 228 | | 229 +-----------------+-----------------| 230 | Interface 1 | Interface 2 | 231 | 192.0.2.131 | 192.0.2.3 | 232 +-----------------+-----------------+ 233 | TCP/UDP/IP | 234 +---------------------------+-------+ 235 | iSCSI Driver | SA | 236 +---------------------------+-------| 237 | | 238 | +--------+ +--------+ +---------+ | 239 | | iSCSI | | iSCSI | | iSCSI | | 240 | | target | | target | | target | | 241 | | "one" | | "two" | | "three" | | 242 | +--------+ +--------+ +---------+ | 243 | iSCSI Server | 244 +-----------------------------------+ 246 In the above drawing, the iSCSI server has three iSCSI targets that 247 the client could discover, named "one", "two" and "three". The iSCSI 248 client has an iSCSI initiator with the name "myhost". The iSCSI 249 client may use the initiator name in its SLP Service Requests as a 250 filter to discover only targets that are configured to accept iSCSI 251 connections from "myhost". 253 Each iSCSI target and initiator has a unique name, called an iSCSI 254 Name. This identifier is the same regardless of the network path 255 (through adapter cards, networks, interfaces on the storage device) 256 over which the target is discovered and accessed. For this example, 257 the iSCSI names "one" and "two", and "three" are used for the 258 targets; the initiator uses the name "myhost". An actual iSCSI name 259 would incorporate more structure, including a naming authority, and 260 is not described here. 262 Each of the iSCSI targets in the drawing can appear at two addresses, 263 since two network interfaces are present. Each target, would have 264 two service URLs. 266 An iSCSI target URL consists of its fully qualified host name or IP 267 address, the TCP port on which it is listening, and its iSCSI name. 268 An iSCSI server must register each of its individual targets at each 269 of its network addresses. 271 The iSCSI server constructs a service advertisement of the type 272 "service:iscsi:target" for each of the service URLs it wishes to 273 register. The advertisement contains a lifetime, along with other 274 attributes which are defined in the service template. 276 If the server in the above drawing is listening at TCP port 3260 for 277 both network addresses, the service URLs registered would be: 279 - 192.0.2.131:3260/one 281 - 192.0.2.131:3260/two 283 - 192.0.2.131:3260/three 285 - 192.0.2.3:3260/one 287 - 192.0.2.3:3260/two 289 - 192.0.2.3:3260/three 291 The remainder of the discovery procedure is identical to that used by 292 any client/server pair implementing SLP: 294 1. If an SLP DA is found, the SA contacts the DA and registers 295 the service advertisement. Whether or not one or more SLPv2 296 DAs are discovered, the SA maintains the advertisement itself 297 and answers multicast UA queries directly. 299 2. When the iSCSI initiator requires contact information for an 300 iSCSI target, the UA either contacts the DA using unicast or 301 the SA using multicast. If a UA is configured with the address 302 of the SA, it may avoid multicast and contact an SA using 303 unicast. The UA includes a query based on 304 the attributes to indicate the characteristics of the 305 target(s) it requires. 307 3. Once the UA has the host name or address of the iSCSI server 308 as well as the port number and iSCSI Target Name, it can begin the 309 normal iSCSI login to the target. 311 As information contained in the iSCSI target template may exceed 312 common network datagram sizes, the SLP implementation for both UAs 313 and SAs supporting this template MUST implement SLP over TCP. 315 4.1.1. Finding Targets Based on Initiator Credentials 317 To be allowed access to an iSCSI target, an initiator must be 318 authenticated. The initiator may be required by the target to 319 produce one or more of the following credentials: 321 - An iSCSI Initiator Name 323 - An IP address 325 - A CHAP, SRP, or Kerberos credential 327 - Any combination of the above 329 Most iSCSI targets allow access to only one or two initiators. In 330 the ideal discovery scenario, an initiator would send an SLP request, 331 and receive responses ONLY for those targets to which the initiator 332 is guaranteed a successful login. To achieve this goal, the iSCSI 333 target template contains the following attributes, each of which 334 allows a list of values: 336 1. auth-name - This attribute contains the list of initiator names 337 allowed to access this target, or the value "any", indicating 338 that no specific initiator name is required. 340 2. auth-addr - This attribute contains the list of host names 341 and/or IP addresses which will be allowed access to this target, 342 or the value "any", indicating that no specific address or 343 host name is required. If a large number of addresses is to 344 be allowed (perhaps a subnet), this attribute may contain the 345 value "any". 347 3. auth-cred - This attribute contains a list of "method/identifier" 348 credentials that will be allowed access to the target, provided 349 they can produce the correct password or other verifier during 350 the login process. If no specific credentials are required, the 351 value "any" is used. 353 The above identifiers follow the semantics described in the IP 354 Storage Authentication MIB [AUTH-MIB]. Examples showing initiator 355 searches based on auth-xxxx attributes are shown in the target- 356 specific template section below. 358 Also note that the auth-xxxx attributes are considered to be security 359 policy information. If these attributes are distributed, IPsec MUST 360 be implemented as specified in the Security Implementation section 361 below. 363 4.1.2. Supporting Access by Multiple Identities to the Same Target 365 If a target is to allow access to multiple host identities, more than 366 one combination of auth-xxxx attributes will need to be present. 367 Since service URLs must be unique, each of these must be registered 368 under its own service URL. 370 For systems that support the configuration of multiple identities to 371 access a target, the service URL must contain an additional, opaque 372 string defining the identity. This appears after the iSCSI name in 373 the URL string, and is separated by a "/". Each registered (target- 374 address, target-name, initiator-identity) tuple can then register its 375 own set of auth-xxxx attributes. 377 An initiator-identity is equivalent to the authentication identity 378 defined in [AUTH-MIB]. 380 4.1.3. Using SLP in a Non-Multicast Environment 382 In some networks, the use of multicast for discovery purposes is 383 either unavailable or not allowed. Such networks include public or 384 service-provider networks that are placed in between an iSCSI client 385 and server; these are probably most common between two iSCSI 386 gateways, one at a storage service provider site, and one at a 387 customer site. 389 In these networks, an initiator may, instead or in addition to its DA 390 configuration, allow the addresses of one or more SAs to be 391 configured. The initiator would then make unicast SLP service 392 requests directly to these SAs, without the use of multicast to first 393 discover them. 395 This functionality is well within the scope of the current SLP 396 protocol. However, it does have two consequences for implementors: 398 - A service-agent responding to requests for iSCSI targets MUST 399 implement SLP over TCP; UDP only is not enough. This is not 400 an issue, since TCP is a requirement for iSCSI implementations 401 that use SLP for other reasons. 403 - An initiator configured to make direct, unicast requests to an 404 SA will have to add this to the SLP API, if it is following the 405 service location API defined in [RFC2614]. This capability 406 is being added to the next revision of the API, in [2614BIS]. 408 4.2. Discovering Storage Management Services using SLP 410 Storage management servers can be built to manage and control access 411 to targets in a variety of ways. They can also provide extended 412 services beyond discovery, which could include storage allocation and 413 management. None of these services are defined here; the intent of 414 this document is to allow these services to be discovered by both 415 clients and servers, in addition to the target discovery already 416 being performed. 418 The following drawing shows an iSCSI client, an iSCSI server, and a 419 storage management server. To simplify the drawing, the second IP 420 network is not shown, but is assumed to exist. The storage 421 management server would use its own protocol (smsp) to provide 422 capabilities to iSCSI clients and servers; these clients and servers 423 can both use SLP to discover the storage management server. 425 +---------------------------+ 426 | iSCSI Client | 427 | | 428 | +-----------+ | 429 | | iSCSI | | 430 | | initiator | | 431 | +-----------+ | 432 | | 433 +---------------+------+----+ +------------+ 434 | iSCSI Driver | smsp | UA | | SLP DA | 435 +---------------+------+----+ | | 436 | TCP/UDP/IP | | (optional) | 437 +---------------+------+----+ +------------+ 438 | | 439 | IP Network | 440 ------------------------------------------ 441 | | 442 | | 443 +---------------+-----------+ +---------------------+ 444 | TCP/UDP/IP | | TCP/UDP/IP | 445 +---------------+------+----+ +---------------------+ 446 | iSCSI Driver | smsp | UA | | SA | smsp | 447 +---------------+------+----+ +---------------------+ 448 | | | | 449 | +--------+ +--------+ | | storage mgmt server | 450 | | iSCSI | | iSCSI | | | | 451 | | target | | target | | +---------------------+ 452 | | 1 | | 2 | | 453 | +--------+ +--------+ | 454 | | 455 | iSCSI Server | 456 +---------------------------+ 458 Note the difference between the storage management server model and 459 the previously-defined target discovery model. When target discovery 460 was used, the iSCSI Server implemented an SA, to be discovered by the 461 initiator's UA. In the storage management server model, the iSCSI 462 clients and servers both implement UAs, and the management server 463 implements the SA. 465 A storage management server's URL contains the domain name or IP 466 address and TCP or UDP port number. No other information is 467 required. 469 The storage management server constructs a service advertisement of 470 the type "service:iscsi:sms" for each of the addresses at which it 471 appears. The advertisement contains the URL, a lifetime, along with 472 other attributes which are defined in the service template. 474 The remainder of the discovery procedure is identical to that used to 475 discover iSCSI targets, except that both initiators and targets would 476 normally be "clients" of the storage management service. 478 Targets that support a storage management service implement a UA in 479 addition to the SA. A target may alternatively just implement the 480 UA, and allow the storage management service to advertise its targets 481 appropriately by providing an SA and registering the appropriate 482 service:iscsi:target registrations on the target's behalf; the target 483 device would not have to advertise its own targets. This has no 484 impact on the initiator. 486 This allows the initiators' discovery of targets to be completely 487 interoperable regardless of which storage management service is used, 488 or whether one is used at all, or whether the target registrations 489 are provided directly by the target or by the management service. 491 4.3. NAT and NAPT Considerations 493 Since SLP provides IP address and TCP port information within its 494 payload, the addresses an SA or DA advertise may not be the same as 495 those a UA must use if a Network Address(/Port) Translation 496 (NAT/NAPT) device is present between the UA and the SA. This may 497 result in the UA discovering address information that is unusable. 498 Also note that SLP advertisements that occur inside a private address 499 realm may be unreachable outside that realm. Below are some 500 recommendations for dealing with SLPv2 and NAT/NAPT devices: 502 - A fully-qualified domain name (i.e. not an IP address) SHOULD be 503 used in service URLs, the mgmt-entity attribute, and the auth-addr 504 attribute [RFC1900]. 506 - Configure the NAPT device to provide default mapping(s) for the 507 well-known port(s) and use the default IANA-assigned iSCSI TCP port 508 number in service URLs, when possible. 510 4.4. Internationalization Considerations 512 SLP allows internationalized strings to be registered and retrieved. 513 Attributes in the template that are not marked with an 'L' (literal) 514 will be registered in a localized manner. An "en" (English) 515 localization MUST be registered, and others MAY be registered. 517 Attributes that include non-ASCII characters will be encoded using 518 UTF-8, as discussed in [RFC3722] and [RFC3491]. 520 5. iSCSI SLP Templates 522 Three templates are provided: an iSCSI target template, a management 523 service template, and an abstract template to encapsulate the two. 525 5.1. The iSCSI Abstract Service Type Template 527 This template defines the abstract service "service:iscsi". It is 528 used as a top-level service to encapsulate all other iSCSI-related 529 services. 531 Name of submitter: Mark Bakke 532 Language of service template: en 533 Security Considerations: see section 6. 535 Template Text: 536 -------------------------template begins here----------------------- 537 template-type=iscsi 539 template-version=0.1 541 template-description= 542 This is an abstract service type. The purpose of the iscsi 543 service type is to encompass all of the services used to support 544 the iSCSI protocol. 546 template-url-syntax= 547 url-path= ; Depends on the concrete service type. 549 --------------------------template ends here------------------------ 551 5.2. The iSCSI Target Concrete Service Type Template 553 This template defines the service "service:iscsi:target". An entity 554 containing iSCSI targets that wishes them discovered via SLP would 555 register each of them, with each of their addresses, as this service 556 type. 558 Initiators (and perhaps management services) wishing to discover 559 targets in this way will generally use one of the following queries: 561 1. Find a specific target, given its iSCSI Target Name: 563 Service: service:iscsi:target 564 Scope: initiator-scope-list 565 Query: (iscsi-name=iqn.2001-04.com.example.sn.456) 567 2. Find all of the iSCSI Target Names that may allow access to a 568 given initiator: 570 Service: service:iscsi:target 571 Scope: initiator-scope-list 572 Query: (auth-name=iqn.1998-03.com.example.hostid.045A7B) 574 3. Find all of the iSCSI Target Names that may allow access to 575 any initiator: 577 Service: service:iscsi:target 578 Scope: initiator-scope-list 579 Query: (auth-name=any) 581 4. Find all of the iSCSI Target Names that may allow access to 582 this initiator, or that will allow access to any initiator: 584 Service: service:iscsi:target 585 Scope: initiator-scope-list 586 Query: &(auth-name=iqn.1998-03.com.example.hostid.045A7B) 587 (auth-name=any) 589 5. Find all of the iSCSI Target Names that may allow access to 590 a given CHAP user name: 592 Service: service:iscsi:target 593 Scope: initiator-scope-list 594 Query: (auth-cred=chap/my-user-name) 596 6. Find all of the iSCSI Target Names that may allow access to 597 a given initiator that supports two IP addresses, a CHAP 598 credential and an SRP credential, and an initiator name: 600 Service: service:iscsi:target 601 Scope: initiator-scope-list 602 Query: &(|(auth-name=iqn.com.example:host47)(auth-name=any) 603 |(auth-addr=192.0.2.3)(auth-addr=192.0.2.131)(auth-addr=any) 604 |(auth-cred=chap/foo)(auth-cred=srp/my-user-name) 605 (auth-cred=any)) 607 7. Find the iSCSI Target Names from which the given initiator is 608 allowed to boot: 610 Service: service:iscsi:target 611 Scope: initiator-scope-list 612 Query: (boot-list=iqn.1998-03.com.example.hostid.045A7B) 614 8. In addition, a management service may wish to discover all 615 targets: 617 Service: service:iscsi:target 618 Scope: management-server-scope-list 619 Query: 621 More details on booting from an iSCSI target are defined in [BOOT]. 623 Name of submitter: Mark Bakke 624 Language of service template: en 625 Security Considerations: see section 6. 627 Template Text: 628 -------------------------template begins here----------------------- 629 template-type=iscsi:target 631 template-version=0.1 633 template-description= 634 This is a concrete service type. The iscsi:target service type is 635 used to register individual target addresses to be discovered by 636 others. UAs will generally search for these by including one of 637 the following: 639 - the iSCSI target name 640 - iSCSI initiator identifiers (iSCSI name, credential, IP address) 641 - the service URL 643 template-url-syntax= 644 url-path = hostport "/" iscsi-name [ "/" identity ] 645 hostport = host [ ":" port ] 646 host = hostname / hostnumber ; DNS name or IP address 647 hostname = *( domainlabel "." ) toplabel 648 alphanum = ALPHA / DIGIT 649 domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum 650 toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum 651 hostnumber = ipv4-number 652 ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) 653 port = 1*DIGIT 654 iscsi-name = iscsi-char ; iSCSI target name 655 identity = iscsi-char ; optional identity string 656 iscsi-char = ALPHA / DIGIT / escaped / ":" / "-" / "." 657 ; Intended to allow UTF-8 encoded strings 658 escaped = 1*(`' HEXDIG HEXDIG) 659 ; 660 ; The iscsi-name part of the URL is required and must be the iSCSI 661 ; name of the target being registered. 662 ; A device representing multiple targets must individually 663 ; register each target/address combination with SLP. 664 ; The identity part of the URL is optional, and is used to 665 ; indicate an identity that is allowed to access this target. 666 ; 667 ; Example (split into two lines for clarity): 668 ; service:iscsi:target://192.0.2.3:3260/ 669 ; iqn.2001-04.com.example.sn.45678 671 iscsi-name = string 672 # The iSCSI Name of this target. 673 # This must match the iscsi-name in the url-path. 675 portal-group = integer 676 # The iSCSI portal group tag for this address. Addresses sharing 677 # the same iscsi-name and portal-group tag can be used within the 678 # same iSCSI session. Portal groups are described in [RFC3720]. 680 transports = string M L 681 tcp 682 # This is a list of transport protocols that the registered 683 # entity supports. iSCSI is currently supported over TCP, 684 # but it is anticipated that it could be supported over other 685 # transports, such as SCTP, in the future. 686 tcp 688 mgmt-entity = string O 689 # The fully qualified domain name, or IP address in dotted-decimal 690 # notation, of the management interface of the entity containing 691 # this target. 692 # 694 alias = string O 695 # The alias string contains a descriptive name of the target. 697 auth-name = string M X 698 # A list of iSCSI Initiator Names that can access this target. 699 # Normal iSCSI names will be 80 characters or less; max length 700 # is 255. 701 # Normally, only one or a few values will be in the list. 702 # Using the equivalence search on this will evaluate to "true" 703 # if any one of the items in this list matches the query. 704 # If this list contains the default name "any", any initiator 705 # is allowed to access this target, provided it matches the 706 # other auth-xxx attributes. 707 # 708 # This attribute contains security policy information. If this 709 # attribute is distributed via an Attribute Reply message, 710 # IPsec MUST be implemented. 712 auth-addr = string M X 713 # A list of initiator IP addresses (or host names) which will 714 # be allowed access to this target. If this list contains the 715 # default name "any", any IP address is allowed access to this 716 # target, provided it matches the other auth-xxx attributes. 717 # 718 # This attribute contains security policy information. If this 719 # attribute is distributed via an Attribute Reply message, 720 # IPsec MUST be implemented. 722 auth-cred = string M X 723 # A list of credentials which will be allowed access to the target 724 # (provided they can provide the correct password or other 725 # authenticator). Entries in this list are of the form 726 # "method/identifier", where the currently defined methods are 727 # "chap" and "srp", both of which take usernames as their 728 # identifiers. 729 # 730 # This attribute contains security policy information. If this 731 # attribute is distributed via an Attribute Reply message, 732 # IPsec MUST be implemented. 734 boot-list = string M O 735 # A list of iSCSI Initiator Names that can boot from this target. 736 # This list works precisely like the auth-name attribute. A name 737 # appearing in this list must either appear in the access-list, 738 # or the access-list must contain the initiator name "iscsi". 739 # Otherwise, an initiator will be unable to find its boot target. 740 # If boot-list contains the name "iscsi", any host can boot from it, 741 # but I am not sure if this is useful to anyone. 742 # If this attribute is not registered, this target is not "bootable". 743 # 744 # Note that the LUN the host boots from is not specified here; a 745 # host will generally attempt to boot from LUN 0. 746 # 747 # It is quite possible that other attributes will need to be defined 748 # here for booting as well. 749 # 750 # This attribute contains security policy information. If this 751 # attribute is distributed via an Attribute Reply message, 752 # IPsec MUST be implemented. 754 --------------------------template ends here------------------------ 756 5.3. iSCSI Storage Management Service Templates 758 This template defines the service "service:iscsi:sms". An entity 759 supporting one or more iSCSI management service protocols may 760 register itself with SLP as this service type. 762 iSCSI clients and servers wishing to discover storage management 763 services using SLP will usually search for them by the protocol(s) 764 they support: 766 Service: service:iscsi:sms 767 Scope: initiator-scope-list 768 Query: (protocols=isns) 770 Name of submitter: Mark Bakke 771 Language of service template: en 772 Security Considerations: see section 6. 774 Template Text: 775 -------------------------template begins here----------------------- 776 template-type=iscsi:sms 778 template-version=0.1 780 template-description= 781 This is a concrete service type. The iscsi:sms service type 782 provides the capability for entities supporting iSCSI to discover 783 appropriate management services. 785 template-url-syntax= 786 url-path = ; The URL of the management service [RFC2608]. 788 protocols = string M 789 # The list of protocols supported by this name service. This 790 # list may be expanded in the future. There is no default. 791 # 792 # "isns" - This management service supports the use of the iSNS 793 # protocol for access management, health monitoring, and 794 # discovery management services. This protocol is defined 795 # in [ISNS]. 796 isns 798 transports = string M L 799 tcp 800 # This is a list of transport protocols that the registered 801 # entity supports. 802 tcp, udp 803 server-priority = integer 804 # The priority a client should give this server, when choosing 805 # between multiple servers with the same protocol type. 806 # When multiple servers are discovered for a given protocol type, 807 # this parameter indicates their relative precedence. Server 808 # precedence is protocol-specific; for some protocols, the primary 809 # server may have the highest server-priority value, while for 810 # others it may have the lowest. For example, with iSNS, the primary 811 # server has the lowest value (value 0). 813 --------------------------template ends here------------------------ 815 6. Security Considerations 817 The SLPv2 security model as specified in [RFC2608] does not provide 818 confidentiality, but does provide an authentication mechanism for UAs 819 to assure that service advertisements only come from trusted SAs with 820 the exception that it does not provide a mechanism to authenticate 821 "zero-result responses". See [RFC3723] for a discussion of the SLPv2 822 [RFC2608] security model. 824 Once a target or management server is discovered, authentication and 825 authorization are handled by the iSCSI protocol, or by the management 826 server's protocol. It is the responsibility of the providers of 827 these services to ensure that an inappropriately advertised or 828 discovered service does not compromise their security. 830 When no security is used for SLPv2, there is a risk of distribution 831 of false discovery information. The primary countermeasure for this 832 risk is authentication. When this risk is a significant concern, 833 IPsec SAs and iSCSI in-band authentication SHOULD be used for iSCSI 834 traffic subject to this risk to ensure that iSCSI traffic only flows 835 between endpoints that have participated in IKE authentication and 836 iSCSI in-band authentication. For example, if an attacker 837 distributes discovery information falsely claiming that it is an 838 iSCSI target, it will lack the secret information necessary to 839 successfully complete IKE authentication or iSCSI in-band 840 authentication, and hence will be prevented from falsely sending or 841 receiving iSCSI traffic. 843 There remains a risk of a denial of service attack based on repeated 844 use of false discovery information that will cause initiation of IKE 845 negotiation. The countermeasures for this are administrative 846 configuration of each iSCSI Target to limit the peers that it is 847 willing to communicate with (i.e., by IP address range and/or DNS 848 domain), and maintenance of a negative authentication cache to avoid 849 repeatedly contacting an iSCSI Target that fails to authenticate. 851 These three measures (i.e., IP address range limits, DNS domain 852 limits, negative authentication cache) MUST be implemented. 854 The auth-name, auth-addr, auth-cred, and boot-list attributes 855 comprise security policy information. When these are distributed, 856 IPsec MUST be implemented. 858 6.1. Security Implementation 860 Security for SLPv2 in an IP storage environment is specified in 861 [RFC3723]. 863 IPsec SHOULD be implemented for SLPv2 as specified in [RFC3723]; this 864 includes ESP with a non-null transform to provide both authentication 865 and confidentiality. 867 When SLPv2 can be used to distribute auth-name, auth-addr, auth-cred, 868 boot-list information (see Section 5.2 above), IPsec MUST be 869 implemented, as these items are considered to be sensitive security 870 policy information. If IPsec is not implemented, auth-name, auth- 871 addr, auth-cred, and boot-list information MUST NOT be distributed 872 via SLPv2, and MUST NOT be used if discovered via SLPv2. 874 SLPv2 authentication is OPTIONAL to implement and use, and SLPv2 875 authentication SHOULD be implemented when IPsec is not supported. 877 7. IANA Considerations 879 This document describes three SLP Templates. When they have been 880 reviewed and approved by the IESG, they should be registered in the 881 IANA "SVRLOC Templates" registry. This process is described in the 882 IANA Considerations section of [RFC2609]. 884 8. Summary 886 This document describes how SLP can be used by iSCSI initiators to 887 find iSCSI targets and storage management servers. Service type 888 templates for iSCSI targets and storage management servers are 889 presented. 891 9. Normative References 892 [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service 893 Location Protocol, version 2", RFC 2608, June 1999. 895 [RFC2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates 896 and service: Schemes", RFC 2609, June 1999. 898 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 899 Requirement Levels", RFC 2119, March 1997. 901 [RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M. and 902 E. Zeidner, "Internet Small Computer Systems Interface 903 (iSCSI)", RFC 3720, March 2004. 905 [RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V. and F. 906 Travostino, "Securing Block Storage Protocols over IP", RFC 907 3723, March 2004. 909 10. Informative References 911 [RFC2614] Kempf, J. and E. Guttman, "An API for Service Location", 912 RFC 2614, June 1999. 914 [2614BIS] Kempf, J. and E. Guttman, "An API for Service Location", 915 draft-kempf-svrloc-rfc2614bis-00.txt, February 2002. 917 [SAM2] ANSI T10. "SCSI Architectural Model 2", March 2000. 919 [RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. 920 Krueger, "Internet Small Computer Systems Interface (iSCSI) 921 Naming and Discovery", RFC 3721, March 2004. 923 [AUTH-MIB] Bakke, M. and J. Muchow, "Definitions of Managed Objects for 924 User Identity Authentication", Work in Progress, draft-ietf- 925 ips-auth-mib-04.txt, March 2003. 927 [ISNS] Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and J. 928 Souza, "Internet Storage Name Service", Work in Progress, 929 draft-ietf-ips-isns-22.txt, February 2004. 931 [BOOT] Sarkar, P., Missimer, D. and C. Sapuntzakis, "A Standard 932 for Bootstrapping Clients using the iSCSI Protocol", Work in 933 Progress, draft-ietf-ips-iscsi-boot-12.txt, March 2004. 935 [RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 936 1900, February 1996. 938 [RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with 939 SLP", RFC 3105, October 2001. 941 [RFC3722] Bakke, M., "String Profile for iSCSI Names", RFC 3722, 942 March 2004. 944 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 945 for Internationalized Domain Names", RFC 3491, March 2003. 947 11. Authors' Addresses 949 Mark Bakke 950 Cisco Systems, Inc. 951 6450 Wedgwood Road 952 Maple Grove, MN 55311 953 Voice: +1 763-398-1000 954 EMail: mbakke@cisco.com 956 Kaladhar Voruganti 957 IBM Almaden Research Center 958 650 Harry Road 959 San Jose, CA 95120 960 Email: kaladhar@us.ibm.com 962 John L. Hufferd 963 IBM Storage Systems Group 964 5600 Cottle Road 965 San Jose, CA 95193 966 Voice: +1 408 256-0403 967 Email: hufferd@us.ibm.com 969 Marjorie Krueger 970 Hewlett-Packard Corporation 971 8000 Foothills Blvd 972 Roseville, CA 95747-5668, USA 973 Voice: +1 916 785-2656 974 Email: marjorie_krueger@hp.com 976 Todd Sperry 977 Adaptec, Inc. 978 691 South Milpitas Boulevard 979 Milpitas, Ca. 95035 980 Voice: +1 408 957-4980 981 Email: todd_sperry@adaptec.com 983 12. Full Copyright Notice 985 Copyright (C) The Internet Society (2004). All Rights Reserved. 987 This document and translations of it may be copied and furnished to 988 others, and derivative works that comment on or otherwise explain it 989 or assist in its implementation may be prepared, copied, published 990 and distributed, in whole or in part, without restriction of any 991 kind, provided that the above copyright notice and this paragraph are 992 included on all such copies and derivative works. However, this 993 document itself may not be modified in any way, such as by removing 994 the copyright notice or references to the Internet Society or other 995 Internet organizations, except as needed for the purpose of 996 developing Internet standards in which case the procedures for 997 copyrights defined in the Internet Standards process must be 998 followed, or as required to translate it into languages other than 999 English. 1001 The limited permissions granted above are perpetual and will not be 1002 revoked by the Internet Society or its successors or assigns. 1004 This document and the information contained herein is provided on an 1005 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1006 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1007 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1008 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1009 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1011 Acknowledgement 1013 Funding for the RFC Editor function is currently provided by the 1014 Internet Society.