RFC 7145
Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification
11. Security Considerations
When iSER is layered on top of an RCaP layer and provides the RDMA extensions to the iSCSI protocol, the security considerations of iSER are the same as that of the underlying RCaP layer. For iWARP, this is described in [RDMAP] and [RDDPSEC], plus the updates to both of those RFCs that are contained in [IPSEC-IPS]. Since iSER-assisted iSCSI protocol is still functionally iSCSI from a security considerations perspective, all of the iSCSI security requirements as described in [iSCSI] apply. If iSER is layered on top of a non-IP-based RCaP layer, all the security protocol mechanisms applicable to that RCaP layer are also applicable to an iSCSI/iSER connection. If iSER is layered on top of a non-IP protocol, the IPsec mechanism as specified in [iSCSI] MUST be implemented at any point where the iSER protocol enters the IP network (e.g., via gateways), and the non-IP protocol SHOULD implement (optional to use) a packet-by-packet security protocol equal in strength to the IPsec mechanism specified by [iSCSI]. In order to protect target RCaP connection resources from possible resource exhaustion attacks, allocation of such resources for a new connection MUST be delayed until it is reasonably certain that the new connection is not part of a resource exhaustion attack (e.g., until after the SecurityNegotiation stage of Login); see Section 5.1.2. A valid STag exposes I/O Buffer resources to the network for access via the RCaP. The security measures for the RCAP and iSER described in the above paragraphs can be used to protect data in an I/O buffer from undesired disclosure or modification, and these measures are of heightened importance for implementations that retain (e.g., cache) STags for use in multiple tasks (e.g., iSCSI I/O operations) because the resources are exposed to the network for a longer period of time. A complementary means of controlling I/O Buffer resource exposure is invalidation of the STag after completion of the associated task, as specified in Section 1.5.1. The use of Send with Invalidate messages (which cause remote STag invalidation) is OPTIONAL, therefore the iSER layer MUST NOT rely on use of a Send with Invalidate by its Remote Peer to cause local STag invalidation. If an STag is expected to be invalid after completion of a task, the iSER layer MUST check the STag and invalidate it if it is still valid.
12. IANA Considerations
IANA has added the following entries to the "iSCSI Login/Text Keys" registry: MaxAHSLength, RFC 7145 TaggedBufferForSolicitedDataOnly, RFC 7145 iSERHelloRequired, RFC 7145 IANA has updated the following entries in the "iSCSI Login/Text Keys" registry to reference this RFC. InitiatorRecvDataSegmentLength MaxOutstandingUnexpectedPDUs RDMAExtensions TargetRecvDataSegmentLength IANA has also changed the reference to RFC 5046 for the "iSCSI Login/Text Keys" registry to refer to this RFC. IANA has updated the registrations of the iSER Opcodes 1-3 in the "iSER Opcodes" registry to reference this RFC. IANA has also changed the reference to RFC 5046 for the "iSER Opcodes" registry to refer to this RFC.13. References
13.1. Normative References
[RFC5046] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007. [iSCSI] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, April 2014. [RDMAP] Recio, R., Metzler, B., Culley, P., Hilland, J., and D. Garcia, "A Remote Direct Memory Access Protocol Specification", RFC 5040, October 2007.
[DDP] Shah, H., Pinkerton, J., Recio, R., and P. Culley, "Direct Data Placement over Reliable Transports", RFC 5041, October 2007. [MPA] Culley, P., Elzur, U., Recio, R., Bailey, S., and J. Carrier, "Marker PDU Aligned Framing for TCP Specification", RFC 5044, October 2007. [RDDPSEC] Pinkerton, J. and E. Deleganes, "Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security", RFC 5042, October 2007. [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IPSEC-IPS] Black, D. and P. Koning, "Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3", RFC 7146, April 2014.13.2. Informative References
[SAM5] INCITS Technical Committee T10, "SCSI Architecture Model - 5 (SAM-5)", T10/BSR INCITS 515 rev 04, Committee Draft. [iSCSI-SAM] Knight, F. and M. Chadalapaka, "Internet Small Computer System Interface (iSCSI) SCSI Features Update", RFC 7144, April 2014. [DA] Chadalapaka, M., Hufferd, J., Satran, J., and H. Shah, "DA: Datamover Architecture for the Internet Small Computer System Interface (iSCSI)", RFC 5047, October 2007. [IB] InfiniBand Architecture Specification Volume 1 Release 1.2, October 2004 [IPoIB] Chu, J. and V. Kashyap, "Transmission of IP over InfiniBand (IPoIB)", RFC 4391, April 2006.
Appendix A. Summary of Changes from RFC 5046
All changes are backward compatible with RFC 5046 except for item #8, which reflects all known implementations of iSER, each of which has implemented this change, despite its absence in RFC 5046. As a result, a hypothetical implementation based on RFC 5046 will not interoperate with an implementation based on this version of the specification. 1. Removed the requirement that a connection be opened in "normal" TCP mode and transitioned to zero-copy mode. This allows the specification to conform to existing implementations for both InfiniBand and iWARP. Changes were made in Sections 1, 3.1.6, 4.2, 5.1, 5.1.1, 5.1.2, 5.1.3, 10.1.3.4, and 11. 2. Added a clause in Section 6.2 to clarify that MaxRecvDataSegmentLength must be ignored if it is declared in the Login Phase. 3. Added a clause in Section 6.2 to clarify that the initiator must not send more than InitiatorMaxRecvDataSegmentLength worth of data when a NOP-Out request is sent with a valid Initiator Task Tag. Since InitiatorMaxRecvDataSegmentLength can be smaller than TargetMaxRecvDataSegmentLength, returning the original data in the NOP-Out request in this situation can overflow the receive buffer unless the length of the data sent with the NOP-Out request is less than InitiatorMaxRecvDataSegmentLength. 4. Added a SHOULD negotiate recommendation for MaxOutstandingUnexpectedPDUs in Section 6.7. 5. Added MaxAHSLength key in Section 6.8 to set a limit on the AHS Length. This is useful when posting receive buffers in knowing what the maximum possible message length is in a PDU that contains AHS. 6. Added TaggedBufferForSolicitedDataOnly key in Section 6.9 to indicate how the memory region will be used. An initiator can treat the memory regions intended for unsolicited and solicited data differently and can use different registration modes. In contrast, RFC 5046 treats the memory occupied by the data as a contiguous (or virtually contiguous, by means of scatter-gather mechanisms) and homogenous region. Adding a new key will allow different memory models to be accommodated. Changes were also made in Section 7.3.1.
7. Added iSERHelloRequired key in Section 6.10 to allow an initiator to allocate connection resources after the login process by requiring the use of the iSER Hello messages before sending iSCSI PDUs. The default is "No" since iSER Hello messages have not been implemented and are not in use. Changes were made in Sections 5.1.1, 5.1.2, 5.1.3, 8.2, 9.3, 9.4, 10.1.3.2, and 10.1.3.4. 8. Added two 64-bit fields in iSER header in Section 9.2 for the Read Base Offset and the Write Base Offset to accommodate a non- zero Base Offset. This allows one implementation such as the Open Fabrics Enterprise Distribution (OFED) stack to be used in both the InfiniBand and the iWARP environment. Changes were made in the definitions of Base Offset, Advertisement, and Tagged Buffer. Changes were also made in Sections 1.5.1, 1.6, 1.7, 7.3.1, 7.3.3, 7.3.5, 7.3.6, 9.1, 9.3, 9.4, 9.5.1, and 9.5.2. This change is not backward compatible with RFC 5046, but it was part of all known implementations of iSER at the time this document was developed. 9. Remove iWARP-specific behavior. Changes were made in the definitions of RDMA Operation and Send Message Type. Clarifications were added in Section 1.5.2 on the use of SendSE and SendInvSE. These clarifications reflect a removal of the requirements in RFC 5046 for the use of these messages, as implementations have not followed RFC 5046 in this area. Changes affecting Send with Invalidate were made in Sections 1.5.1, 1.6, 1.7, 4.1, and 7.3.2. Changes affecting Terminate were made in Sections 10.1.2.1 and 10.1.2.2. Changes were made in Appendix B to remove iWARP headers. 10. Removed denial-of-service descriptions for the initiator in Section 5.1.1 since they are applicable for the target only. 11. Clarified in Section 1.5.1 that STag invalidation is the initiator's responsibility for security reasons, and the initiator cannot rely on the target using an Invalidate version of Send. Added text in Section 11 on Stag invalidation.
Appendix B. Message Format for iSER
This section is for information only and is NOT part of the standard.B.1. iWARP Message Format for iSER Hello Message
The following figure depicts an iSER Hello Message encapsulated in an iWARP SendSE Message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPA Header | DDP Control | RDMA Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Send) Queue Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Send) Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Send) Message Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0010b | Zeros | 0001b | 0001b | iSER-IRD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | All Zeros | | MPA CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: SendSE Message Containing an iSER Hello Message
B.2. iWARP Message Format for iSER HelloReply Message
The following figure depicts an iSER HelloReply Message encapsulated in an iWARP SendSE Message. The Reject (REJ) flag is set to zero. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPA Header | DDP Control | RDMA Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Send) Queue Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Send) Message Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Send) Message Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0011b |Zeros|0| 0001b | 0001b | iSER-ORD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPA CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: SendSE Message Containing an iSER HelloReply Message
B.3. iSER Header Format for SCSI Read Command PDU
The following figure depicts a SCSI Read Command PDU embedded in an iSER Message. For this particular example, in the iSER header, the Write STag Valid flag is set to zero, the Read STag Valid flag is set to one, the Write STag field is set to all zeros, the Write Base Offset field is set to all zeros, the Read STag field contains a valid Read STag, and the Read Base Offset field contains a valid Base Offset for the Read Tagged Buffer. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0001b |0|1| All zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Read STag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Read Base Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCSI Read Command PDU | // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: iSER Header Format for SCSI Read Command PDU
B.4. iSER Header Format for SCSI Write Command PDU
The following figure depicts a SCSI Write Command PDU embedded in an iSER Message. For this particular example, in the iSER header, the Write STag Valid flag is set to one, the Read STag Valid flag is set to zero, the Write STag field contains a valid Write STag, the Write Base Offset field contains a valid Base Offset for the Write Tagged Buffer, the Read STag field is set to all zeros since it is not used, and the Read Base Offset field is set to all zeros. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0001b |1|0| All zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Write STag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Write Base Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCSI Write Command PDU | // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: iSER Header Format for SCSI Write Command PDU
B.5. iSER Header Format for SCSI Response PDU
The following figure depicts a SCSI Response PDU embedded in an iSER Message: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0001b |0|0| All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | All Zeros | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCSI Response PDU | // // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: iSER Header Format for SCSI Response PDU
Appendix C. Architectural Discussion of iSER over InfiniBand
This section explains how an InfiniBand network (with Gateways) would be structured. It is informational only and is intended to provide insight on how iSER is used in an InfiniBand environment.C.1. Host Side of iSCSI and iSER Connections in InfiniBand
Figure 11 defines the topologies in which iSCSI and iSER will be able to operate on an InfiniBand Network. +---------+ +---------+ +---------+ +---------+ +--- -----+ | Host | | Host | | Host | | Host | | Host | | | | | | | | | | | +---+-+---+ +---+-+---+ +---+-+---+ +---+-+---+ +---+-+---+ |HCA| |HCA| |HCA| |HCA| |HCA| |HCA| |HCA| |HCA| |HCA| |HCA| +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ |----+------|-----+-----|-----+-----|-----+-----|-----+---> To IB IB| IB | IB | IB | IB | SubNet2 SWTCH +-v-----------v-----------v-----------v-----------v---------+ | InfiniBand Switch for Subnet1 | +---+-----+--------+-----+--------+-----+------------v------+ | TCA | | TCA | | TCA | | +-----+ +-----+ +-----+ | IB / IB \ / IB \ / \ +--+--v--+--+ | iSER | | iSER | | IPoIB | | | TCA | | | Gateway | | Gateway | | Gateway | | +-----+ | | to | | to | | to | | Storage | | iSCSI | | iSER | | IP | | Controller| | TCP | | iWARP | |Ethernet | +-----+-----+ +---v-----| +---v-----| +----v----+ | EN | EN | EN +--------------+---------------+----> to IP based storage Ethernet links that carry iSCSI or iWARP Figure 11: iSCSI and iSER on IB In Figure 11, the Host systems are connected via the InfiniBand Host Channel Adapters (HCAs) to the InfiniBand links. With the use of IB switch(es), the InfiniBand links connect the HCA to InfiniBand Target Channel Adapters (TCAs) located in gateways or Storage Controllers. An iSER-capable IB-IP Gateway converts the iSER Messages encapsulated in IB protocols to either standard iSCSI, or iSER Messages for iWARP. An [IPoIB] Gateway converts the InfiniBand [IPoIB] protocol to IP protocol, and in the iSCSI case, permits iSCSI to be operated on an IB Network between the Hosts and the [IPoIB] Gateway.
C.2. Storage Side of iSCSI and iSER Mixed Network Environment
Figure 12 shows a storage controller that has three different portal groups: one supporting only iSCSI (TPG-4), one supporting iSER/iWARP or iSCSI (TPG-2), and one supporting iSER/IB (TPG-1). Here, "TPG" stands for "Target Portal Group". | | | | | | +--+--v--+----------+--v--+----------+--v--+--+ | | IB | |iWARP| | EN | | | | | | TCP | | NIC | | | |(TCA)| | RNIC| | | | | +-----| +-----+ +-----+ | | TPG-1 TPG-2 TPG-4 | | 9.1.3.3 9.1.2.4 9.1.2.6 | | | | Storage Controller | | | +---------------------------------------------+ Figure 12: Storage Controller with TCP, iWARP, and IB Connections The normal iSCSI portal group advertising processes (via the Service Location Protocol (SLP), Internet Storage Name Service (iSNS), or SendTargets) are available to a Storage Controller.C.3. Discovery Processes for an InfiniBand Host
An InfiniBand Host system can gather portal group IP addresses from SLP, iSNS, or the SendTargets discovery processes by using TCP/IP via [IPoIB]. After obtaining one or more remote portal IP addresses, the Initiator uses the standard IP mechanisms to resolve the IP address to a local outgoing interface and the destination hardware address (Ethernet MAC or InfiniBand Global Identifier (GID) of the target or a gateway leading to the target). If the resolved interface is an [IPoIB] network interface, then the target portal can be reached through an InfiniBand fabric. In this case, the Initiator can establish an iSCSI/TCP or iSCSI/iSER session with the Target over that InfiniBand interface, using the hardware address (InfiniBand GID) obtained through the standard Address Resolution Protocol (ARP) processes. If more than one IP address is obtained through the discovery process, the Initiator should select a Target IP address that is on the same IP subnet as the Initiator, if one exists. This will avoid a potential overhead of going through a gateway when a direct path exists.
In addition, a user can configure manual static IP route entries if a particular path to the target is preferred.C.4. IBTA Connection Specifications
It is outside the scope of this document, but it is expected that the InfiniBand Trade Association (IBTA) has or will define: * The iSER ServiceID * A means for permitting a Host to establish a connection with a peer InfiniBand end-node, and that peer indicating when that end- node supports iSER, so the Host would be able to fall back to iSCSI/TCP over [IPoIB]. * A means for permitting the Host to establish connections with IB iSER connections on storage controllers or IB iSER-connected Gateways in preference to IPoIB-connected Gateways/Bridges or connections to Target Storage Controllers that also accept iSCSI via [IPoIB]. * A means for combining the IB ServiceID for iSER and the IP port number such that the IB Host can use normal IB connection processes, yet ensure that the iSER target peer can actually connect to the required IP port number.Appendix D. Acknowledgments
The authors acknowledge the following individuals for identifying implementation issues and/or suggesting resolutions to the issues clarified in this document: Robert Russell, Arne Redlich, David Black, Mallikarjun Chadalapaka, Tom Talpey, Felix Marti, Robert Sharp, Caitlin Bestler, Hemal Shah, Spencer Dawkins, Pete Resnick, Ted Lemon, Pete McCann, and Steve Kent. Credit also goes to the authors of the original iSER Specification [RFC5046], including Michael Ko, Mallikarjun Chadalapaka, John Hufferd, Uri Elzur, Hemal Shah, and Patricia Thaler. This document benefited from all of their contributions.
Authors' Addresses
Michael Ko EMail: mkosjc@gmail.com Alexander Nezhinsky Mellanox Technologies 13 Zarchin St. Raanana 43662 Israel Phone: +972-74-712-9000 EMail: alexandern@mellanox.com, nezhinsky@gmail.com