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}@csie.ntu.edu.tw
Feb. 18, 1998
Abstract
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.
Introduction
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.
1
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).
2
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).
3
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):
4
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).
5
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)
Configuration
Server
HTTP
CGI
program
(Web Server)
Configuration
Client
RHCP/UDP
(Web Browser)
Host to be
configured
Configuration
Daemon
Fig. 5 Relationship among the key components in the Remote Host Configuration Environment
6
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).
Client
CGI
get
Daemon
RHCP_GET
RHCP_ACK
set
confirm
Authenticate
& verify
RHCP_SET
RHCP_ACK, RHCP_FINAL
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
7
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):
8
0
7 8
Op (1)
15 16
Reserved (1)
31
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).
DHCP
Client
Request parameters
for the Client
Offer parameters
DHCP
Server
Access parameters
on the Daemon
RHCP
Server
RHCP
Daemon
Action Complete
Fig. 8 Differences between the role of DHCP and RHCP in host configuration. The circles in dashed line are the
hosts to be configured.
9
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).
RHCP
Client
RHCP
Server
Router,
gateway,
firewall
DHCP
Client
Normal RHCP
Daemon (Fixed IP)
DHCP
Server
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.
Discussion
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
10
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).
RHCP request
Configuration
Client
Configuration
Daemon
RHCP reply
Fig. 10 Shows the relationship between Configuration Components when HTML forms and CGI programs are not
employed.
Conclusion
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.
Reference
[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.
11
[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
http://hoohoo.ncsa.uiuc.edu/cgi/.
[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.
12