morgan@navajo (Bob Morgan) (01/22/88)
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