Remote Host Configuration Protocol: Configuring a Remote Host in a User-Friendly Manner

Дата канвертавання25.04.2016
Памер31.34 Kb.
Remote Host Configuration Protocol:

Configuring a Remote Host in a User-Friendly Manner
Jenq-Haur Wang, Tzao-Lin Lee, Hsi-Hui Lin

Department of Computer Science and Information Engineering,

National Taiwan University,
Taipei, Taiwan, R.O.C.

E-mail: {f3506002, tl_lee, r5526069}

Feb. 18, 1998


Linux (or UNIX-like) system administration is mostly done in text-mode with some text-editing of system configuration files. It requires much experience and familiarity of the whole system to configure a Linux host as an Internet server. This paper describes a user-friendly way of configuring and managing remote hosts by incorporating the most-popular HTML (HyperText Markup Language) [1, 2, 3, 4] as the user interface. In addition to acquiring system-specific and server-dependent parameters on a remote host, one can easily modify these parameters without worrying about the location and the format of configuration files. The validity of parameters is automatically verified before real modifications are carried out. With a simple click, one can confirm and invoke these modifications. Important messages are logged into a file and passed back to the administrator in case one may want to monitor the situations on the remote host. Since system administration becomes so easy and convenient, a good security policy is critical. In this paper, we’ll also propose an authentication scheme to avoid unauthorized access to important system configurations.


In the fast-changing world of Internet, a powerful user-friendly client attracts the attention of most of the users since most people use the client to browse the Internet for the information they need. However, information service providers are more important because they provide the information. Therefore, Internet servers are getting more and more attention these days. Since the nature of servers is to serve as many clients as possible, stably and fast enough, the platform on which servers are run is therefore quite important. In current market, Windows 95 or NT seems to be the greatest winner since it suits most users' needs. However, in the case of servers, Windows may not gain as much popularity. For example, in the fast-growing market of Web servers, UNIX-based ones still dominate. Although other platforms, like Windows NT, are more widely configured as Internet servers, the configuration and the management of the Windows NT servers are usually done via the PDC (Primary Domain Controller) which talks to other NT servers with multiprotocols (TCP/IP, NetBEUI, and IPX). This multiprotocol environment will naturally consume more valuable network bandwidth than pure TCP/IP environment.

In the case of UNIX, the mainstream platform for servers in campus especially, TCP/IP, the mother tongue of the Internet, is built in the kernel from the very beginning. Since there are many dialects of UNIX, each one of them may differ quite a lot. Linux, among others, is continuously updated and enhanced by Linus Torvalds and many other hackers and developers around the world. Also, it’s freely available, and easy to install. With its source code availability and extensibility, it’s very suitable for system developers to delve into the kernel and to enhance the kernel whenever needed.

Linux has some disadvantages, of course. For example, system configurations are stored as text files under various system directories, e.g. /etc. System administrator must be very familiar with each and every directory and configuration file. Also, he needs to have good command of at least one text-editor before he can configure the host at will. He might also need real experience with program development tools to keep everything working. Although Linux is equipped with a GUI (Graphical User Interface): X Window System, the configuration in X Window itself is much more difficult than the other configurations, which requires detailed knowledge of your VGA card and monitor.

In the daily life of system administrators, the management and configuration of Internet servers is a major job and its difficulty usually depends on the complexity of the interconnection network and the platform of the servers. Although network related configurations on a host may be simplified by installing DHCP (Dynamic Host Configuration Protocol) [5, 6, 7] distributions, e.g. DHCP Client Daemons and the like, the difficulty in configuring all sorts of servers in a whole LAN (Local Area Network) may remain the same, and even harder. The administrator must distinguish between the hosts that are assigned IP addresses and get configuration parameters via DHCP, and those that don’t. The conflict between fixed and allocated parameters must be resolved. This is usually quite difficult.

With the introduction of our proposed Remote Host Configuration Protocol (RHCP) instead of using Telnet [8, 9, 10, 11], one can configure and manage a remote host with more security and ease. The security comes from the use of an authentication scheme which will be described later. The easy part derives from the friendly user interface and the verification process.

Configuration Process Made Simple: The User Interface

Therefore, we want to leverage the burden of system administrators by utilizing a now-popular user-interface to configure and manage all kinds of parameters on an Internet host.

From users’ point of view, you can use your favorite web browser that supports HTML forms [1,2,3,4] and CGI (Common Gateway Interface) [12, 13] as a Configuration Client (Client, for short). When you connect to the Configuration Server (Server, for short), you will see an Authentication Homepage first (Fig. 1).

Fig. 1 The Authentication Homepage

To start the configuration process, you must somehow get an authentication key which is generated by the Configuration Daemon (Daemon, for short) on the host to be configured (Host, for short). When you input that key to authenticate your identity and click the ‘OK’ Button, the Server verifies and decodes that key. The Host is determined, and the parameters are obtained from the Host and are shown (Fig. 2).

Fig. 2 System Parameter Configuration Page

In Fig. 2, the parameters may be divided into two parts: system-related and server-dependent parameters. For system-related parameters, you can see hostname, IP address, subnet mask, gateway, DNS server, …etc. For server-dependent parameters, you can see which servers are running, and the configuration of each one of them. The server-dependent parameters may be quite different for each server. Typical settings may include port numbers, server type (standalone or inetd super server), and maximum number of clients…etc. For example, the parameters for HTTPD Server is shown as follows (Fig. 3):

Fig. 3 Server-specific parameter configuration

With the help of control elements in HTML forms, you can then modify the values of the parameters easily. After all those modifications, you can send out the parameters to the Server with another click. Once the values of the parameters are verified by the CGI program on the Server, you are required to confirm that modification by a final click (Fig. 4).

Fig. 4 Parameter Modification Confirm Page
And the Server will actually request the Host to invoke parameter modifications. All results in the process of parameter modifications will be passed back to the Client and shown in the browser. The procedure is illustrated as the following: (Fig. 5)

Fig. 5 Relationship among the key components in the Remote Host Configuration Environment

Relationship among the Components

In Fig. 5, we can easily see the three key components in our Remote Host Configuration Environment: the web browser (as the Configuration Client), the web server together with a CGI program (as the Configuration Server), and the host to be configured (with the Configuration Daemon).

In this environment, the Client actively sends requests to the Server. These requests are verified by the Server and get delivered to the Daemon on the Host. All replies and results on the Daemon are returned to the Server, which then passed them back to the Client. In other words, The Server is acting as the gateway to the Configuration Daemon.

The network transport between the Client and the Server is the usual HTTP [14] above UDP (User Datagram Protocol) [9, 10, 11, 15], while the transport between the Server and the Daemon is called RHCP (Remote Host Configuration Protocol, to be defined later on) above UDP. Since HTTP is only used to deliver Client requests to the Server, we’ll focus on the protocol between the Server and the Daemon: RHCP.

Remote Host Configuration Protocol (RHCP): The Protocol

In fact, it is the CGI program on the Server that communicates with the Daemon. So it plays an important role in the configuration process. It acts as the agent for the Client and more importantly, it is the gatekeeper to make sure that every parameter is valid. It is responsible for three kinds of Client requests: request for getting parameters, setting parameters, and confirmation of parameter modifications (Fig. 6).

Fig. 6 Shows the interaction among the Client, the CGI program, and the Daemon. The message exchanges among them are also depicted in the diagram.
In the first case, when the Client requests for getting parameters, the CGI program first decodes and checks the authentication key to find out the identity of the Client and the Host to be configured. If the authentication succeeds, the CGI program then sends an RHCP_GET request to the Daemon (on that Host). When the Daemon replies an RHCP_ACK message with parameters attached, the CGI program passes the parameters back to the Client. Unauthenticated Client will receive an RHCP_NAK message from the Daemon.

In the second case, when the Client asks for setting parameters, the CGI program must again decode and check the authentication key. If it succeeds, the CGI program verifies if those parameters are valid. If so, the CGI program writes them to a Configuration File on the Server, and asks the user for final confirmation. If parameters are invalid, the CGI program will show an error or warning message depending on how serious the parameters go wrong. It will either ask the user to modify parameters or let the user enforce these modifications. The client requests here are not really sent to the Daemon until the user confirms them.

In the last case, when the user confirms this modification, the CGI program will again pass the authentication key along with the settings in the Configuration File to the Daemon through an RHCP_SET request. Unauthenticated modifications are not allowed, and will get an RHCP_NAK response from the Daemon. When the Daemon is modifying the parameters, the output message produced is sent back to the CGI program simultaneously in RHCP_ACK messages. The CGI program not only logs these messages, but also passes them back to the Client if the user wants them. After parameter modifications are completed, the Daemon sends an RHCP_FINAL message to the CGI program. If the Daemon still finds the modifications invalid, it will respond by an RHCP_NAK message, and no real change to the parameters will take place.

The Configuration Daemon

As for the Daemon, it is the real program that enforces parameter reading and modification. Since it has direct access to the configurations on the Host, a very secure authentication scheme must be enforced. As the Daemon first starts up, it generates an authentication key that is used to identify the host it’s on and also authorizes the administrator to access its configurations. Then it steps into ‘daemon’ mode to listen to RHCP requests.

As you can see in Fig. 6, there are only two kinds of requests for the Daemon: RHCP_GET and RHCP_SET. In response to RHCP_GET requests, the Daemon checks for the authentication key. Unauthenticated access will get RHCP_NAK replies. If the authentication succeeds, the Daemon will invoke parameter reading, and will pass them back in RHCP_ACK messages.

For RHCP_SET requests, in addition to the authentication key, the Daemon also checks for parameter validity. Unauthenticated access and invalid parameters will both get RHCP_NAK messages. If the authentication succeeds and the parameters are valid, the Daemon then invokes real parameter modification and replies with RHCP_ACK messages and an RHCP_FINAL message for the final parameter change. All diagnostic information will be logged on the Daemon, and will also be passed back to the CGI program. Any change in the Host is also logged.

The Message Format

There are five kinds of messages in RHCP: RHCP_GET, RHCP_SET, RHCP_ACK, RHCP_NAK, and RHCP_FINAL. The format of RHCP messages is as follows (Fig. 7):

0 7 8 15 16 31

Op (1)

Reserved (1)

Flags (2)

Timestamp (4)

Hardware Address: Upper Half (4)

Hardware Address: Lower Half (2)

Access times (2)

Magic Cookie for RHCP (4)

Options (n)

Fig. 7 The Format of RHCP Messages
In Fig. 7, the number in the parenthesis is the number of bytes that field occupies. ‘Op’ is a 1-byte field denoting the type of the operation in the message. Valid values are the five message types. ‘Flags’ field is used for additional control on the message. The authentication key is the key part concerning the security policy of this protocol. It consists of ‘Timestamp’, ‘Hardware Address’, and number of ‘Access Times’. Although we present the authentication key as three separate fields, in real implementation, we may encrypt these fields into a single 12-byte field. ‘Magic Cookie’ field is used to identify RHCP messages. When RHCP messages are carrying parameters, they are stored in the variable-length ‘Options’ field.

Differences and Interoperations between RHCP and DHCP

From the name of RHCP, one can easily think of another protocol about configuration parameters: DHCP (Dynamic Host Configuration Protocol) [5, 6, 7]. In DHCP, the client plays an active role. It requests parameters from DHCP servers for configuring itself. While in RHCP, the Server passively waits for RHCP Client requests. It does not request parameters for itself. It accesses the Daemon’s parameters, and configures the host where the Daemon is run (Fig. 8).

Fig. 8 Differences between the role of DHCP and RHCP in host configuration. The circles in dashed line are the hosts to be configured.
Since DHCP servers and clients are getting more and more common, we need to take into considerations the interoperations between RHCP and DHCP (Fig. 9).

Fig. 9 Shows the interoperation between RHCP and DHCP
Since we can configure a normal host with fixed IP address, can we configure a host that happens to be a DHCP client? There may be two solutions for this. For the first one, if the RHCP Daemon finds the Host to be a DHCP client, it can prohibit users from modifying the network-related parameters, e.g. IP address, netmask, gateway, …etc. Only server-dependent parameters are allowed to modify. For the other one, the RHCP Daemon can also allow the users to enforce those modifications anyway. However, in this case, it will force the DHCP client to release its lease with DHCP servers, and the client will no longer be a DHCP client. The DHCP-related configuration will be disabled, and the host will use the new fixed IP address instead. Care must be taken since it may also cause unwanted misconfiguration.

In fact, an RHCP server can also be a DHCP server, but that seems to add not much convenience to the management of RHCP, and it may slow down the performance of pure RHCP servers. The only convenience may be that: it’s able to take over the management of the DHCP leases in the DHCP client case mentioned above.


To complicate things further, what if we want to configure a special host like a gateway, a router, or a firewall? In these situations, special parameter settings should be available, for example, settings for two Network Interface Cards. In RHCP, this is possible since the message format is versatile enough to handle all kinds of parameter settings.

In previous paragraphs, our statement of RHCP is focused on Linux system administration. However, in a typical LAN environment, with all sorts of platforms, RHCP can still configure the whole LAN. The only thing we need to do is to write different Configuration Daemon for each platform. The other two components in RHCP, the Configuration Client and Server, remain unchanged.

Since the parameter modification is as simple as browsing the web, authentication is very critical. Unauthenticated access to Configuration Daemon is absolutely forbidden and will get RHCP_NAK messages.

Since the advent of DHCP, the Internet is getting more difficult to manage. Some hosts are configured as DHCP clients, while others remain using fixed network addresses. If we take this into consideration, RHCP may also need to cooperate with DHCP.

If you browse through the documents about DHCP, you may wonder why we need another protocol. We could have utilized the same DHCP protocol, and added more message types and more DHCP options [6] for our needs. The reason is if we did so, we could have made the situation even worse. We may need to modify existing DHCP servers to avoid redundant DHCP messages.

In this paper, we suggest an HTML forms-CGI-based user interface for configuration control. However, this is not required. As long as we have a Configuration Client that is capable of all the work we have mentioned for the CGI program: to send RHCP_GET and RHCP_SET requests, to verify the validity of parameters, and to authenticate the keys, the results will be the same (Fig. 10).

Fig. 10 Shows the relationship between Configuration Components when HTML forms and CGI programs are not employed.


In this paper, we suggest a user-friendly way of managing and configuring Internet servers. However, the user interface provided by HTML and CGI programs is not the most important thing. The point is that we can manage, configure, and even control a lot of Internet servers in the whole LAN in a uniform way. You don’t have to stay on the console, and you don’t have to know too much tedious details of not-so-important things. The most important is that the configuration process is automatically carried out and the changes of configurations are carefully verified and well monitored.

With the help of RHCP, system administrators can easily and conveniently configure a remote host as well as a local host, as long as the network is working. He can also monitor and even control the whole LAN with a normal browser on any platform.


  1. Dave Raggett, Arnaud Le Hors, and Ian Jacobs, “HTML 4.0 Specification”, 18 December 1997.

  2. Dave Raggett, “HTML 3.2 Reference Specification”, 14 January 1997.

  3. Dave Raggett, “HyperText Markup Language Specification Version 3.0”, September 1995.

  4. T. Berners-Lee and D. Connolly, “HyperText Markup Language 2.0”, RFC 1866, November 1995.

  5. R. Droms, “Dynamic Host Configuration Protocol”, RFC 2131, March 1997.

  6. S. Alexander and R. Droms, “DHCP Options and BOOTP Vendor Extensions”, RFC 2132, March 1997.

  7. R. Droms, “Interoperation between DHCP and BOOTP”, RFC 1534, October 1993.

  8. J. B. Postel, J.K. Reynolds, “Telnet Protocol specification”, RFC 854, May 1983.

  9. Douglas E. Comer, Internetworking with TCP/IP, Vol. I: Principles, Protocols, and Architectures, Second Edition, Prentice-Hall, Inc., 1991.

  10. Douglas E. Comer, and David L. Stevens, Internetworking with TCP/IP, Vol. III: Client-Server Programming and Applications, BSD Socket Version, Prentice-Hall, Inc., 1993.

  11. W. Richard Stevens, TCP/IP Illustrated, Vol. I: The protocols, Addison-Wesley Publishing Company, 1994.

  12. NCSA, “The Common Gateway Interface (CGI) Specification 1.1”, Internet article at

  13. Shishir Gundavaram, CGI programming on the World Wide Web, O’Reilly & Associates, Inc., 1996.

  14. R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners-Lee, "HTTP Version 1.1 ", RFC 2068, January 1997.

  15. J. B. Postel, “User Datagram Protocol”, RFC 768, August 1980.

База данных защищена авторским правом © 2016
звярнуцца да адміністрацыі

    Галоўная старонка