Internet Draft David Peterson Cisco Expires September 2002 March 2002 Finding FCIP Entities Using SLPv2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The FCIP protocol [FCIP] provides a method for the tunneling of Fibre Channel frames over an IP network. This document defines the use of Service Location Protocol, version 2 (SLPv2) [RFC2608], by FCIP Entities to discover one another, and provides the appropriate templates describing their services. 1. Acknowledgements This draft was produced by the FCIP discovery team, including Todd Sperry (Adaptec), Larry Lamars (SanValley), Robert Snively (Brocade), Peterson Standards Track [Page 1] Internet Draft FCIP and SLPV2 March 2002 Ravi Natarajan (Lightsand), Anil Rijhsinghani (McData), and Venkat Rangan (Rhapsody Networks). Thanks also to Mark Bakke (Cisco) for initial help and consultation. 2. Notation Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Terminology Here are some definitions that may aid readers that are unfamiliar with either SLP, or FCIP. Some of these definitions have been reproduced from [RFC2608] and "Finding an RSIP Server with SLP" [RSIP]. User Agent (UA) A process working on the client's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents. Service Agent (SA) A process working on behalf of one or more services to advertise the services and their capabilites. Directory Agent (DA) A process which collects service advertisements. There can only be one DA present per given host. Scope A named set of services, typically making up a logical administrative group. Service Advertisement A URL, attributes, and a lifetime (indicating how long the advertisement is valid), providing service access information and capabilities description for a particular service. FCIP Entity The principle FCIP interface point to the IP network. FCIP Entity Name The world wide name of the switch if the FCIP Entity resides in a switch or the world wide node name of the associated Nx_Port. Peterson Standards Track [Page 2] Internet Draft FCIP and SLPV2 March 2002 FCIP Discovery Domain The FCIP Discovery Domain specifies which FCIP Entities are allowed to connect within the bounds of the scope. 4. Using SLPv2 for FCIP Service Discovery At least two FCIP Entities must be involved in the entity discovery process. The end result is that an FCIP Entity will discover one or more peer FCIP Entities. Peterson Standards Track [Page 3] Internet Draft FCIP and SLPV2 March 2002 4.1. Discovering FCIP Entities using SLPv2 The following diagram shows the relationship between FCIP Entities and their associated SLPv2 agents. +--------------------------------------+ | FCIP Entity | +----------------------------------+ | | FCIP Control and Services Module | | +----------------+ | | | SA | UA | | | +----------------+-----------------+ | | TCP/UDP/IP | | +----------------+-----------------+ | | Interface | | | 180.10.1.10 | | +----------------+-----------------+---| | +------------+ | | SLPv2 DA |----+ IP Network +------------+ | | +----------------+-----------------+---| | Interface | | | 190.10.1.20 | | +----------------+-----------------+ | | TCP/UDP/IP | | +----------------+-----------------+ | | SA | UA | | | +----------------+ | | | FCIP Control and Services Module | | +--------------------------------- + | | FCIP Entity | +--------------------------------------+ Fig. 1 FCIP Entity and SLPv2 Agent Relationship. As indicated in the above drawing above, each FCIP Entity contains an FCIP Control and Services Module that interfaces to an SLPv2 SA and UA. The SA constructs a service advertisement of the type "service:fcip:entity" for each of the service URLs it wishes to register. The service advertisement contains a lifetime, along with other attributes defined in the service template. The remainder of the discovery process is identical to that used by any client/server pair implementing SLPv2: Peterson Standards Track [Page 4] Internet Draft FCIP and SLPV2 March 2002 1. If an SLPv2 DA is found, the SA contacts the DA and registers the service advertisement. If no DA is found, the SA maintains the service advertisement itself, and answers multicast UA queries directly. 2. When the FCIP Entity requires contact information for a peer FCIP Entity, the UA either contacts the DA using unicast or the SA using multicast using an SLPv2 service request. The UA service request includes a query, based on the attributes, to indicate the characteristics of the peer FCIP Entities it requires. 3. Once the UA has the IP address and port number of a peer FCIP Entity, it may begin the normal connection procedure, as described in [FCIP], to a peer FCIP Entity. The use of a DA is recommended for SLPv2 operation in an FCIP environment. 4.1.1. FCIP Discovery Domains The concept of a discovery domain provides further granularity of control of the allowed connections between FCIP Entities within a specific SLPv2 scope. The following example diagram shows the relationship between FCIP Entities and their associated discovery domains within a specified SLPv2 scope. Peterson Standards Track [Page 5] Internet Draft FCIP and SLPV2 March 2002 =============fcip====================================================== = = = *************************purple********************************** = = * * = = * #####orange######################### * = = * # ------------ /////////////////+//////blue/////////// * = = * # | FC SAN A | / # / * = = * # ------------ / # ------------ / * = = * # / # | FC SAN C | / * = = * # / ------------ # ------------ / * = = * # / | FC SAN B | # / * = = * # / ------------ # / * = = * ##################+################# / * = = * /////////////////////////////////////// * = = * * = = ***************************************************************** = = = ======================================================================= Fig. 2 FCIP Entity and Discovery Domain Example. Within the specified scope "fcip", the administrator has defined a discovery domain "purple", encompassing FC SAN's A, B, and C. This discovery domain is illustrated using the "*" character. Within the specified scope "fcip", it is determined that FC SAN A is allowed to connect to FC SAN B but not to FC SAN C. This discovery domain, labeled "orange", is illustrated using the "#" character. Within the specified scope "fcip", it is determined that FC SAN C is allowed to connect to FC SAN B but not to FC SAN A. This discovery domain, labeled "blue", is illustrated using the "/" character. 4.2. NAT and NAPT Considerations Since SLPv2 provides IP address and TCP port information within its payload, the addresses an SA or DA advertise may not be the same as those a UA must use if a Network Address(/Port) Translation (NAT/NAPT) device is present between the UA and the SA. This may result in the UA discovering address information that is unusable. Below are a few recommendations to handle this: - Use a fully-qualified domain name instead of IP address in service URLs and in the mgmt-entity attribute. Peterson Standards Track [Page 6] Internet Draft FCIP and SLPV2 March 2002 - Use the default IANA-assigned FCIP TCP port number in service URLs, , when possible. - If advertising service URLs through a NAT/NAPT device, and the FQDN, IP address, or TCP port will be translated, the NAT/NAPT device can provide an SLPv2 proxy capability to do the translation. 5. FCIP SLPv2 Templates Two templates are provided: an FCIP Entity template, and an abstract template to provide a means to add other FCIP related templates in the future. 5.1. The FCIP Abstract Service Type Template This template defines the abstract service "service:fcip". It is used as a top-level service to encapsulate all other FCIP related services. Name of submitter: David Peterson Language of service template: en Security Considerations: See the security considerations of the concrete service type. Template Text: -------------------------template begins here----------------------- template-type=fcip template-version=0.1 template-description= This is an abstract service type. The purpose of the fcip service type is to encompass all of the services used to support the FCIP protocol. template-url-syntax = url-path= ; Depends on the concrete service type. --------------------------template ends here------------------------ 5.2. The FCIP Entity Concrete Service Type Template This template defines the service "service:fcip:entity". A device containing FCIP Entities that wishes to have them discovered via SLPv2 would register each of them, with each of their addresses, as this service type. Peterson Standards Track [Page 7] Internet Draft FCIP and SLPV2 March 2002 FCIP Entities wishing to discover other FCIP Entities in this manner will generally use one of the following example query strings: 1. Find a specific FCIP Entity, given its FCIP Entity Name: Service: service:fcip:entity Scope: fcip-entity-scope-list Query: (fcip-entity-name=10:00:00:60:69:20:34:0C) 2. Find all of the FCIP Entities within a specified FCIP Discovery Domain: Service: service:fcip:entity Scope: fcip-entity-scope-list Query: (fcip-discovery-domain=fcip-discovery-domain-name) 3. In addition, a management application may wish to discover all FCIP Entities: Service: service:fcip:entity Scope: management-service-scope-list Query: none Name of submitter: David Peterson Language of service template: en Security Considerations: See later section. Template Text: -------------------------template begins here----------------------- template-type=fcip:entity template-version=0.1 template-description= This is a concrete service type. The fcip:entity service type is used to register individual FCIP Entity addresses to be discovered by others. UAs will generally search for these by including one of the following: - the FCIP Entity Name for which an address is needed - the FCIP Discovery Domain Name for which addresses are requested - the service URL template-url-syntax = url-path = ipaddr [ : tcpport ] / fcip-entity-name ipaddr = DNS host name or ip address tcpport = decimal tcp port number fcip-entity-name = FCIP Entity Name Peterson Standards Track [Page 8] Internet Draft FCIP and SLPV2 March 2002 ; The fcip-entity-name portion of the URL is required and must be the ; FCIP Entity Name of the entity being registered. ; An entity representing multiple endpoints must register each of them ; using SLPv2. ; ; Examples: ; service:fcip:entity://hammer.cisco.com:4000/10:00:00:60:69:20:34:0C ; service:fcip:entity://192.1.3.40:4000/10:00:00:60:69:20:34:0C ; ; A DNS host name should be used along with the well-known IANA FCIP ; port number for allow for operation with NAT/NAPT devices. fcip-entity-name = opaque # This must match the fcip-entity-name specified in the url-path. # The fcip-entity-name is either the Fibre Channel Switch Name [FC-SW-2] if the # FCIP Entity is embedded in a switch or the Fibre Channel Node Name [FC-FS] if # the FCIP Entity is not embedded in a switch (e.g., an Nx_Port). transports = string M L tcp # This is a list of transport protocols that the registered entity # supports. FCIP is currently supported over TCP only. tcp mgmt-entity = string M O # The URL's of the management interface(s) appropriate for SNMP, # web-based, or telnet management of the FCIP Entity. # Examples: # snmp://10.1.1.1 # http://fcipentity.dap.com:1080/ # telnet://fcipentity.dap.com fcip-discovery-domain = string M fcip # The fcip-discovery-domain string contains the name(s) of the FCIP # discovery domain(s) to which this FCIP Entity belongs. --------------------------template ends here------------------------ 6. Security Considerations Service type templates provide information that is used to interpret information obtained by clients through SLPv2. If the FCIP templates are modified or if false templates are distributed, FCIP Entities may not correctly register themselves or may not be able to interpret service information. Peterson Standards Track [Page 9] Internet Draft FCIP and SLPV2 March 2002 SLPv2 provides an authentication mechanism for UAs to assure that service advertisements only come from trusted SAs [RFC2608]. If trust is an issue, then SLPv2 authentication should be enabled in the network. Once an FCIP Entity is discovered, authentication and authorization are handled by the FCIP protocol. It is the responsibility of the providers of these services to ensure that an inappropriately advertised or discovered service, does not comprimise their security. 6.1. IPsec Integration Although SLPv2 security provides authentication, it does not provide confidentiality. When confidentiality is a concern, in particular when SLPv2 is used to distribute security policy information, IPsec MUST be used with SLPv2 when discovering FCIP entities. When confidentiality is not a concern, SLPv2 security MAY be implemented and used. The use of IPsec and IKE for use with SLPv2 is described in [IPS- SEC], and is a work in progress. 7. Summary This document describes how SLPv2 can be used by FCIP Entities to find other FCIP Entities. Service type templates for FCIP Entities are presented. 8. References [RFC2608] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Protocol, version 2", RFC 2608, July 1999. [RFC2609] E. Guttman, C. Perkins, J. Kempf. "Service Templates and service: Schemes", RFC 2609, July 1999. [RFC2614] J. Kempf, E. Guttman. "An API for Service Location", RFC 2614, June 1999. [2614BIS] J. Kempf, E. Guttman. "An API for Service Location", draft- kempf-srvloc-rfc2614bis-00.txt, February 2001. [RFC2119] S. Bradner. "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Peterson Standards Track [Page 10] Internet Draft FCIP and SLPV2 March 2002 [RFC3082] J. Kempf, J Goldschmidt. "Notification and Subscription for SLP", RFC 3082, March 2001. [FCIP] Rajagopal, et. al. "FCIP", draft-ietf-ips- fcovertcpip-09.txt, February 2002. [FCIP-MIB] Rijhsinghani, et. al. "FCIP MIB", draft-ietf-ips-fcip- mib-01.txt, January 2002. [RSIP] Kempf, J., Montenegro, G. "Finding an RSIP Server with SLP", draft-ietf-nat-rsip-slp-00, February 2000. [FC-SW-2] Fibre Channel Switch Fabric - 2, ANSI INCITS.355:200x, May 23, 2001. [FC-FS] Fibre Channel Framing and Signaling, T11 Project 1331-D, Rev 1.70, February 8, 2002. [IPS-SEC] B. Aboba, et. al. "Securing iSCSI, iFCP, and FCIP", draft- ietf-ips-security-10.txt, February, 2002. Author's Address: David Peterson Cisco Systems, Inc. 6450 Wedgwood Road Maple Grove, MN USA 55311 Voice: +1 763-398-1007 E-Mail: dap@cisco.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than Peterson Standards Track [Page 11] Internet Draft FCIP and SLPV2 March 2002 English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Peterson Standards Track [Page 12]