Remote Host Configuration Protocol:
Configuring a Remote Host in
Lin Lee, Hsi
Department of Computer Science and Information Engineering
Taipei, Taiwan, R
6002, tl_lee, email@example.com
Feb. 18, 1998
Linux (or U
like) system administration is mostly done in text
mode with some text
edit ing of system
configuration files. It requires much
experience and familiarity of the whole system t
o configure a
Linux host as an
describes a user
friendly way of configuring and managing remote hosts b
popular HTML (HyperText Markup Language)
[1, 2, 3, 4]
as the user interface. In addition to acquirin
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
before real modificat
ions are carried out.
With a simple click, one can confirm and invoke these
Important messages are logged into a file and passed back to the
r in case
situations on the remote host.
Since system admini
stration 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
attracts the attention of most of the
users since most people use the
client to browse the Internet for the information they need. However,
service providers are more important because they provide
the informat ion
. 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
, 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
, Windows may
. For example, in the
growing market of Web servers, U
based ones still
other platforms, like Windows NT, are more widely configured as Internet servers, the
the management of the Windows NT servers are usually done via the PDC (Primary Domain
Controller) which talks to other NT servers with multiprotocols (T
CP/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 In
ternet, 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.
. System administrator must be very familiar with each and every directory and
configuration file. Also, he needs to have good command of at lea
st 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
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
Configurat ion Protocol) [5, 6, 7] distributio
ns, 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
With the introduction of our proposed Remote Host Configuration Protocol (RHCP) instead of u
[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 ve
Configuration Process Made Simple: The User Interface
Therefore, we want to leverage the burden of system administrators by utilizing a now
to configure and manage all kinds of parameters on an Internet host.
m 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), yo
u will see an Authentication Homepage first (Fig. 1).
The Authentication Homepage
To start the configuration process, you must somehow get an authentication key which is generated by the
Configurat ion 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).
System Parameter Configuration Page
In Fig. 2, the parameters may be divided into two parts: system
related and server
dependent parameters. For
related parameters, you can see hostname, IP address, subnet mask, gateway, DNS server, …etc. For
dependent parameters, you can see which servers are running, and the configuration of each one of them. The
dependent parameters may be quite different for each server. Typical settings may include port numbers,
server type (standalone or
super server), and maximum number of clients…etc. For example, the parameters
for HTTPD Server is shown as follows (Fig. 3):
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
final click (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)
Relationship among the key components in the Remote Host Configuration Environment
Host to be
Relationship among the Components
In Fig. 5, we can easily see the three key comp
onents 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 environmen
t, 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 othe
r words, The Server is act ing as the gateway to the Configuration
The network t ransport between the Client and the Server is the usual HTTP  above UDP (User Datagram
Protocol) [9, 10, 11, 15], while the transport between the Server and the Daem
on is called RHCP (Remote Host
Configurat ion 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 Prot
ocol (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
e 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).
Shows the interaction among the Client, t
he 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 para
meters 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 c
onfirms this modificat ion, 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
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
The Configuration Daemon
As for the Daemon, it is the real program that enforces parameter reading and modificat ion. Since it has
direct access to the configurations on the Host, a very secure authentication scheme must be enforced. As the
n 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 t wo 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
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 Daem
on, and will also be passed back to the CGI program. Any change in the Host is also
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 (F
Hardware Address: Upper Half (4)
Hardware Address: Lower Half
Access times (2)
Magic Cookie for RHCP (4)
The Format of RHCP Messages
ig. 7, the number in the parenthesis is the number of bytes that field occupies. ‘Op’ is a 1
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 implementati
on, we may encrypt these fields into a single 12
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 betwee
n 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 con
figuring 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).
een the role of DHCP and RHCP in host configuration. The circles in dashed line are the
hosts to be configured.
for the Client
on the Daemon
Since DHCP servers and clients are getting more and more common, we need to take into considerations the
interoperations between RHCP and DHCP
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 th
e 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
lso 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
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 specia
l 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
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.
thenticated 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
Daemon (Fixed IP)
DHCP clients, while others remain using fixed netwo
rk 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  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
based user int
erface 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,
authenticate the keys, the results will be the same (Fig. 10).
Shows the relationship between Configuration Components when HTML forms and CGI programs are not
In this paper, we suggest a user
friendly way of man
aging 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
important things. The most
important is that the configuration process is automatically carried out and the changes of configurations are
ed 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
Dave Raggett, Arnaud Le Hors,
HTML 4.0 Specification
18 December 1997.
HTML 3.2 Reference Specification
, 14 January 1997.
HyperText Markup Language Specification Version 3.0
Lee and D. Connolly,
HyperText Markup Language 2.0
R. Droms, “Dynamic Host Configuration Protocol”, RFC 2131, March 1997.
S. Alexander and R. Droms, “DHCP Options and BOOTP Vendor Extensions”, RFC 2132, Mar
R. Droms, “Interoperation between DHCP and BOOTP”, RFC 1534, October 1993.
J. B. Postel, J.K. Reynolds, “Telnet Protocol specification”, RFC 854, May 1983.
Douglas E. Comer,
Internetworking with TCP/IP, Vol. I: Principles, Protocols, and Architect
Hall, Inc., 1991.
Douglas E. Comer, and David L. Stevens,
Internetworking with TCP/IP, Vol. III: Client
and Applications, BSD Socket Version
Hall, Inc., 1993.
W. Richard Stevens,
d, Vol. I: The protocols
Wesley Publishing Company, 1994.
NCSA, “The Common Gateway Interface (CGI) Specification 1.1”, Internet article at
rogramming on the World Wide Web
, O’Reilly & Associates, Inc., 1996.
R. Fielding, J. Gettys, J. Mogul, H. Frystyk Nielsen, and T. Berners
Lee, "HTTP Version 1.1 ",
J. B. Postel, “User Datagram Protocol”, RFC 768, August 1980.