Internet Protocols Supported By Kermit There example essay topic
Protocols, in other words agreed upon methods of communication make this possible. Protocols can be also stated as a language that is agreed upon two or more computers to communicate. Network protocol standards are based upon the Open System Interconnection (OSI) Reference Model and the Institute of Electrical and Electronic Engineers (I ) 802 standards. In general most protocols follow the guidelines established by the OSI reference model. A protocol suite, also called a stack, is a combination of protocols that work together to achieve network communication. So as we can see networking and communicating plays a major role today, so because of this factor we must see how computers communicate and what kind of tools they use to communicate.
After the initial brief introduction to the types of protocols used and their categorizations, I would be aiming the course of this research paper on describing a popular file transfer protocol named Kermit. I choose Kermit because even though it's widespread, the wider end user population seems to know very little about the protocol and the software. The first few sections would contain an introduction to Kermit, its features and its use. Then moving on to technical aspects of how Kermit works, about Kermit software, and about its frame format.
Lastly, I would be concentrating on some general Kermit commands, and the security of Kermit, thus, which protocols Kermit supports on security. 2 Types of Protocols There are three main categories of protocols, which are Network protocols, Transport protocols, and Application protocols. Network Protocols Network protocols provide the following services, addressing and routing information, error checking, requesting retransmission, and establishing rules for communication in a particular networking environment. These services are also called link services. Some popular network protocols are: DDP (Delivery Datagram Protocol) Apple's data transport protocol that is used in AppleTalk. IP (Internet Protocol) Part of the TCP / IP protocol suite that provides addressing and routing information.
IPX (Internetwork Packet Exchange) and NWLink Novell's NetWare protocol (and Microsoft's implementation of this protocol, respectively) used for packet routing and forwarding. NetBEUI Developed by IBM and Microsoft, it provides transport services for NetBIOS. (Reference 1.) Transport Protocols In addition, protocol suites also contain transport protocols, which are responsible for ensuring reliable data delivery between computers. Some popular transport protocols are: ATP (AppleTalk Transaction Protocol) and NBP (Name Binding Protocol) AppleTalk's session and data transport protocols NetBIOS / NetBEUI NetBIOS establishes and manages communications between computers; NetBEUI provides data transport services for that communication SPX (Sequenced Packet Exchange) and NWLink Novell's connection oriented protocol that is used to guarantee data delivery (and Microsoft's implementation of this protocol) TCP (Transmission Control Protocol) The portion of the TCP / IP protocol suite that is responsible for reliable delivery of data 3 Application Protocols Finally, there are application protocols, which are responsible for application to- application services. Some popular application protocols are: AFP (AppleTalk File Protocol) Apple's remote file management protocol FTP (File Transfer Protocol) Another member of the TCP / IP protocol suite that is used to provide file transfer services NCP (NetWare Core Protocol) Novell's client shells and re directors NFS (Network File System) a client / server file system protocol primarily used to share directories with Unix systems. SMB (Server Message Block) A protocol that sits above NetBEUI and NetBIOS that defines and formats commands for information passing between networked computers.
SMTP (Simple Mail Transport Protocol) A member of the TCP / IP protocol suite that is responsible for transferring email. SNMP (Simple Network Management Protocol) A TCP / IP protocol that is used to manage and monitor network devices. (Reference 1.) What Is Kermit As mentioned earlier Kermit is a popular file transfer protocol, Kermit is available on most, if not all, the major platforms. Kermit was written at Colombia University in the early 1980's in response to a growing demand to transfer mainframe files to a new and emerging technological wonder, the floppy disk. Kermit is unique in that it is not proprietary software. In other words, it doesn't cost anything.
It is exchanged freely and is widely available. Its availability has enabled many people to study it and make suggestions for improving it. Consequently, Kermit has grown and appears in many versions. Because there is so many versions the features change all the time, there could be changes undergoing even now. Because of this aspect I have decided to discuss Kermit in general. The name Kermit probably seems familiar.
Indeed, Kermit is named after one of the late Jim Henson's Muppet characters. According to da Cruz. F. a researcher for Kermit, the name Kermit was chosen because the Muppet frog is a pleasant unassuming sort of a character and the protocol designers liked the association. To 4 justify its use they tried to think of a phrase for which Kermit was an acronym. After failing in their attempt, they decided to use the name anyway and requested and got permission from Henson Associates, Inc. to do so. Over the years, the Kermit project has grown into a worldwide cooperative nonprofit software development effort, headquartered at and coordinated from Colombia University. The Kermit Project is dedicated to production of cross platform, long-lasting, standards-conformant, interoperable communications software, and is actively engaged in the standards process.
Since its inception in 1981, the Kermit protocol has developed into a sophisticated and powerful tool for file transfer and management, incorporating, among other things: File group transmission File attribute transmission (size, date, permissions, etc) File name, record-format, and character- set conversion File collision options, including an "update" feature File transfer recovery Auto upload and download Client / Server operations Automatic per-file text / binary mode switching Recursive directory-tree transfer, even between unlike platforms Uniform services on serial and network connections An Internet Kermit Service Daemon Kermit Software Kermit software has been written for hundreds of different computers and operating systems, some of it by volunteer programmers all over the world, some of it by the Kermit Project professional staff. The major features of the most popular Kermit programs are: Connection establishment and maintenance for a wide variety of connection methods (TCP / IP, X. 25, LAN, serial port, modem, etc). Terminal emulation. Error-free file transfer. Internet protocols including Telnet, Rlogin, FTP, and HTTP. Internet security methods including Kerberos, SSL / TLS, SSH, and SRP.
Character-set translation during both terminal emulation and file transfer a unique feature of Kermit software. Numeric and alphanumeric paging. Script programming to automate complicated or repetitive tasks. 5 Kermit's user interface and script programming language are consistent across platforms and communication methods, allowing the investment in learning to pay off time and again as you move from one platform to another, one communication method to another. Premiere Kermit software implementations are: Kermit 95 for Windows 95/98/ME, Windows NT/2000/XP, and OS/2; C-Kermit for UNIX, VMS, VOS, AOS / VS, OS-9, and other operating systems; MS-DOS Kermit for DOS and Windows 3. x; IBM Mainframe Kermit for VM / CMS, MVS / TSO, and CICS. Kermit File Transfer Process (Reference 2.) As shown in the above diagram, to transfer a file between two computers, each must run a copy of Kermit.
The above diagram shows the general approach involving a PC and a remote computer connected by a phone line and modem. The PC's user runs some communication software to log on to the remote machine. Once logged on, he or she calls Kermit by entering its name. The user then enters the command Receive myfile. At this point, the Kermit running on the remote computer is waiting for a file to arrive. The boldface characters in the figure indicate system prompts (which will vary with the system).
Next, the user calls Kermit from the local PC and enters the command Send datafile. This activates the PC's Kermit. At this point, the user's interaction is done and Kermit does the rest. It looks for a file named "datafile" on the local PC and divides it into packets, the number depending on the size of the file and a packet. The PC Kermit constructs and sends frames through the modem and phone lines using the standard techniques and protocols described. When the frames arrive at the remote computer, its Kermit receives them.
If there are no errors, it extracts the packets and creates a file named "myfile". Once all the packets have been reassembled, the PC's Kermit informs the user the file transfer was successful. 6 From the user's perspective, the transfer was almost trivial. Two commands on each end were enough to do the job.
But as we know data transmission through networks is far from trivial. The Kermit Frame Format Kermit is a byte-oriented protocol. As with the Binary Synchronous Communication Protocol (BSC), the Kermit frame consists of a sequence of bytes. Each byte's placement in the frame determines its meaning. The diagram below shows the frame format and, as you might expect, it differs little from BSC and High Level Data Link Control Protocol (HDLC). It contains the ASCII SOH character, a frame number, and data.
It also contains the number of bytes or length of a frame. This differs from previous protocols in which variable-length frames were terminated by a special character. With Kermit, the receiving station finds the frame's end by counting the number of bytes and comparing with the length field. Each frame also contains an error-checking field. Error checking may be done using the CRC method or checksums. The checksum method computes a modular sum of frame bytes treated as integers.
The sum is stored and sent with the frame. The receiving station recalculates the sum and compares it with the stored sum. Any discrepancy indicates an error. Finally, each frame has a type field represented by a character.
Kermit's frame types are similar to HDLC and BSC. Table 1.1 summarizes some of them. Kermit Frame Format (Reference 2.) SOH Length Number Type... Data...
Error Check Table 1.1 Kermit Frame Types (Reference 2.) Frame Type Meaning B Break transmission. Indicates the two communicating stations should disconnect. D Data frame. E Error. Indicates a fatal error has occurred and the data field specifies the error F File Header. Contains the name of the file that will be sent.
G Generic command. The Data field contains one of a number of commands and optional parameters that can be sent to the other station. N Negative Acknowledgment. 7 S Send initiation. Sent to the receiving Kermit. It indicates a file will be coming soon and contains parameters used in the protocol.
Y Acknowledgment frame. Used to acknowledge both data and control frames. Z End of file frame. Indicates that all frames for the file have been sent. The Kermit Protocol Kermit was written as a half duplex but will support full duplex, stop and wait protocol for point-to-point connection. The station (A) that sends the first file starts by sending an initiation frame (type S) to the other station (B).
As Specified in the above table, this frame informs the receiving station that it will be receiving frames. The S frame and its eventual acknowledgment contain parameters on which the stations must agree in order for the protocol to work correctly If A and B exchange several files. The S frame contains parameters such as the following: The longest frame that A expects to get. This prevents (B) from sending (A) more than it can handle. Timeout period. This specifies how long (B) should wait for a frame before a timeout occurs.
Control prefix character. If a file's data includes certain control characters, sending them can have unexpected effects if a device such as a modem intercepts and interprets them. To avoid misinterpretation of data, Kermit replaces a control character with two printable characters. The first is an agreed on prefix such as the character #. (A) must tell (B) which prefix character to use so that (A) can recognize it. The second character is obtained by adding 64 to the control character's code, thus making it a printable character.
(Table 1.2). For example, if the control characters X-ON and XOFF appeared as data they would be sent as the two-letter sequences #Q and #S, respectively. When (B) receives a two-character sequence starting with #, it discards the # and subtracts 64 from the second character. Eighth-bit prefix character.
Many versions of Kermit are written to transfer seven-bit ASCII text files. However, the seven-bit codes are often stored in eight-bit bytes with the eighth bit being 0. In such cases, an eighth bit is replaced by a parity bit determined from the other seven. When the file arrives, a 0 bit replaces the parity bit. A problem can occur when binary files are sent because all eight bits in a byte are meaningful. If the eighth bit is replaced with a parity bit then it is lost for good and the protocol fails.
One option for dealing with binary files is to use an eighth-bit prefix character. If the eighth bit in a byte is 1, the seven remaining bits are 8 sent with parity. However, the sending Kermit will insert the agreed-on prefix character (such as an &) prior to it. If the eighth bit is 0 then no eighth-bit prefix is sent. When the receiving Kermit sees the (&) character, it removes it and concludes that the eighth bit of the next byte is a 1.
Otherwise it concludes that the eighth bit is 0. Run-length encoding prefix. Run-length encoding, a data compression method that replaces long strings of a character with a single occurrence of it preceded by the number of times it occurs. Kermit also can provide run-length encoding. However, the receiving Kermit must be able to determine when it receives a run-length encoded string.
For example, suppose it receives two consecutive bytes 00000111 (binary 7) and 01000001 (ASCII code for A). Are these data, or do they represent a run-length-encoded string? To differentiate the two cases, the sending Kermit inserts a special prefix (such as ~) prior to a run-length-encoded string. Thus, when the receiving Kermit sees the character (~), it concludes the following characters define a run-length-encoded string.
Table 1.2 Example. (Reference 2.) 9 The diagram below shows a typical exchange of Kermit frames. Station (A) starts by sending an S frame containing the previous information. (B) responds by sending a Y frame (acknowledgment).
The Y frame may also contain the previous information. This exchange allows each station to inform the other what it expects. Next, (A) sends an F frame specifying the name of the file it will send. Again, (B) responds by acknowledging the F frame by sending another Y frame. Sending data frames proceeds as described earlier, with (B) acknowledging the ones it receives correctly and sending Negative Acknowledgment's (N AKs) (N frames) when it receives a damaged frame or times out. When the last frame has been sent, (A) sends a Z frame indicating the entire file has been sent.
Again, (B) responds with an acknowledgment. Finally, if there is no more work to be done, (A) sends a B frame indicating its intention to disconnect. (B) acknowledges it and the disconnection occurs. (Reference 2.) 10 Using the Kermit Protocol to Send a File Commands Many people who use Kermit do not know how it works. In many cases they do not want or need to know.
However, they do need to know how to interact with it to perform necessary tasks. There are some common commands to which Kermit responds. But, this description is general, and all commands may not be available on every Kermit. The table below shows some general commands. Kermit is included here primarily because of its widespread use, but it's not necessarily the only file transfer protocol. There are others, such as XMODEM, XMODEM-CRC, XMODEM-lK, XMODEM, MODEM, and MODEM.
The differences among them, including frame sizes and formats, error checking methods, and control characters used, are not huge. On the other hand, as anyone who has ever written a program knows, even the smallest differences can make protocols incompatible. (Reference 2.) Command Function clear Clears buffers and removes deadlocks caused if each station sends the other an X-OFF character. get Request (usually to a file server) for a specified file. It differs from receive, which assumes the other station has issued a send command independent of the receive.
The get command requests that the server send it. receive Tells Kermit to wait for a file that will be arriving. If the command specifies a file name, the incoming file will be stored under that name. If not, the file will be stored under the name specified in the file header (F frame). It is expected that a file has been (or will be) sent, otherwise, the wait is very long send Tells Kermit to send one or more files to the other station. It is expected the other station can receive it. set baud Defines the baud rate. 11 set block-check Specifies how error checking will be performed.
As stated previously, the choices are a checksum or cyclic redundancy check. set delay Defines how much time Kermit waits before sending the first frame in response to a send command. This is needed when a user is running two Kermit's and enters a send command. He or she needs time to get to the other Kermit to enter the receive command before frames start arriving. set duplex Specifies whether the connection is half or full duplex. set parity Establishes how and if parity is used. Choices are ODD (for odd parity), EVEN (for even parity), MARK (parity bit always 1), SPACE (parity bit always 0), or NONE (no parity, all eight bits are data). It is essential that both Kermit's use the same method. set receive Used to establish previously discussed parameters such as the maximum frame length and prefix characters for incoming frames. set send Used to establish previously discussed parameters such as the maximum frame length and prefix characters for outgoing frames. The parameters can be changed by a send receive command entered at the other Kermit. set timer Used to enable or disable the timeout mechanism. set window Allows Kermit to use a sliding window protocol (go-back-n) instead of the typical stop and wait protocol to improve overall efficiency.
A parameter for this command specifies the window size (between 0 and 31). set {send or receive} packet-length Changes the default frame size to send or receive. The default maximum is 94, but an extended version of Kermit allows frame sizes up to 9000. set {send or receive} timeout Specifies how long a station should wait for a frame before responding with a negative acknowledgment. 12 Kermit Security Security is the hot topic on the Internet. Security systems and protocols abound.
But it was not always so. In the early days, the mere act of putting two computers in touch with each other was quite amazing. To connect multiple diverse computers to a common network, allowing any pair of them to communicate, was almost inconceivable. When the ARPANET (precursor of the Internet) was first operational on October 1, 1969, the eager task for many years afterwards was to open up more and more sites to it.
The architecture of the network and its protocols were developed in research laboratories in an atmosphere of trust. The network itself is not secure. By its very nature and fundamental design, it is entirely open. While it might be possible to insert security at the transport and / or network layers, transparent to all applications, the approach until now has been to layer security protocols over TCP and IP: some of them standard, some not so standard. Even among the standard ones, there are many to choose from. This approach requires one or more security methods to be programmed into each and every client and server application that is to make or accept secure Internet connections.
The situation should improve in the future, as security becomes part of the network itself through evolving standards such as IPSec, IPv 6, and DNSSEC. Kermit software has offered secure connections since 1998. The information I present here, is the security methods embodied in C-Kermit 8.0 and Kermit 95 1.1. 21, which include: (Reference 4.) Kerberos (TM) IV and V Secure Remote Password (TM) (SRP) Secure Sockets Layer (SSL) /Transport Layer Security (TLS) Secure Shell (SSH) vs. 1 and vs. 2 (built into K 95, external in C-Kermit) Microsoft NT LAN Manager (NTLM, K 95 Windows only) Kermit Secure Connection Methods What is a secure connection? A connection is secure if it provides: Authentication of the user to the host / service without the transmission of the user's password; Authentication of the host to the user; Privacy, through a shared secret that can be used as an end-to-end encryption key; and: Integrity: the assurance that the data has not been altered in transit.
13 A secure connection requires two applications, one on each end, that support and can negotiate a common security method, for example, a Telnet client on your desktop and a Telnet server at the remote site, both equipped with Kerberos V protocols. Kermit software supports a variety of connection methods, including serial ports, modems, and TCP / IP. Presently, secure connections are supported only over TCP / IP connections. Since there are many security protocols to consider (Kerberos, SRP, TLS, etc) and several TCP / IP application protocols where they can be used (Telnet, SSH, FTP, HTTP, etc), and different platforms for the clients and servers (Unix, VMS, Windows, OS/2, etc), the possibilities are many. To complicate matters, every Kermit program can come with or without security. USA export law requires non-secure versions.
Secure versions can be built with any combination of the security methods listed above. Kerberos IV but not Kerberos V, SRP and SSL / TLS but not Kerberos, etc. Kermit 95 has either no security methods built in or else all of them. C-Kermit on Unix can have any combination, depending on the libraries available on each platform and which ones the builder selected. Internet Protocols Supported By Kermit There are several Internet protocols that Kermit supports.
Below I have listed which security options are available for each: TELNET (Network Virtual Terminal Protocol) The Telnet protocol can be used to establish the most secure connections with a large choice of authentication and privacy methods. Kermit's Telnet implementation supports Kerberos 4, Kerberos 5, Secure Remote Password (SRP), NTLM, and X. 509 certificates for client and server authentication. Privacy can be accomplished with the Secure Sockets Layer (SSL) or Transport Layer Security (TLS). SSH (Secure Shell and Port Forwarding Protocol) The SSH protocols (versions 1 and 2) can be used to establish secure connections with a wide choice of authentication methods. Kermit's SSH implementation supports Kerberos 4, Kerberos 5, Secure Remote Password (SRP), and Public Keys for client and server authentication. Privacy is integrated into the protocol through the use of secure public key or GSSAPI based key exchange coupled with strong cipher suites.
FTP (File Transfer Protocol) 14 An FTP client can make secure connections for both the command and data channels. Kermit's FTP implementation supports Kerberos 4, GSSAPI Kerberos 5, SRP, and SSL / TLS. HTTP (Hyper Text Transfer Protocol) HTTP can be used with SSL or TLS to submit requests and receive responses in a secure manner. RLOGIN (Remote Login) The Remote Login protocol can be used with Kerberos 4 or 5 to make authenticated connections. After authentication the DES streaming cipher can be used for privacy.
SSL (Secure Socket Layer) / TLS (Transport Layer Security) The SSL and TLS protocols can be used by themselves to establish a private connection to a host. Authentication of the server (and perhaps the client) is performed via exchange and verification of X. 509 certificates or Kerberos 5 credentials. Kermit also can make Telnet connections over a secure SSL or TLS tunnel. Kerberos 5 User-to-User The Kerberos 5 user-to-user protocol can make authenticated and private connections between two end-user operated copies of Kermit.
The table below summarizes which security methods Kermit can support for each Internet service if those security methods are built in to Kermit. Protocol Krb 4 Krb 5 SSL / TLS SRP SSH NTLM Telnet Yes Yes Yes Yes Yes (K 95) Rlogin Yes Yes No No No No SSL / TLS No Yes N / A No No No K 5 User -User No Yes No No No No FTP Yes Yes Yes Yes No No HTTP No No Yes No No No Kermit Yes Yes Yes Yes No (K 95) SSH No Yes No Yes N / A No 15 Conclusion There are three main categories of protocols, which are Network protocols, Transport protocols, and Application protocols. As mentioned earlier Kermit is a popular file transfer protocol, Kermit is available on most major platforms. As we can see, Kermit has grown and appears in many versions.
The name Kermit seems familiar because Kermit is named after one of the late Jim Henson's Muppet characters. Kermit is a byte-oriented protocol. The major features of the most popular Kermit programs are: Error-free file transfer. There are several Internet protocols that Kermit supports. Which include TELNET, SSH, FTP, HTTP, RLOGIN, SSL, and Kerberos 5 After carefully and thoroughly looking at this research on Kermit, I have understood how different protocols work and how even a minor difference affects the incompatibility between protocols.
And since I have never known about Kermit until now it was really interesting to know about how secure it is, the features that it had, and the differences of Kermit with regard to other file transfer protocols. The security aspect, since Kermit is being updated all the time it has compatibility with almost every common Internet protocol. So to summarize my paper and conclude, through this paper I have briefly described about different protocols and their use. Primarily I have concentrated on giving information about Kermit file transfer protocol and Kermit software. Through this paper I have discussed about how Kermit transfers files and about various commands and security options that it has. Kermit is being updated all the time to improve its present performance and to make it compatible with new platforms and protocols.
Lastly, Kermit is free, and because of its availability it changes all the time, and new features are added to it all the time. Because of this factor I think it has the potential to become a very successful project for the people at Columbia University.
Bibliography
1. Networking Essentials (Ed Tittel, Kurt Hudson, James Michael Stewart) 2. Understanding Data Communications & Networks (William A. Shay) 3. Data & Computer Communications (William Stallings) Internet Resources 4. web (Columbia University Official Kermit site).