Telnet-to-Telenet? (long)


Bob Morgan (navajo!morgan@labrea.stanford.edu)
22 Jan 88 05:06:35 GMT


I'm with the Networking Systems organization at Stanford. We're
investigating possibilities for connecting our campus-wide
TCP/IP/Ethernet-based network (SUNet) to some X.25 networks. We
envision a gateway box that would have one or more X.25 trunks on one
side and an Ethernet interface on the other. We've figured out a few
things, found out some other things, and now are casting about for
fellow travelers (or maybe clever entrepreneurs).

(In the following, please excuse if my X.25 terminology isn't correct;
I'm not as familiar with it as I should be.)

We would like to provide the following services:

  * Outgoing terminal connections from SUNet machines to service
providers (such as Dialog) on X.25 PDNs (such as Telenet) (Yes, this
is the long-awaited Telnet-to-Telenet service 8^)

  * Outgoing terminal connections from SUNet machines to various
campus hosts that don't support TCP/IP/Ethernet but do support X.25

  * Incoming terminal connections from X.25 PDNs to SUNet hosts

  * Terminal connections from X.25-only campus hosts to SUNet hosts

There are some problems with setting up something like this, mostly
having to do with trying to connect an anarchic, "free" network
(SUNet/Internet) to metered, pay-as-you-go networks (PDNs). In
particular:

  * Some campus hosts already have direct PDN (Telenet) lines and
support users who place "collect" calls to those hosts. PDN charges
are eaten by the host-providing organization, or (in some cases, I
think) charged back to users through host usage charges. They would
like to continue this sort of service, through this new box. This
means that we somehow have to a) restrict collect calls to a specific
set of IP hosts, and b) capture the information about connections to
be able to do billing.

  * On the other hand, other hosts that don't want to worry about
collect calls might still like to receive connections from users who
pay their own PDN charges, so these connections should be possible to
any SUNet host. But we'd just as soon not provide access through our
facilities to the entire Internet from any Telenet PAD, so we'd like
to restrict the IP-side destinations to just Stanford.

  * We expect that outgoing calls (SUNet-to-PDN) will be collect only,
but once again we would prefer that these calls originate only at
Stanford, not anywhere in the Internet.

  * As much as possible, we'd like to insulate users from logging in
six times and entering long strings of numbers to make connections.
For example, I'd like to just say "> telnet dialog" from my Unix
system and have it all happen. This means that the gateway should
have some ability to translate names and addresses across the two
types of nets.

We're testing a Develcon system which is basically a port selector
with an X.25 card and a Telnet-server/Ethernet card installed in it.
This works fine for making the basic connections, and to some extent
for handling the name translation issue. But it's very difficult to
make it deal with the access-control (password protection is the prime
method) and cross-net accounting issues. It's not really their fault,
as it seems to me that no IP terminal server vendor is dealing with
access control in a comprehensive way.

Another approach, of course, is to take a Sun or a VAX with an X.25
board and munge it to do some of these things. Maybe all it would
take is rewriting Telnet client and server modules to be more picky.
We would, of course, prefer an off-the-shelf solution. Also, there's
some concern about how well something like this would scale up if the
service became popular.

So: is anybody doing anything like this? It sure looks to me like a
market opportunity here, folks. Suggestions, solutions, flames may be
sent to me and I'll digest and repost, etc.

Thanks,

- RL "Bob" Morgan
  Stanford Networking
  morgan@jessica.stanford.edu



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:40:41 GMT