of the SLPv2 [RFC2608] security model.

   Once a target or management server is discovered, authentication and
   authorization are handled by the iSCSI protocol, or by the management
   server's protocol.  It is the responsibility of the providers of
   these services to ensure that an inappropriately advertised or
   discovered service does not compromise 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 and iSCSI in-band authentication SHOULD be used for iSCSI
   traffic subject to this risk to ensure that iSCSI traffic only flows
   between endpoints that have participated in IKE authentication and
   iSCSI in-band authentication.  For example, if an attacker
   distributes discovery information falsely claiming that it is an
   iSCSI target, it will lack the secret information necessary to
   complete IKE authentication or iSCSI in-band authentication
   successfully and therefore will be prevented from falsely sending or
   receiving iSCSI traffic.

   A risk remains 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 iSCSI Target to limit the peers  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 iSCSI Target that fails to authenticate.
   These three measures (i.e., IP address range limits, DNS domain
   limits, negative authentication cache) MUST be implemented.

   The auth-name, auth-addr, auth-cred, and boot-list attributes
   comprise security policy information.  When these are distributed,
   IPsec MUST be implemented.





Bakke & Hufferd             Standards Track                    [Page 18]

RFC 4018                    iSCSI and SLPv2                   April 2005


6.1.  Security Implementation

   Security for SLPv2 in an IP storage environment is specified in
   [RFC3723].  IPsec is mandatory-to-implement for IPS clients and
   servers.  Thus, all IP storage clients, including those invoking SLP,
   can be assumed to support IPsec.  SLP servers, however, cannot be
   assumed to implement IPsec, since there is no such requirement in
   standard SLP.  In particular, SLP Directory Agents (DA) may be
   running on machines other than those running the IPS protocols.

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

   When SLPv2 can be used to distribute auth-name, auth-addr, auth-cred,
   and boot-list information (see section 5.2 above), IPsec MUST be
   implemented, as these items are considered sensitive security policy
   information.  If IPsec is not implemented, auth-name, auth-addr,
   auth-cred, and boot-list information MUST NOT be distributed via
   SLPv2 and MUST NOT be used if discovered via SLPv2.

   Because the IP storage services have their own authentication
   capabilities when located, SLPv2 authentication is OPTIONAL to
   implement and use (as discussed in more detail in [RFC3723]).

7.  IANA Considerations

   This document describes three SLP Templates.  They have been reviewed
   and approved by the IESG and registered in the IANA's "SVRLOC
   Templates" registry.  This process is described in the IANA
   Considerations section of [RFC2609].

8.  Summary

   This document describes how SLP can be used by iSCSI initiators to
   find iSCSI targets and storage management servers.  Service type
   templates for iSCSI targets and storage management servers are
   presented.

9.  Normative References

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

   [RFC2609]   Guttman, E., Perkins, C., and J. Kempf, "Service
               Templates and Service: Schemes", RFC 2609, June 1999.




Bakke & Hufferd             Standards Track                    [Page 19]

RFC 4018                    iSCSI and SLPv2                   April 2005


   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3491]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
               Profile for Internationalized Domain Names (IDN)", RFC
               3491, March 2003.

   [RFC3513]   Hinden, R. and S. Deering, "Internet Protocol Version 6
               (IPv6) Addressing Architecture", RFC 3513, April 2003.

   [RFC3720]   Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M.,
               and E. Zeidner, "Internet Small Computer Systems
               Interface (iSCSI)", RFC 3720, April 2004.

   [RFC3722]   Bakke, M., "String Profile for Internet Small Computer
               Systems Interface (iSCSI) Names", RFC 3722, April 2004.

   [RFC3723]   Aboba, B., Tseng, J., Walker, J., Rangan, V., and F.
               Travostino, "Securing Block Storage Protocols over IP",
               RFC 3723, April 2004.

10.  Informative References

   [RFC2614]   Kempf, J. and E. Guttman, "An API for Service Location",
               RFC 2614, June 1999.

   [SAM2]      ANSI T10.  "SCSI Architectural Model 2", March 2000.

   [RFC3721]   Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M.
               Krueger, "Internet Small Computer Systems Interface
               (iSCSI) Naming and Discovery", RFC 3721, April 2004.

   [ISNS]      Tseng, J., Gibbons, K., Travostino, F., Du Laney, C. and
               J.  Souza, "Internet Storage Name Service", Work in
               Progress, February 2004.

   [BOOT]      Sarkar, P., Missimer, D. and C. Sapuntzakis,  "A Standard
               for Bootstrapping Clients using the iSCSI Protocol", Work
               in Progress, March 2004.

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









Bakke & Hufferd             Standards Track                    [Page 20]

RFC 4018                    iSCSI and SLPv2                   April 2005


11.  Acknowledgements

   This document was produced by the iSCSI Naming and Discovery team,
   including Joe Czap, Jim Hafner, John Hufferd, and Kaladhar Voruganti
   (IBM), Howard Hall (Pirus), Jack Harwood (EMC), Yaron Klein (Sanrad),
   Marjorie Krueger (HP), Lawrence Lamers (San Valley), Todd Sperry
   (Adaptec), and Joshua Tseng (Nishan).  Thanks also to Julian Satran
   (IBM) for suggesting the use of SLP for iSCSI discovery, and to Matt
   Peterson (Caldera) and James Kempf (Sun) for reviewing the document
   from an SLP perspective.









































Bakke & Hufferd             Standards Track                    [Page 21]

RFC 4018                    iSCSI and SLPv2                   April 2005


Authors' Addresses

   Mark Bakke
   Cisco Systems, Inc.
   7900 International Drive, Suite 400
   Bloomington, MN
   USA 55425

   EMail: mbakke@cisco.com


   Kaladhar Voruganti
   IBM Almaden Research Center
   650 Harry Road
   San Jose, CA 95120

   EMail: kaladhar@us.ibm.com


   John L. Hufferd
   IBM Storage Systems Group
   5600 Cottle Road
   San Jose, CA 95193

   Phone: +1 408 997-6136
   EMail: jlhufferd@comcast.net


   Marjorie Krueger
   Hewlett-Packard Corporation
   8000 Foothills Blvd
   Roseville, CA 95747-5668, USA

   Phone: +1 916 785-2656
   EMail: marjorie_krueger@hp.com


   Todd Sperry
   Adaptec, Inc.
   691 South Milpitas Boulevard
   Milpitas, Ca. 95035

   Phone: +1 408 957-4980
   EMail: todd_sperry@adaptec.com







Bakke & Hufferd             Standards Track                    [Page 22]

RFC 4018                    iSCSI and SLPv2                   April 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Bakke & Hufferd             Standards Track                    [Page 23]