rfc3721.txt

一个学习iSCSI协议的文档

   which the initiator is either authenticated or denied the connection
   request.  If authenticated, the SOCKS server then opens a TCP
   connection to the iSCSI target using addressing information sent to
   it by the initiator in the SOCKS shim.  The SOCKS server then
   forwards iSCSI commands, data, and responses between the iSCSI
   initiator and target.

   Use of the SOCKS server requires special modifications to the iSCSI
   initiator.  No modifications are required to the iSCSI target.

   As a SOCKS server can map most of the addresses and information
   contained within the IP and TCP headers, including sequence numbers,
   its effects on iSCSI are identical to those in the port redirector.

B.3. SCSI gateway

   This gateway presents logical targets (iSCSI Names) to the
   initiators, and maps them to SCSI targets as it chooses.  The
   initiator sees this gateway as a real iSCSI target, and is unaware of
   any proxy or gateway behavior.  The gateway may manufacture its own
   iSCSI Names, or map the iSCSI names using information provided by the
   physical SCSI devices.  It is the responsibility of the gateway to



Bakke, et al.                Informational                     [Page 17]

RFC 3721               iSCSI Naming and Discovery             April 2004


   ensure the uniqueness of any iSCSI name it manufactures.  The gateway
   may have to account for multiple gateways having access to a single
   physical device.  This type of gateway is used to present parallel
   SCSI, Fibre Channel, SSA, or other devices as iSCSI devices.

   Effects on iSCSI:

   -  Since the initiator is unaware of any addresses beyond the
      gateway, the gateway's own address is for all practical purposes
      the real address of a target.  Only the iSCSI Name needs to be
      passed.  This is already done in iSCSI, so there are no further
      requirements to support SCSI gateways.

B.4. iSCSI Proxy

   An iSCSI proxy is a gateway that terminates the iSCSI protocol on
   both sides, rather than translate between iSCSI and some other
   transport.  The proxy functionality is aware that both sides are
   iSCSI, and can take advantage of optimizations, such as the
   preservation of data integrity checks.  Since an iSCSI initiator's
   discovery or configuration of a set of targets makes use of address-
   independent iSCSI names, iSCSI does not have the same proxy
   addressing problems as HTTP, which includes address information into
   its URLs.  If a proxy is to provide services to an initiator on
   behalf of a target, the proxy allows the initiator to discover its
   address for the target, and the actual target device is discovered
   only by the proxy.  Neither the initiator nor the iSCSI protocol
   needs to be aware of the existence of the proxy.  Note that a SCSI
   gateway may also provide iSCSI proxy functionality when mapping
   targets between two iSCSI interfaces.

   Effects on iSCSI:

   -  Same as a SCSI gateway.  The only other effect is that iSCSI must
      separate data integrity checking on iSCSI headers and iSCSI data,
      to allow the data integrity check on the data to be propagated
      end-to-end through the proxy.

B.5.  Stateful Inspection Firewall (stealth iSCSI firewall)

   The stealth model would exist as an iSCSI-aware firewall, that is
   invisible to the initiator, but provides capabilities found in the
   iSCSI proxy.

   Effects on iSCSI:

   -  Since this is invisible, there are no additional requirements on
      the iSCSI protocol for this one.



Bakke, et al.                Informational                     [Page 18]

RFC 3721               iSCSI Naming and Discovery             April 2004


   This one is more difficult in some ways to implement, simply because
   it has to be part of a standard firewall product, rather than part of
   an iSCSI-type product.

   Also note that this type of firewall is only effective in the
   outbound direction (allowing an initiator behind the firewall to
   connect to an outside target), unless the iSCSI target is located in
   a DMZ (De-Militarized Zone) [RFC3303].  It does not provide adequate
   security otherwise.

Appendix C: iSCSI Names and Security Identifiers

   This document has described the creation and use of iSCSI Node Names.
   There will be trusted environments where this is a sufficient form of
   identification.  In these environments the iSCSI Target may have an
   Access Control List (ACL), which will contain a list of authorized
   entities that are permitted to access a restricted resource (in this
   case a Target Storage Controller).  The iSCSI Target will then use
   that ACL to permit (or not) certain iSCSI Initiators to access the
   storage at the iSCSI Target Node.  This form of ACL is used to
   prevent trusted initiators from making a mistake and connecting to
   the wrong storage controller.

   It is also possible that the ACL and the iSCSI Initiator Node Name
   can be used in conjunction with the SCSI layer for the appropriate
   SCSI association of LUNs with the Initiator.  The SCSI layer's use of
   the ACL will not be discussed further in this document.

   There will be situations where the iSCSI Nodes exist in untrusted
   environments.  That is, some iSCSI Initiator Nodes may be authorized
   to access an iSCSI Target Node, however, because of the untrusted
   environment, nodes on the network cannot be trusted to give the
   correct iSCSI Initiator Node Names.

   In untrusted environments an additional type of identification is
   required to assure the target that it really knows the identity of
   the requesting entity.

   The authentication and authorization in the iSCSI layer is
   independent of anything that IPSec might handle, underneath or around
   the TCP layer.  This means that the initiator node needs to pass some
   type of security related identification information (e.g., userid) to
   a security authentication process such as SRP, CHAP, Kerberos etc.
   (These authentication processes will not be discussed in this
   document.)






Bakke, et al.                Informational                     [Page 19]

RFC 3721               iSCSI Naming and Discovery             April 2004


   Upon the completion of the iSCSI security authentication, the
   installation knows "who" sent the request for access.  The
   installation must then check to ensure that such a request, from the
   identified entity, is permitted/authorized.  This form of
   Authorization is generally accomplished via an Access Control List
   (ACL) as described above.  Using this authorization process, the
   iSCSI target will know that the entity is authorized to access the
   iSCSI Target Node.

   It may be possible for an installation to set a rule that the
   security identification information (e.g., UserID) be equal to the
   iSCSI Initiator Node Name.  In that case, the ACL approach described
   above should be all the authorization that is needed.

   If, however, the iSCSI Initiator Node Name is not used as the
   security identifier there is a need for more elaborate ACL
   functionality.  This means that the target requires a mechanism to
   map the security identifier (e.g., UserID) information to the iSCSI
   Initiator Node Name.  That is, the target must be sure that the
   entity requesting access is authorized to use the name, which was
   specified with the Login Keyword "InitiatorName=".  For example, if
   security identifier 'Frank' is authorized to access the target via
   iSCSI InitiatorName=xxxx, but 'Frank' tries to access the target via
   iSCSI InitiatorName=yyyy, then this login should be rejected.

   On the other hand, it is possible that 'Frank' is a roaming user (or
   a Storage Administrator) that "owns" several different systems, and
   thus, could be authorized to access the target via multiple different
   iSCSI initiators.  In this case, the ACL needs to have the names of
   all the initiators through which 'Frank' can access the target.

   There may be other more elaborate ACL approaches, which can also be
   deployed to provide the installation/user with even more security
   with flexibility.

   The above discussion is trying to inform the reader that, not only is
   there a need for access control dealing with iSCSI Initiator Node
   Names, but in certain iSCSI environments there might also be a need
   for other complementary security identifiers.












Bakke, et al.                Informational                     [Page 20]

RFC 3721               iSCSI Naming and Discovery             April 2004


Authors' Addresses

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

   EMail: [e-mail]


   Mark Bakke
   Cisco Systems, Inc.
   6450 Wedgwood Road
   Maple Grove, MN 55311

   Phone: [phone]
   EMail: [e-mail]


   Jim Hafner
   IBM Almaden Research Center
   650 Harry Road
   San Jose, CA 95120

   Phone: [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]


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

   Phone: [phone]
   EMail: [e-mail]







Bakke, et al.                Informational                     [Page 21]

RFC 3721               iSCSI Naming and Discovery             April 2004


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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-
   [e-mail].

Acknowledgement

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









Bakke, et al.                Informational                     [Page 22]