don@SRI-LEWIS.ARPA (Donald Holman) (01/21/88)
To all,
This mobile host/circuit switched IP discussion seems to crop up every
six months or so. At the risk of re-kindling this fire. Here's another
perspective on this matter.
DISCLAIMERS
Since neither of us attended the "slip" discussion at Monterey East,
please correct us if there are any new developments.
This is probably as much of an issue in network management as in link
layer protocols. Please accept our apologies if we posted to the
incorrect forum.
INTRODUCTION
Over the past several months, there have been numerous discussions
concerning PC-based IP primarily tailored for academic and business
environments. Unfortunately, the current serial line IP implementations
do not appear to be entirely suited for military applications --
specifically, where a network must respond dynamically to architectural
changes.
The particular architecture which the past discussions have focused on
have been in connecting mobile nodes to pre-specified and fixed network
ports. Additionally the discussions have centered on the attachment of
PC's (e.g. IBM PC class machines) running some variant of SLIP (Rick
Adams, KA9Q, etc..).
There appears to be a more general problem which we would like to see
addressed; that of connecting hosts/PC's to a subnet via any available
network port on any PSN. We envision the host would have sufficient
processing power to support more sophisticated link layer protocols than
just simple framing. The discussion below focuses on the ability to
dial-up a PSN, use some network service, disconnect because the PSN
failed, dial-up another PSN, and gain immediate network access. Of
course, the requirement is on the ability to gain access via any node
without manual intervention and without excessive bandwidth consumption
due to routing table updates.
While there are protocols for acquiring a newly connected neighbor, they
do not appear to be entirely suited for large low speed networks where
hosts are not statically connected to the network but may randomly
appear at any network port. What we mean by low speed is the use of 16
kbps trunks, and 2.4 kbps host-to-subnet links. This is partially
governed by the requirement to keep telephone line costs low. The other
is availability during times of conflict.
Ideally the situation which we would like to have is to configure a
single host/PSN with the network configuration and be able to drop in
new machines without knowing their addresses, a priori.
Fully realizing that there are many issues at stake, we would like to
concentrate on a particular issue and system concept -- that of mobile
PC nodes using dial-up IP to any one of a set of ports available
throughout a fairly stable subnet.
The PC's will probably be replaced by high performance workstations in
the near future -- but the problem set remains the same. Similarly, this
discussion is not advocating the use of SLIP, X.25 or any other serial
line protocol, rather we are attempting to define a systems model for
use in a dynamic network.
BACKGROUND
The environment which we envision using a serial line protocol is in
connecting PC's to a relatively static backbone network consisting of
packet switches and dedicated nodes providing resources such as mail
queuing, computing services, distributed databases, etc.. Since, for
our use, this application is in the military arena the line protocol for
connecting into the subnet should be self configuring, be highly robust,
and not cause instabilities within the subnet.
Additionally, these PC's will dial into the backbone using voice-grade
commercial/tactical (low bandwidth) circuits. Our focus is on the
problem of connecting mobile PC's to this fairly static subnet. (For
now we're not going to entertain any of the complexities of subnet
partitioning or self reconfiguration.)
PC's should be able to dial into any available port at any PSN or
resource server and be able to immediately acquire available computing
resources. The service provided by the subnet to the PC should include
virtual connection services (e.g. TCP) and not just message/mail
forwarding (UUCP, CSNET Phonenet)
Circuit switched IP is a related matter but we'll assume for now that
the subnet is linked together using leased-lines and circuit switched IP
applies only on the PC to subnet data link. Under this model the user
is aware of a set of phone numbers or network entry points for accessing
the network.
DEFICIENCIES OF CURRENT APPROACHES
Present point-to-point link layer implementations either assume that
there is a pre-specified host at the remote end or that some negotiation
will occur specifying who the remote host is and if the host has the
proper access privileges. Another method, described by Bill Westfield
as the Gateway model, will accept packets from any IP host and is
managed by sending the appropriate routing updates. This method can be
viewed as extending routing mechanisms to the mobile host.
The problem with most existing point-to-point links is reconfiguration
of interfaces to accept different source and destination ends. This
does not occur dynamically and requires user intervention. With most
point-to-point links one must first specify a source and destination
interface address. Unfortunately, this binding of names to physical
devices forces the network to be static in nature. For example, current
SLIP implementations, BBN PSN's, and commercially available gateway
serial interfaces all require addresses to be assigned before the
interfaces become active. Most (if not all) X.25 links require a fixed
X.121 address.
Even if the host operator was able to reconfigure the machine's
interface, he/she would still need to determine what its interface
address should be and what the address of the PSN port is. For dynamic
situations it would be difficult to manage and distribute addresses at
the host level. This is particularly true in a military environment
during times of conflict when the network topology becomes very dynamic.
The gateway model of determining remote addresses and updating the
routing tables may be an answer for small nets. However, when nets are
large and many PC's dial into the network only to exit shortly after
(e.g. as in a tactical arena), the network may become congested with
routing updates. The convergence of the routing protocols must be quick
to minimize instabilities. In general, the ability to support arbitrary
hosts using the gateway model is gained at the risk of network
instability. Resources distant from the host may not be attainable
until routing information propagates to the server providing the
requested service. With low speed trunking, the network may do little
else than to update routing tables, especially if the radius was large
and the frequency of host connection/disconnection was high. (If anyone
has performed analytic or quantitative analysis of this situation,
pointers are greatly appreciated.)
A compromise between the two above methods is to have the calling PC
identify itself and to have the PSN port accept variable destination
ends within a given set of addresses. However, the deficit we see with
this approach is that addresses are still statically bound on the host
end. Given this approach the PC would be unable to use an access point
on a different PSN without incurring routing updates. Furthermore, the
set of addresses with access point would need to support may be large.
Our experience has been with BBN PSN's, cisco's, Sun IR and DDN X.25
products, and Rick Adam's SLIP. These require binding of addresses to
interfaces. If both ends of the interfaces have not been configured
with the proper addresses, the interfaces will not transport packets.
Current discussions have focused on stable address spaces -- the PC's
have a fixed address, the subnet ports have fixed addresses, and the
routing updates constitute the transport of these pre-assigned addresses
and their state. What would be nice is if there was a protocol for
having the network assign addresses dynamically having the dial-up hosts
conform automatically to this address. The idea of not binding network
addresses to either network access points or to the hosts may have
applicability.
DYNAMIC ADDRESS ASSIGNMENT
A method which may be suitable for the described network architecture
(static low speed backbone and roving dial-up PC's) but has not seen
much discussion, is dynamic address assignment rather than route
updating or fixed address assignment. Under this method a the network
access point is given a pool of addresses which it can freely delegate
to calling PC's and to the PSN ports. These address pools are assigned
by the subnet administrator at the time of system generation and are
available for assignment. The PC is required to abide by the assigned
address or risk having its packets dropped. The benefit of this
approach is that no routing updates need occur and authentication
becomes manageable -- away from the idea of authentication based on
addresses. What is proposed here is that an internet address is bound
to an interface after a calling PC is validated for access, and that the
address is re-used when the calling PC disconnects or the link fails.
This also requires the allocation of a pool of addresses large enough to
support the anticipated number of dial-up hosts. This could be
supported through subnetting, making the movement of PC hosts
transparent to the network layer routing protocols. This approach will
help preserve the stability of the subnet in terms of routing and
minimizing network flow changes only to user data packets.
This requires the interfaces to be able to communicate without knowing
what its network layer addresses should be. This shouldn't be a problem
as LAPB already supports this, there are two implicit addresses for a
point-to-point link -- DTE and DCE.
While X.25 is designed to address this issue of calling up a network and
gaining network access, it addresses only the host to subnet connection
and not how the subnet manages its external ports or performs the
routing of packets. This is an issue which we would like to discuss
with others. We are sure the ISO network layer working groups have
worked on this issue and we would be interested in hearing from them
concerning this subject.
Because the address pool is managed by the subnet, the user's need not
be concerned with low level details about attaching to the network.
They need only be concerned if they have appropriate access privileges.
The link to the network will be established automatically.
This dynamic address assignment model assumes that the host computer has
no services to offer the network, and that the network resources are
used by the PC and not vice versa. That is, the PC is a strict client,
and there is no need to seek out servers on the PC by other users or by
the network. Additionally, services which the PC will subscribe to are
offered by the subnet through resource servers which are stable and have
"well-know" addresses.
Since this model assumes a strict client-server relationship, the PC
will not be providing any services to the network. It is merely a
consumer. For the most part, this strict model is sufficient when PC
hosts are used. Again the feasibility of this model is dependent upon
servers which;
1.) are stable within the network,
2.) support name/service lookup,
4.) are capable of validating user accounts/passwords,
which as an entity provide a distributed authentication
and resource server capabilities.
3.) will offer services such as queuing up and retrieving mail,
(perhaps running a POP-like protocol), providing disk space,
distributed databases, etc..
In most networks, there are existing resources which are non-mobile or
their locations are fixed. If the architecture can support a distributed
maintenance of accounts this access and authentication scheme will allow
a user to log into any point in the network and access network services.
As with other approaches, a solid authentication mechanism needs to be
established to control network access. For network management, a
mechanism also needs to be developed to determine exactly who has
attached and what its new address is.
AUTHENTICATION
Allowing a PC to arbitrarily log into any point in the network requires
that the network support a distributed authentication mechanism. To
accomplish this the use of distributed authentication servers will
probably be required. The authentication servers must:
1.) maintain, through periodic updates, a table of users and
passwords of valid users that are allowed access to the network.
(it should be possible to derive this from the network passwd file)
2.) receive and validate authentication packets from login hosts.
3.) allow the authenticated PC user to modify the existing authentication
password.
When a PC enters the network it passes an authentication packet into the
network port where this packet is received and forwarded to the nearest
authentication server for validation. If authentication is successful,
the PC is permitted access to the network. If authentication is
unsuccessful then the network notifies the PC and access is not
permitted and the port reclaimed after several unsuccessful attempts to
gain access.
After authentication, the responsibility for seeking out services will
remain with the PC -- where the services are held, how "expensive" the
service is in terms of cost, transmission time, reliability, load, etc..
From a network wide perspective, transcending the layers, there should
be resource/name servers for informing the PC where it can locate files
and other pertinent information. Through the resource servers, the PC
is able to contact other servers for specific information.
Access control could be maintained by the authentication server which is
a network layer authentication mechanism. Some monitoring of
individuals currently logged onto the network may be performed at this
layer to map users to addresses or perhaps to notify recently logged on
users of important events which may have transpired since last login.
In a truly distributed environment, login into the net will also result
in updates containing resource locations be sent to the PC identifying
where and what kind of resources can be found at the current moment.
ADDITIONAL REQUIREMENTS
In order to support the before mentioned slip access and authentication
mechanisms the development of a higher layer protocol must occur. It is
this protocol which will support the passing of authentication
information to and from the network. As well, a distributed
authentication-server must be developed which is capable of maintaining
distributed account/password file information and authenticating client
requests.
In addition, a higher layer protocol and server must be developed which
will support the concept of an information/resource service. It is the
job of these resource servers to provide information, upon request, to
the PC indicating at what point in the subnet information such as mail
or data base updates (etc.) can be retrieved and what the cost
associated with this information might be.
SUMMARY
To summarize the above, we see the requirement for:
1) Serial line IP protocol for support of dynamic address assignment to
minimize routing table updates and address/configuration problems.
2) user authentication based upon a distributed authentication server.
3) resource servers, which are capable of providing information
on request to the PC, informing the PC the whereabouts of mail
and other services.
There appears to be many benefits to this approach for the given
architecture, and perhaps many drawbacks. While this idea is
conceptually no different than the idea of dialing up to your local
computer via a dumb terminal, we leverage the multiplexing features of
existing protocols such as IP. This approach does imply that the
resources at the host may not be used optimally, but for a military
application, the need for survivability may preempt efficiency
requirements.
Any comments will be appreciated.
Jointly,
Don Holman
Danny Lee
SRI International.