Remote Host Configuration Protocol:

gayheadavonNetworking and Communications

Oct 27, 2013 (3 years and 5 months ago)

58 views


1

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
,

Nation
al

Taiwan University
,

Taipei, Taiwan, R
.
O
.
C
.

E
-
mail: {f350
6002, tl_lee, r5526069}@csie.ntu.edu.tw

Feb. 18, 1998


Abstract


Linux (or U
NIX
-
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
Internet server.

This paper

describes a user
-
friendly way of configuring and managing remote hosts b
y incorporating
the most
-
popular HTML (HyperText Markup Language)

[1, 2, 3, 4]

as the user interface. In addition to acquirin
g
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

automat ically
verified

before real modificat
ions 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
administrato
r in case
one

may
want
to
monitor
the
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.


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 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
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, U
NIX
-
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 (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.


2

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 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
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
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
difficult.

With the introduction of our proposed Remote Host Configuration Protocol (RHCP) instead of u
sing 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 ve
rification 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.

Fro
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).


3


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).



4


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
s
erver
-
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
inet
d

super server), and maximum number of clients…etc. For example, the parameters
for HTTPD Server is shown as follows (Fig. 3):







5


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).


6


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

Configuration
Client

(Web Browser)


Configuration
Server

(Web Server)

Host to be
configured

CGI
program

Configuration
Daemon


HTTP

RHCP/UDP


7


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
Daemon.

The network t ransport 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 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
sur
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).














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
Client

CGI

Daemon

get

set

confirm

RHCP_GET

RHCP_ACK

RHCP_SET

RHCP_ACK, RHCP_F
INAL

Authenticate
& verify


8

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
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 modificat ion. Since it has
direct access to the configurations on the Host, a very secure authentication scheme must be enforced. As the
Daemo
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
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 Daem
on, 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 (F
ig. 7):




9



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 F
ig. 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 implementati
on, 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 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).










Fig. 8

Differences betw
een the role of DHCP and RHCP in host configuration. The circles in dashed line are the
hosts to be configured.

DHCP
Client

DHCP
Server

Request parameters
for the Client

Offer parameters

RHCP
Server

RHCP
Daemon

Access parameters
on the Daemon

Action Complete


10


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 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
a
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
-
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 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

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.
Unau
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
RHCP
Client

RHCP
Server

Normal RHCP
Daemon (Fixed IP)

DHCP
Client

DHCP
Server

Router,
gateway,
firewall


11

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 [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 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,
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.



Conclusion

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
-
so
-
important things. The most
important is that the configuration process is automatically carried out and the changes of configurations are
carefully verifi
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
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

, Septe
mber 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, Mar
ch 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.

Configuration
Client

Configuration
Daemon

RHCP request

RHCP reply


12

[9]

Douglas E. Comer,
Internetworking with TCP/IP, Vol. I: Principles, Protocols, and Architect
ures, 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 Illustrate
d, 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 p
rogramming 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.