File eXchange Protocol

File eXchange Protocol (FXP) is a method of data transfer which uses the FTP protocol to transfer data from one remote server to another (inter-server) without routing this data through the client's connection. Conventional FTP involves a single server and a single client; all data transmission is done between these two. In the FXP session, a client maintains a standard FTP connection to two servers, and can direct either server to connect to the other to initiate a data transfer. The advantage of using FXP over FTP is evident when a high-bandwidth server demands resources from another high-bandwidth server, but only a low-bandwidth client, such as a network administrator working away from location, has the authority to access the resources on both servers.

Risk

Enabling FXP support, however, can make a server vulnerable to an exploit known as FTP bounce. As a result of this, FTP server software often has FXP disabled by default.

FXP over SSL

Some FTP Servers such as glFTPd, RaidenFTPd, and wzdftpd support negotiation of a secure data channel between two servers using either of the FTP protocol extension commands; CPSV or SSCN. This normally works by the client issuing CPSV in lieu of the PASV command - or by sending SSCN prior to PASV transfers -, which instructs the server to create either a SSL or TLS connection. However, both methods - CPSV and SSCN - are susceptible to Man-in-the-Middle attacks, since the two FTP servers do not verify each other's SSL certificates. SSCN was first introduced by RaidenFTPd and SmartFTP in 2003 and has been widely adopted now.

Managed File Transfer

Managed File Transfer (MFT) refers to software solutions that facilitate the secure transfer of data from one computer to another through a network (e.g., the Internet). MFT solutions are often built using the FTP network protocol. However, the term specifically describes solutions that remedy the disadvantages associated with FTP.

Typically, MFT offers a higher level of security and control than FTP. Features include reporting (e.g., notification of successful file transfers), non-repudiation (i.e., guaranteed delivery), auditability, global visibility, automation of file transfer-related activities and processes, end-to-end security, and performance metrics/monitoring.

Background

From its inception in 1980, FTP has made moving large volumes of bulk data between any two entities--including file servers, applications, and trading partners--possible. However, FTP (and other communication protocols such as HTTP and SMTP) do not, on their own, provide a way to secure or manage the payload or the transmission. Yet, regardless of the lack of security and management capabilities, many companies have continued to transport large batches of structured and unstructured data using these protocols.

This practice is changing, however. According to Gartner Research, "Numerous factors cause companies to re-examine how they manage the movement of information from system to system, partner to partner, and person to person. FTP alone is not a viable option to give [organizations] the insight, security, performance and, ultimately, the risk mitigation necessary to responsibly conduct business."

FTP over SSH (not SFTP)

FTP over SSH (not SFTP) refers to the practice of tunneling a normal FTP session over an SSH connection.

Because FTP uses multiple TCP connections (unusual for a TCP/IP protocol that is still in use), it is particularly difficult to tunnel over SSH. With many SSH clients, attempting to set up a tunnel for the control channel (the initial client-to-server connection on port 21) will protect only that channel; when data is transferred, the FTP software at either end will set up new TCP connections (data channels) which will bypass the SSH connection, and thus have no confidentiality, integrity protection, etc.

Otherwise, it is necessary for the SSH client software to have specific knowledge of the FTP protocol, and monitor and rewrite FTP control channel messages and autonomously open new forwardings for FTP data channels. Version 3 of SSH Communications Security's software suite, and the GPL licensed FONC are two software packages that support this mode.

FTP over SSH is sometimes referred to as secure FTP; this should not be confused with other methods of securing FTP, such as with SSL/TLS (FTPS). Other methods of transferring files using SSH that are not related to FTP include SFTP and SCP; in each of these, the entire conversation (credentials and data) is always protected by the SSH protocol.


Red Drive is a free file transfer extension that integrates with your Windows Explorer environment allowing you to drag, drop, open and edit files on remote servers without launching a separate file transfer client. Red Drive supports various file transfer protocols including FTP, FTPS (FTP over SSL), SFTP (FTP over SSH) and WebDAV.

Anonymous FTP

A host which provides an FTP service may additionally provide Anonymous FTP access as well. Under this arrangement, users do not strictly need an account on the host. Instead the user typically enters 'anonymous' or 'ftp' when prompted for username. Although users are commonly asked to send their email address as their password, little to no verification is actually performed on the supplied data.

As modern FTP clients typically hide the anonymous login process from the user, the ftp client will supply dummy data as the password (since the user's email address may not be known to the application).

For example, the following ftp user agents specify the listed passwords for anonymous logins:

* Mozilla Firefox (2.0) — mozilla@example.com

* KDE Konqueror (3.5) — anonymous@

* wget (1.10.2) — -wget@

* lftp (3.4.4) — lftp@

The Gopher protocol has been suggested as an alternative to anonymous FTP, as well as Trivial File Transfer Protocol and File Service Protocol.

Technorati Tags: TFTP,Anonymous FTP,FTP,File transfer,Protocol,FTP Service,Access,Modern FTP,Login Process,Mozilla,KDE,Wget,Lftp,Gopher Protocol

Types of Packet Switching

Connectionless and connection-oriented packet switching

The service actually provided to the user by networks using packet switching nodes can be either be connectionless (based on datagram messages), or virtual circuit switching (also known as connection oriented). Some connectionless protocols are Ethernet, IP, and UDP; connection oriented packet-switching protocols include X.25, Frame relay, Asynchronous Transfer Mode (ATM), Multiprotocol Label Switching (MPLS), and TCP.

In connection oriented networks, each packet is labeled with a connection ID rather than an address. Address information is only transferred to each node during a connection set-up phase, when an entry is added to each switching table in the network nodes.

In connectionless networks, each packet is labeled with a destination address, and may also be labeled with the sequence number of the packet. This precludes the need for a dedicated path to help the packet find its way to its destination. Each packet is dispatched and may go via different routes. At the destination, the original message/data is reassembled in the correct order, based on the packet sequence number. Thus a virtual connection, also known as a virtual circuit or byte stream is provided to the end-user by a transport layer protocol, although intermediate network nodes only provides a connectionless network layer service.

History of packet switching

image

The concept of packet switching was first explored by Paul Baran in the early 1960s, and then independently a few years later by Donald Davies (Abbate, 2000).

Leonard Kleinrock conducted early research in queueing theory which would be important in packet switching, and published a book in the related field of digital message switching (without the packets) in 1961; he also later played a leading role in building and management of the world's first packet switched network, the ARPANET.

Baran developed the concept of packet switching during his research at the RAND Corporation for the US Air Force into survivable communications networks, first presented to the Air Force in the summer of 1961 as briefing B-265 then published as RAND Paper P-2626 in 1962 , and then including and expanding somewhat within a series of eleven papers titled On Distributed Communications in 1964. Baran's P-2626 paper described a general architecture for a large-scale, distributed, survivable communications network. The paper focuses on three key ideas: first, use of a decentralized network with multiple paths between any two points; and second, dividing complete user messages into what he called message blocks (later called packets); then third, delivery of these messages by store and forward switching.

Baran's study made its way to Robert Taylor and J.C.R. Licklider at the Information Processing Technology Office, both wide-area network evangelists, and it helped influence Lawrence Roberts to adopt the technology when Taylor put him in charge of development of the ARPANET.

Baran's packet switching work was similar to the research performed independently by Donald Davies at the National Physical Laboratory, UK. In 1965, Davies developed the concept of packet-switched networks and proposed development of a UK wide network. He gave a talk on the proposal in 1966, after which a person from the Ministry of Defense told him about Baran's work. Davies met Lawrence Roberts at the 1967 ACM Symposium on Operating System Principles, bringing the two groups together.

Interestingly, Davies had chosen some of the same parameters for his original network design as Baran, such as a packet size of 1024 bits. Roberts and the ARPANET team took the name "packet switching" itself from Davies's work.

Packet switching in networks

Packet switching is used to optimize the use of the channel capacity available in digital telecommunication networks such as computer networks, to minimize the transmission latency (i.e. the time it takes for data to pass across the network), and to increase robustness of communication.

The most well-known use of packet switching is the Internet and local area networks. The Internet uses the Internet protocol suite over a variety of Link Layer protocols. For example, Ethernet and frame relay are very common. Newer mobile phone technologies (e.g., GPRS, I-mode) also use packet switching.

X.25 is a notable use of packet switching in that, despite being based on packet switching methods, it provided virtual circuits to the user. These virtual circuits carry variable-length packets. In 1978, X.25 was used to provide the first international and commercial packet switching network, the International Packet Switched Service (IPSS). Asynchronous Transfer Mode (ATM) also is a virtual circuit technology, which uses fixed-length cell relay connection oriented packet switching.

Datagram packet switching is also called connectionless networking because no connections are established. Technologies such as Multiprotocol Label Switching (MPLS) and the Resource Reservation Protocol (RSVP) create virtual circuits on top of datagram networks. Virtual circuits are especially useful in building robust failover mechanisms and allocating bandwidth for delay-sensitive applications.

MPLS and its predecessors, as well as ATM, have been called "fast packet" technologies. MPLS, indeed, has been called "ATM without cells". Modern routers, however, do not require these technologies to be able to forward variable-length packets at multigigabit speeds across the network.

image

Packet switching

Packet switching is a network communications method that groups all transmitted data, irrespective of content, type, or structure into suitably-sized blocks, called packets. The network over which packets are transmitted is a shared network that routes each packet independently from all others and allocates transmission resources as needed. Principal goals of packet switching are to optimize utilization of available link capacity and to increase robustness of communication.

Network resources are managed by statistical multiplexing or dynamic bandwidth allocation in which a physical communication channel is effectively divided into an arbitrary number of logical variable-bit-rate channels or data streams. Each logical stream consists of a sequence of packets, which normally are forwarded by a network node asynchronously in a first-in, first-out fashion. Alternatively, the packets may be forwarded according to some scheduling discipline for fair queuing or for differentiated or guaranteed quality of service. In case of a shared physical medium, the packets may be delivered according to some packet-mode multiple access scheme. When traversing network nodes, packets are buffered and queued, resulting in variable delay and throughput, depending on the traffic load in the network.

Packet switching contrasts with another principal networking paradigm, circuit switching, a method which sets up a specific circuit with a limited number dedicated connection of constant bit rate and constant delay between nodes for exclusive use during the communication session.

Packet mode (or packet-oriented, packet-based) communication may be utilized with or without intermediate forwarding nodes (packet switches).

ConnNet

ConnNet was a packet switched data network operated by the Southern New England Telephone Company serving the U.S. state of Connecticut.

ConnNet was the nation's first local public packet switching network when it was launched on March 11, 1985. Users could access services such as Dow Jones News Retrieval, CompuServe, Dialcom, GEnie, Delphi, Eaasy Sabre, NewsNet, PeopleLink, the National Library of Medicine, and BIX. ConnNet could also be used to access other national and international packet networks, such as Tymnet and ACCUNET. Large companies also connected their mainframe computers to ConnNet allowing employees access to the mainframes from home. The network is no longer in operation.

Hardware

The X.25 network was based on hardware from Databit, Inc. consisting of three EDX-P Network Nodes that performed switching and were located in Hartford, New Haven and Stamford. Databit also supplied 23 ANP 2520 Advanced Network Processors each of which provided the system with a point of presence, a network control center and modems. Customers would order leased line connections into the network for host computers running at 4,800 to 56,000 bits per second (bit/s). Terminals would connect over a leased line from 1,200 to 9,600 bit/s synchronous, 300 to 2,400 bit/s asynchronous or using dial-up connections from 300 to 1,200 bit/s. The connection to Tymnet was established over an X.75 based 9,600 bit/s analog link from the ConnNet Hartford node to Tymnet's Bloomfield node.

Operations in Tymshare

Organization

In operation, Tymshare's Data Networks Division was responsible for the development and maintenance of the network and Tymnet was responsible for the administration, provisioning and monitoring of the network. Each company had their own software development staff and a line was drawn to separate what each group could do. Tymshare development engineers wrote all the code which ran in the network, and the Tymnet staff wrote code running on host computers connected to the network. It is for this reason, that many of the Tymnet projects ran on the Digital Equipment Corporation DECSystem-10 computers that Tymshare offered as timesharing hosts for their customers. Tymnet operations formed a strategic alliance with the Tymshare PDP-10 TYMCOM-X operating systems group to assist them in developing new network management tools.

Trouble Tracking

Origins

Trouble reports were initially tracked on pieces of paper. This was until a manager at Tymnet wrote a small FORTRAN IV program to maintain a list of problem reports and track their status in a System 1022 database (a hierarchical database system for TOPS-10 published by Software House[citation needed]). He called the program PAPER after the old manual way of managing trouble tickets. The program grew as features were added to handle customer information, call-back contact information, escalation procedures, and outage statistics.

Company-wide Use

Access to PAPER became critical as more and more functionality was added. It eventually was maintained on two dedicated PDP-10 computers, model KL-1090, accessible via the Tymnet Packet Network as Tymshare hosts 23 and 26. Each computer was the size of 5 refrigerators, and had a string of disks that looked like 18 washing machines. Their power supplies produced +5 volts at 200 amps (non-switching) making them expensive to operate.

Major upgrades

In 1996 the DEC PDP-10s that ran Tymnet's trouble-ticket system were replaced by PDP-10 clones from XKL, Inc. They were accessible via TCP/IP as ticket.tymnet.com and token.tymnet.com, by both TELNET and HTTP. A low-end workstation from Sun was used as a telnet gateway; it accepted logins from the Tymnet network via x.25 to IP translation done by a Cisco router forwarded to "ticket" and/or "token". The XKL TOAD-1 systems ran a modified TOPS-20. The application was ported to a newer version of the Fortran compiler, and still used the 1022 database.

Decommission

In mid to late 1998, Concert produced an inter-company trouble tracking system for use by both MCI and Concert. This was adopted and the TTS PAPER data necessary for ongoing tickets was re-entered on the new system. TTS was kept up for historical information until the end of the year. In January 1999, both XKL servers (ticket and token) were decommissioned. In late 2003 the hardware left onsite in San Jose was accidentally scrapped by the facilities manager during a scheduled cleanup.

Electronic Data Interchange

EDI

Tymshare EDI, MD Payment Systems Company, MCI EDI Department

Tymshare was one of the pioneers in the EDI field. Under McDonnell Douglas, the Payment Systems Company continued that legacy and maintained its own network monitoring and support group. They used Tandem computers connected to a high speed data link using Tymnet as the connection and translation medium. Tymshare developed a bi-sync modem interface (HSA), a translation module to translate between EBCDIC and ASCII (BBXS), and a highly customized x.25 module (XCOM) to interface with the Tandem computers.

Apparently, there was no TCP/IP equivalent service, so to continue use of this service after the shutdown of Tymnet, an ingenious solution was selected. A special version of Tymnet Engine node code which allows nodes and interfaces to communicate with one another and the rest of the network was created. Instead of relying on the supervisor to validate calls, a table of permitted connections was defined per customer to allow an incoming call to be made from the HSA interface to the BBXS interface to the XCOM interface and on to the Tandem computer. In effect, they created a Tymnet Island consisting of a single Tymnet node that accepted calls for a pre-determined list of clients. No supervisor needed.

These islands of Tymnet have not only outlived the parent company, Tymshare, and the operations company, Tymnet, but also the Tymnet Network itself. As of 2008, these Tymnet Island nodes are still running and doing their jobs.

Tymnet - History

Beginnings: Tymshare

Tymshare was founded in 1964 as a time sharing company, selling computer time and software packages for users. It had two SDS/XDS 940 computers; access was via direct dial-up to the computers. In 1968, it purchased Dial Data, another time-sharing service bureau.

In 1968, Ann & Norm Hardy, Bill Frantz, Joe Rinde, and LaRoy Tymes developed the idea of using remote sites with minicomputers to communicate with the mainframes. The minicomputers would serve as the network's nodes, running a program called a "Supervisor" to route data. In November 1971, the first Tymnet Supervisor program became operational. Written in assembly code by LaRoy Tymes for the SDS 940, with architectural design contributions from Norman Hardy, the "Supervisor" was the beginning of the Tymnet network. The Varian 620i was also used for the TYMNET nodes. During those first years, Tymshare and its direct customers were the network's only users.

It soon became apparent that the SDS 940 could not keep up with the rapid growth of the network. In 1972, Joseph Rinde joined the Tymnet group and began porting the Supervisor code to the 32-bit Interdata 7/32, as the 8/32 was not yet ready. In 1973, the 8/32 became available, but the performance was disappointing and a crash-effort was made to develop a machine that could run Rinde's Supervisor.

In 1974, a second, more efficient version of the Supervisor software became operational. The new Tymnet "Engine" software was used on both the Supervisor machines and on the nodes.

After the migration to Interdata, they started developing Tymnet on PDP-10. Tymshare sold the Tymnet network software to TRW, who created their own private network, TRWNET.

Tymes and Rinde then developed Tymnet II. Tymnet II ran in parallel with the original network, which continued to run on the Varian machines until it was phased out over a period of several years. Tymnet II's different method of constructing virtual circuits allowed for much better scalability.

Tymnet, Inc. spun off

In about 1979, Tymnet Inc. was spun off from Tymshare Inc. to continue administration and operation of the network. The network continued to grow, and customers who owned their own host computers and wanted access to them from remote sites became interested in connecting their computers to the network. This led to the foundation of Tymnet as a wholly owned subsidiary of Tymshare to run a public network as a common carrier within the United States. This allowed users to connect their host computers and terminals to the network, and use the computers from remote sites or sell time on their computers to other users of the network, with Tymnet charging them for the use of the network.

Tymnet

Tymnet was an international data communications network headquartered in San Jose, California that utilized virtual call packet switched technology and used X.25, SNA/SDLC, ASCII and BSC interfaces to connect host computers (servers) at thousands of large companies, educational institutions, and government agencies. Users typically connected via dial-up connections or dedicated async connections. The business consisted of a large public network that supported dial-up users and a private network business that allowed government agencies and large companies (mostly banks and airlines) to build their own dedicated networks. The private networks were often connected via gateways to the public network to reach locations not on the private network. Tymnet was also connected to dozens of other public networks in the United States and internationally via X.25/X.75 gateways.

As the Internet grew and became almost universally accessible in the late 1990s, the need for services such as Tymnet migrated to the Internet style connections, but still had some value in the third world and for specific legacy roles. However the value of these links continued to decrease, and Tymnet was officially shut down in 2004.

Network

Tymnet offered local dial-up modem access in most cities in the United States and to a limited degree in Canada, which preferred its own DATAPAC service.

Users would dial into Tymnet and then interact with a simple command-line interface to establish a connection with a remote system. Once connected, data was passed to and from the user as if connected directly to a modem on the distant system. For various technical reasons, the connection was not entirely "invisible", and sometimes required the user to enter arcane commands to make 8-bit clean connections work properly for file transfer.

Tymnet was extensively used by large companies to provide dial-up services for their employees who were "on the road", as well as a gateway for users to connect to large online services such as CompuServe or The Source.

Organization and functionality

In its original implementation, the network supervisor contained most of the routing intelligence in the network. Unlike the TCP/IP protocol underlying the internet, Tymnet used a circuit switching layout which allowed the supervisors to be aware of every possible end-point. In its original incarnation, the users connected to nodes built using Varian minicomputers, then entered commands that were passed to the supervisor which ran on a XDS 940 host.

Circuits were character oriented and the network was oriented towards interactive character-by-character full-duplex communications circuits. The nodes handled character translation between various character sets, which were numerous at that point in time. This did have the side effect of making data transfers quite difficult, as bytes from the file would be invisibly "translated" without specific intervention on the part of the user.

Tymnet later developed their own custom hardware, the Tymnet Engine, which contained both nodes and a supervisor running on one of those nodes. As the network grew, the supervisor was in danger of being overloaded by the sheer number of nodes in the network, since the requirements for controlling the network took a great part of the supervisor's capacity.

Tymnet II was developed in response to this challenge. Tymnet II was developed to ameliorate the problems outlined above by off-loading some of the work-load from the supervisor and providing greater flexibility in the network by putting more intelligence into the node code. A Tymnet II node would set up its own "permuter tables", eliminating the need for the supervisor to keep copies of them, and had greater flexibility in handling its inter-node links. Data transfers were also possible via "auxiliary circuits".

Accessing the Network

Asynchronous Access

Users could use modems on the Public Switched Telephone Network to dial TAC ports, calling either from "dumb" terminals or from computers emulating such terminals. Organizations with a large number of local terminals could install a TAC on their own site, which used a dedicated line, at up to 56 kbit/s, to connect to a switch at the nearest Telenet location. Dialup modems supported had a maximum speed of 1200 bit/s, and later 4800 bit/s.

Computer Access

Computers supporting the X.25 protocol could connect directly to switching centers. These connections ranged from 2.4 to 56 kbit/s.

Other Access Protocols

Telenet supported remote concentrators for IBM 3270 family intelligent terminals, which communicated, via X.25, to Telenet-written software that ran in IBM 370x series front-end processors.

PC Pursuit

In the late 1980s, Telenet offered a service called PC Pursuit. For a flat monthly fee, customers could dial into the Telenet network in one city, then dial out on the modems in another city to access bulletin board systems and other services. PC Pursuit was popular among computer hobbyists because it sidestepped long-distance charges. In this sense, PC Pursuit was a forerunner of Voice over IP services.

Cities accessible by PC Pursuit

City Code	Area Code(s)	City
AZPHO	602	Phoenix, Arizona
CAGLE	818	Glendale, California
CALAN	213	Los Angeles, California
CODEN	303	Denver, Colorado
CTHAR	203	Hartford, Connecticut
FLMIA	305	Miami, Florida
GAATL	404	Atlanta, Georgia
ILCHI	312, 815	Chicago, Illinois
MABOS	617	Boston, Massachusetts
MIDET	313	Detroit, Michigan
MNMIN	612	Minneapolis, Minnesota
NCRTP	919	Research Triangle Park, North Carolina
NJNEW	201	Newark, New Jersey
NYNYO	212, 718	New York City
OHCLV	216	Cleveland, Ohio
ORPOR	503	Portland, Oregon
PAPHI	215	Philadelphia, Pennsylvania
TXDAL	214, 817	Dallas, Texas
TXHOU	713	Houston, Texas
WIMIL	414	Milwaukee, Wisconsin

Telenet

Telenet was a packet switched network which went into service in 1974. It was the first publicly available commercial packet-switched network service.

The original founding company, Telenet Inc., was established by Larry Roberts (former head of the ARPANet), and Barry Wessler. GTE acquired Telenet in 1979. It was later acquired by Sprint and called "Sprintnet". Sprint migrated customers from Telenet to the modern-day SprintLink IP network, one of many networks composing today's Internet. Telenet had its first offices in downtown Washington DC, then moved to McLean, Virginia. It was acquired by GTE while in McLean, and then moved offices in Reston, Virginia.

Under the various names, the company operated a public network, and also sold its packet switching equipment to other carriers and to large enterprise networks.

Coverage

Originally, the public network had switching nodes in seven US cities:

* Washington, D.C. (network operations center as well as switching)
* Boston, MA
* New York, NY
* Chicago, IL
* Dallas, TX
* San Francisco, CA
* Los Angeles, CA

The switching nodes were fed by Telenet Access Controller (TAC) terminal concentrators both colocated and remote from the switches. By 1980, there were over 1000 switches in the public network. At that time, the next largest network using Telenet switches was that of Southern Bell, which had approximately 250 switches.

Internal Network Technology

The initial network used statically-defined hop-by-hop routing, using Prime commercial minicomputers as switches, but then migrated to a purpose-built multiprocessing switch based on 6502 microprocessors. Among the innovations of this second-generation switch was a patented arbitrated bus interface that created a switching fabric, a shared bus in modern terms, among the microprocessors.

Most interswitch lines ran at 56 kbit/s, with a few, such as New York-Washington, at T1 (i.e., 1.544 Mbit/s). The main internal protocol was a proprietary variant on X.75; Telenet also ran standard X.75 gateways to other packet switching networks.

Originally, the switching tables could not be altered separately from the main executable code, and topology updates had to be made by deliberately crashing the switch code and forcing a reboot from the network management center. Improvements in the software allowed new tables to be loaded, but the network never used dynamic routing protocols. Multiple static routes, on a switch-by-switch basis, could be defined for fault tolerance. Network management functions continued to run on Prime minicomputers.

Its X.25 host interface was the first in the industry and Telenet helped standardize X.25 in the CCITT.

Reverse telnet

Reverse telnet is a specialized application of telnet, where the server side of the connection reads and writes data to a TTY line (RS-232 serial port), rather than providing a command shell to the host device. Typically, reverse telnet is implemented on an embedded device (e.g. terminal/console server), which has an Ethernet network interface and serial port(s). Through the use of reverse telnet on such a device, IP-networked users can use telnet to access serially-connected devices.

In the past, reverse telnet was typically used to connect to modems or other external asynchronous devices. Today, reverse telnet is used mostly for connecting to the console port of a router, switch or other device.

Example

On the client, the command line for initiating a "reverse telnet" connection might look like this:

telnet 172.16.1.254 2002

(The syntax in the above example would be valid for the command-line telnet client packaged with many operating systems, including most Unices, or available as an option or add-on.)

In this example, 172.16.1.254 is the IP address of the server, and 2002 is the TCP port associated with a TTY line on the server.

A typical server configuration on a Cisco router would look like this:

version 12.3
service timestamps debug uptim
service timestamps log uptime
no service password-encryption
!
hostname Terminal_Server
!
ip host Router1 2101 8.8.8.8
ip host Router2 2102 8.8.8.8
ip host Router3 2113 8.8.8.8
!
!
interface Loopback0
description Used for Terminal Service
ip address 8.8.8.8 255.255.255.255
!
line con 0
exec-timeout 0 0
password MyPassword
login
line 97 128
transport input telnet
line vty 0 4
exec-timeout 0 0
password MyPassword
login
transport input none
!
end

Telnet - Current status

As of the mid-2000s, while the Telnet protocol itself has been mostly superseded for remote login, Telnet clients are still used, often when diagnosing problems, to manually "talk" to other services without specialized client software. For example, it is sometimes used in debugging network services such as an SMTP, IRC, HTTP, FTP or POP3 server, by serving as a simple way to send commands to the server and examine the responses.



This approach has limitations as Telnet clients speak is close to, but not equivalent to, raw mode (due to terminal control handshaking and the special rules regarding \377 and \15). Thus, other software such as nc (netcat) or socat on Unix (or PuTTY on Windows) are finding greater favor with some system administrators for testing purposes, as they can be called with arguments not to send any terminal control handshaking data. Also netcat does not distort the \377 octet, which allows raw access to TCP socket, unlike any standard-compliant Telnet software.



Telnet is popular with:

* enterprise networks to access host applications, e.g. on IBM Mainframes.
* administration of network elements, e.g., in commissioning, integration and maintenance of core network elements in mobile communication networks.
* MUD games played over the Internet, as well as talkers, MUSHes, MUCKs, MOOes, and the resurgent BBS community.
* embedded systems

Telnet Security

When Telnet was initially developed in 1969, most users of networked computers were in the computer departments of academic institutions, or at large private and government research facilities. In this environment, security was not nearly as much of a concern as it became after the bandwidth explosion of the 1990s. The rise in the number of people with access to the Internet, and by extension, the number of people attempting to crack other people's servers made encrypted alternatives much more of a necessity.

Experts in computer security, such as SANS Institute, and the members of the comp.os.linux.security newsgroup recommend that the use of Telnet for remote logins should be discontinued under all normal circumstances, for the following reasons:


* Telnet, by default, does not encrypt any data sent over the connection (including passwords), and so it is often practical to eavesdrop on the communications and use the password later for malicious purposes; anybody who has access to a router, switch, hub or gateway located on the network between the two hosts where Telnet is being used can intercept the packets passing by and obtain login and password information (and whatever else is typed) with any of several common utilities like tcpdump and Wireshark.

* Most implementations of Telnet have no authentication to ensure that communication is carried out between the two desired hosts and not intercepted in the middle.

* Commonly used Telnet daemons have several vulnerabilities discovered over the years.


These security-related shortcomings have seen the usage of the Telnet protocol drop rapidly, especially on the public Internet, in favor of the ssh protocol, first released in 1995. SSH provides much of the functionality of telnet, with the addition of strong encryption to prevent sensitive data such as passwords from being intercepted, and public key authentication, to ensure that the remote computer is actually who it claims to be.

As has happened with other early Internet protocols, extensions to the Telnet protocol provide TLS security and SASL authentication that address the above issues. However, most Telnet implementations do not support these extensions; and there has been relatively little interest in implementing these as SSH is adequate for most purposes. The main advantage of TLS-Telnet would be the ability to use certificate-authority signed server certificates to authenticate a server host to a client that does not yet have the server key stored. In SSH, there is a weakness in that the user must trust the first session to a host when it has not yet acquired the server key.

Telnet - protocol details

Telnet is a client-server protocol, based on a reliable connection-oriented transport. Typically this protocol used to establish a connection to TCP port 23, where a getty-equivalent program (telnetd) is listening, although Telnet predates TCP/IP and was originally run on NCP.

Initially, Telnet was an ad-hoc protocol with no official definition. Essentially, it used an 8-bit channel to exchange 7-bit ASCII data. Any byte with the high bit set was a special Telnet character.

On March 5th, 1973, a meeting was held at UCLA where "New Telnet" was defined in two NIC documents: Telnet Protocol Specification, NIC #15372, and Telnet Option Specifications, NIC #15373.

The protocol has many extensions, some of which have been adopted as Internet standards. IETF standards STD 27 through STD 32 define various extensions, most of which are extremely common. Other extensions are on the IETF standards track as proposed standards.

Telnet 5250

IBM 5250 or 3270 workstation emulation is supported via custom telnet clients, TN5250/TN3270, and IBM servers. Clients and servers designed to pass IBM 5250 data streams over Telnet generally do support SSL encryption, as SSH does not include 5250 emulation. Under OS/400, port 992 is the default port for secured telnet.

Telnet

Telnet (Telecommunication network) is a network protocol used on the Internet or local area network (LAN) connections. It was developed in 1969 beginning with RFC 15 and standardized as IETF STD 8, one of the first Internet standards.

The term telnet also refers to software which implements the client part of the protocol. Telnet clients are available for virtually all platforms. Most network equipment and OSes with a TCP/IP stack support some kind of Telnet service server for their remote configuration (including ones based on Windows NT). Because of security issues with Telnet, its use has waned as it is replaced by the use of SSH for remote access.

"To telnet" is also used as a verb meaning to establish or use a Telnet or other interactive TCP connection, as in, "To change your password, telnet to the server and run the passwd command".

Most often, a user will be telnetting to a Unix-like server system or a simple network device such as a router. For example, a user might "telnet in from home to check his mail at school". In doing so, he would be using a telnet client to connect from his computer to one of his servers. Once the connection is established, he would then log in with his account information and execute operating system commands remotely on that computer, such as ls or cd.

On many systems, the client may also be used to make interactive raw-TCP sessions. It is commonly believed that a telnet session which does not include an IAC (character 255) is functionally identical. This is not the case however due to special NVT (Network Virtual Terminal) rules such as the requirement for a bare CR (ASCII 13) to be followed by a NULL (ASCII 0).