IPS Douglas Otis Internet Draft SANlight Document: draft-otis-record-delivery-01.txt May 8, 2001 Category: Standards Track SCTP compatible delivery subsystem draft-otis-record-delivery-01.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 Offload Architecture..............................................2 5 Record Directed Data Placement....................................3 6 Structures within User Data.......................................4 6.1 Client's Request [CR] structure within User Data: ..............4 6.2 Directed Data [DD] structure within the User Data: .............5 6.3 Server's Response [SR] structure within the User Data: .........6 6.4 Transfer Request [TR] structure within User Data: ..............9 6.5 Setup [SU] structure within the User Data: .....................9 6.6 Setup Data ....................................................10 6.6.1 Login [SU:LI](Client to Server) .............................10 6.6.2 Login [SU:LI] (Server to Client) ............................11 6.6.3 Logout [SU:LO] (Client to Server) ...........................14 6.6.4 Logout [SU:LO] (Server to Client) ...........................14 6.6.5 Text expressions [SU:TK] (Client to Server) .................15 6.6.6 Text expressions [SU:TK] (Server to Client) .................16 6.6.7 Client's Management [SU:CM] (Client to Server) ..............16 6.6.8 Client's Management [SU:CM] (Server to Client) ..............18 7 Client, Server, and Members Labels and Addresses.................19 8 Client Server Interaction........................................21 8.1 Login Phase ...................................................21 8.1.1 Login Phase Start ...........................................22 8.1.2 Integrity-Authentication Negotiation ........................23 8.1.3 Subsystem Parameter Negotiation During the Login Phase ......25 8.1.4 Subsystem Parameter Negotiation after Login Phase ...........25 8.2 Subsystem Error Handling and Recovery .........................26 8.3 Syntax Errors .................................................26 9 IANA Considerations..............................................26 10 Security Considerations.........................................26 10.1 Protection Modes .............................................27 10.1.1 No Protection ..............................................27 10.1.2 Client-Server Authentication ...............................27 10.1.3 Integrity-authentication ...................................27 10.2 Authentication ...............................................29 10.3 Login Phase Examples .........................................32 11 Symbols.........................................................39 11.1 Authentication-Integrity Symbols .............................39 11.2 Prompting Pseudo Symbols .....................................39 11.3 Labels and Aliases ...........................................41 11.4 Addressing ...................................................43 11.5 Subsystem Symbols ............................................44 12 Full Copyright Statement........................................49 4 Offload Architecture Offloading the data placement for network exchanges at the network adapter adds constraints for scaling. For multiple paths to the adapter, SCTP combines individual connections into Associations. To allow multiple adapters to be used in combination, these Associations are combined into a Gang. Each SCTP Association dedicates Stream zero for resolving Gang management operations over multiple D. Otis 3 Associations. The Gang is a fusion of one or more Associations where Stream combines with an Association Key (A_KEY) as part of Stream addressing to enable use of multiple adapters and SCTP Associations as if one. For collaborative operations, Gangs are extended into Groups. Within a Group, Gangs share the same Client Key (C_KEY), Server Key (S_KEY). If Gangs across Group Members also share the same Association Key (A_KEY), then their exchange happens as if on the same Stream. Reception vectors assigned to a Stream is thus shared across all Group Members to enable distributive server processing. 5 Record Directed Data Placement In keeping with the conventions established for record based 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 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. D. Otis 4 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 | / / +---------------+---------------+---------------+---------------+ 6 Structures within User Data 6.1 Client's Request [CR] structure within User Data: (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 +---------------+---------------+---------------+---------------+ 0| Mode | reserved | Alliance | +---------------+---------------+---------------+---------------+ 4| Expected Read Transfer Length | +---------------+---------------+---------------+---------------+ 8| Expected Write Transfer Length | +---------------+---------------+---------------+---------------+ 12| Queue | +---------------+---------------+---------------+---------------+ 16| Argument | +/ / +---------------+---------------+---------------+---------------+ Mode: (For Queue Entity layer use only.) 0x0 - Simple Queue 0x1 - Head of Queue 0x2 - Ordered Queue 0x4 - Error Queue 0x8 - No Queue Others values reserved Alliance May be used to establish relationships within the Queues. The actual use is not defined within this document. D. Otis 5 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 that acts as a limit. If set to 0xffffffff, then the related transfer count is unlimited. A Read transfer would be from the server to the client and conversely a write operation would be from the client to the server. Queue This value is not defined within this document beyond queue management functions. Argument (For Queue Entity layer use only.) This information is passed to the Queue Entity and is not defined within this document. 6.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 6 6.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 | reserved | Status-Class | Status-Detail | +---------------+---------------+---------------+---------------+ 4| Residual Read Count | +---------------+---------------+---------------+---------------+ 8| Residual Write Count | +---------------+---------------+---------------+---------------+ 12| Reply | +/ / +---------------+---------------+---------------+---------------+ 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-Class: (if Defined by Delivery Subsystem) 0x01 - Unsolicited Data Rejected 0x02 - Client's Request Rejected by Delivery Subsystem 0x03 - Client's Request Rejected by Queue Entity Layer 0x04 - Illegal Request before Login 0x10 - Server Failure (may be AE) 0x11 - Delivery Subsystem Failure (may be AE) 0x20 - Server Alert (AE) 0x21 - Server Being Reset (AE) 0x22 - Server Requests Logout (AE) 0x23 - Server Will Close Association (AE) 0x24 - Client's Management Completion (AE) 0x80-0xff - Reserved for Vendor-Unique Responses Status-Detail Status-Detail use is not defined in this document. 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. D. Otis 7 Reply This data provides additional information related to the status. In the case of this information having been set by the Delivery Subsystem, only those defined for Status-Class 0x2n are defined by this document. Information included in status and Reply is beyond the scope of this document if not defined by the Delivery Subsystem. A set overflow bit indicates the residual count contains the number of bytes remaining to be transferred at the Queue Entity layer 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 residual count may not be indicative of an error. A set Asynchronous Event bit indicates the status and Reply information does not represent a Server's Response to a Client's Request and indicates the residual counts are not valid. A set Defined by Delivery Subsystem bit indicates the Queue Entity layer has not set status and Reply information. If also accompanied with the Asynchronous Event bit being set, then this Server's Response is presented independent of any other client and server exchange. Replies for Status-Class 0x2n Server Alert +---------------+---------------+---------------+---------------+ 12| Alert Code | reserved | +---------------+---------------+---------------+---------------+ Alert Code: 0x01 - Queue Configuration Modified 0x02 - Subsystem Configuration Modified 0x03 - Association Added 0x04 - Association Removed 0x05 - Group Member Added 0x06 - Group Member Removed Server Being Reset The server indicates to all clients with an Association. This response also indicates the earliest time before the server will be ready for continued operation. D. Otis 8 +---------------+---------------+---------------+---------------+ 12| reserved | S_KEY | +---------------+---------------+---------------+---------------+ 16| Earliest Time before Ready | +---------------+---------------+---------------+---------------+ Server Requests Logout The first 32 bits within Reply information contains the A_KEY of the Association to Logout. +---------------+---------------+---------------+---------------+ 12| reserved | A_KEY | +---------------+---------------+---------------+---------------+ Server Will Close Association The first 32 bits within Reply information contains the A_KEY of the affected Association. The second 32 bits indicates the earliest time and the third 32 bits indicates the latest time in seconds to establish Association and Login. +---------------+---------------+---------------+---------------+ 12| reserved | A_KEY | +---------------+---------------+---------------+---------------+ 16| Earliest Time before Login | +---------------+---------------+---------------+---------------+ 20| Latest Time before Login | +---------------+---------------+---------------+---------------+ Client's Management Completion The first 16 bits within Reply information contains Stream Identifier followed by the 16 bit Association Key, A_KEY. The Function being responded to by the Server is identified in the next 16 bits pair. This response is sent to all Associations within the Gang, the same C_KEY, not receiving the initial management request. If there were multiple responses made at the server, the Reply information may be repeated to encompass all such functions. +---------------+---------------+---------------+---------------+ 12| Stream Identifier | A_KEY | +---------------+---------------+---------------+---------------+ 16| Function | S_KEY | +---------------+---------------+---------------+---------------+ 20| additional responses (if any) | +/ / +---------------+---------------+---------------+---------------+ D. Otis 9 6.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 Queue Entity settings. The Desired Data Transfer Length MUST not be 0. There may be several Transfer Requests active on a given stream. 6.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|M| reserved | Status-Class | Status-Detail | +---------------+---------------+---------------+---------------+ 4| Setup Data | +/ / +---------------+---------------+---------------+---------------+ Setup Attribute: 0x00 - Login 0x01 - Logout 0x02 - Text expressions 0x03 - Client's Management Other values reserved C (Continue) Bit The C bit is set to indicate additional setup is requested. M (Member) Bit The M bit is set to indicate the client has designated this Association is with a Group Member server. If cleared, this indicates the primary server is designated. D. Otis 10 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. 6.6 Setup Data 6.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_KEY | +---------------+---------------+---------------+---------------+ 8| C_KEY | S_KEY | +---------------+---------------+---------------+---------------+ 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. A_KEY This is a unique ID for this Association within the Gang. C_KEY This is a client identifier established by the client to identify a Gang or Group. It MUST be the same for all Associations within a Gang and a Group sharing the same S_KEY. The client will ensure C_KEY is unique within the client's domain. If attempting to restore the state of a prior exchange, the Client label and C_KEY is used to recognize this prior exchange. S_KEY This is a client identifier returned by the server at the conclusion of the initial Login. This value is set to zero until known. S_KEY will be the same for all Group Members as well as for those Associations within the initial server Gang. D. Otis 11 Text The client MAY provide some Text expressions 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 expressions with the exception of Server_Label processing. The Server_Label response is delayed and occurs within the final Login exchange to allow for iteration from default to specific servers. Symbols and their explanations are listed in the Symbols section. 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. 6.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_KEY | +---------------+---------------+---------------+---------------+ 8| C_KEY | S_KEY | +---------------+---------------+---------------+---------------+ 12| Text | +/ / +---------------+---------------+---------------+---------------+ Version-Max This is the highest version number supported by the server. 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. D. Otis 12 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 expressions parameters 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 13 ----------------------------------------------------------------- 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:C_KEY |0x0206| 0 | No additional Associations accepted Error | | | for this Client:C_KEY (S_KEY = 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 14 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. C_KEY S_KEY The S_KEY is a client identifier set by the server. It is valid only if the Association Login is accepted. The S_KEY MUST be returned in partial responses (C bit set) and the same value MUST be presented with the final response (C bit cleared). The Client Label together with the C_KEY forms the Gang identifier. 6.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| Action Code | reserved | A_KEY | +---------------+---------------+---------------+---------------+ Action Code: 0x00 - Close Gangs 0x01 - Close Association 0x02 - Close Association at server's request (Requested through an Asynchronous Event) A_KEY This is the Association ID to be closed. This field is valid only if the Action Code is not "Close Gangs". Logout is used to perform a controlled closing of an Association. 6.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| Action Code | reserved | A_KEY | +---------------+---------------+---------------+---------------+ Action Code and A_KEY The server echoes Action Code and A_KEY. D. Otis 15 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. 6.6.5 Text expressions [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 symbol=value or symbol=list pairs encoded in UTF-8 Unicode. The symbol and value are separated by an '=' (0x3D) delimiter. Many symbol=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 symbol SHOULD contain more than 512 characters. The server responds to understood symbols with its representation of the symbol in similar format. The value of the symbol reflects server's present setting. Some basic symbol=value pairs are described in Symbols section. Clients and servers MUST support all of these symbols, except those using the 'X-' (0x58, 0x2D) extension format. Vendors may introduce new symbols 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 symbol not understood by the server may be ignored without affecting basic function. If the Text expressions response does not contain a symbol that was requested, the client must assume the server did not understand the symbol or, whenever appropriate, the response was "none". The server, whenever appropriate, should respond using "none" rather than no response, if the symbol was understood. Text expressions is usually meant for parameter setting or negotiations but can be also used to perform infrequent Delivery Subsystem operations. D. Otis 16 It is recommended that Text expressions that invoke operations expected to take a long time be placed in separate requests. A Gang may have only one text sequence active at any given time. 6.6.6 Text expressions [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 expressions contain the server's response to the client's Text expressions 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 Text expressions with the Continue bit cleared, then the server wishes additional setup. A Text expressions response with the Continue bit cleared to a request with the Continue bit set indicates an error. The Text expressions contains symbol=value responses in the same order as the Text expressions request and with the same encoding constraints. If the Text expressions response does not contain a symbol that was requested, the client must assume the symbol was not understood by the server or that the answer is symbol=none. The Symbols section list Text expression representations and their responses. Text expressions 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 6.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| Function | reserved | +---------------+---------------+---------------+---------------+ 8| Queue | +---------------+---------------+---------------+---------------+ D. Otis 17 Queue This value is used to access a Queue Entity and is not defined within this document. Function: 0x01 - Abort Request 0x02 - Abort Request Set (w/Client's Management Completion AE) 0x03 - Clear Error Interlock (For Queue Entity layer only.) 0x04 - Clear Request Set (w/Client's Management Completion AE) 0x05 - Queue Reset (w/Client's Management Completion AE) 0x06 - Server Reset 0x07 - Server Reset and Close Gangs 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 a server returns Client's Management response, the Client's Management request is no longer active. If there are multiple Associations within a Gang affected, all Associations not receiving the request will also be sent a Server's Response on Stream 0 indicating an Asynchronous Event defined by the Delivery Subsystem with Client's Management Completion status. In addition to the possible discard of Client's Requests pending delivery to the Queue Entity layer, an equivalent action may also be performed at the Queue Entity layer. The mapping of the Function code to a Queue Entity 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 Queue Entity layer and returns a Completion of Client's Request Discarded. Otherwise, a Queue Entity action is sent to the specified Queue and returns the normal Completion of Function Complete. Abort Request Set Discards all Client's Requests pending delivery to the Queue Entity layer issued by this client to the specified Queue and a Queue Entity action is sent to the specified Queue. A Client's Management Completion Asynchronous Event will be sent to Stream 0 of all other Associations. Clear Error Interlock Clears an error interlock with a Queue Entity action sent to the specified Queue. D. Otis 18 Clear Request Set Discards all Client's Requests pending delivery to the Queue Entity layer issued by all clients for the specified Queue and a Queue Entity action is sent to the specified Queue. A Client's Management Completion Asynchronous Event will be sent to Stream 0 of all other Associations. Queue Reset In addition to performing Clear Request Set, this sends a Queue Entity action that returns the Entity to a state similar to power-on. A Client's Management Completion Asynchronous Event will be sent to Stream 0 of all other Associations. Server Reset In addition to performing Queue Reset for all Queues, this returns the server to the power-on state while maintaining Delivery Subsystem Gangs. The Asynchronous Event response will be sent to Stream 0 of all Associations. Server Reset and Close Gangs This does the same as a Server Reset but then also performs Close Gangs 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. 6.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| Function | reserved | +---------------+---------------+---------------+---------------+ 8| Queue | +---------------+---------------+---------------+---------------+ Function The server echoes Function. Class-Detail: 0x0000 - Function Complete 0x0001 - Client's Request Discarded 0x0002 - Client's Request not active on Stream 0x0100 - Queue does not exist 0x0200 - Function Rejected If Abort Request was able to discard a Client's Request prior to delivery to the Queue Entity layer or where the Queue Entity layer D. Otis 19 determined there was no active Client's Request, no Queue Entity action is taken. Otherwise, in addition to a Client's Management response from the server, the Queue Entity layer should also indicate a Queue Entity action was taken. For the Server Reset and Close Gangs function, upon delivery of this Completion response, the server MUST then close all of its Associations to all clients to effectively close all Gangs. The mapping of a Queue Entity response into Class-Detail status is beyond the scope of this document. 7 Client, Server, and Members Labels and Addresses Server discovery is beyond the scope of this document but once an address for a server has been obtained, further resolution is done using labels. 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" may be used. As with clients, servers should also be assigned globally unique labels. The assignment of client and server labels is beyond 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 symbol request Server_List="" to retrieve an iterative list of servers that exist at that the present Association. The information is presented sequentially starting with Server_Label=<>, followed by one or more Server_Address=<>, and then Server_Alias=<>. If there are additional Servers available, the final entry is Server_More="". The next server entry is obtained using a Server_Next="" request. The Group Members of a server is obtained in a similar fashion. The request is made using Member_List=. The response is Member_Label=<>, followed by one or more Member_Address=<>, and then Member_Alias=<>. If there are additional Members available, then the final entry is Member_More="". The next member entry is obtained using a Member_Next="" request. Servers and Members have an address that specifies a single initial path on which to create an Association. It also carries the optional port specification. If ":port" is not specified, the well-known port assigned by IANA will be assumed. D. Otis 20 Where is one of: - IPv4 address, in dotted decimal notation. Assumed if the name contains exactly four numbers, separated by periods '.'(0x2E), where each number is in the range of 0 to 255. If placed within square brackets '[' (0x5B) and ']' (0x5D), then an IP address is assumed rather than a domain name. - 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 periods '.', where each number is in the range of 0 to 255. If placed within square brackets '[' and ']', then text representations and abbreviations defined in [RFC1884] may also be used and is the preferred representation of IPv6. - Fully qualified domain name. Assumed if the is neither an IPv4 nor an IPv6 address. This is not the preferred means of providing addressing, as it then requires an additional step of acquiring the IP address through use of a domain name. Examples of server label: fqn.com.example.diskarrays.sn.45678 Examples of IPv4 addresses: 10.0.0.1 10.0.0.2:2000 Examples of IPv6 addresses: 12.5.7.10.0.0.1 [::FFFF:129.144.52.38] [FEDC:BA98:7654:3210:FEDC:BA98:7654:3210] [1080::8:800:200C:417A]:2000 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 interface for 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. The client defines the Client Key (C_KEY), and must be unique for each Group at the client. The server defines the Server Key (S_KEY), and it must also be unique for each Group at the server. A Group shares the same C_KEY and S_KEY. An Association within a Group having the same A_KEY can exchange information on a particular Stream using the same vectors assigned for the Stream. All servers within a D. Otis 21 Group may respond to requests made to the primary server within the Group. All requests must be made to the primary server within the Group. 8 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. An exception to this limitation is on Stream 0 where asynchronous Server's Responses carrying Client Management Completion are sent to allow coherent completions across multiple Associations. In the case of multiple Associations, the completion response should not be relayed to the application until all affected Associations have indicated completion. The server responds 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 Queue Entity layer, may also issue Directed Data. The Queue Entity 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. 8.1 Login Phase The login phase establishes a Gang between client and server. It authenticates the client and server to each other and establishes subsystem parameters. 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 confidentiality setup MAY be performed independently (as when using tunneling IPSec or some implementations D. Otis 22 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 expressions 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 expressions with the C bit cleared. In this case, additional parameters are requested. 8.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 - Primary Server or Group Member flag - Client and Server IDs, and Association IDs - Integrity-Authentication parameters - Subsystem parameters 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 Queues. The means the server uses to disclose the available Queues 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 Gang to identify the server of the Gang. However, it is OPTIONAL for all the Associations after the first. The server, for new Associations within an existing Gang, ignores the server label. 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 D. Otis 23 an unknown server. A "default" server may not allow Client's Requests if a server is to be selected from the server list. 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 Gang to terminate. - Login Response with Login Accept with S_KEY 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 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). 8.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 expressions=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. - SCTP integrity - an integrity-authentication digest (IAD) Chunk is inserted at the beginning of each frame. The algorithm is negotiable. Using IPsec for confidentiality or integrity may eliminate the need for integrity-authentication negotiation at the server level, e.g., ISAKMP for IPsec. D. Otis 24 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 expressions. 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 Symbols Section. - Every party in the integrity-authentication negotiation indicates that it has completed building its security context (has all the required information) by sending the symbol=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. 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 D. Otis 25 request; 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. The integrity-authentication negotiation must ensure by some means, no man in the middle tampering is able to negotiate less than the lowest mutually supported mode. 8.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 expressions) 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. 8.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 26 8.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 Queue Entity 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 Queue Entity layer. Once the server response has be acknowledged by Delivery Subsystem back to the server, these server resources may also be released. 8.3 Syntax Errors Explicit violations of the rules stated in this document are syntax errors. While a Gang 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. 9 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. 10 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 confidentiality 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. D. Otis 27 10.1 Protection Modes Every compliant client and server MUST be able to provide client- server authentication and data integrity-authentication. This quality of protection MAY be achieved on every Association through properly configured IPSec. 10.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. 10.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. 10.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 28 +-------------------------------------------------------------+ | 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 29 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]. 10.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 30 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 that 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 31 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. D. Otis 32 For the Algorithm, as stated in [RFC1994], one value is required to be implemented: (CHAP with MD5) To guarantee interoperability, clients SHOULD always offer it as one of the proposed algorithms. 10.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' D. Otis 33 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. 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 D. Otis 34 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= 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 D. Otis 35 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. 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 D. Otis 36 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' 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' D. Otis 37 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 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: D. Otis 38 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= 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] D. Otis 39 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. 11 Symbols 11.1 Authentication-Integrity Symbols For information see: Authentication 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= 11.2 Prompting Pseudo Symbols Server_List="" Use: ALL Who: Client This symbol is used within a text request to obtain a list of servers be sent back to the client. The presence of this symbol is sufficient to do this; no value should be sent with this symbol. Example: Server_List= D. Otis 40 Server_More="" Use: ALL Who: Server This symbol is used within a text response to indicate additional servers are available sent back to the client. The presence of this symbol is sufficient to do this; no value should be sent with this symbol. Example: Server_More= Server_Next="" Use: ALL Who: Client This symbol is used within a text request to iteratively respond to a Server_More="" from the server to obtain the next within a list of servers to be sent back to the client. The iterative process presents a list valid at the initial Server_List="" request. The presence of this symbol is sufficient to do this; no value should be sent with this symbol. Example: Server_Next= Member_List= Use: ALL Who: Client This symbol is used within a text request to obtain a list of Group Member servers be sent back to the client. Example: Member_List=fqn.com.example.myserver D. Otis 41 Member_More="" Use: ALL Who: Server This symbol is used within a text response to indicate additional Group Member servers are available sent back to the client. The presence of this symbol is sufficient to do this; no value should be sent with this symbol. Example: Member_More= Member_Next="" Use: ALL Who: Client This symbol is used within a text request to iteratively respond to a Member_More="" from the server to obtain the next within a list of Group Member servers to be sent back to the client. The iterative process presents a list valid at the initial Member_List="" request. The presence of this symbol is sufficient to do this; no value should be sent with this symbol. Example: Member_Next= 11.3 Labels and Aliases Server_Label Use: BA by client ALL by server Who: Client and Server Server_Label= Examples: Server_Label=com.example.diskarrays.sn.45678 The client MUST provide this symbol 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 symbol before authenticating. D. Otis 42 Client_Label Use: BA Who: Client and Server Client_Label= Examples: Client_Label=com.example.users.customer235.host90 The client MUST provide this symbol to the server before the end of the login phase. The client symbol enables the client to identify itself to the server. The default alias "anonymous" may be used. The server may silently ignore this symbol assignment. A server may allow or deny access to this alias. Member_Label Use: BA by client ALL by server Who: Client and Server Member_Label= Examples: Member_Label=com.example.diskarrays.sn.45678 The client MUST provide this symbol to the server before the end of the login phase. Member_Label specifies the server. During Login to a Group Member server, Member_Label symbol replaces Server_Label and the Login has the M bit set. 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 Server_List="" if it is set at the server. D. Otis 43 Client_Alias Use: ALL Who: Client Client_Alias= Examples: Client_Alias=My Home Drive at example.com 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 symbol within the Login phase if available. Member_Alias Use: ALL Who: Server Member_Alias= Examples: Member_Alias=Cluster Server 3 at example.com If a server has been configured with a human-readable name or description, it may 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 in a list of clients to which it is connected. The server SHOULD send this symbol within the Login phase if available. 11.4 Addressing Server_Address Use: ALL Who: Server Server_Address=address[:port] Examples: Server_Address=10.0.0.1:2000 Server_Address=[1080::8:800:200C:417A]:2000 The response to Server_List="" 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. This field is repeated to indicate additional addresses. D. Otis 44 Member_Address Use: ALL Who: Server Member_Address=address[:port] Examples: Member_Address=10.0.0.1:2000 Member_Address=[1080::8:800:200C:417A]:2000 The response to Member_List= returns one or more Group Member server addresses for each member label it returns. This field is used to indicate one of the known addresses of the server. This field is repeated to indicate additional addresses. 11.5 Subsystem Symbols Some Gang specific parameters MUST be negotiated prior to assignment of S_KEY and cannot be changed after the leading Association Login. The symbols that fall into this category have the use defined as BA (Before Assignment Only). Symbols 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 afterwards have the use defined as ALL. Unless explicitly stated otherwise, all symbol=value pairs specified here are Gang specific. MaxAssociations Use: BA 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 two numbers is selected. D. Otis 45 MaxGroupMembers Use: BA Who: Client and Server MaxGroupMembers= The default is 16. This refers to the number of Member Gangs supported. Client and server negotiate the maximum number of Group Members requested/acceptable. The lower of the two numbers is selected. AccessID Use: ALL Who: client AccessID= Delivers a Queue Entity AccessID to the server. Initial_TR Use: ALL Who: Client and Server Initial_TR= Examples: C:Initial_TR=no S:Initial_TR=no The default is yes. The Initial_TR symbol is used to turn off the default use of Transfer Request, thus allowing the client to start sending write data to a server as if it had received a Transfer Request to 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 Transfer Request is required, unless both the client and the server send this symbol-pair attribute specifying Initial_TR=no. Once Initial_TR 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 46 BidiInitial_TR Use: ALL Who: Client and Server BidiInitial_TR= Examples: C:BidiInitial_TR=no S:BidiInitial_TR=no The BidiInitial_TR symbol is used to turn off the default mode of bi- directional Client's Requests, thus allowing the client to start sending write data of a bi-directional request (setting both the Read and the Write Expected Transfer Lengths) to a server as if it had received Transfer Request 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 Transfer Request is required, unless both the client and the server send this symbol-pair attribute specifying BidiInitial_TR=no. Once BidiInitial_TR has been set to 'no', it cannot be set back to 'yes'. Note that only the first write data can be sent unsolicited. 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 Queue Entity 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. D. Otis 47 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. MaxOutstanding_TR Use: ALL Who: Client and Server MaxOutstanding_TR= The default is 8. Client and server negotiate the maximum number of outstanding Transfer Requests per Stream. The Vector Data will present the same Data Offset as sent within the Buffer Offset. BootGang Use: BA Who: Client BootGang= Default is no. BootGang MAY be set to yes by Login indicating to the server that the only purpose of this Gang is booting. The server MAY restrict the type of requests it accepts in such a Gang to Logout, and read requests. Accepting other requests in this type of Gang is vendor-dependent. A server MAY reject a boot-Gang. Vendor Specific Symbol Format Use: ALL Who: Client and Server X-reversed.vendor.dns_name.do_something= Symbols with this format are used for vendor-specific purposes. These symbols always start with 'X-' and to identify the vendor it is suggested to use the reversed DNS-name as a prefix to the symbol- proper. D. Otis 48 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 49 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.