INTERNET-DRAFT This document is an Internet-Draft and is subject to 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.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html ??? Working Group T. Hruska Category: Internet Drafts Shining Light Productions June 2002 *********************** The Unified RFC Protocol *********************** 1. Abstract.........................................................2 2. Introduction.....................................................2 3. The Unified RFC Protocol.........................................2 3.1 Assumptions...................................................2 3.2 Protocol Preservation.........................................3 3.3 Command/Response Sequence.....................................3 3.4 Initial Communication.........................................4 3.5 Server Information............................................5 3.6 Data Transfer.................................................5 3.7 Transfers over SSL/TLS........................................5 3.8 Command Help..................................................6 3.9 Unknown Lengths...............................................6 3.10 Closing Communication........................................7 3.11 Sample Transactions..........................................7 3.12 Coding Tips..................................................8 3.13 Security Considerations......................................9 4. Credits.........................................................10 5. Conclusion......................................................11 Hruska Internet Draft [Page 1] Internet-Draft Unified RFC Protocol June 2002 1. Abstract The goal of this Draft is to define a single protocol that envelops all RFCs of the past, present, and future. This document describes communication across the Unified RFC Protocol, preserving ancient protocols, and a framework for new protocols. 2. Introduction Developers everywhere work with Internet RFCs every single day writing slightly different code to do the exact same thing. Whether the protocol is SMTP or HTTP, each one is exactly the same in nature. However, each protocol is different enough to warrant writing a completely new code base to do something so simple as retrieve and send data. To complicate matters even more, most protocols are stagnant and are unable to be expanded upon due to lack of security and backwards-compatability issues. Also, many protocols have been "hacked" in the sense that, for instance, to transmit an attachment across SMTP requires encoding the file using Base64 (which increases the file size by one-third) or UUEncode and using MIME headers with an SMTP header "hack". Obviously, SMTP is not the only ailing protocol. It quickly becomes apparent that something needs to be done without interfering with the current (ancient) technologies. What follows this section is the first Internet Draft under which any type of transaction can take place. Under the Unified RFC Protocol, mail can be sent, webpages retrieved, files transferred all with one base protocol. Thus, the programmer/developer only has to write one code base and every protocol based on the Unified RFC Protocol is readily supported. 3. The Unified RFC Protocol The goal of this protocol is to unify the separate RFCs into one combined protocol in such a way as to not interfere with the aforementioned ancient technology, but provide a jump point for all clients and servers to move quickly away from the old RFCs into more robust, more secure, more expandable environments. 3.1 Assumptions 1 bit = a zero (0) or a one (1). 1 byte = 8 bits. ASCII is the ONLY communication character set (not EBCDIC or any other character set...this means that the programmer for such systems will have to use a translation table to and from ASCII). RAW is defined as a series of bytes of data. RAW is used for the transmission of data. The end of a line is a in ASCII. Hruska Internet Draft [Page 2] Internet-Draft Unified RFC Protocol June 2002 3.2 Protocol Preservation Obviously, no one likes change. So, to make the move simpler and easier, all formerly defined protocols will be preserved by providing _minimal_ functionality for that protocol. New protocols and changes to old protocols are required to base their documentation on the Unified RFC Protocol. 3.3 Command/Response Sequence When a command is sent, the server will respond to it. The proper form of a client command request is: **** UNIFIED RFC PROTOCOL **** CommandName NumberOfBytesOfAdditionalData Additional Data or Information goes here Where CommandName is the name of a recognized command. NumberOfBytesOfAdditionalData is the number of bytes that will follow the pair. Beyond the third line, RAW data may or may not follow depending on the value in the third line. Note that RAW data may or may not be "chunked" (see section G on unknown lengths and large amounts of data). Once a command is issued, the server will respond in this fashion on an 'OK' response: **** UNIFIED RFC PROTOCOL SomethingUsuallyHere **** OK CommandName command valid. Some string goes here NumberOfBytesOfAdditionalData Additional Data or Information goes here However, if the server determines that there is an error either in the command or in general, it will reply in this fashion: **** UNIFIED RFC PROTOCOL ERROR **** ERR CommandName command invalid. Some string goes here NumberOfBytesOfAdditionalData Additional Data or Information goes here The only thing required to be standard are the 's and 'OK'/'ERR' responses. So, an okay response could just be (depends on the situation): **** UNIFIED RFC PROTOCOL **** OK 0 Therefore, the only reliable things for a response from the server are three lines of data. The first line consists of the declared base protocol (should always be a case-insensitive "UNIFIED RFC PROTOCOL"). The second line consists of either an 'OK' or an 'ERR'. The third line consists of the number of bytes of additional information (RAW data) beyond that line that can be read by the client. Hruska Internet Draft [Page 3] Internet-Draft Unified RFC Protocol June 2002 3.4 Initial Communication The first question any programmer will ask is how to handle the issue of sending and receiving the initial data. This is a difficult issue to deal with because the default protocol (if any) is being overridden. So, the following steps are to be taken to determine if the server supports the Unified RFC Protocol or not: 1) The client sends the server a communication request: **** UNIFIED RFC PROTOCOL **** Start 0 2) The client then waits for a response from the server. The proper server response to this request is: **** UNIFIED RFC PROTOCOL READY **** OK Start command valid. Welcome message follows. 74 Welcome to the local web server! We hope that you will enjoy your stay! 3) If the client/server times out or returns an improper response, the server does not support the Unified RFC Protocol. At that point, the client should revert to ancient methods of communication. 4) Assuming the communication succeeded, the client needs information on how to communicate with the server. So, the client must send: **** UNIFIED RFC PROTOCOL **** RetrieveCommands 0 5) The server then replies with a list of allowed commands at this point: **** UNIFIED RFC PROTOCOL COMMANDS **** OK RetrieveCommands command valid. Data follows. 7 Login 6) If a client does not understand any of the commands, it may not communicate with the server. Hruska Internet Draft [Page 4] Internet-Draft Unified RFC Protocol June 2002 3.5 Server Information Obviously, it can be useful to obtain information about a server. Particularly, timeouts, the primary server name, the server IP address, etc. To obtain this information (for display only...not to be used for any authentication purposes), the client must send: **** UNIFIED RFC PROTOCOL **** GetServerInfo 0 The server must respond with proper information in the fields: **** UNIFIED RFC PROTOCOL SERVER INFORMATION **** OK GetServerInfo command valid. Information follows. 209 Server Name: MyWebServ Server Address: www.mywebsite.com Server IP: 185.23.4.10 Server Type: HTTP under the Unified RFC Protocol Server Port: 80 Max Header: 255 Max Command: 255 Max Data: 4096 3.6 Data Transfer Raw data may be transferred over the connection using the additional data section. If the server or client determines that too much data is being sent (usually through some sort of configuration mechanism), either side may drop the connection. 3.7 Transfers over SSL/TLS In today's world there needs to be security. However, SSL/TLS only allows for IP-based virtual hosting (e.g. HTTP/1.1). So, to overcome this issue, the Unified RFC Protocol declares itself to be superior to SSL/TLS and therefore SSL/TLS must run _UNDER_ the Unified RFC Protocol. Based on this, the following command is added to tell SSL/TLS or other server/protocol which certificate chain/virtual host to use: **** UNIFIED RFC PROTOCOL **** SetServerInfo 41 Host: www.myvirtualhost.com Port: 80 If the command is valid, the server must reply: **** UNIFIED RFC PROTOCOL SET SERVER **** OK SetServerInfo command valid. Server information set. 0 The SSL/TLS protocol will then use the certificate chain for 'www.myvirtualhost.com' for that communication. This stops man-in-the-middle attacks since changing the host will change the certificates returned, which can be verified using standard host matching from the certificate. Hruska Internet Draft [Page 5] Internet-Draft Unified RFC Protocol June 2002 3.8 Command Help All servers implementing the Unified RFC Protocol are required to provide detailed instructions on each command when the HELP command is sent by the client: **** UNIFIED RFC PROTOCOL **** HELP Login 0 The server replies: **** UNIFIED RFC PROTOCOL COMMAND HELP **** OK HELP Login command valid. Details on this command follow. 162 The 'Login' command is used to gain access to restricted resources. If you are logging in from a console, you will be stepped through the process by the server. 3.9 Unknown Lengths The server may not always know the length of the data that it is returning. This is particularly true for large data sets. To help ease this problem, the server is allowed to transfer the data to the client in pieces. The header is required as usual, but the raw data can be tranferred in pieces. This piecemeal transaction method could occur as early as the initial handshake: **** UNIFIED RFC PROTOCOL **** Start 0 The server replies: **** UNIFIED RFC PROTOCOL READY **** OK Start command valid. Welcome message follows. =34 Welcome to the local web server! =4 We h 36 ope that you will enjoy your stay! The client may also send data of unknown length to the server in the same fashion: **** UNIFIED RFC PROTOCOL **** SetServerInfo =32 Host: www.shininglightpro.com 11 Port: 80 The server replies: **** UNIFIED RFC PROTOCOL SET SERVER **** OK SetServerInfo command valid. Server information set. 0 Hruska Internet Draft [Page 6] Internet-Draft Unified RFC Protocol June 2002 3.10 Closing Communication When all communications with the server are finished, the client sends: **** UNIFIED RFC PROTOCOL **** Quit 0 The server replies: **** UNIFIED RFC PROTOCOL EXITING **** OK Quit command valid. Exiting. 10 Goodbye! Both ends drop the connection and communication is finished. 3.11 Sample Transactions The following is a sample transaction with a HTTP server under the Unified RFC Protocol (NOTE: Until the HTTP protocol is re-designed to work under the Unified RFC Protocol, this is to be used only as an example and not as an actual communication): Client: **** UNIFIED RFC PROTOCOL **** Start 0 Server: **** UNIFIED RFC PROTOCOL READY **** OK Start command valid. Welcome message follows. 74 Welcome to the local web server! We hope that you will enjoy your stay! Client: **** UNIFIED RFC PROTOCOL **** RetrieveCommands 0 Server: **** UNIFIED RFC PROTOCOL COMMANDS **** OK RetrieveCommands command valid. Data follows. 19 Login GetWebPage Client: **** UNIFIED RFC PROTOCOL **** SetServerInfo 43 Host: www.shininglightpro.com Port: 80 Server: **** UNIFIED RFC PROTOCOL SET SERVER **** OK SetServerInfo command valid. Server information set. 0 Hruska Internet Draft [Page 7] Internet-Draft Unified RFC Protocol June 2002 Client: **** UNIFIED RFC PROTOCOL **** GetWebPage 29 / 19 Connection: close 0 Server: **** UNIFIED RFC PROTOCOL HTTP WEBPAGE **** OK GetWebPage command valid. Webpage follows. 1746 ... Client: **** UNIFIED RFC PROTOCOL **** Quit 0 Server: **** UNIFIED RFC PROTOCOL EXITING **** OK Quit command valid. Exiting. 10 Goodbye! 3.12 Coding Tips Writing a client/server pair for the Unified RFC Protocol is simple. Using the C/C++ language and BSD-style sockets, a single set of functions can be written that both the client and server can use. Shining Light Productions has a fully functional set of functions (500 lines of C code) that perform the necessary communications across the Unified RFC Protocol. The function names and what each one does is listed below (from Shining Light Productions' closed source, proprietary library LibLink): InitUnifiedRFC - Performs initialization of a generic socket structure for use with the other Unified RFC Protocol functions. Returns 1 if allocation and initialization was successful, 0 on error. CloseUnifiedRFC - Cleans up Unified RFC Protocol specific items from the generic socket structure in preparation for another connection or shutdown. Returns 1 if successful, 0 on error. SetUnifiedRFCServer - Sets the server and port to connect to. Returns 1 if successful, 0 on error. OpenUnifiedRFCConnection - This is a client-specific function that opens the connection to a server and performs the initial handshake. Returns 1 if the connection and handshake were successful, 0 if either one failed. CloseUnifiedRFCConnection - This is a client-specific function that sends the closing communication message, retrieves the response, and closes the connection. Returns 1 if successful, 0 on error. Hruska Internet Draft [Page 8] Internet-Draft Unified RFC Protocol June 2002 GetUnifiedRFCResponse - This function can be used both by clients and servers when getting data across the Unified RFC Protocol. Six different "Modes" (or "States") are used by this function to determine what to do next: 1) Header ("**** UNIFIED RFC PROTOCOL ****") 2) Command/Response 3) Size of Additional Data 4) Additional Data (Unknown Length data) 5) Final Data 6) Communication Completed This function reads in data each time and processes as much of it as it can. Whenever the function returns and Additional Data exists, the Additional Data should be stored/processed as it will be destroyed on the next function call. This function returns 1 on success, 0 on error or if the server/client disconnected. SendUnifiedRFCCommand SendUnifiedRFCData SendUnifiedRFCCommandData The three functions above can be used by both the client and server for sending commands/responses. The first two are designed to send data of unknown length in small pieces. The last function sends data in one complete package all at once. All of them return 1 on success, 0 on error. 3.13 Security Considerations Obviously, no protocol exists without its own security implications. The major thing to remember is that any implementation of the Unified RFC Protocol may disconnect (either server or client) at any point that either deems the other to be invalid or not following the protocol correctly. The first security consideration any developer must take into account is illegal requests from clients. Particularly buffer underflows and overflows. For example, the following request is to be considered malicious: **** UNIFIED RFC PROTOCOL **** Login -1 Hruska Internet Draft [Page 9] Internet-Draft Unified RFC Protocol June 2002 All servers can either respond with an 'ERR' response or disconnect from the client. A disconnect is probably preferred when a request has harmful intent such as the aforementioned buffer underflow. A buffer overflow request such as: **** UNIFIED RFC PROTOCOL **** Login 50000000000000000000000000000000000 Should also be considered malicious and appropriate action taken. Also, overflows can occur in the first two lines of a request: **** UNIFIED RFC PROTOCOL adsfasdfasfdasdf...adsfasdfasdfasdf **** MySuperDuperUltraLongCommandWouldProbablyGoHereAndCrashTheServerOrBring ItToItsKnees... 123 As with every protocol, timeouts on both servers and clients should be implemented for every connection to avoid consuming resources for an extended amount of time. For instance, if the previous request did not send 123 bytes of data, the connection should close after a while. Finally, buffers should be limited to a certain maximum size set by the server. These sizes can be determined by the client via the GetServerInfo command. If the maximum size is exceeded by the client, the server should drop the connection. 4. Credits Name E-mail Address ----------------------------------------------------------------------- Thomas J. Hruska shinelight(_at_)shininglightpro(_dot_)com Hruska Internet Draft [Page 10] Internet-Draft Unified RFC Protocol June 2002 5. Conclusion This document is being submitted to both the IETF as an Internet Draft and placed on the Shining Light Productions website under the Shining Light Productions Open Documentation Agreement with full modification and distribution rights given to the IETF. Shining Light Productions hopes that this document will spur on an Internet RFC to quickly form and eliminate ancient protocols with more secure, robust, and easy to use protocols with a standard set of library functions. Legal Note: This document is subject to the Shining Light Productions Open Documentation Agreement ("SLPODA"). Shining Light Productions is the claimant and holder of Copyright of this document. Shining Light Productions grants the Internet Engineering Task Force ("IETF") unrestrictive rights to use, modify, distribute, and create derivative works of this document. Signed, Thomas J. Hruska shinelight(_at_)shininglightpro(_dot_)com Shining Light Productions "Meeting the Needs of Fellow Programmers" (C) 2002 Shining Light Productions Hruska Internet Draft [Page 11]