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