IPS Douglas Otis Internet Draft SANlight Document: draft-otis-record-delivery-00.txt April 29, 2001 Category: Standards Track SCTP compatible delivery subsystem draft-otis-record-delivery-00.txt 1 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. 2 Abstract This document is to allow record based equipment a common record offload layer suitable for other protocols. As all storage protocols anticipate hardware acceleration, it becomes incumbent to provide this hardware a generic structure that can be applied to many protocols and yet allow an unencumbered feature set. The structures defined for SCTP [RFC2960] were developed to provide record based solutions and are well suited for this common record offload layer. This document will assume either direct use of SCTP, a modified SCTP common header used as a TCP option, or this modified SCTP common header placed within the TCP byte stream. SCTP conventions will be used to enable enhanced features such as connection recovery in lieu of other techniques. The sequential handling of delineated records is done in accordance with SCTP. 3 Conventions used in this document 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 RFC-2119. "C:" denotes sent by the client, and "S:" sent by the server. User Data Payload types are identified as "[CR]","[SR]","[DD]", "[TR]", and "[SU]" for Client's Request, Server's Response, Directed Data, Transfer Request, and Setup respectively. D. Otis 2 1 Status of this Memo...............................................1 2 Abstract..........................................................1 3 Conventions used in this document.................................1 4 Record Directed Data Placement....................................2 5 Structures within User Data.......................................3 5.1 Client's Request [CR] structure within User Data: ..............3 5.2 Directed Data [DD] structure within the User Data: .............4 5.3 Server's Response [SR] structure within the User Data: .........5 5.4 Transfer Request [TR] structure within User Data: ..............6 5.5 Setup [SU] structure within the User Data: .....................7 5.6 Setup Data .....................................................7 5.6.1 Login [SU:LI](Client to Server) ..............................7 5.6.2 Login [SU:LI] (Server to Client) .............................8 5.6.3 Logout [SU:LO] (Client to Server) ...........................11 5.6.4 Logout [SU:LO] (Server to Client) ...........................11 5.6.5 Text Key [SU:TK] (Client to Server) .........................12 5.6.6 Text Key [SU:TK] (Server to Client) .........................13 5.6.7 Client's Management [SU:CM] (Client to Server) ..............13 5.6.8 Client's Management [SU:CM] (Server to Client) ..............15 6 Client and Server Labels and Addresses...........................16 7 Client Server Interaction........................................17 7.1 Login Phase ...................................................17 7.1.1 Login Phase Start ...........................................18 7.1.2 Integrity-Authentication Negotiation ........................19 7.1.3 Subsystem Parameter Negotiation During the Login Phase ......21 7.1.4 Subsystem Parameter Negotiation after Login Phase ...........21 7.2 Subsystem Error Handling and Recovery .........................22 7.3 Syntax Errors .................................................22 8 IANA Considerations..............................................22 9 Security Considerations..........................................22 9.1 Protection Modes ..............................................22 9.1.1 No Protection ...............................................23 9.1.2 Client-Server Authentication ................................23 9.1.3 Integrity-authentication ....................................23 9.2 Authentication ................................................25 9.3 Login Phase Examples ..........................................28 10 Appendix A. Keys................................................35 11 Acknowledgement.................................................41 12 Full Copyright Statement........................................42 4 Record Directed Data Placement In keeping with the conventions established for record base devices, memory is allocated by the application at the client. For record offloading, the client then assigns Streams in a symmetrical manner analogous to tags used to identify data exchanges referenced in server responses. To assist in further resolving record placement, Client's Request, Server's Response, Directed Data, Transfer Request and Setup information will be handled separately. To allow for such bifurcation of related information, the SCTP Payload Protocol Identifier is used. There are five categories D. Otis 3 identified to associate the contained User Data with differing vectors. These categories are Client's Request, Server's Response, Directed Data, Transfer Request and Setup. With the exception of the Directed Data category, reception placement is relative to the last record setting within that category on that Stream. Directed Data is a complex structure that includes a 32-bit offset at the beginning of the User Data and acts as an offset from an opaque vector set by the receiver for that Stream. The actual data length contained within the User Data is 4 bytes less as a result of this offset. Streams are treated symmetrically between both client and server. For each Stream, both the client and server maintain opaque placement vectors delineated by the Payload Protocol Identifier and Stream Identifier in an opaque manner. Protective vector restrictions are beyond the scope of this document. Informative Example of the SCTP Data Chunk 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 +---------------+---------------+---------------+---------------+ | Type = 0 |reserved |U|B|E| Length | +---------------+---------------+---------------+---------------+ | TSN | +---------------+---------------+---------------+---------------+ | Stream Identifier | Stream Sequence Number | +---------------+---------------+---------------+---------------+ | Payload Protocol Identifier | +---------------+---------------+---------------+---------------+ | User Data | / / +---------------+---------------+---------------+---------------+ 5 Structures within User Data 5.1 Client's Request [CR] structure within User Data: 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 +---------------+---------------+---------------+---------------+ 0| | + Unit + 4| | +---------------+---------------+---------------+---------------+ 8| Queue | Xfer | reserved | +---------------+---------------+---------------+---------------+ 12| Expected Read Transfer Length | +---------------+---------------+---------------+---------------+ 16| Expected Write Transfer Length | +---------------+---------------+---------------+---------------+ 20| Command | +/ / +---------------+---------------+---------------+---------------+ D. Otis 4 Unit This value is used to access a device and is not defined within this document. Expected Read Transfer Length Expected Write Transfer Length The values set by the client's application indicating the expected number of bytes to be transferred. Queue: (For device layer use only.) 0x0 - Simple Queue 0x1 - Head of Queue 0x2 - Ordered Queue 0x4 - Error Queue 0x8 - No Queue Others values reserved Xfer: 0x0 - No Data to Transfer 0x1 - Read Data Transfer 0x2 - Write Data Transfer 0x3 - Read and Write Data Transfer Command (For device layer use only.) This information is passed to the device and is not defined within this document. 5.2 Directed Data [DD] structure within the User Data: 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 +---------------+---------------+---------------+---------------+ 0| Data Offset | +---------------+---------------+---------------+---------------+ 4| Data Payload | +/ / +---------------+---------------+---------------+---------------+ Data Offset The offset from the beginning of the buffer assigned to the Stream. Data Payload The actual data transferred. D. Otis 5 5.3 Server's Response [SR] structure within the User Data: (Server to Client) 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 +---------------+---------------+---------------+---------------+ 0| Exchange | Status | reserved | +---------------+---------------+---------------+---------------+ 4| Residual Read Count | +---------------+---------------+---------------+---------------+ 8| Residual Write Count | +---------------+---------------+---------------+---------------+ 12| Sense | +/ / +---------------+---------------+---------------+---------------+ Exchange: Bit 7 = Read Overflow Bit 6 = Read Underflow Bit 5 = Write Overflow Bit 4 = Write Underflow Bit 3 = Asynchronous Event (AE) Bit 2 = Defined by Delivery Subsystem Bit 1 & 0 reserved Status: (if Defined by Delivery Subsystem) 0x01 - Server Failure 0x02 - Delivery Subsystem Failure 0x03 - Unsolicited Data Rejected 0x04 - Client's Request Rejected by Delivery Subsystem 0x05 - Client's Request Rejected by Device Layer 0x06 - Illegal Request before Login 0x40 - Server Being Reset (AE) 0x41 - Server Requests Logout (AE) 0x42 - Server Will Close Association (AE) 0x43 - Server Detected Configuration Change (AE) 0x80-0xff - Reserved for Vendor-Unique Responses Residual Read Count Residual Write Count These two byte count values are used to indicate a conflict between the expected number of bytes and the actual transfer. The Exchange overflow and underflow bits determine the nature of this conflict. Sense This data provides additional information related to the Status. In the case of this information having been set by the Delivery Subsystem, only Association ID and time values are defined. Information included in Status and Sense is beyond the scope of this document if not defined by the Delivery Subsystem. D. Otis 6 A set overflow bit indicates the residual count contains the number of bytes remaining to be transferred at the device interface when limited by the expected length. A set underflow bit indicates the residual count contains the number of bytes remaining from the expected length compared to the bytes transferred. The residual count should be zero if neither of these bits are set. Underflow and overflow bits for the same count MUST not be set concurrently. A set Asynchronous Event bit indicates the Status and Sense information does not represent a Server's Response to a Client's Request and the residual counts will not be valid. A set Defined by Delivery Subsystem bit indicates the device layer has not set Status and Sense information and this Server's Response is presented independent of any other client and server exchange. A set Defined by Delivery Subsystem bit with Status indicating Server Requests Logout, the first 32 bits within Sense Information contains the A_ID of the Association to Logout. For Status indicating Server Will Close Association, the first 32 bits within Sense information contains the A_ID of the affected Association. The second 32 bits indicates the minimum time and the third 32 bits indicates the maximum time in seconds to establish Association and Login. 5.4 Transfer Request [TR] structure within User Data: (Server to Client) 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 +---------------+---------------+---------------+---------------+ 0| Buffer Offset | +---------------+---------------+---------------+---------------+ 4| Desired Data Transfer Length | +---------------+---------------+---------------+---------------+ Buffer Offset The server specifies a Buffer Offset to indicate the point at which the data transfer should begin, relative to the data vector associated with the client's Stream. Desired Data Transfer Length The server specifies the number of bytes the client is to send. The client will use the same offset within the Directed Data. The server may request the data from the client in several iterations, not necessarily in sequential order depending on device settings. The Desired Data Transfer Length MUST not be 0. There may be several Transfer Requests active on a given stream. D. Otis 7 5.5 Setup [SU] structure within the User Data: 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 +---------------+---------------+---------------+---------------+ 0|Setup Attribute|C| reserved | Status-Class | Status-Detail | +---------------+---------------+---------------+---------------+ 4| Setup Data | +/ / +---------------+---------------+---------------+---------------+ Setup Attribute: 0x00 - Login 0x01 - Logout 0x02 - Text Key 0x03 - Client's Management Other values reserved C (Continue) Bit The C bit is set to indicate additional setup is requested. Status-Class Status-Detail These represent status returned by the server as defined in the various setup operations indicated in Setup Attribute. The client should clear these values in requests. 5.6 Setup Data 5.6.1 Login [SU:LI](Client to Server) 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 +---------------+---------------+---------------+---------------+ 4| Version-Max | Version-Min | A_ID | +---------------+---------------+---------------+---------------+ 8| ISID | TSID | +---------------+---------------+---------------+---------------+ 12| Text | +/ / +---------------+---------------+---------------+---------------+ Version-Max Maximum Version number supported. Version-Min Minimum Version supported. Version number start at 0x01 and is the current version defined in this document. Proto implementations should use version 0. D. Otis 8 A_ID This is a unique ID for this Association within the session. ISID This is a client identifier randomly established by the client. It MUST be the same for all Associations within a session. TSID This is a client identifier returned by the server at the conclusion of the initial Login. This value is set to zero until known. Text The client MAY provide some key based parameters in order to enable the server to determine if the client may use the server's resources which may include parameters for an integrity-authentication exchange. The format of these parameters is the same as specified for Text Key. Keys and their explanations are listed in the appendixes. After establishing an Association between a client and a server, the client MUST issue Login to gain further access to the server's resources. Until Login process is completed, Login is the only legal request made to the server. A login process MUST NOT be completed more than once over each Association. 5.6.2 Login [SU:LI] (Server to Client) 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 +---------------+---------------+---------------+---------------+ 4| Version-Max | Version-Act | A_ID | +---------------+---------------+---------------+---------------+ 8| ISID | TSID | +---------------+---------------+---------------+---------------+ 12| Text | +/ / +---------------+---------------+---------------+---------------+ Version-Max This is the highest version number supported by the server. D. Otis 9 Version-Act Indicates the version active (the highest version supported by the server and client). If the server does not support a version within the range specified by the client, the server rejects Login and this field indicates the lowest version supported by the server. Status-Class and Status-Detail The Status-Class is sufficient for a client to use when handling errors, without having to examine the Status-Detail. The Status- Detail allows improved error recovery as well as better information within error logging. Status classes are as follows: 0x00 - Success: Indicates that the server successfully received and accepted Login. 0x01 - Redirection: Indicates that further action must be taken by the client to complete the login process. This is usually due to the server redirecting the client to a different server. All of the class 1 responses MUST return one or more text key parameters of the type "Server_URL", which indicates the next server. 0x02 - Client Error: Indicates that the client likely caused the error. This MAY be due to a request for a resource for which the client does not have permission. 0x03 - Server Error: Indicates that the server is incapable of fulfilling the request. The allowable state of the Continue (C) bit in Login from the server with currently defined Status Class-Detail is indicated in the following table. The most significant byte of Code is the Status Class and the least significant byte is the Status Detail. D. Otis 10 ----------------------------------------------------------------- Class-Detail | Code |C bit| Status Description ----------------------------------------------------------------- Accept Login |0x0000| 0/1 | Login is OK ----------------------------------------------------------------- Authenticate |0x0001| 1 | Server label exists | | | and authentication proceeds. ----------------------------------------------------------------- Server Label |0x0002| 1 | Server label must be provided Required | | | for authentication to proceed. ----------------------------------------------------------------- Server Moved |0x0101| 0 | The requested server label is Temporarily | | | temporarily the label provided. ----------------------------------------------------------------- Server Moved |0x0102| 0 | The requested server label is Permanently | | | permanently the label provided. ----------------------------------------------------------------- Proxy Required|0x0103| 0 | The client must use the proxy | | | server label provided. ----------------------------------------------------------------- Authentication|0x0201| 0 | The client authentication failed. Failed | | | ----------------------------------------------------------------- Forbidden |0x0202| 0 | The client is not allowed access Server | | | to the server. ----------------------------------------------------------------- Not Found |0x0203| 0 | The requested server label was not | | | found. ----------------------------------------------------------------- Server Removed|0x0204| 0 | The requested server label has been | | | removed. No forwarding. ----------------------------------------------------------------- Server |0x0205| 0 | Server is in use and does not Conflict | | | support multiple clients. ----------------------------------------------------------------- Client |0x0206| 0 | No additional Associations accepted TSID error | | | for this Client with TSID set to 0 ----------------------------------------------------------------- Missing |0x0207| 0 | Missing parameters parameter | | | ----------------------------------------------------------------- Server Error |0x0300| 0 | An error occurred in the Server | | | (out of resources, etc.). ----------------------------------------------------------------- Service |0x0301| 0 | The service or server is Unavailable | | | currently not operational. ----------------------------------------------------------------- Unsupported |0x0302| 0 | The required version is not version | | | supported by the server. ----------------------------------------------------------------- If the Status is "Accept Login" (0x0000) and the C bit is cleared, the client may proceed to issue requests, data, and non-login setup. If the Status is "Accept Login" (0x0000) and the C bit is set, the D. Otis 11 client MAY proceed to negotiate additional login parameters. The server MUST not set the Status to 0x0000 and clear the C bit if Login from the client had the C bit set. If the Status Class is not 0, the client and server MUST close the Association. If the server wishes to reject Login for more than one reason, it should return the significant reason for rejection. ISID TSID The TSID is a client identifier set by the server. It is valid only if the Association Login is accepted. The TSID MUST be returned in partial responses (C bit set) and the same value MUST be presented with the final response (C bit cleared). ISID and TSID together form the Session identifier. 5.6.3 Logout [SU:LO] (Client to Server) 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 +---------------+---------------+---------------+---------------+ 4| A_ID | Action Code | reserved | +---------------+---------------+---------------+---------------+ A_ID This is the Association ID to be closed. This field is valid only if the Action Code is not "Close Session". Action Code: 0x00 - Close Session 0x01 - Close Association 0x02 - Close Association at server's request (Requested through an Asynchronous Event) Logout is used to perform a controlled closing of an Association. 5.6.4 Logout [SU:LO] (Server to Client) 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 +---------------+---------------+---------------+---------------+ 4| A_ID | Action Code | reserved | +---------------+---------------+---------------+---------------+ A_ID and Action Code The server echoes A_ID and Action Code. D. Otis 12 Class-Detail: 0x0000 - Association Closed Successfully 0x0100 - Cleanup Failed The server, to indicate that the cleanup operation for the Association has completed, replies with Logout. After the server returns Logout, then the affected Associations MUST be closed. 5.6.5 Text Key [SU:TK] (Client to Server) 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 +---------------+---------------+---------------+---------------+ 4| Text | +/ / +---------------+---------------+---------------+---------------+ The client sends the server a set of key=value or key=list pairs encoded in UTF-8 Unicode. The key and value are separated by an '=' (0x3D) delimiter. Many key=value pairs can be included in Text by separating them with Null (0x00) delimiters. A list is a set of values separated by a comma (0x2C). Numbers can be represented as hexadecimal prefixed with '0x' (0x30, 0x78) or as decimal. The maximum size for integer encoding of an individual value is 255 bytes. The length of a text request or response SHOULD be less than 4096 bytes. No key SHOULD contain more than 255 characters. The server responds to understood keys with its representation of the key in similar format. The value of the key reflects server's present setting. Some basic key=value pairs are described in appendixes. Clients and servers MUST support all of these keys, except those using the 'X-' (0x58, 0x2D) extension format. Vendors may introduce new keys by prefixing them with 'X-' followed by their (reversed) domain name, for example the company owning the domain example.com can issue: X-com.example.bar.foo.do_something=0x3 Any other key not understood by the server may be ignored without affecting basic function. If the Text Key response does not contain a key that was requested, the client must assume the key was not understood by the server or, whenever appropriate, that the response was "none". Text Key is usually meant for parameter setting or negotiations but can be also used to perform Delivery Subsystem operations. It is recommended that Text Key operations expected to take a long time be placed in separate requests. D. Otis 13 A session may have only one text sequence active at any given time. 5.6.6 Text Key [SU:TK] (Server to Client) 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 +---------------+---------------+---------------+---------------+ 4| Text | +/ / +---------------+---------------+---------------+---------------+ The Text Key contains the server's response to the client's Text Key request. The Continue bit cleared in response to a request with the Continue bit also cleared indicates the server has finished the setup operation. Otherwise, if the Continue bit is set in response to a Text Key with the Continue bit cleared, then the server wishes additional setup. A Text Key response with the Continue bit cleared to a request with the Continue bit set indicates an error. The Text Key contains key=value responses in the same order as the Text Key request and with the same encoding constraints. If the Text Key response does not contain a key that was requested, the client must assume the key was not understood by the server or that the answer is =none. Appendixes lists Text Key representations and their responses. Text Key request and response sequences when used to set/negotiate subsystem parameters do the negotiation/parameter setting atomically - i.e. either the whole sequence succeeds or no parameter setting takes place. Class-Detail: 0x0000 - Request Accepted 0x0100 - Request Failed 5.6.7 Client's Management [SU:CM] (Client to Server) 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 +---------------+---------------+---------------+---------------+ 4| | + Unit + 8| | +---------------+---------------+---------------+---------------+ 12| Function | reserved | +---------------+---------------+---------------+---------------+ D. Otis 14 Unit This value is used to access a device and is not defined within this document. Function: 0x01 - Abort Request 0x02 - Abort Request Set 0x03 - Clear Error Interlock (Used for device layer only.) 0x04 - Clear Request Set 0x05 - Unit Reset 0x06 - Server Reset 0x07 - Server Reset and Close Sessions For all these functions, the Client's Management response SHALL be returned over the same Stream. No more than one Client's Management request SHALL be active on a Stream. Once the server returns Client's Management response, the Client's Management request is no longer active. In addition to the possible discard of Client's Requests pending delivery to the device layer, an equivalent action may also be performed at the device layer. The mapping of the Function code to a device action is beyond the scope of this document. The Client's Management functions provide the client with a way to explicitly control execution of one or more Client's Requests as follows. Abort Request Discards the Client's Request identified by the Stream if it is pending delivery to the device layer and returns a Completion of Client's Request Discarded. Otherwise, a device action is sent to the specified Unit and returns the normal Completion of Function Complete. Abort Request Set Discards all Client's Requests pending delivery to the device layer issued by this client to the specified Unit and a device action is sent to the specified Unit. Clear Error Interlock Clears an error interlock with a device action sent to the specified Unit. Clear Request Set Discards all Client's Requests pending delivery to the device layer issued by all clients for the specified Unit and a device action is sent to the specified Unit. D. Otis 15 Unit Reset In addition to performing Clear Request Set, this sends a device action that returns the Unit to a state similar to power-on. Server Reset In addition to performing Unit Reset for all Units, this returns the server to the power-on state while maintaining Delivery Subsystem sessions. Server Reset and Close Sessions This does the same as a Server Reset but then also performs a Close Session for all clients. If the server is unable to send the required Asynchronous Event response to clients, it MUST continue the reset operation and it SHOULD log this condition for later retrieval. Log retrieval is not defined within this document. 5.6.8 Client's Management [SU:CM] (Server to Client) 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 +---------------+---------------+---------------+---------------+ 4| | + Unit + 8| | +---------------+---------------+---------------+---------------+ 12| Function | reserved | +---------------+---------------+---------------+---------------+ Function The server echoes Function. Class-Detail: 0x0000 - Function Complete 0x0001 - Client's Request Discarded 0x0002 - Client's Request not active on Stream 0x0100 - Unit does not exist 0x0200 - Function Rejected If Abort Request was able to discard a Client's Request prior to delivery to the device layer or where the device layer determined there was no active Client's Request, no device action is taken. Otherwise, in addition to a Client's Management response from the server, the device layer should also indicate a device action was taken. For the Server Reset and Close Sessions function, upon delivery of this Completion response, the server MUST then close all of its Associations to all clients to effectively close all sessions. D. Otis 16 The mapping of a device response into Class-Detail status is beyond the scope of this document. 6 Client and Server Labels and Addresses All clients and servers are labeled. These labels are independent of the physical address and machine of the client and server. The label for the client can be "anonymous" if the server is not required to resolve clients to unique labels otherwise the client label should be globally unique. To access a default server at a location, the server label "default" can be used. As with clients, servers should also be assigned globally unique labels. The assignment of client and server labels is outside the scope of this document. The label is a case insensitive UTF-8 text string that does not include white space and is treated as opaque. A Label alias may include spaces. The client MUST present both its label and the server label it wishes service from during the login phase. If the client uses the default server label, it may use a key request "Send_Labels" to retrieve a list of servers that exist at that the present Association. Servers have an address that specifies a single initial path on which to create an Association. The server label is incorporated as the path part of the URL. A server address is specified as a URL, such as: [:]/ Where is one of: - IPv4 address, in dotted decimal notation. Assumed if the name contains exactly four numbers, separated by dots (.), where each number is in the range of 0 to 255. - IPv6 address, in dotted decimal notation. Assumed if the name contains more than four, but at most 16 numbers processed right to left, separated by dots (.), where each number is in the range of 0 to 255. - Fully qualified domain name. Assumed if the is neither an IPv4 nor an IPv6 address. The in the address is optional; it specified the port on which the server is listening for Associations. If is not specified, the well-known port assigned by IANA will be assumed. The server URL is not used within Associations between clients and servers. Examples of server label: fqn.com.example.diskarrays.sn.45678 D. Otis 17 Examples of IPv4 URL: 10.0.0.1/fqn.com.example.diskarrays.sn.45678 10.0.0.2:2000/default Examples of IPv6 addresses/labels: 12.5.7.10.0.0.1/fqn.com.example.home.24 12.5.6.10.0.0.2/default For support tools that use a prefix to express the protocol intended such as 'http://' and as a server name alias within the IP domain, the following form should be used: rds://[:port][/server-label] Example: rds://rds.example.com/eui.02004567A425678D To assist in providing a more human-readable user interface for devices containing servers and clients, a server or client may also provide a label alias. This label alias is a simple UTF-8 string, is not globally unique, and is never interpreted or used to identify a client or server. When a server has to act as a client for a third party command, it MAY use the client label it learned during login as required by the authentication mechanism to the third party. Command addressing and server discovery is beyond the scope of this document. 7 Client Server Interaction The server, using the same Payload Protocol Identifier with the same Setup Attribute, responds to every client Setup function on the same Stream. There MUST never be more than one outstanding Setup exchange per Stream. The server responses to every Client's Request with a Server's Response. There are Server's Responses that are marked Asynchronous Event and Defined by Subsystem that are independent of this exchange pair. The client responds to a Transfer Request from the server using Directed Data on the same Stream. There may be more than one outstanding Transfer Request-Directed Data exchange active. The server in response to the device layer, may also issue Directed Data. The device layer action would be in response to a Client's Request. A matching Server's Response to the Client's Request concludes Directed Data from the Server. 7.1 Login Phase The login phase establishes a session between client and server. It authenticates the client and server to each other and establishes subsystem parameters. D. Otis 18 Subsystem parameters MAY be negotiated within or after the login phase. Integrity-authentication MUST be completely negotiated within the login phase or provided by external means (e.g., IPSec.) In some environments, a server or a client does not authenticate its counterpart and so it is possible to bypass authentication during Login if allowed by both client and server. The client and server MAY want to negotiate integrity-authentication parameters. Once this negotiation is completed, the Association is considered secure. Authentication, integrity and privacy setup MAY be performed independently (as when using tunneling IPSec or some implementations of transport IPSec) in which case the Login phase can be reduced to subsystem parameter negotiations. The login phase is implemented via Login requests and responses only. The login process is done on a single Stream. The login request is sent from the client to the server to start the login phase. The Login response is sent to the client to conclude the login phase. Text Key is used to set subsystem parameters following the login phase. The login phase sequence of requests and responses proceeds as follows: Note: 'li' or 'tk' signifies a continued sequence. (C bit set.) C:[SU:LI] S:[SU:LI] (minimum mandatory) C:[SU:li] S:[SU:li] ...C:[SU:LI] S:[SU:LI] (optional) The Login final-response (C bit cleared) accepts or rejects the Login request. Until Login is final, Login is the only legal client request. The Login final-response that accepts a Login request SHALL only follow Login with the C bit cleared. The server can respond with the C bit set to Login or Text Key with the C bit cleared. In this case, additional parameters are requested. 7.1.1 Login Phase Start The login phase starts with Login request from the client to the server. The login request includes: -Protocol version supported by the client -Session IDs and Association Ids -Integrity-Authentication Parameters OR -Subsystem parameters D. Otis 19 A server MAY use the client label as part of its access control mechanism; therefore, the client label MUST be sent before the server is required to disclose its Units. The means the server uses to disclose the available Units is beyond the scope of this document. If the server label is going to be used in determining the integrity- authentication mode or it is an implicit part of authentication, then the server label MUST be sent in the Login request of the first Association of a session to identify the server of the session. However, it is OPTIONAL for all the Associations after the first. It is ignored by the server for new Associations within an existing session. If the server label is going to be used only for access control, it can be sent after the Security Complete is achieved. Using "default" to then obtain a list of servers can be used access an unknown server. The server can answer in the following ways: -Login Response with Login Reject (and C bit cleared). This is an immediate rejection from the server that causes the session to terminate. -Login Response with Login Accept with session ID and subsystem parameters and C bit cleared. This is a valid response only if the Login request also had the C bit cleared. In this case, the server does not support any integrity-authentication mechanism and starts with the session immediately. -Login Response with C bit set indicating the start of a negotiation sequence. The response includes the protocol version supported by the server and either integrity-authentication parameters or subsystem parameters when no integrity-authentication mechanism is chosen or supported by the server. It also indicates what sequence is expected next such as integrity-authentication or subsystem parameters negotiation. The client MAY decide to drop the Association if the sequence is not what it expects (e.g., a client that expects a integrity-authentication sequence and gets a response indicating that subsystem parameter negotiation is the next phase expected of the client). 7.1.2 Integrity-Authentication Negotiation The security exchange sets the security mechanism and authenticates the user and the server to each other. The exchange proceeds according to the algorithms that were chosen in the negotiation phase and is conducted by the text key=value parameters. The negotiable mechanisms for integrity-authentication include the following modes: -Client-server authentication - the client and the server authenticate themselves to each other. A negotiable algorithm such as Kerberos provides this feature. D. Otis 20 -SCTP integrity - an integrity-authentication digest (IAD) Chunk is inserted at the beginning of each frame. The algorithm is negotiable. Using IPsec for encryption or authentication may eliminate the need for integrity-authentication negotiation at the server level, e.g., ISAKMP for IPsec. If integrity-authentication is established in the login phase note that: -After the integrity-authentication negotiation is complete, each frame MUST include the appropriate IAD Chunk if any. -The subsystem parameter negotiation SHOULD start only after integrity-authentication is established. This should be performed using Text Key. The negotiation proceeds as follows: -The client sends text with an ordered list of the options it supports for each subject (authentication algorithm, subsystem parameters, etc). The options are listed in the client's order of preference. -The server MUST reply with the first option in the list it supports and is allowed for the specific client. The client MAY also send proprietary options. The "none" option, if allowed, MUST be included in the list, which indicates that the server supports no algorithm. If integrity-authentication is to be established, the client MUST NOT send parameters other than integrity-authentication parameters in the initial Login request. The subsystem parameters should be negotiated only after integrity-authentication is established at the desired level. When establishing the integrity- authentication, the server and the client MAY ignore any subsystem parameters sent prior. For a list of integrity-authentication parameters see appendixes. -Every party in the integrity-authentication negotiation indicates that it has completed building its security context (has all the required information) by sending the key=value pair: SecurityContextComplete=yes The other party either offers some more parameters or answers with the same: SecurityContextComplete=yes The party that is ready keeps sending the SecurityContextComplete=yes pair (in addition to new security parameters if required) until the handshake is complete. D. Otis 21 If the client has been the last to complete the handshake it MUST NOT start sending operational parameters within the same text request; a text response including only SecurityContextComplete=yes concludes the integrity-authentication phase. If the server has been the last to complete the handshake, the client can start the subsystem parameter negotiation with the next text command; the integrity-authentication negotiation phase ends with the server text response. All frames sent after the integrity-authentication negotiation phase MUST include the agreed IAD Chunk. If the integrity-authentication negotiation fails at the server then the server MUST send the appropriate Login response. If the integrity-authentication negotiation fails at the client, the client shall drop the Association. 7.1.3 Subsystem Parameter Negotiation During the Login Phase Subsystem parameter negotiation during the login MAY be done: - Starting with the Login request if the client does not offer any integrity-authentication option. - Starting immediately after the integrity-authentication negotiation if the client and server perform such a negotiation. - Starting immediately after Login response with C bit cleared if the client does offer integrity-authentication options but the server chose none. Subsystem parameter negotiation MAY involve several request-response exchanges (Login and/or Text Key) always driven by the client. The client MUST indicate its intent to terminate the negotiation by clearing the C bit; the server clears the C bit on the last response. If the server responds to a text request with the C bit set, the client must keep sending the text requests (even empty) with the C bit cleared until it gets the response with the C bit cleared. 7.1.4 Subsystem Parameter Negotiation after Login Phase Subsystem parameter negotiation MAY involve several text request- response exchanges always driven by the client. The client MUST indicate its intent to terminate the negotiation by clearing the C bit; the server clears the C bit on the last response. If the server responds to a text request with the C bit cleared, with a text response with the C bit set, the client must keep sending the text request (even empty) with the C bit cleared until it gets the text response with the C bit cleared. D. Otis 22 7.2 Subsystem Error Handling and Recovery For any service delivery, it is assumed that in conjunction with SCTP Association recovery, the Delivery Subsystem is able to ensure the integrity of the interface and release resources only when there is no further requirement. It is also assumed, that the client will be able to respond to any device layer error and that the Delivery Subsystem is unaware of errors at this layer. The Client must retain information until confirmation is made from the device layer. Once the server response has be acknowledged by Delivery Subsystem back to the server, these server resources may also be released. 7.3 Syntax Errors Explicit violations of the rules stated in this document are syntax errors. While a session is active, whenever a server receives a request with a syntax error, it MUST respond with "Client's Request Rejected by Delivery Subsystem". When a client receives a syntax error, for which it has an outstanding request, it MUST abort the request and report the error through an appropriate service. The means of this reporting is beyond the scope of this document. 8 IANA Considerations There will be a well-known port for RDS Associations. This well- known port will be registered with IANA. There will also be IANA registration required for the Payload Protocol Identifiers and the IAD Chunk and the Setup Attributes. 9 Security Considerations Historically, storage systems have not had to consider security issues because their environments offered minimal risks from intrusion. The use of this protocol for such use over IP networks requires that security concerns be addressed. Implementations MUST provide means of protection against active attacks and MAY provide means of protection against passive attacks from eavesdropping. Authentication, integrity and privacy MAY be performed independently as when using tunneling IPSec or some implementations of transport IPSec. The following section describes the security protection modes to be provided by an implementation. 9.1 Protection Modes Every compliant client and server MUST be able to provide client- server authentication and data integrity-authentication. This D. Otis 23 quality of protection MAY be achieved on every Association through properly configured IPSec. 9.1.1 No Protection This mode does not authenticate nor does it verify data. This mode should only be used in environments where the risk is minimal and configuration errors are improbable. 9.1.2 Client-Server Authentication In this mode, the server authenticates the client and the client optionally authenticates the server. An attacker should not gain any advantage by inspecting the authentication phase. This mode protects against an unauthorized access to resources by using a false identity (spoofing). Once the authentication phase is completed, all data is sent and received in the clear and unverified. This mode should only be used when there is minimal risk to man-in-the-middle message insertion, deletion, and modification attacks. 9.1.3 Integrity-authentication This mode provides data integrity and protects against data being compromised from message insertion, deletion, or modification. This does not protect from man-in-the-middle eavesdropping. An Association or multiple Associations MAY be protected end-to-end or partial-path (gateway tunneling) by using IPSec to protect against eavesdropping. Implementations MAY also negotiate digests for data integrity as detailed in the following table: D. Otis 24 +-------------------------------------------------------------+ | Name | Description | Definition | +-------------------------------------------------------------+ | KRB5_MD5 | the SGN_CKSUM field (8 bytes) | RFC1964 | | | of the GSS_GetMIC() token in | | | | GSS_KRB5_INTEG_C_QOP_MD5 QOP | | | | (partial MD5 ("MD2.5")) | | +-------------------------------------------------------------+ | KRB5_DES_MD5 | the SGN_CKSUM field (8 bytes) | RFC1964 | | | of the GSS_GetMIC() token in | | | | GSS_KRB5_INTEG_C_QOP_DES_MD5 | | | | QOP (DES MAC of MD5) | | +-------------------------------------------------------------+ | KRB5_DES_MAC | the SGN_CKSUM field (8 bytes) | RFC1964 | | | of the GSS_GetMIC() token in | | | | GSS_KRB5_INTEG_C_QOP_ DES_MAC | | | | QOP (DES MAC) | | +-------------------------------------------------------------+ | SPKM | the int-cksum field of the | RFC2025 | | | SPKM-MIC token, calculated | | | | without the optional int-alg | | | | and snd-seq fields of the | | | | mic-header (i.e., the default | | | | I-ALG is used, and sequencing | | | | service is not used). | | +-------------------------------------------------------------+ Note: the KRB5_* digests are allowed only when combined with KRB5 authentication method (see below) (i.e., the client may offer one of these digests only if it also offers KRB5 as AuthMethod, and the server may respond with one of these digests only if it also responds with KRB5 as the AuthMethod). Similarly, the SPKM digest is allowed only when combined with SPKM-1 or SPKM-2 authentication methods (see below). Other and proprietary algorithms MAY also be negotiated. The "none" value is the only one that MUST be supported. D. Otis 25 The following table details authentication methods: +------------------------------------------------------------+ | Name | Description | +------------------------------------------------------------+ | KRB5 | Kerberos V5 | +------------------------------------------------------------+ | SPKM-1 | Simple Public-Key GSS-API Mechanism | +------------------------------------------------------------+ | SPKM-2 | Simple Public-Key GSS-API Mechanism | +------------------------------------------------------------+ | SRP | Secure Remote Password | +------------------------------------------------------------+ | CHAP | Challenge Handshake Authentication Protocol| +------------------------------------------------------------+ | none | No authentication | +------------------------------------------------------------+ KRB5 is defined in [RFC1510], SPKM-1, SPKM-2 are defined in [RFC2025], Secure Remote Password is defined in [RFC2945] and CHAP is defined in [RFC1994]. 9.2 Authentication The authentication exchange authenticates the client to the server, and optionally the server to the client. Authentication is not mandatory and is distinct from the data integrity-authentication exchange. The authentication methods to be used are KRB5, SPKM-1, SPKM-2, SRP, CHAP, or proprietary. For KRB5 (Kerberos V5) [RFC1510], the client MUST use: KRB_AP_REQ= where KRB_AP_REQ is the client message as defined in [RFC1510]. If the client authentication fails, the server MUST return an error. Otherwise, if the client has selected the mutual authentication option (by setting MUTUAL-REQUIRED in the ap-options field of the KRB_AP_REQ), the server MUST reply with: KRB_AP_REP= where KRB_AP_REP is the server's response message as defined in [RFC1510]. KRB_AP_REQ,KRB_AP_REP are large binaries encoded as hexadecimal strings. D. Otis 26 For SPKM-1,SPKM-2 [RFC2025], the client MUST use: SPKM-REQ= where SPKM-REQ is the first client token as defined in [RFC2025]. [RFC2025] defines situations where each side may send an error token which may cause the peer to re-generate and resend this last token. This scheme is followed and the error token syntax is: SPKM-ERROR= However, SPKM-DEL tokens that are defined by [RFC2025] for fatal errors will not be used. If the server needs (by [RFC2025]) to send SPKM-DEL token, it will, instead, send a Login 'login reject' response and terminate the Association. If the client needs to send SPKM-DEL token, it will just abort the Association. In the sequel, we assume that no SPKM-ERROR tokens are required: If the client authentication fails, the server MUST return an error. Otherwise, if the AuthMethod is SPKM-1 or if the client has selected the mutual authentication option (by setting mutual-state bit in the options field of the REQ-TOKEN in the SPKM-REQ), the server MUST reply with: SPKM-REP-TI= where SPKM-REP-TI is the server token as defined in [RFC2025]. If mutual authentication was selected and server authentication fails, the client MUST abort the Association. Otherwise, if the AuthMethod is SPKM-1, the client MUST continue with: SPKM-REP-IT= where SPKM-REP-IT is the second client token as defined in [RFC2025]. All the SPKM-* tokens are large binaries encoded as hexadecimal strings. For SRP [RFC2945], the client MUST use: U= ServerAuth=yes (or ServerAuth=no) The server MUST either return an error or reply with: N= g= s= The client MUST continue with: A= The server MUST either return an error or reply with: D. Otis 27 B= The client MUST either abort or continue with: M= If the client authentication fails, the server MUST return an error. Otherwise, If the client sent ServerAuth=yes in the first message (requiring server authentication) the server MUST reply with: HM= Where U, N, g, s, A, B, M and H(A | M | K) are defined in [RFC2945]. U is a text string, N,g,s,A,B,M and H(A | M | K) are numbers. For CHAP [RFC1994], the client MUST use: A= Where A1,A2... are proposed algorithms, in order of preference. The server MUST either return an error or reply with: A= I= C= Where A is one of A1,A2... that were proposed by the client. The client MUST continue either with: N= R= or, if he requires server authentication, with: N= R= I= C= If the client authentication fails, the server MUST return an error. Otherwise, if the client required server authentication, the server MUST reply with N= R= Where N, (A,A1,A2), I, C, R are (correspondingly) the Name, Algorithm, Identifier, Challenge and Response as defined in [RFC1994]. N is a text string, A,A1,A2,I are numbers and C,R are large binaries encoded as hexadecimal strings. For the Algorithm, as stated in [RFC1994], one value is required to be implemented: (CHAP with MD5) D. Otis 28 To guarantee interoperability, clients SHOULD always offer it as one of the proposed algorithms. 9.3 Login Phase Examples Note: 'li' or 'tk' signifies a continued sequence. In the first example, the client and server authenticate each other via Kerberos: C:[SU:LI] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 IA_Digest=KRB5_MD5,KRB5_DES_MAC,none AuthMethod=SRP,KRB5,none S:[SU:li] IA_Digest=KRB5_MD5 AuthMethod=KRB5 C:[SU:li] KRB_AP_REQ= (krb_ap_req contains the Kerberos V5 ticket and authenticator with MUTUAL-REQUIRED set in the ap-options field) If the authentication is successful, the server proceeds with: S:[SU:li] KRB_AP_REP= SecurityContextComplete=yes (krb_ap_rep is the Kerberos V5 mutual authentication reply) If the authentication is successful, the client proceeds: C:[SU:li] SecurityContextComplete=yes S:[SU:li] SecurityContextComplete=yes From this point on, any frame thereafter has a KRB5_MD5 digest. The client may proceed: C:[SU:li] subsystem parameters S:[SU:li] subsystem parameters ... C:[SU:LI] optional subsystem parameters S:[SU:LI] Server_Label=com.example.diskarray.sn.88 'login accept' If the client authentication by the server is not successful, the server responds with: S:[SU:LI] 'login reject' instead of the text KRB_AP_REP message, and terminates the Association. D. Otis 29 If the server authentication by the client is not successful, the client terminates the Association (without responding to the text KRB_AP_REP message). In the next example the server via Kerberos authenticates only the client: C:[SU:li] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 IA_Digest=KRB5_MD5,KRB5_DES_MAC,none AuthMethod=SRP,KRB5,none S:[SU:li] IA_Digest=KRB5_MD5 AuthMethod=KRB5 C:[SU:li] KRB_AP_REQ=krb_ap_req SecurityContextComplete=yes (MUTUAL-REQUIRED not set in the ap-options field of krb_ap_req) If the authentication is successful, the server proceeds with: S:[SU:li] SecurityContextComplete=yes From this point on, each frame thereafter MUST have a KRB5_MD5 digest. C:[SU:li] subsystem parameters S:[SU:li] subsystem parameters ... C:[SU:LI] S:[SU:LI] Server_Label=com.example.diskarray.sn.88 'login accept' In the next example, the client and server authenticate each other via SPKM-1: C:[SU:li] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 AI_Digest=KRB5_MD5,KRB5_DES_MAC,SPKM,none AuthMethod=SPKM-1,KRB5,none S:[SU:li] IA_Digest=SPKM AuthMethod=SPKM-1 C:[SU:li] SPKM-REQ= spkm-req is the SPKM-REQ token with the mutual-state bit in the options field of the REQ-TOKEN set) S:[SU:li] SPKM-REP-TI= If the authentication is successful, the client proceeds: C:[SU:li] SPKM-REP-IT= D. Otis 30 SecurityContextComplete=yes If the authentication is successful, the server proceeds with: S:[SU:li] SecurityContextComplete=yes From this point on, each frame thereafter has SPKM digests. The client may proceed: C:[SU:li] subsystem parameters S:[SU:li] subsystem parameters ... C:[SU:LI] subsystem parameters S:[SU:LI] subsystem parameters Server_Label=com.example.diskarray.sn.88 'login accept' If the server authentication by the client is not successful, the client terminates the Association (without responding to the text SPKM-REP-TI message). If the client authentication by the server is not successful, the server responds with: S:[SU:LI] 'login reject' instead of the SecurityContextComplete=yes message, and terminates the Association. In the next example, the client and server authenticate each other via SPKM-2: C:[SU:li] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 IA_Digest=SPKM,none AuthMethod=SPKM-1,SPKM-2,none S:[SU:li] IA_Digest=SPKM AuthMethod=SPKM-2 C:[SU:li] SPKM-REQ= SecurityContextComplete=yes (spkm-req is the SPKM-REQ token with the mutual-state bit in the options field of the REQ-TOKEN not set) If the authentication is successful, the server proceeds with: S:[SU:li] SecurityContextComplete=yes From this point on, each frame thereafter has an SPKM digest. D. Otis 31 The client may proceed: C:[SU:li] subsystem parameters S:[SU:li] subsystem parameters ... C:[SU:LI] subsystem parameters S:[SU:LI] subsystem parameters Server_Label=com.example.diskarray.sn.88 'login accept' In the next example, the client and server authenticate each other via SRP: C:[SU:li] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 IA_Digest=none AuthMethod=KRB5,SRP,none S:[SU:li] IA_Digest=none AuthMethod=SRP C:[SU:li] U= ServerAuth=yes S:[SU:li] N= g= s= C:[SU:li] A= S:[SU:li] B= C:[SU:li] M= If the client authentication is successful, the server proceeds: S:[SU:li] HM= SecurityContextComplete=yes If the server authentication is not successful, the client terminates the Association. Otherwise it proceeds: C:[SU:li] SecurityContextComplete=yes S:[SU:li] SecurityContextComplete=yes Where N, g, s, A, B, M, and H(A | M | K) are defined in [RFC2945]. From this point on, each frame thereafter has no digest. C:[SU:li] subsystem parameters S:[SU:li] subsystem parameters ... C:[SU:LI] subsystem parameters S:[SU:LI] subsystem parameters Server_Label=com.example.diskarray.sn.88 'login accept' D. Otis 32 If the client authentication is not successful, the server responds with: S:[SU:LI] 'login reject' Instead of the S:[SU:LI] HM= message and terminates the Association. In the next example the server via SRP authenticates only the client: C:[SU:li] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 IA_Digest=none AuthMethod=KRB5,SRP,none S:[SU:li] IA_Digest=none AuthMethod=SRP C:[SU:li] U= ServerAuth=no S:[SU:li] N= g= s= C:[SU:li] A= S:[SU:li] B= C:[SU:li] M= SecurityContextComplete=yes If the client authentication is successful, the server proceeds: S:[SU:li] SecurityContextComplete=yes From this point on, each frame thereafter has no digest as normal. C:[SU:li] subsystem parameters S:[SU:li] subsystem parameters ... C:[SU:LI] subsystem parameters S:[SU:LI] subsystem parameters Server_Label=com.example.diskarray.sn.88 'login accept' In the next example the client and server authenticate each other via CHAP: C:[SU:li] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 IA_Digest=none AuthMethod=KRB5,CHAP,none S:[SU:li] IA_Digest=none AuthMethod=CHAP D. Otis 33 C:[SU:li] A= S:[SU:li] A= I= C= C:[SU:li] N= R= I= C= If the client authentication is successful, the server proceeds: S:[SU:li] SecurityContextComplete=yes If the server authentication is not successful, the client aborts the Association. Otherwise it proceeds: C:[SU:li] SecurityContextComplete=yes S:[SU:li] SecurityContextComplete=yes From this point on, each frame does not have a digest as normal. C:[SU:li] subsystem parameters S:[SU:li] subsystem parameters ... C:[SU:LI] subsystem parameters S:[SU:LI] subsystem parameters Server_Label=com.example.diskarray.sn.88 'login accept' If the client authentication is not successful, the server responds with: S:[SU:LI] 'login reject' and terminates the Association instead of: S:[SU:LI] R= SecurityContextComplete=yes In the next example the server via CHAP authenticates only the client: C:[SU:li] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 IA_Digest=none AuthMethod=KRB5,CHAP,none S:[SU:li] IA_Digest=none AuthMethod=CHAP C:[SU:li] A= S:[SU:li] A= I= C= D. Otis 34 C:[SU:li] N= R= SecurityContextComplete=yes If the client authentication is successful, the server proceeds: S:[SU:li] SecurityContextComplete=yes C:[SU:li] subsystem parameters S:[SU:li] subsystem parameters ... C:[SU:LI] subsystem parameters S:[SU:LI] subsystem parameters Server_Label=com.example.diskarray.sn.88 'login accept' In the next example, the client does not offer any integrity- authentication parameters, so it may offer subsystem parameters on initial Login, and the server may respond with a final Login response immediately: C:[SU:LI] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 subsystem parameters S:[SU:LI] Server_Label=com.example.diskarray.sn.88 subsystem parameters 'login accept' C:[SU:TK] subsystem parameters S:[SU:TK] subsystem parameters In the next example, the client does offer integrity-authentication parameters on Login, but the server does not choose any (i.e., chooses the "none" values): C:[SU:li] Client_Label=com.example.hostid.77 Server_Label=com.example.diskarray.sn.88 IA_Digest=none AuthMethod:KRB5,SRP S:[SU:li] C:[SU:li] subsystem parameters S:[SU:li] subsystem parameters ... C:[SU:LI] subsystem parameters S:[SU:LI] subsystem parameters Server_Label=com.example.diskarray.sn.88 'login accept' Note that no SecurityContextComplete=yes is required since no security mechanism was chosen. D. Otis 35 10 Appendix A. Keys IA_Digest= AuthMethod= ServerAuth= KRB_AP_REQ= KRB_AP_REP= SPKM-REQ= SPKM-ERROR= SPKM-REP-TI= U= N= g= s= A= B= M= HM= SecurityContextComplete= For information on the above keys see: Authentication Some session specific parameters MUST be carried only prior to assignment of TSID and cannot be changed after the leading Association Login. The keys that fall into this category have the use defined as LO (Leading Only). Key that can be used only during login have the use defined as IO (initialize only) while those that can be used in both the login phase and full feature phase have the use defined as ALL. Unless explicitly stated otherwise, all key=value pairs specified here are session specific. MaxAssociations Use: LO Who: Client and Server MaxAssociations= The default is 8. This refers to the number of Associations allowed Login. Client and server negotiate the maximum number of Associations requested/acceptable. The lower of the 2 numbers is selected. D. Otis 36 Server_Label Use: LO by client ALL by server Who: Client and Server Server_Label= Examples: Server_Label=com.example.diskarrays.sn.45678 The client MUST provide this key to the server before the end of the login phase. Server_Label specifies the server. The server default alias "default" may be used to select whatever default server exists at the address to which the Association was made. Some servers MAY require this key before authenticating. Client_Label Use: LO Who: Client and Server Client_Label= Examples: Client_Label=com.example.users.customer235.host90 The client MUST provide this key to the server before the end of the login phase. The client key enables the client to identify itself to the server. The default alias "anonymous" may be used. The server may silently ignore this key. A server may allow or deny access to this alias. Server_Alias Use: ALL Who: Server Server_Alias= Examples: Server_Alias=Database Server 1 Log Disk If a server has been configured with a human-readable label or description, this name MUST be communicated to the client during Login. This string is not used as an identifier, but can be displayed by the client's user interface as a list of servers to which it is connected. This field MUST also be returned in the response to "List_Servers" if it is set at the server. D. Otis 37 Client_Alias Use: ALL Who: Client Client_Alias= Examples: Client_Alias=spyalley.nsa.gov If a client has been configured with a human-readable name or description, it may be communicated to the server during Login. If not, the host name can be used instead. This string is not used as an identifier, but can be displayed by the server's user interface in a list of clients to which it is connected. The client SHOULD send this key within the Login phase if available. Server_URL Use: ALL Who: Server Server_URL=domainname[:port][/server_label] If the address contains a server_name part then this is a LO parameter. Examples: Server_URL=10.0.0.1/com.disk-vendor.diskarrays.sn.45678 Server_URL=12.5.7.10.0.0.1/com.gateways.yourservers.24 The response to List_Servers returns one or more server addresses for each server label it returns. This field is used to indicate one of the known addresses of the server. List_Servers Use: ALL Who: Client This key is used within a text command to request a list of servers be sent back to the client. The presence of this key is sufficient to do this; no value should be sent with this key. Example: List_Servers= D. Otis 38 AccessID Use: ALL Who: client AccessID= Delivers a device AccessID to the server. InitialR2T Use: ALL Who: Client and Server InitialR2T= Examples: C:InitialR2T=no S:InitialR2T=no The default is yes. The InitialR2T key is used to turn off the default use of Request to Transfer Setup, thus allowing the client to start sending write data to a server as if it had received Request to Transfer with Buffer Offset=0 and Desired Data Transfer Length set to the lesser of FirstBurstSize or Expected Data Transfer Length. The default action is that R2T is required, unless both the client and the server send this key-pair attribute specifying InitialR2T=no. Once InitialR2T has been set to 'no', it cannot be set back to 'yes'. Note that only the first write data can be sent unsolicited. BidiInitialR2T Use: ALL Who: Client and Server BidiInitialR2T= Examples: C:BidiInitialR2T=no S:BidiInitialR2T=no The BidiInitialR2T key is used to turn off the default use of BiDiR2T, thus allowing the client to start sending write data of a Bi-directional command (having both the Read and the Write bits set) to a server as if it had received Request to Transfer with Buffer Offset=0 and Desired Data Transfer Length set to the lesser of FirstBurstSize or Expected Data Transfer Length. The default action is that Request to Transfer is required, unless both the client and the server send this key-pair attribute specifying BidiInitialR2T=no. Once BidiInitialR2T has been set to 'no', it cannot be set back to 'yes'. Note that only the first write data can be sent unsolicited. D. Otis 39 FirstBurstSize Use: ALL Who: Client and Server FirstBurstSize= The default is 128 units. Client and server negotiate the maximum length supported for unsolicited write data in units of 512 bytes. The lesser of the two numbers is selected. This parameter may be visible at the device layer. LogoutLoginMinTime Use: ALL Who: Client and Server LogoutLoginMinTime= The default is 1. Client and server negotiate the minimum time in seconds a Login may follow a Logout response or Asynchronous Message announcing disconnect. The greater of the two values is selected. LogoutLoginMaxTime Use: ALL Who: Client and Server LogoutLoginMaxTime= The default is 3. Client and server negotiate the maximum time in seconds after which recovery is still possible after a logout or Asynchronous Message announcing disconnect. The lesser of the two values is selected. MaxOutstandingR2T Use: ALL Who: Client and Server MaxOutstandingR2T= The default is 8. Client and server negotiate the maximum number of outstanding Requests to Transfer per Stream. The Vector Data will present the same Data Offset as sent within the Buffer Offset. D. Otis 40 BootSession Use: LO Who: Client BootSession= Default is no. BootSession MAY be set to yes by Login indicating to the server that the only purpose of this Session is booting. The server MAY restrict the type of requests it accepts in such a session to Logout, and read commands. Accepting other commands in this type of session is vendor-dependent. A server MAY reject a boot-session. Vendor Specific Key Format Use: ALL Who: Client and Server X-reversed.vendor.dns_name.do_something= Keys with this format are used for vendor-specific purposes. These keys always start with 'X-' and to identify the vendor it is suggested to use the reversed DNS-name as a prefix to the key-proper. D. Otis 41 11 Acknowledgement Information contained was largely complied from the Internet Draft draft-ietf-ips-iscsi-6.txt by Julian Satran Daniel Smith Kalman Meth Ofer Biran IBM Costa Sapuntzakis Cisco Systems Matt Wakeley Agilent Technologies Luciano Dalle Ore Quantum Paul Von Stamwitz Adaptec Randy Haagens Mallikarjun Chadalapaka Hewlett-Packard Co. Efri Zeidner SANGate Yaron Klein SANRAD and Randall R. Stewart Author of SCTP D. Otis 42 Author's Addresses Douglas Otis SANlight Inc. 160 Saratoga Ave. #40 Santa Clara, CA 95051 Phone: 408-260-1400 x 2 Email: dotis@sanlight.net 12 Full Copyright Statement "Copyright (C) The Internet Society (date). 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.