RFC 4171
Internet Storage Name Service (iSNS)
7. Security Considerations
7.1. iSNS Security Threat Analysis
When the iSNS protocol is deployed, the interaction between iSNS server and iSNS clients is subject to the following security threats: a) An attacker could alter iSNS protocol messages, such as to direct iSCSI and iFCP devices to establish connections with rogue peer devices, or to weaken/eliminate IPSec protection for iSCSI or iFCP traffic. b) An attacker could masquerade as the real iSNS server using false iSNS heartbeat messages. This could cause iSCSI and iFCP devices to use rogue iSNS servers. c) An attacker could gain knowledge about iSCSI and iFCP devices by snooping iSNS protocol messages. Such information could aid an attacker in mounting a direct attack on iSCSI and iFCP devices, such as a denial-of-service attack or outright physical theft. To address these threats, the following capabilities are needed: a) Unicast iSNS protocol messages may need to be authenticated. In addition, to protect against threat c), confidentiality support is desirable and is REQUIRED when certain functions of iSNS server are utilized.
b) Multicast iSNS protocol messages such as the iSNS heartbeat
message may need to be authenticated. These messages need not be
confidential since they do not leak critical information.
7.2. iSNS Security Implementation and Usage Requirements
If the iSNS server is used to distribute authorizations for
communications between iFCP and iSCSI peer devices, IPsec ESP with
null transform MUST be implemented, and non-null transform MAY be
implemented. If a non-null transform is implemented, then the DES
encryption algorithm SHOULD NOT be used.
If the iSNS server is used to distribute security policy for iFCP and
iSCSI devices, then authentication, data integrity, and
confidentiality MUST be supported and used. Where confidentiality is
desired or required, IPSec ESP with non-null transform SHOULD be
used, and the DES encryption algorithm SHOULD NOT be used.
If the iSNS server is used to provide the boot list for clients, as
described in Section 6.11.2.9, then the iSCSI boot client SHOULD
implement a secure iSNS connection.
In order to protect against an attacker masquerading as an iSNS
server, client devices MUST support the ability to authenticate
broadcast or multicast messages such as the iSNS heartbeat. The iSNS
authentication block (which is identical in format to the SLP
authentication block) SHALL be used for this purpose. iSNS clients
MUST implement the iSNS authentication block and MUST support BSD
value 0x002. If the iSNS server supports broadcast or multicast iSNS
messages (i.e., the heartbeat), then the server MUST implement the
iSNS authentication block and MUST support BSD value 0x002. Note
that the authentication block is used only for iSNS broadcast or
multicast messages and MUST NOT be used in unicast iSNS messages.
There is no requirement that the communicating identities in iSNS
protocol messages be kept confidential. Specifically, the identity
and location of the iSNS server is not considered confidential.
For protecting unicast iSNS protocol messages, iSNS servers
supporting security MUST implement ESP in tunnel mode and MAY
implement transport mode.
All iSNS implementations supporting security MUST support the replay
protection mechanisms of IPsec.
iSNS security implementations MUST support both IKE Main Mode and
Aggressive Mode for authentication, negotiation of security
associations, and key management, using the IPSec DOI [RFC2407].
Manual keying SHOULD NOT be used since it does not provide the necessary rekeying support. Conforming iSNS security implementations MUST support authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKEs Sections 5.2 and 5.3 [RFC2409] SHOULD NOT be supported. Conforming iSNS implementations MUST support both IKE Main Mode and Aggressive Mode. IKE Main Mode with pre-shared key authentication SHOULD NOT be used when either of the peers use dynamically assigned IP addresses. Although Main Mode with pre-shared key authentication offers good security in many cases, situations where dynamically assigned addresses are used force the use of a group pre-shared key, which is vulnerable to man-in-the-middle attack. IKE Identity Payload ID_KEY_ID MUST NOT be used. When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. In all cases, access to locally stored secret information (pre-shared key or private key for digital signing) MUST be suitably restricted, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols. When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures. When the iSNS server is used without security, IP block storage protocol implementations MUST support a negative cache for authentication failures. This allows implementations to avoid continually contacting discovered endpoints that fail authentication within IPsec or at the application layer (in the case of iSCSI Login). The negative cache need not be maintained within the IPsec implementation, but rather within the IP block storage protocol implementation.7.3. Discovering Security Requirements of Peer Devices
Once communication between iSNS clients and the iSNS server has been secured through use of IPSec, the iSNS client devices have the capability to discover the security settings that they need to use for their peer-to-peer communications using the iSCSI and/or iFCP protocols. This provides a potential scaling advantage over device- by-device configuration of individual security policies for each iSCSI and iFCP device.
The iSNS server stores security settings for each iSCSI and iFCP device interface. These security settings, which can be retrieved by authorized hosts, include use or non-use of IPSec, IKE, Main Mode, and Aggressive Mode. For example, IKE may not be enabled for a particular interface of a peer device. If a peer device can learn of this in advance by consulting the iSNS server, it will not need to waste time and resources attempting to initiate an IKE phase 1 session with that peer device interface. If iSNS is used for this purpose, then the minimum information that should be learned from the iSNS server is the use or non-use of IKE and IPSec by each iFCP or iSCSI peer device interface. This information is encoded in the Security Bitmap field of each Portal of the peer device, and is applicable on a per-interface basis for the peer device. iSNS queries for acquiring security configuration data about peer devices MUST be protected by IPSec/ESP authentication.7.4. Configuring Security Policies of iFCP/iSCSI Devices
Use of iSNS for distribution of security policies offers the potential to reduce the burden of manual device configuration, and to decrease the probability of communications failures due to incompatible security policies. If iSNS is used to distribute security policies, then IPSec authentication, data integrity, and confidentiality MUST be used to protect all iSNS protocol messages. The complete IKE/IPSec configuration of each iFCP and/or iSCSI device can be stored in the iSNS server, including policies that are used for IKE Phase 1 and Phase 2 negotiations between client devices. The IKE payload format includes a series of one or more proposals that the iSCSI or iFCP device will use when negotiating the appropriate IPsec policy to use to protect iSCSI or iFCP traffic. In addition, the iSCSI Authentication Methods used by each iSCSI device can also be stored in the iSNS server. The iSCSI AuthMethod field (tag=42) contains a null-terminated string embedded with the text values indicating iSCSI authentication methods to be used by that iSCSI device. Note that iSNS distribution of security policy is not necessary if the security settings can be determined by other means, such as manual configuration or IPsec security policy distribution. If a network entity has already obtained its security configuration via other mechanisms, then it MUST NOT request security policy via iSNS.
7.5. Resource Issues
The iSNS protocol is lightweight and will not generate a significant amount of traffic. iSNS traffic is characterized by occasional registration, notification, and update messages that do not consume significant amounts of bandwidth. Even software-based IPSec implementations should not have a problem handling the traffic loads generated by the iSNS protocol. To fulfill iSNS security requirements, the only additional resources needed beyond what is already required for iSCSI and iFCP involve the iSNS server. Because iSCSI and iFCP end nodes are already required to implement IKE and IPSec, these existing requirements can also be used to fulfill IKE and IPSec requirements for iSNS clients.7.6. iSNS Interaction with IKE and IPSec
When IPSec security is enabled, each iSNS client with at least one Storage Node that is registered in the iSNS database SHALL maintain at least one phase-1 security association with the iSNS server. All iSNS protocol messages between iSNS clients and the iSNS server SHALL be protected by a phase-2 security association. When a Network Entity is removed from the iSNS database, the iSNS server SHALL send a phase-1 delete message to the associated iSNS client IKE peer, and tear down all phase-1 and phase-2 SAs associated with that iSNS client.8. IANA Considerations
The well-known TCP and UDP port number for iSNS is 3205. The standards action of this RFC creates two registries to be maintained by IANA in support of iSNSP and assigns initial values for both registries. The first registry is of Block Storage Protocols supported by iSNS. The second registry is a detailed registry of standard iSNS attributes that can be registered to and queried from the iSNS server. Note that this RFC uses the registry created for Block Structure Descriptor (BSD) in Section 15 of Service Location Protocol, Version 2 [RFC2608].8.1. Registry of Block Storage Protocols
In order to maintain a registry of block storage protocols supported by iSNSP, IANA will assign a 32-bit unsigned integer number for each block storage protocol supported by iSNS. This number is stored in the iSNS database as the Entity Protocol. The initial set of values to be maintained by IANA for Entity Protocol is indicated in the
table in Section 6.2.2. Additional values for new block storage protocols to be supported by iSNS SHALL be assigned by the IPS WG Chairperson, or by a Designated Expert [RFC2434] appointed by the IETF Transport Area Director.8.2. Registry of Standard iSNS Attributes
IANA is responsible for creating and maintaining the Registry of Standard iSNS Attributes. The initial list of iSNS attributes is described in Section 6. For each iSNS attribute this information MUST include, its tag value, the attribute length, and the tag values for the set of permissible registration and query keys that can be used for that attribute. The initial list of iSNS attributes to be maintained by IANA is indicated in Section 6.1. Additions of new standard attributes to the Registry of Standard iSNS Attributes SHALL require IETF Consensus [RFC2434]. The RFC required for this process SHALL specify use of tag values reserved for IANA allocation in Section 6.1. The RFC SHALL specify as a minimum, the new attribute tag value, attribute length, and the set of permissible registration and query keys that can be used for the new attribute. The RFC SHALL also include a discussion of the reasons for the new attribute(s) and how the new attribute(s) are to be used. As part of the process of obtaining IETF Consensus, the proposed RFC and its supporting documentation SHALL be made available to the IPS WG mailing list or, if the IPS WG is disbanded at the time, to a mailing list designated by the IETF Transport Area Director. The review and comment period SHALL last at least three months before the IPS WG Chair or a person designated by the IETF Transport Area Director decides either to reject the proposal or to forward the draft to the IESG for publication as an RFC. When the specification is published as an RFC, then IANA will register the new iSNS attribute(s) and make the registration available to the community.8.3. Block Structure Descriptor (BSD) Registry
Note that IANA is already responsible for assigning and maintaining values used for the Block Structure Descriptor for the iSNS Authentication Block (see Section 5.5). Section 15 of [RFC2608] describes the process for allocation of new BSD values.
9. Normative References
[iSCSI] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004. [iFCP] Monia, C., Mullendore, R., Travostino, F., Jeong, W., and M. Edwards, "iFCP - A Protocol for Internet Fibre Channel Storage Networking", RFC 4172, September 2005. [iSNSOption] Monia, C., Tseng, J., and K. Gibbons, The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service, RFC 4174, September 2005. [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2 ", RFC 2608, June 1999. [iSCSI-SLP] Bakke, M., Hufferd, J., Voruganti, K., Krueger, M., and T. Sperry, "Finding Internet Small Computer Systems Interface (iSCSI) Targets and Name Servers by Using Service Location Protocol version 2 (SLP), RFC 4018, April 2005. [iSCSI-boot] Sarkar, P., Missimer, D., and C. Sapuntzakis, "Bootstrapping Clients using the Internet Samll Computer System Interface (iSCSI) Protocol", RFC 4173, September 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [STRINGPREP] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004. [NAMEPREP] Hoffman, P. Nameprep: A Stringprep Profile for Internationalized Domain Names, July 2002. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[EUI-64] Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority, May 2001, IEEE [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [802-1990] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, Technical Committee on Computer Communications of the IEEE Computer Society, May 31, 1990 [FC-FS] Fibre Channel Framing and Signaling Interface, NCITS Working Draft Project 1331-D10. Informative References
[iSNSMIB] Gibbons, K., et al., "Definitions of Managed Objects for iSNS (Internet Storage name Service)", Work in Progress, July 2003. [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997 [FC-GS-4] Fibre Channel Generic Services-4 (work in progress), NCITS Working Draft Project 1505-D [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
Appendix A: iSNS Examples
A.1. iSCSI Initialization Example
This example assumes an SLP Service Agent (SA) has been implemented on the iSNS host, and an SLP User Agent (UA) has been implemented on the iSNS initiator. See [RFC2608] for further details on SAs and UAs. This example also assumes that the target is configured to use the iSNS server, and have its access control policy subordinated to the iSNS server.A.1.1. Simple iSCSI Target Registration
In this example, a simple target with a single iSCSI name registers with the iSNS server. The target is represented in the iSNS by an Entity containing one Storage Node, one Portal, and an implicitly registered Portal Group that provides a relationship between the Storage Node and Portal. The target has not been assigned a Fully Qualified Domain Name (FQDN) by the administrator. In this example, because a PG object is not explicitly registered, a Portal Group with a PGT of 1 is implicitly registered. In this example SLP is used to discover the location of the iSNS Server. An alternative is to use the iSNS DHCP option [iSNSOption] to discover the iSNS server. +--------------------------+------------------+-------------------+ | iSCSI Target Device | iSNS Server |Management Station | +--------------------------+------------------+-------------------+ |Discover iSNS--SLP------->| |/*mgmt station is | | |<--SLP--iSNS Here:| administratively | | | 192.0.2.100 | authorized to view| | | | all DDs. Device | | DevAttrReg--------->| | NAMEabcd was | |Src:(tag=32) "NAMEabcd" | | previously placed | |Key: <none present> | | into DDabcd along | |Oper Attrs: | | with devpdq and | |tag=1: NULL | | devrst. | |tag=2: "iSCSI" | | | |tag=16: 192.0.2.5 | | | |tag=17: 5001 | | | |tag=32: "NAMEabcd" | | | |tag=33: target | | | |tag=34: "disk 1" | | | | |<---DevAttrRegRsp | | | |SUCCESS | | | |Key:(tag=1) "isns:0001" | | |Oper Attrs: | | | |tag=1: "isns:0001"| | | |tag=2: "iSCSI" | |
| |tag=16: 192.0.2.5 | | | |tag=17: 5001 | | | |tag=32: "NAMEabcd"|/* previously | | |tag=33: target | placed in a DD */ | | |tag=34: "disk 1" | | | | | | | | SCN-------->| | | |(or SNMP notification) | | |dest:(tag=32):"MGMTname1" | | |time:(tag=4): <current time> | | |tag=35: "MGT-SCN, OBJ-ADD" | | |tag=32: "NAMEabcd"| | | | |<-------SCNRsp | | DevAttrQry--------->| | | |Src:(tag=32) "NAMEabcd" | | | |Key:(tag=33) "initiator" | | | |Oper Attrs: | | | |tag=16: NULL | | | |tag=17: NULL | | | |tag=32: NULL | | | |/*Query asks for all initr| | | |devices' IP address, port |<---DevAttrQryRsp | | |number, and Name*/ |SUCCESS | | | |tag=16:192.0.2.1 | | | |tag=17:50000 | | | |tag=32:"devpdq" | | | |tag=16:192.0.2.2 | | | |tag=17:50000 | | | |tag=32:"devrst" | | |/*************************| |<-----DevAttrQry | |Our target "NAMEabcd" | |src: "MGMTname1" | |discovers two initiators | key:(tag=32)"NAMEabcd" |in shared DDs. It will | |Op Attrs: | |accept iSCSI logins from | |tag=16: NULL | |these two identified | |tag=17: NULL | |initiators presented by | |tag=32: NULL | |iSNS | | | |*************************/| DevAttrQryRsp--->| | | |SUCCESS | | | |tag=16: 192.0.2.5 | | | |tag=17: 5001 | | | |tag=32: "NAMEabcd"| | +--------------------------+------------------+-------------------+
A.1.2. Target Registration and DD Configuration
In this example, a more complex target, with two Storage Nodes and two Portals using ESI monitoring, registers with the iSNS. This target has been configured with a Fully Qualified Domain Name (FQDN) in the DNS servers, and the user wishes to use this identifier for the device. The target explicitly registers Portal Groups to describe how each Portal provides access to each Storage Node. One target Storage Node allows coordinated access through both Portals. The other Storage Node allows access, but not coordinated access, through both Portals. +--------------------------+------------------+-------------------+ | iSCSI Target Device | iSNS Server |Management Station | +--------------------------+------------------+-------------------+ |Discover iSNS--SLP--> | |/*mgmt station is | | |<--SLP--iSNS Here:| administratively | | | 192.0.2.100 | authorized to view| | DevAttrReg--> | | all DDs */ | |Src: | | | |tag=32: "NAMEabcd" | | | |Msg Key: | | | |tag=1: "jbod1.example.com"| | | |Oper Attrs: | | | |tag=1: "jbod1.example.com"| | | |tag=2: "iSCSI" | | | |tag=16: 192.0.2.4 | | | |tag=17: 5001 | | | |tag=19: 5 | | | |tag=20: 5002 | | | |tag=16: 192.0.2.5 | | | |tag=17: 5001 | | | |tag=19: 5 | | | |tag=20: 5002 | | | |tag=32: "NAMEabcd" | | | |tag=33: "Target" | | | |tag=34: "Storage Array 1" | | | |tag=51: 10 | | | |tag=49: 192.0.2.4 | | | |tag=50: 5001 | | | |tag=49: 192.0.2.5 | | | |tag=50: 5001 | | | |tag=32: "NAMEefgh" | | | |tag=33: "Target" | | | |tag=34: "Storage Array 2" |/*****************| | |tag=51: 20 |jbod1.example.com is | |tag=49: 192.0.2.4 |now registered in | | |tag=50: 5001 |iSNS, but is not | |
|tag=51: 30 |in any DD. Therefore, | |tag=49: 192.0.2.5 |no other devices | | |tag=50: 5001 |can "see" it. | | | |*****************/| | | |<--DevAttrRegRsp | | | |SUCCESS | | | |Msg Key: | | | |tag=1: "jbod1.example.com" | | |Oper Attrs: | | | |tag=1: "jbod1.example.com" | | |tag=2: "iSCSI" | | | |tag=16: 192.0.2.4 | | | |tag=17: 5001 | | | |tag=19: 5 | | | |tag=20: 5002 | | | |tag=16: 192.0.2.5 | | | |tag=17: 5001 | | | |tag=19: 5 | | | |tag=20: 5002 | | | |tag=32: "NAMEabcd"| | | |tag=33: "Target" | | | |tag=34: "Storage Array 1" | | |tag=48: "NAMEabcd"| | | |tag=49: 192.0.2.4 | | | |tag=50: 5001 | | | |tag=51: 10 | | | |tag=48: "NAMEabcd"| | | |tag=49: 192.0.2.5 | | | |tag=50: 5001 | | | |tag=51: 10 | | | |tag=32: "NAMEefgh"| | | |tag=33: "Target" | | | |tag=34: "Storage Array 2" | | |tag=43: X.509 cert| | | |tag=48: "NAMEefgh"| | | |tag=49: 192.0.2.4 | | | |tag=50: 5001 | | | |tag=51: 20 | | | |tag=48: "NAMEefgh"| | | |tag=49: 192.0.2.5 | | | |tag=50: 5001 | | | |tag=51: 30 | | | | | | | | SCN------> | | | | (or SNMP notification) | | |dest:(tag=32)"mgmt.example.com" | | |time:(tag=4): <current time> | | |tag=35: "MGT-SCN, OBJ-ADD" |
| |tag=32: "NAMEabcd"| | | |tag=35: "MGT-SCN, OBJ-ADD" | | |tag=32: "NAMEefgh"| | | | |<--SCNRsp | | | |SUCCESS | | | tag=32:"mgmt.example.com"| | | | | | | |<--DevAttrQry | | | |Src: | | | tag=32:"mgmt.example.com" | | |Msg Key: | | | |tag=32: "NAMEabcd" | | | |Oper Attrs: | | | |tag=16: <0-length> | | | |tag=17: <0-length> | | | |tag=32: <0-length> | | | | | | | DevAttrQryRsp--> | | | |SUCCESS | | | |Msg Key: | | | |tag=32: "NAMEabcd"| | | |Oper Attrs: | | | |tag=16: 192.0.2.4 | | | |tag=17: 5001 | | | |tag=32:"NAMEabcd" | | | |tag=16: 192.0.2.5 | | | |tag=17: 5001 | | | |tag=32:"NAMEabcd" | | | | |Src: | | | tag=32:"mgmt.example.com" | | |Msg Key: | | | |tag=32: "NAMEefgh" | | | |Oper Attrs: | | | |tag=16: <0-length> | | | |tag=17: <0-length> | | | |tag=32: <0-length> | | | | | | | DevAttrQryRsp--> | | | |SUCCESS | | | |Msg Key: | | | |tag=32: "NAMEefgh"| | | |Oper Attrs: | | | |tag=16: 192.0.2.4 | | | |tag=17: 5001 | | | |tag=32:"NAMEefgh" | | | |tag=16: 192.0.2.5 |/**Mgmt Station ***| | |tag=17: 5001 |displays device, | | |tag=32:"NAMEefgh" |the operator decides
| | |to place "NAMEabcd"| | | |into Domain "DDxyz"| |/*************************| |******************/| |Target is now registered | | | |in iSNS. It is then placed| |<--DDReg | |in a pre-existing DD with | |Src: | |DD_ID 123 by a management | tag=32:"mgmt.example.com" |station. | |Msg Key: | |*************************/| |tag=2065: 123 | | | |Oper Attrs: | | | |tag=2068: "NAMEabcd" | | DDRegRsp-----> | | | |SUCCESS | | | |Msg Key: | | | |tag=2065: 123 | | | |Oper Attrs: | | | |tag=2065: 123 | | +--------------------------+------------------+-------------------+A.1.3. Initiator Registration and Target Discovery
The following example illustrates a new initiator registering with the iSNS, and discovering the target NAMEabcd from the example in A.1.2. +--------------------------+------------------+-------------------+ | iSCSI Initiator | iSNS |Management Station | +--------------------------+------------------+-------------------+ |Discover iSNS--SLP--> | |/*mgmt station is | | |<--SLP--iSNS Here:| administratively | | | 192.36.53.1 | authorized to view| |DevAttrReg--> | | all DDs ********/ | |Src: | | | |tag=32: "NAMEijkl" | | | |Msg Key: | | | |tag=1: "svr1.example.com" | | | |Oper Attrs: | | | |tag=1: "svr1.example.com" | | | |tag=2: "iSCSI" | | | |tag=16: 192.20.3.1 |/*****************| | |tag=17: 5001 |Device not in any | | |tag=19: 5 |DD, so it is | | |tag=20: 5002 |inaccessible by | | |tag=32: "NAMEijkl" |other devices | | |tag=33: "Initiator" |*****************/| | |tag=34: "Server1" | | | |tag=51: 11 | | | |tag=49: 192.20.3.1 | | |
|tag=50: 5001 | | | | |<--DevAttrRegRsp | | | |SUCCESS | | | |Msg Key: | | | |tag=1: "svr1.example.com" | | |Oper Attrs: | | | |tag=1: "svr1.example.com" | | |tag=2: "iSCSI" | | | |tag=16: 192.20.3.1| | | |tag=17: 5001 | | | |tag=19: 5 | | | |tag=20: 5002 | | | |tag=32: "NAMEijkl"| | | |tag=33: "Initiator" | | |tag=34: "Server1" | | | |tag=48: "NAMEijkl"| | | |tag=49: 192.20.3.1| | | |tag=50: 5001 | | | |tag=51: 11 | | | | | | | | SCN------> | | | | (or SNMP notification) | | |dest:(tag=32)"mgmt.example.com" | | |time:(tag=4): <current time> | | |tag=35: "MGT-SCN, OBJ-ADD" | | |tag=32: "NAMEijkl"| | | | | | | | |<------SCNRsp | | | |SUCCESS | | | tag=32:"mgmt.example.com" | | | | |SCNReg--> | | | |Src: | | | |tag=32: "NAMEijkl" | | | |Msg Key: | | | |tag=32: "NAMEijkl" | | | |Oper Attrs: | | | |tag=35: <TARG&SELF, OBJ-RMV/ADD/UPD> | | | |<--SCNRegRsp | | | |SUCCESS | | | | | | | | |<----DevAttrQry | | | |Src: | | | tag=32:"mgmt.example.com" | | |Msg Key: | | | |tag=32: "NAMEijkl" | | | |Oper Attrs: | | | |tag=16: <0-length> |
| | |tag=17: <0-length> | | | |tag=32: <0-length> | | | DevAttrQryRsp--->| | | |SUCCESS | | | |Msg Key: | | | |tag=32: "NAMEijkl"| | | |Oper Attrs: | | | |tag=16:192.20.3.1 | | | |tag=17: 5001 | | | |tag=32:"NAMEijkl" | | | | |/**Mgmt Station ***| | | |displays device, the | | |operator decides to| | | |place "NAMEijkl" into | | |pre-existing Disc | | | |Domain "DDxyz" with| | | |device NAMEabcd | | | |******************/| | | |<--DDReg | | | |Src: | | | tag=32:"mgmt.example.com" | | |Msg Key: | | | |tag=2065: 123 | | | |Oper Attrs: | | | |tag=2068: "NAMEijkl" | | | | | | DDRegRsp---->| | | |SUCCESS | | | |Msg Key: | | | |tag=2065: 123 | | | |Oper Attrs: | | | |tag=2065: 123 |/******************| | | |"NAMEijkl" has been| | | |moved to "DDxyz" | | | |******************/| | | SCN------>| | | |dest:(tag=32)"mgmt.example.com" | | |time:(tag=4): <current time> | | |tag=35: <MGT-SCN, DD/DDS-MBR-ADD> | | |tag=2065: 123 | | | |tag=2068: "NAMEijkl" | | | | | | | |<------SCNRsp | | | |SUCCESS | | | tag=32:"mgmt.example.com" | |<-----SCN | | | |dest:(tag=32)"NAMEijkl" | | |time:(tag=4): <current time> |
| |tag=35: <TARG&SELF, OBJ-ADD> | | |tag=32: "NAMEijkl"| | | SCNRsp------> | | | |SUCCESS | | | |tag=32:"NAMEijkl" | | | | | | | | |/*****************| | | |Note that NAMEabcd| | | |also receives an | | | |SCN that NAMEijkl | | | |is in the same DD | | | |*****************/| | | (to "NAMEabcd")|<-----SCN | | | |dest:(tag=32)"NAMEabcd" | | |time:(tag=4): <current time> | | |tag=35: <INIT&SELF, OBJ-ADD> | | |tag=32: "NAMEijkl"| | | SCNRsp------> | | | |SUCCESS | | | |tag=32:"NAMEabcd" | | | | | | | | DevAttrQry----------->| | | |Src: | | | |tag=32: "NAMEijkl" | | | |Msg Key: | | | |tag=33: "Target" | | | |Oper Attrs: | | | |tag=16: <0-length> | | | |tag=17: <0-length> | | | |tag=32: <0-length> | | | |tag=34: <0-length> | | | |tag=43: <0-length> | | | |tag=48: <0-length> | | | |tag=49: <0-length> | | | |tag=50: <0-length> | | | |tag=51: <0-length> | | | | |<--DevAttrQryRsp | | | |SUCCESS | | | |Msg Key: | | | |tag=33:"Target" | | | |Oper Attrs: | | | |tag=16: 192.0.2.4 | | | |tag=17: 5001 | | | |tag=32: "NAMEabcd"| | | |tag=34: "Storage Array 1" | | |tag=16: 192.0.2.5 | | | |tag=17: 5001 | | | |tag=32: "NAMEabcd"| |
| |tag=34: "Storage Array 1" | | |tag=43: X.509 cert| | | |tag=48: "NAMEabcd"| | | |tag=49: 192.0.2.4 | | | |tag=50: 5001 | | | |tag=51: 10 | | | |tag=48: "NAMEabcd"| | | |tag=49: 192.0.2.5 | | | |tag=50: 5001 | | | |tag=51: 10 | | | | | | |/***The initiator has discovered | | |the target, and has everything | | |needed to complete iSCSI login | | |The same process occurs on the | | |target side; the SCN prompts the | | |target to download the list of | | |authorized initiators from the | | |iSNS (i.e., those initiators in the | | |same DD as the target.************/ | | +--------------------------+------------------+-------------------+Acknowledgements
Numerous individuals contributed to the creation of this document through their careful review and submissions of comments and recommendations. We acknowledge the following persons for their technical contributions to this document: Mark Bakke (Cisco), John Hufferd (IBM), Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe Czap (IBM), John Dowdy (IBM), Tom McSweeney (IBM), Jim Hafner (IBM), Chad Gregory (Intel), Yaron Klein (Sanrad), Larry Lamers (Adaptec), Jack Harwood (EMC), David Black (EMC), David Robinson (Sun), Alan Warwick (Microsoft), Bob Snead (Microsoft), Fa Yoeu (Intransa), Joe White (McDATA), Charles Monia (McDATA), Larry Hofer (McDATA), Ken Hirata (Vixel), Howard Hall (Pirus), Malikarjun Chadalapaka (HP), Marjorie Krueger (HP), Siva Vaddepuri (McDATA), and Vinai Singh (American Megatrends).
Authors' Addresses
Josh Tseng Riverbed Technology 501 2nd Street, Suite 410 San Francisco, CA 94107 Phone: (650)274-2109 EMail: joshtseng@yahoo.com Kevin Gibbons McDATA Corporation 4555 Great America Parkway Santa Clara, CA 95054-1208 Phone: (408) 567-5765 EMail: kevin.gibbons@mcdata.com Franco Travostino Nortel 600 Technology Park Drive Billerica, MA 01821 USA Phone: (978) 288-7708 EMail: travos@nortel.com Curt du Laney Rincon Research Corporation 101 North Wilmot Road, Suite 101 Tucson AZ 85711 Phone: (520) 519-4409 EMail: cdl@rincon.com Joe Souza Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 Phone: (425) 706-3135 EMail: joes@exmsft.com
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.