idnits 2.17.1 draft-ietf-ips-fcip-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 page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 11) being 75 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 114 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? -- 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 == Line 12 has weird spacing: '...d is in full ...' == Line 16 has weird spacing: '...as, and its ...' == Line 17 has weird spacing: '... other group...' == Line 21 has weird spacing: '... and may be...' == Line 22 has weird spacing: '...me. It is i...' == (109 more instances...) == Unrecognized Status in 'Category: standards-track', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (January 2004) is 7406 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) == Unused Reference: 'RFC2609' is defined on line 482, but no explicit reference was found in the text == Unused Reference: 'RFC2614' is defined on line 485, but no explicit reference was found in the text == Unused Reference: '2614BIS' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC3082' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'FCIP-MIB' is defined on line 497, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1900 -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-SW-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-BB-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-FS' -- No information found for draft-kempf-srvloc-rfc2614bis - is the name correct? == Outdated reference: A later version (-09) exists of draft-ietf-ips-fcip-mib-05 Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS Working Group David Peterson 3 INTERNET-DRAFT SBS Technologies 4 January 2004 5 Expires: July 2004 6 Category: standards-track 8 Finding FCIP Entities Using SLPv2 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document defines the use of Service Location Protocol version 2 38 (SLPv2), by Fibre Channel over TCP/IP (FCIP) Entities. 40 1. Introduction 42 This document describes the use of Service Location Protocol version 43 2 to perform dynamic discovery of participating Fibre Channel over 44 TCP/IP (FCIP) Entities. Implementation guidelines, service type 45 templates, and security considerations are specified. 47 2. Notation Conventions 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 3. Terminology 55 Here are some definitions that may aid readers that are unfamiliar 56 with either SLP, or FCIP. Some of these definitions have been 57 reproduced from [RFC2608] and [RFC3105]. 59 User Agent (UA) A process working on the client's behalf 60 to establish contact with some service. 61 The UA retrieves service information from 62 the Service Agents or Directory Agents. 64 Service Agent (SA) A process working on behalf of one or more 65 services to advertise the services and 66 their capabilites. 68 Directory Agent (DA) A process which collects service 69 advertisements. There can only be one DA 70 present per given host. 72 Scope A named set of services, typically making 73 up a logical administrative group. 75 Service Advertisement A URL, attributes, and a lifetime 76 (indicating how long the advertisement is 77 valid), providing service access 78 information and capabilities description 79 for a particular service. 81 FCIP Entity The principle FCIP interface point to the 82 IP network. 84 FCIP Entity Name The world wide name of the switch if the 85 FCIP Entity resides in a switch or the 86 world wide node name of the associated 87 Nx_Port. 89 FCIP Discovery Domain The FCIP Discovery Domain specifies which 90 FCIP Entities are allowed to discover each 91 other within the bounds of the scope. 93 4. Using SLPv2 for FCIP Service Discovery 95 At least two FCIP Entities must be involved in the entity discovery 96 process. The end result is that an FCIP Entity will discover one or 97 more peer FCIP Entities. 99 4.1. Discovering FCIP Entities using SLPv2 101 The following diagram shows the relationship between FCIP Entities 102 and their associated SLPv2 agents. 104 +--------------------------------------+ 105 | FCIP Entity | 106 +----------------------------------+ | 107 | FCIP Control and Services Module | | 108 +----------------+ | | 109 | SA | UA | | | 110 +----------------+-----------------+ | 111 | TCP/UDP/IP | | 112 +----------------+-----------------+ | 113 | Interface | | 114 | 192.0.2.10 | | 115 +----------------+-----------------+---| 116 | 117 +------------+ | 118 | SLPv2 DA |----+ IP Network 119 +------------+ | 120 | 121 +----------------+-----------------+---| 122 | Interface | | 123 | 192.0.2.20 | | 124 +----------------+-----------------+ | 125 | TCP/UDP/IP | | 126 +----------------+-----------------+ | 127 | SA | UA | | | 128 +----------------+ | | 129 | FCIP Control and Services Module | | 130 +--------------------------------- + | 131 | FCIP Entity | 132 +--------------------------------------+ 134 Fig. 1 FCIP Entity and SLPv2 Agent Relationship. 136 As indicated in the drawing above, each FCIP Entity contains an FCIP 137 Control and Services Module that interfaces to an SLPv2 SA and UA. 139 The SA constructs a service advertisement of the type 140 "service:fcip:entity" for each of the service URLs it wishes to 141 register. The service advertisement contains a lifetime, along with 142 other attributes defined in the service template. 144 The remainder of the discovery process is identical to that used by 145 any client/server pair implementing SLPv2: 147 1. If an SLPv2 DA is found [RFC2608], the SA contacts the DA and 148 registers the service advertisement. Whether or not one or more SLPv2 149 DAs are discovered, the SA maintains the service advertisement itself 150 and answers multicast UA queries directly. 152 2. When the FCIP Entity requires contact information for a peer FCIP 153 Entity, the UA either contacts the DA using unicast or the SA using 154 multicast using an SLPv2 service request. The UA service request 155 includes a query, based on the attributes, to indicate the 156 characteristics of the peer FCIP Entities it requires. 158 3. Once the UA has the IP address and port number of a peer FCIP 159 Entity, it may begin the normal connection procedure, as described in 160 [FCIP], to a peer FCIP Entity. 162 The use of a DA is RECOMMENDED for SLPv2 operation in an FCIP 163 environment. 165 4.1.1. FCIP Discovery Domains 167 The concept of a discovery domain provides further granularity of 168 control of allowed discovery between FCIP Entities within a specific 169 SLPv2 scope. 171 The following example diagram shows the relationship between FCIP 172 Entities and their associated discovery domains within a specified 173 SLPv2 scope. 175 =================fcip======================================= 176 = = 177 = *************************purple*********************** = 178 = * * = 179 = * #####orange###################### * = 180 = * # ------------ //////blue//////+/////////////// * = 181 = * # | FCIP | / # / * = 182 = * # | Entity A | / # / * = 183 = * # ------------ / # ------------ / * = 184 = * # / # | FCIP | / * = 185 = * # / # | Entity C | / * = 186 = * # / ------------ # ------------ / * = 187 = * # / | FCIP | # / * = 188 = * # / | Entity B | # / * = 189 = * # / ------------ # / * = 190 = * ################+################ / * = 191 = * //////////////////////////////// * = 192 = * * = 193 = ****************************************************** = 194 = = 195 ============================================================ 197 Fig. 2 FCIP Entity and Discovery Domain Example. 199 Within the specified scope "fcip", the administrator has defined a 200 discovery domain "purple", allowing FCIP Entities A, B, and C to 201 discover each other. This discovery domain is illustrated using the 202 "*" character. 204 Within the specified scope "fcip", the administrator has defined a 205 discovery domain "orange", allowing FCIP Entity A to discover FCIP 206 Entity B, but not FCIP Entity C. This discovery domain is 207 illustrated using the "#" character. 209 Within the specified scope "fcip", the administrator has defined a 210 discovery domain "blue", allowing FCIP Entity C to discover FCIP 211 Entity B, but not FCIP Entity A. This discovery domain is 212 illustrated using the "/" character. 214 For this example, the value of the fcip-discovery-domain attribute 215 for each FCIP Entity is as follows: 217 FCIP Entity A = orange,purple 219 FCIP Entity B = orange,blue,purple 221 FCIP Entity C = blue,purple 223 4.2. NAT and NAPT Considerations 225 Since SLPv2 provides IP address and TCP port information within its 226 payload, the addresses an SA or DA advertise may not be the same as 227 those a UA must use if a Network Address(/Port) Translation 228 (NAT/NAPT) device is present between the UA and the SA. This may 229 result in the UA discovering address information that is unusable. 230 Also note that SLP advertisements that occur inside a private address 231 realm may be unreachable outside that realm. Below are some 232 recommendations for dealing with SLPv2 and NAT/NAPT devices: 234 - A fully-qualified domain name (i.e., not an IP address) SHOULD be 235 used in service URLs and the mgmt-entity attribute [RFC1900]. 237 - Configure the NAPT device to provide default mapping(s) for the 238 well-known port(s) and use the default IANA-assigned FCIP TCP port 239 number in service URLs, when possible. 241 5. FCIP SLPv2 Templates 243 Two templates are provided: an FCIP Entity template, and an abstract 244 template to provide a means to add other FCIP related templates in 245 the future. 247 5.1. The FCIP Abstract Service Type Template 249 This template defines the abstract service "service:fcip". It is used 250 as a top-level service to encapsulate all other FCIP related 251 services. 253 Name of submitter: David Peterson 254 Language of service template: en 255 Security Considerations: see section 6. 257 Template Text: 258 -------------------------template begins here----------------------- 259 template-type=fcip 261 template-version=0.1 263 template-description= 264 This is an abstract service type. The purpose of the fcip service 265 type is to encompass all of the services used to support the FCIP 266 protocol. 268 template-url-syntax = 269 url-path= ; Depends on the concrete service type. 271 --------------------------template ends here------------------------ 273 5.2. The FCIP Entity Concrete Service Type Template 275 This template defines the service "service:fcip:entity". A device 276 containing FCIP Entities that wishes to have them discovered via 277 SLPv2 would register each of them, with each of their addresses, as 278 this service type. 280 FCIP Entities wishing to discover other FCIP Entities in this manner 281 will generally use one of the following example query strings: 283 1. Find a specific FCIP Entity, given its FCIP Entity Name: 285 Service: service:fcip:entity 286 Scope: fcip-entity-scope-list 287 Query: (fcip-entity-name=\ff\10\00\00\60\69\20\34\0C) 289 2. Find all of the FCIP Entities within a 290 specified FCIP Discovery Domain: 292 Service: service:fcip:entity 293 Scope: fcip-entity-scope-list 294 Query: (fcip-discovery-domain=fcip-discovery-domain-name) 296 3. In addition, a management application may wish to discover 297 all FCIP Entities: 299 Service: service:fcip:entity 300 Scope: management-service-scope-list 301 Query: none 303 Name of submitter: David Peterson 304 Language of service template: en 305 Security Considerations: see section 6. 307 Template Text: 308 -------------------------template begins here----------------------- 309 template-type=fcip:entity 311 template-version=0.1 313 template-description= 314 This is a concrete service type. The fcip:entity service type is 315 used to register individual FCIP Entity addresses to be discovered 316 by others. UAs will generally search for these by including one of 317 the following: 318 - the FCIP Entity Name for which an address is needed 319 - the FCIP Discovery Domain Name for which addresses are requested 320 - the service URL 322 template-url-syntax = 323 url-path = hostport 324 hostport = host [ ":" port ] 325 host = hostname / hostnumber 326 hostname = *( domainlabel "." ) toplabel 327 alphanum = ALPHA / DIGIT 328 domainlabel = alphanum / alphanum * [alphanum / "-"] alphanum 329 toplabel = ALPHA / ALPHA * [ alphanum / "-" ] alphanum 330 hostnumber = ipv4-number 331 ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) 332 port = 1*DIGIT 334 ; 335 ; A DNS host name should be used along with the well-known 336 ; IANA FCIP port number for operation with NAT/NAPT devices. 337 ; 338 ; Examples: 339 ; service:fcip:entity://host.example.com 340 ; service:fcip:entity://192.0.2.0:4000 341 ; 343 fcip-entity-name = opaque L 344 # If the FCIP Entity is a VE_Port/B_Access implementation [FC-BB-2] 345 # residing in a switch, the fcip-entity-name is the Fibre Channel 346 # Switch Name [FC-SW-2]. Otherwise, the fcip-entity-name is the 347 # Fibre Channel Node Name [FC-FS] of the port (e.g., an Nx_Port) 348 # associated with the FCIP Entity. 349 # An entity representing multiple endpoints must register each of 350 # the endpoints using SLPv2. 352 transports = string M L 353 tcp 354 # This is a list of transport protocols that the registered entity 355 # supports. FCIP is currently supported over TCP only. 356 tcp 358 mgmt-entity = string M O L 359 # The URL's of the management interface(s) appropriate for SNMP, 360 # web-based, or telnet management of the FCIP Entity. 361 # Examples: 362 # snmp://192.0.2.0 363 # http://fcipentity.example.com:1080/ 364 # telnet://fcipentity.example.com 366 fcip-discovery-domain = string M L 367 fcip 368 # The fcip-discovery-domain string contains the name(s) of the FCIP 369 # discovery domain(s) to which this FCIP Entity belongs. 371 --------------------------template ends here------------------------ 373 6. Security Considerations 375 The SLPv2 security model as specified in [RFC2608] does not provide 376 confidentiality, but does provide an authentication mechanism for UAs 377 to assure that service advertisements only come from trusted SAs with 378 the exception that it does not provide a mechanism to authenticate 379 "zero-result responses". See [IPS-SEC] for a discussion of the SLPv2 380 [RFC2608] security model. 382 Once an FCIP Entity is discovered, authentication and authorization 383 are handled by the FCIP protocol. It is the responsibility of the 384 providers of these services to ensure that an inappropriately 385 advertised or discovered service does not comprimise their security. 387 When no security is used for SLPv2, there is a risk of distribution 388 of false discovery information. The primary countermeasure for this 389 risk is authentication. When this risk is a significant concern, 390 IPsec SAs SHOULD be used for FCIP traffic subject to this risk to 391 ensure that FCIP traffic only flows between endpoints that have 392 participated in IKE authentication. For example, if an attacker 393 distributes discovery information falsely claiming that it is an FCIP 394 endpoint, it will lack the secret information necessary to 395 successfully complete IKE authentication, and hence will be prevented 396 from falsely sending or receiving FCIP traffic. 398 There remains a risk of a denial of service attack based on repeated 399 use of false discovery information that will cause initiation of IKE 400 negotiation. The countermeasures for this are administrative 401 configuration of each FCIP Entity to limit the peers that it is 402 willing to communicate with (i.e., by IP address range and/or DNS 403 domain), and maintenance of a negative authentication cache to avoid 404 repeatedly contacting an FCIP Entity that fails to authenticate. 405 These three measures (i.e., IP address range limits, DNS domain 406 limits, negative authentication cache) MUST be implemented. 408 6.1. Security Implementation 410 Security for SLPv2 in an IP storage environment is specified in [IPS- 411 SEC]. 413 IPsec SHOULD be implemented for SLPv2 as specified in [IPS-SEC]. This 414 includes ESP with a non-null transform to provide both authentication 415 and confidentiality. 417 SLPv2 authentication is OPTIONAL to implement and use, and SLPv2 418 authentication SHOULD be implemented when IPsec is not supported. 420 7. IANA Considerations 422 After RFC publication, an SLP designated expert will oversee 423 registration of the template(s) in the IANA repository. 425 8. Internationalization Considerations 427 SLP allows internationalized strings to be registered and retrieved. 428 Attributes in the template that are not marked with an 'L' (literal) 429 will be registered in a localized manner. An "en" (English) 430 localization MUST be registered, and others MAY be registered. 432 9. Summary 434 This document describes how SLPv2 can be used by FCIP Entities to 435 find other FCIP Entities. Service type templates for FCIP Entities 436 are presented. 438 10. Acknowledgements 440 This draft was produced by the FCIP discovery team, including Todd 441 Sperry (Adaptec), Larry Lamars (SanValley), Robert Snively (Brocade), 442 Ravi Natarajan (Lightsand), Anil Rijhsinghani (McData), and Venkat 443 Rangan (Rhapsody Networks). Thanks also to Mark Bakke (Cisco) for 444 initial help and consultation, and David Black, Erik Guttman, and 445 James Kempf for assistance during expert review. 447 11. Normative References 449 The references in this section were current at the time this 450 specification was approved. This specification is intended to operate 451 with newer versions of the referenced documents. Looking for newer 452 references is recommended. 454 [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service 455 Location Protocol, version 2", RFC 2608, July 1999. 457 [RFC2119] S. Bradner. "Key Words for Use in RFCs to Indicate 458 Requirement Levels", RFC 2119, March 1997. 460 [RFC1900] B. Carpenter, Y. Rekhter. "Renumbering Needs Work", RFC 461 1900, February 1996. 463 [FCIP] Rajagopal, et. al. "FCIP", draft-ietf-ips- 464 fcovertcpip-12.txt, February 2003. 466 [FC-SW-2] Fibre Channel Switch Fabric - 2, ANSI INCITS.355:2001, 467 December 12, 2001. 469 [FC-BB-2] Fibre Channel Backbone - 2, T11 Project 1238-D, Rev 6.0, 470 February 4, 2003. 472 [FC-FS] Fibre Channel Framing and Signaling, T11 Project 1331-D, Rev 473 1.90, April 9, 2003. 475 [IPS-SEC] B. Aboba, et. al. "Securing Block Storage Protocols over 476 IP", draft-ietf-ips-security-19.txt, January 14, 2003. 478 12. Informative References 480 The references in this section may further assist the reader. 482 [RFC2609] E. Guttman, C. Perkins, J. Kempf. "Service Templates and 483 service: Schemes", RFC 2609, July 1999. 485 [RFC2614] J. Kempf, E. Guttman. "An API for Service Location", RFC 486 2614, June 1999. 488 [2614BIS] J. Kempf, E. Guttman. "An API for Service Location", draft- 489 kempf-srvloc-rfc2614bis-00.txt, February 2001. 491 [RFC3082] J. Kempf, J Goldschmidt. "Notification and Subscription for 492 SLP", RFC 3082, March 2001. 494 [RFC3105] Kempf, J., Montenegro, G. "Finding an RSIP Server with SLP", 495 RFC 3105, October 2001. 497 [FCIP-MIB] Rijhsinghani, et. al. "FCIP MIB", draft-ietf-ips-fcip- 498 mib-05.txt, December 2003. 500 Author's Address: 502 David Peterson 503 SBS Technologies, Inc. 504 1284 Corporate Center Dr. 505 St. Paul, MN 506 USA 55121 508 Voice: +1 651-905-4755 509 E-Mail: dap@sbs.com 511 Full Copyright Statement 513 Copyright (C) The Internet Society (2003). All Rights Reserved. 515 This document and translations of it may be copied and furnished to 516 others, and derivative works that comment on or otherwise explain it 517 or assist in its implementation may be prepared, copied, published 518 and distributed, in whole or in part, without restriction of any 519 kind, provided that the above copyright notice and this paragraph are 520 included on all such copies and derivative works. However, this 521 document itself may not be modified in any way, such as by removing 522 the copyright notice or references to the Internet Society or other 523 Internet organizations, except as needed for the purpose of 524 developing Internet standards in which case the procedures for 525 copyrights defined in the Internet Standards process must be 526 followed, or as required to translate it into languages other than 527 English. 529 The limited permissions granted above are perpetual and will not be 530 revoked by the Internet Society or its successors or assigns. 532 This document and the information contained herein is provided on an 533 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 534 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 535 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 536 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 537 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 539 Acknowledgement 541 Funding for the RFC Editor function is currently provided by the 542 Internet Society.