[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 3822

IPS Working Group                                         David Peterson
INTERNET-DRAFT                                          SBS Technologies
<draft-ietf-ips-fcip-slp-09.txt>                            January 2004
Expires: July 2004
Category: standards-track



                   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 (2003). All Rights Reserved.


Abstract


   This  document defines the use of Service Location Protocol version 2
   (SLPv2), by Fibre Channel over TCP/IP (FCIP) Entities.


1.  Introduction


   This document describes the use of Service Location Protocol  version
   2  to  perform  dynamic discovery of participating Fibre Channel over
   TCP/IP (FCIP)  Entities.   Implementation  guidelines,  service  type
   templates, and security considerations are specified.






Peterson                     Standards Track                    [Page 1]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



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 [RFC3105].


   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.


   FCIP Discovery Domain      The  FCIP Discovery Domain specifies which
                              FCIP Entities are allowed to discover each
                              other within the bounds of the scope.






Peterson                     Standards Track                    [Page 2]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



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.



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             |   |
              |           192.0.2.10             |   |
              +----------------+-----------------+---|
                               |
     +------------+            |
     |  SLPv2 DA  |----+  IP Network
     +------------+            |
                               |
              +----------------+-----------------+---|
              |            Interface             |   |
              |           192.0.2.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 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




Peterson                     Standards Track                    [Page 3]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



   "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:


   1.  If  an  SLPv2  DA  is found [RFC2608], the SA contacts the DA and
   registers the service advertisement. Whether or not one or more SLPv2
   DAs are discovered, 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 allowed discovery 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 4]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



   =================fcip=======================================
   =                                                          =
   =  *************************purple***********************  =
   =  *                                                    *  =
   =  *  #####orange######################                 *  =
   =  *  # ------------  //////blue//////+///////////////  *  =
   =  *  # | FCIP     |  /               #              /  *  =
   =  *  # | Entity A |  /               #              /  *  =
   =  *  # ------------  /               # ------------ /  *  =
   =  *  #               /               # | FCIP     | /  *  =
   =  *  #               /               # | Entity C | /  *  =
   =  *  #               /  ------------ # ------------ /  *  =
   =  *  #               /  | FCIP     | #              /  *  =
   =  *  #               /  | Entity B | #              /  *  =
   =  *  #               /  ------------ #              /  *  =
   =  *  ################+################              /  *  =
   =  *                  ////////////////////////////////  *  =
   =  *                                                    *  =
   =  ******************************************************  =
   =                                                          =
   ============================================================


   Fig. 2 FCIP Entity and Discovery Domain Example.


   Within  the  specified  scope "fcip", the administrator has defined a
   discovery domain "purple", allowing FCIP Entities  A,  B,  and  C  to
   discover  each other.  This discovery domain is illustrated using the
   "*" character.


   Within the specified scope "fcip", the administrator  has  defined  a
   discovery  domain  "orange",  allowing FCIP Entity A to discover FCIP
   Entity  B,  but  not  FCIP  Entity  C.   This  discovery  domain   is
   illustrated using the "#" character.


   Within  the  specified  scope "fcip", the administrator has defined a
   discovery domain "blue", allowing FCIP  Entity  C  to  discover  FCIP
   Entity   B,  but  not  FCIP  Entity  A.   This  discovery  domain  is
   illustrated using the "/" character.


   For this example, the value of  the  fcip-discovery-domain  attribute
   for each FCIP Entity is as follows:


   FCIP Entity A = orange,purple


   FCIP Entity B = orange,blue,purple


   FCIP Entity C = blue,purple





Peterson                     Standards Track                    [Page 5]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



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.
   Also note that SLP advertisements that occur inside a private address
   realm  may  be  unreachable  outside  that  realm.   Below  are  some
   recommendations for dealing with SLPv2 and NAT/NAPT devices:


   - A fully-qualified domain name (i.e., not an IP address)  SHOULD  be
     used in service URLs and the mgmt-entity attribute [RFC1900].


   - Configure  the  NAPT  device  to provide default mapping(s) for the
     well-known port(s) and use the default IANA-assigned FCIP TCP  port
     number in service URLs, when possible.



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 section 6.


   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 =




Peterson                     Standards Track                    [Page 6]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



     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.


   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=\ff\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 section 6.


   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




Peterson                     Standards Track                    [Page 7]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



     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 = hostport
     hostport = host [ ":" port ]
     host = hostname / hostnumber
     hostname = *( domainlabel "." ) toplabel
     alphanum = ALPHA / DIGIT
     domainlabel = alphanum / alphanum * [alphanum / "-"] alphanum
     toplabel = ALPHA / ALPHA * [ alphanum / "-" ] alphanum
     hostnumber = ipv4-number
     ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
     port = 1*DIGIT


     ;
     ; A DNS host name should be used along with the well-known
     ; IANA FCIP port number for operation with NAT/NAPT devices.
     ;
     ; Examples:
     ; service:fcip:entity://host.example.com
     ; service:fcip:entity://192.0.2.0:4000
     ;


   fcip-entity-name = opaque L
   # If the FCIP Entity is a VE_Port/B_Access implementation [FC-BB-2]
   # residing in a switch, the fcip-entity-name is the Fibre Channel
   # Switch Name [FC-SW-2]. Otherwise, the fcip-entity-name is the
   # Fibre Channel Node Name [FC-FS] of the port (e.g., an Nx_Port)
   # associated with the FCIP Entity.
   # An entity representing multiple endpoints must register each of
   # the endpoints using SLPv2.


   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 L
   # The URL's of the management interface(s) appropriate for SNMP,
   # web-based, or telnet management of the FCIP Entity.
   # Examples:
   #  snmp://192.0.2.0
   #  http://fcipentity.example.com:1080/




Peterson                     Standards Track                    [Page 8]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



   #  telnet://fcipentity.example.com


   fcip-discovery-domain = string M L
   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


   The  SLPv2  security model as specified in [RFC2608] does not provide
   confidentiality, but does provide an authentication mechanism for UAs
   to assure that service advertisements only come from trusted SAs with
   the exception that it does not provide a  mechanism  to  authenticate
   "zero-result  responses". See [IPS-SEC] for a discussion of the SLPv2
   [RFC2608] security model.


   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.


   When no security is used for SLPv2, there is a risk  of  distribution
   of  false  discovery information. The primary countermeasure for this
   risk is authentication. When this  risk  is  a  significant  concern,
   IPsec  SAs  SHOULD  be  used for FCIP traffic subject to this risk to
   ensure that FCIP traffic  only  flows  between  endpoints  that  have
   participated  in  IKE  authentication.  For  example,  if an attacker
   distributes discovery information falsely claiming that it is an FCIP
   endpoint,   it   will   lack  the  secret  information  necessary  to
   successfully complete IKE authentication, and hence will be prevented
   from falsely sending or receiving FCIP traffic.


   There  remains a risk of a denial of service attack based on repeated
   use of false discovery information that will cause initiation of  IKE
   negotiation.   The   countermeasures   for  this  are  administrative
   configuration of each FCIP Entity to  limit  the  peers  that  it  is
   willing  to  communicate  with  (i.e., by IP address range and/or DNS
   domain), and maintenance of a negative authentication cache to  avoid
   repeatedly  contacting  an  FCIP  Entity  that fails to authenticate.
   These three measures (i.e.,  IP  address  range  limits,  DNS  domain
   limits, negative authentication cache) MUST be implemented.







Peterson                     Standards Track                    [Page 9]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



6.1.  Security Implementation


   Security for SLPv2 in an IP storage environment is specified in [IPS-
   SEC].


   IPsec SHOULD be implemented for SLPv2 as specified in [IPS-SEC]. This
   includes ESP with a non-null transform to provide both authentication
   and confidentiality.


   SLPv2 authentication is OPTIONAL to  implement  and  use,  and  SLPv2
   authentication SHOULD be implemented when IPsec is not supported.



7.  IANA Considerations


   After   RFC  publication,  an  SLP  designated  expert  will  oversee
   registration of the template(s) in the IANA repository.



8.  Internationalization Considerations


   SLP allows internationalized strings to be registered and  retrieved.
   Attributes  in the template that are not marked with an 'L' (literal)
   will  be  registered  in  a  localized  manner.  An  "en"   (English)
   localization MUST be registered, and others MAY be registered.


9.  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.



10.  Acknowledgements


   This  draft  was  produced by the FCIP discovery team, including Todd
   Sperry (Adaptec), Larry Lamars (SanValley), Robert Snively (Brocade),
   Ravi  Natarajan  (Lightsand),  Anil Rijhsinghani (McData), and Venkat
   Rangan (Rhapsody Networks). Thanks also to  Mark  Bakke  (Cisco)  for
   initial  help  and  consultation,  and David Black, Erik Guttman, and
   James Kempf for assistance during expert review.


11.  Normative References


The  references  in  this  section  were  current  at  the   time   this
specification  was  approved.  This specification is intended to operate
with newer versions of  the  referenced  documents.  Looking  for  newer
references is recommended.




Peterson                     Standards Track                   [Page 10]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



[RFC2608]   E.  Guttman,  C.  Perkins,  J.  Veizades,  M.  Day. "Service
            Location Protocol, version 2",  RFC 2608, July 1999.


[RFC2119]   S.  Bradner.  "Key  Words  for  Use  in  RFCs  to   Indicate
            Requirement Levels",  RFC 2119, March 1997.


[RFC1900]   B.  Carpenter,  Y.  Rekhter.  "Renumbering  Needs Work", RFC
            1900, February 1996.


[FCIP]      Rajagopal,     et.     al.      "FCIP",      draft-ietf-ips-
            fcovertcpip-12.txt, February 2003.


[FC-SW-2]   Fibre  Channel  Switch  Fabric  -  2,  ANSI INCITS.355:2001,
            December 12, 2001.


[FC-BB-2]   Fibre Channel Backbone - 2, T11  Project  1238-D,  Rev  6.0,
            February 4, 2003.


[FC-FS]     Fibre Channel Framing and Signaling, T11 Project 1331-D, Rev
            1.90, April 9, 2003.


[IPS-SEC]   B. Aboba, et. al. "Securing  Block  Storage  Protocols  over
            IP", draft-ietf-ips-security-19.txt, January 14, 2003.



12.  Informative References


The references in this section may further assist the reader.


[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.


[RFC3082]   J. Kempf, J Goldschmidt. "Notification and Subscription  for
            SLP", RFC 3082, March 2001.


[RFC3105]   Kempf, J., Montenegro, G. "Finding an RSIP Server with SLP",
            RFC 3105, October 2001.


[FCIP-MIB]  Rijhsinghani,  et.  al.  "FCIP  MIB",   draft-ietf-ips-fcip-
            mib-05.txt, December 2003.






Peterson                     Standards Track                   [Page 11]

Internet-Draft     Finding FCIP Entities Using SLPv2        January 2004



Author's  Address:


       David Peterson
       SBS Technologies, Inc.
       1284 Corporate Center Dr.
       St. Paul, MN
       USA 55121


       Voice:  +1 651-905-4755
       E-Mail: dap@sbs.com


Full Copyright Statement


   Copyright (C) The Internet Society (2003).  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
   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]

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/