Network Working Group A. Majumder Internet Draft HFCL R&D January 2002 This document expires on 21st July, 2002 Generic Client Server Protocol (GCSP) for Application Layer draft-majumder-gcsp-application-01.txt 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/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Table of Contents 1. Abstract.................................................1 2. Introduction.............................................1 3. Purpose..................................................1 4. Prior Assumption.........................................2 5. Access Control...........................................2 6. Understanding Encryption Standards.......................2 7. Operations and Opcodes...................................3 8. Common Information Base (CIB) for Server and Client....................................3 9. Overview of the Protocol.................................3 10. Packet Structures.......................................4 11. Server Architecture.....................................6 12. References..............................................7 13. Author's Address........................................7 14. Full Copyright Statement................................7 Appendix I..................................................7 1. Abstract Generic Client Server Protocol is a simple generic Application level protocol to standardize communication between a pair of generic Client and Server. It also tries to show some way to develop a tool that will build automatically the generic Client/Server pair at application layer. However, the main objective of this memo is to standardize an application layer protocol stack for Client/Server communication. 2. Introduction The Client Server architecture is one of the most used techniques in today's internet community. Yet there exists no standardized method to implement a protocol stack in Application Layer for generic Clients and Servers.This memo is a generic approach to implement some standardization in this direction.There exists several application level protocols as HTTP[1],FTP[2],TFTP[3] etc.Except these people design their own proprietary protocols to implement Client Server communication at application level appropriate for their use only. 3. Purpose This is mainly intended for the developers who are trying to implement a generic protocol stack for Client Server communication at application layer. Also note that this protocol is not intended for well established application level protocols as http,ftp etc. as it will cost a havoc for internet industry.This is only for generic user defined Client and Servers. page 1 4. Prior Assumptions As any other protocol there should be some standardization before we go to the actual details of the protocol.These are : a. The protocol is primarily implemented on TCP (however with some changes it can be used on UDP also). b. As on TCP the server will listen on a particular well known port. I suggest port 110 if TCP be the transport protocol. c. Prior understanding between Client and Server of Access Control and encryption standards are required if client and server like to communicate in encrypted PDUs. (See section 5). d. Prior understanding between Client and Server of Common Information Base (CIB) and Operation Codes (opcodes).(See section 7 and 8). 5. Access Control This option is kept for security reasons. Access Control policies are required while initiating the communication.The Connection Request (CR) packet (described later) should contain a username and password in encrypted manner. Based on this,appropriate access control will be picked up by the server.These users and their passwords are configured separately (manually at the server end) or a client with "administrator" privilege can set up a client. Setting up a client include : i. Assigning a username and password. ii. Choosing appropriate type of that user. Based on this the appropriate access control will be assigned to the user. Access Control is basically nothing but a way to find a subset of all the available operations (see section 7) and a subset of CIB ( see section 8) known to the server. This subset of operations only are permitted and will be executed by the server on the subset of CIB for that particular client.Otherwise an error packet will be returned stating "Access Violation". 6. Understanding Encryption Standards The communication between server and client can go on without any encryption. But for security reason it is recommended that the communication should go on in encrypted way. Typically server should know all the encryption standards available nowadays.So,it is the client's responsibility to inform, while sending the Connection Request (CR) packet,what encryption standard/s it is going to follow for this communication. The related keys etc. are also supposed to be understood between server and client beforehand (i.e, before client sends CR packet). A 2-byte identifier,Encryption Standard Identifier (ESID) is also required corresponding to each encryption standard .This encryption identifier will be used in the Connection Request (CR) packet (described later) to identify the encryption standard and keys corresponding to it to be used in the encrypted communication. page 2 7. Operations and Opcodes There should be obviously a set of operations (finite in number) that the server can perform. As for example, a database server can read data, modify data etc. So, for each operations there would be a 2 byte opcode. Note the opcodes are generic and vary from system to system. The only restriction is the size (2 bytes) of each opcode. Access control disables some of the operations respective to a particular client depending on the type of user (known from the username found in the request packet). 8. Common Information Base (CIB) for Server and Client CIB is just like MIB for NMS and can follow the same methodology and tools (i.e, standard ASN.1 & GDMO) to define this common information Base. The server and client should agree upon this CIB prior to the actual communication. This protocol currently has NO provision to configure the CIB online. CIB is nothing but the actual resources the server is capable to handle along with the Resource IDs and the types of the resources in details. The client and server should uniquely know the Resource IDs. Access control again makes a subset of the CIB and thus resources on which a particular client can work on. 9. Overview of the Protocol The communication between server and client will begin normally with a connection request from the client. CR packet will be preceded by a 2-byte Encryption Standard Identifier (ESID) and this will be followed by a 2-byte Protocol Opcode (POP). This POP is completely different from the opcodes discussed in section 6.Initially server will listen on port 110. The client will send a Connection Request (CR) packet to it. The first two bytes of the CR packet should contain 2-byte Encryption Standard Identifier (ESID) as per understanding between server and client. Using that encryption standard the REST of the CR packet including POP is decrypted (Note the ESID of the CR packet is NOT encrypted). The packet may not be in encrypted form and then the first 2 bytes of the CR packet will contain 00. If the CR packet is encrypted then the rest of the communication should also be encrypted using same encryption standard.And if the CR packet is not encrypted then the rest of the communication will also NOT be in encrypted form.If the CR packet is encrypted then the encryption standard is stored by the server as using the same standard the rest of the packets will be decrypted and the reply packets encrypted. >From the raw data of CR packet server will first extract the POP. For CR POP will be 01 (The POPs are described in details in section 9). Seeing it as a CR packet the server will extract username and password and will try to authenticate.If the authentication succeeds it will send back a Connection Granted (CG) reply packet giving the port number to the client (TCP will take care of the port no.).Otherwise it sends an error packet specifying an error code "Authentication Failure". On successful authentication it will set appropriate access control parameters to check "Access Violation" by the Client requests which are to follow. After sending the positive response it (practically the thread spawned by server) will listen to get the requests from the client. On receiving Request packet it will decrypt it and get the opcode first. If the opcode does not conforms with the access control of the client it will send an error packet with errorcode "Access Violation".If Access control is OK then it will get the list of arguments. The arguments will contain the Resource IDs and the values (if appropriate). The server will parse the arguments according to the opcode fetched using a Finite State Machine (FSM). If parsing fails it sends an error packet with an error code "Access Violation".Otherwise, it executes the command and forms and sends Response packet. page 3 Then the server again goes on listening for another request.If client sends a connection termination packet, server sends an acknowledgement (configuration) packet and terminates the connection. Note the server does NOT wait for an acknowledgement from client whether any response to a particular request from client has actually reached to the client.Neither it resends the information.This is also done for security reasons.If no response found from server(which will not be the case normally for TCP) client will resend the request. If still nothing is found then the client will sense something is wrong (may be with security,i.e, some other client is proxying for it) and immediately send the Close Connection Request(CCR) packet. 10. Packet Structures As implemented on TCP/IP stack no fixed or maximum size limit is not imposed on the packets of this protocol. So the packets in this protocol can be of any length. TCP will take care of that. Encryption Standard ID (ESID) values: 00 -> No Encryption 01 -> RSA (say) etc. These values will be specified on mutual understanding of Server and Client Protocol Opcodes (Standard): 00 -> Configuration Packets (only used by administrator clients) 01 -> Connection Request (CR) Packets (send by clients) 02 -> Connection Granted Packets (send by servers) 03 -> Request Packets (send by clients) 04 -> Response Packets (send by server) 05 -> Close Connection Request (CCR) packets (send by both clients and servers) 06 -> Error packets (send by servers) There may be other POPs defined also APART FROM THESE according to the specific needs of the client and server. 2 bytes 2 bytes string 1 byte string 1 byte +---+---+---+---+---+---~----+---+---+--~-----+---+ | ESID | POP | username | 0 | password | 0 | +---+---+---+---+---+---~----+---+---+--~-----+---+ <---------Encrypted(usually)-------------> Here POP = 01 Figure 10-1: Connection Request(CR) packet 2 bytes 2 bytes +------+------+-------+-------+ | POP | access control| +------+------+-------+-------+ <------Encrypted(usually)-----> Here POP = 02 Figure 10-2: Connection Granted(CG) packet Access Control value will typically contain the user type value.Reading which the user should know what access is given to it by the server. Typical User Types/Access Rights : 00 -> Administrator etc. Other access levels should be defined mutually by client and server. page 4 2 bytes 2 bytes 2 bytes RID1 type 2 bytes RID2 type +---+---+---+---+---+---+---+--~--+---+---+----+--+--~--+---+....----+ | POP | OP | RID1 | value | RID2 | value |... | +---+---+---+---+---+---+---+--~--+---+---+----+--+--~--+---+....----+ <------------------Encrypted(usually)--------------------....-------> Here POP = 03 Figure 10-3: Request packet It is evident that all the RID will contain a value. And the value will tottally depend on the type of the operation. Example, Suppose a database Client wants to execute the following command on database server : "Get the names of the employees from the employee database".The packet structure would be something like +---+---+---+---+---+---+---+--~--+---+---+---+ | 03 | GET | TABLE | employee | NAME | +---+---+---+---+---+---+---+--~--+---+---+---+ Here GET is the operation code.TABLE is the RID. "employee" is the value of the RID TABLE. NAME is the RID for the "name" field in the table "employee". Now,suppose a database Client wants to execute the following command on database server : "Get the names of the employees from the employee database where salary is greater than 5000". The packet structure would be something like +--+--+--+--+--+--+--+-~-+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 03 | GET |TABLE|employee | NAME| COND|EQUAL| GT |SALARY|5000| +--+--+--+--+--+--+--+-~-+--+--+--+--+--+--+--+--+--+--+--+--+--+ Here GET is the operation code.TABLE is the RID. "employee" is the value of the RID TABLE. NAME is the RID for the "name" field in the table "employee". COND implies that the next of the packet contains a condition. The rest of the packet structure is clear enough. Actually these issues are very much application dependent and completely depends upon the CIB shared by the client and server. Further comments are requested for standardizing the CIBs specific to particular classes of Clients and Servers depending upon there nature. Server sends the response in Response packet: 2 bytes 2 bytes 2 bytes RID1 type 2 bytes RID2 type +---+---+---+---+---+---+---+--~--+---+---+---+---+--~--+---+....----+ | POP | OP | RID1 | value | RID2 | value |... | +---+---+---+---+---+---+---+--~--+---+---+---+---+--~--+---+....----+ <------------------Encrypted(usually)--------------------....-------> Here POP = 04 Figure 10-4: Response packet If the corresponding request was of "GET" type the server will respond with the values requested in the GET request or a NULL value if the GET is not successful. If the request is of type SET then the corresponding value with RID will be of Boolean type indicating whether the SET was successful or not. 2 bytes +------+------+------+--------- | POP | anything....... +------+------+------+---------- <------Encrypted(usually)------> Here POP = 05 Figure 10-5: Close Connection Request (CCR) packet page 5 If the Client or Server wants to close the connection then it will send this CC packet. After sending this,sender will wait for a Configuration packet to know whether everything is OK. 2 bytes 2 bytes string +------+------+------+------+------+---~---+------+ | POP | Error Code | Error Msg | 0 | +------+------+------+------+------+---~---+------+ <---------------Encrypted(usually)----------------> Here POP = 06 Figure 10-6: Error packet Error Codes (Standard) : 00 -> Unknown Error see Error Msg for detail 01 -> Authentication Failure (may occur at the time ofConnection Request) 02 -> Access Violation (If client request found illegal w.r.t Access Control) 03 -> Illformed Packet ( Server cannot parse the request ) etc. In addition to this application specific error codes can be included. Configuration packets can only be sent to servers by administrator clients. 2 bytes 2 bytes string +-----+-----+-----+-----+-----+--~--+-----+ | POP |Config Code| Config Msg. | +-----+-----+-----+-----+-----+--~--+-----+ <------------Encrypted(usually)-------------> Here POP = 00 Figure 10-7: Configuration packet Config codes (Standard): 00 -> Everything is going fine.Rest of the packet (Config Msg.) is ignored. 01 -> Change Password In this case Config Msg. should contain the following structure string string +----+---~--+----+----+--~--+----+ | username | new password | +----+---~--+----+----+--~--+----+ 02 -> Change Access Control In this case Config Msg. should contain the following structure string 2-bytes +----+---~--+----+----+--~--+----+ | username | access code | +----+---~--+----+----+--~--+----+ access code would be same as described for POP = 02. etc. Along with these other user specific configuration messages along with configuration codes can be defined. 11. Server Architecture Server should contain a Finite State Machine(FSM) that will parse the incoming packets for integrity. page 6 12. References [1] R. Fielding et. al. "Hypertext Transfer Protocol -- HTTP/1.1" RFC 2068, January 1997. [2] J. Postel, J. Reynolds, "File Transfer Protocol (FTP)" RFC 959 October , 1985. [3] K. Sollins , "The TFTP Protocol (Revision 2)" ,RFC 1350, July 1992. 13. Author's Address Anirban Majumder 286,Udyog Vihar Phase-II Gurgaon - 122016 INDIA e-mail: majumderanirban@lycos.com 14. Full Copyright Statement Copyright (C) The Internet Society (2001). 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 implmentation 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." Appendix I Meaning of the Terms Used: SHOULD / WOULD / WILL This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. MAY / CAN This word or the adjective "optional" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. This document expires on 21st July, 2002 page 7