What is Network Security? 7.8 Network Layer Security: IPsec Having examined case studies of the use of various security mechanisms at the application, socket, and transport layers, our final case study naturally takes us down to the network layer Here, we'll examine the the IP Security protocol, more commonly known as IPsec - a suite of protocols that provides security at the network layer IPsec is a rather complex animal, and different parts of it are described in more than a dozen RFCs In this section, we'll discuss IPsec in a specific context, namely, in the context that all hosts in the Internet support IPsec Although this context is many years away, the context will simplify the discussion and help us understand the key features of IPsec Two key RFCs are [RFC 2401], which describes the overall IP security architecture and [RFC 2411], which provides an overview of the IPsec protocol suite and the documents describing it A nice introduction to IPsec is given in [Kessler] Before getting into the specifics of IPsec, let's step back and consider what it means to provide security at the network layer Consider first what it means to provide network layer secrecy The network layer would provide secrecy if all data carried by all IP datagrams were encrypted This means that whenever a host wants to send a datagram, it encrypts the data field of the datagram before shipping it out into the network In principle, the encryption could be done with symmetric key encryption, public key encryption or with session keys that have are negotiated using public key encryption The data field could be a TCP segment, a UDP segment, an ICMP message, etc If such a network layer service were in place, all data sent by hosts including e-mail, Web pages, control and management messages (such as ICMP and SNMP) would be hidden from any third party that is "wire tapping" the network (However, the unencrypted data could be snooped at points in the source or destination hosts.) Thus, such a service would provide a certain "blanket coverage" for all Internet traffic, thereby giving all of us a certain sense of security In addition to secrecy, one might want the network layer to also provide source authentication When a destination host receives an IP datagram with a particular IP source address, it might authenticate the source by making sure that the IP datagram was indeed generated by the host with that IP source address Such a service prevents attackers from spoofing IP addresses In the IPsec protocol suite there are two principal protocols: the Authentication Header (AH) protocol and the Encapsulation Security Payload (ESP) protocol When a source host sends secure datagrams to a destination host, it does so with either the AH protocol or with the ESP protocol.The AH protocol provides source authentication and data integrity but does not provide secrecy The ESP protocol provides data integrity and secrecy Providing more services, the ESP protocol is naturally more complicated and requires more processing than the AH protocol We'll discuss both of these protocols below For both the AH and the ESP protocols, before sending secured datagrams from a source host to a destination host, the source and network hosts handshake and create a network layer logical connection This logical channel is called a security agreement (SA) Thus, IPsec transforms the traditional file:///D|/Downloads/Livros/computaỗóo/Computer%20Net own%20Approach%20Featuring%20the%20Internet/IPsec.htm (1 of 5)20/11/2004 15:53:10 What is Network Security? connectionless network layer of the Internet to a layer with logical connections! The logical connection defined by a SA is a simplex connection, that is, it is unidirectional If both hosts want to send secure datagrams to each other, then two SAs (i.e., logical connections) need to be established, one in each direction A SA is uniquely identified by a 3-tuple consisting of: q q q a security protocol (AH or ESP) identifier; the source IP address for the simplex connection; a 32-bit connection identifier called the Security Paramter Index (SPI) For a given SA (that is, a given logical connection from source host to destination host), each IPsec datagram will have a special field for the SPI All of the datagrams in the SA will use the same SPI value in this field Authentication Header (AH) Protocol As mentioned above, the AH protocol provides source host identification and data integrity but not secrecy When a particular source host wants to send one or more datagrams to a particular destination, it first establishes an SA with the destination After having established the SA, the source can send secured datagrams to the destination host The secured datagrams include the AH header, which is inserted between the original IP datagram data (e.g., a TCP or UDP segment) and the IP header, as shown in Figure 7.8-1 Thus the AH header augments the original data field, and this augmented data field is encapsulated as a standard IP datagram For the protocol field in the IP header, the value 51 is used to indicate that the datagram includes an AH header When the destination host recieves the IP datagram, it takes note of the 51 in the protocol field, and processes the datagram using the AH protocol (Recall that the protocol field in the IP datagram is traditionally used to distinguish between UDP, TCP, ICMP, etc.) Intermediate routers process the datagrams just as they always have they examine the destination IP address and route the datagrams accordingly Figure 7.8-1: Position of the AH header in the IP datagram The AH header includes several fields, including: q Next Header field, which has the role that the protocol field has for an ordinary datagram It indicates if the data following the AH header is a TCP segment, UDP segment, ICMP segment, file:///D|/Downloads/Livros/computaỗóo/Computer%20Net own%20Approach%20Featuring%20the%20Internet/IPsec.htm (2 of 5)20/11/2004 15:53:10 What is Network Security? q q q etc (Recall that protocol field in the datagram is now being used to indicate the AH protocol, so it can no longer be used to indicate the transport-layer protocol.) Security Parameter Index (SPI) field, an arbitrary 32-bit value that, in combination with the destination IP address and the security protocol, uniquely identifies the SA for the datagram Sequence Number field, a 32-bit field containing a sequence number for each datagram It is initally set to at the establishment of an SA The AH protocol uses the sequence numbers to prevent playback and man-in-the-middle attacks (see Section 7.3) Authentication Data field, a variable-length field containing signed message digest (i.e., a digital signature) for this packet The message digist is calculated over the original IP datagram, thereby providing source host authentication and IP datagram integrity The digital signature is computed using the authentication algorithm specified by the SA, such as DES, MD5 or SHA When the destination host receives an IP datagram with an AH header, it determines the SA for the packet and then authenticates the integrity of the datagram by processing the authentication data field The IPsec authentication scheme (for both the AH and ESP protocols) uses a scheme called HMAC, which is an encrypted message digest described in [RFC 2104] HMAC uses a shared secret key between two parties rather than public key methods for message authentication Further details about the AH protocol can be found in [RFC 2402] The ESP Protocol The ESP protocol provides network layer secrecy as well as source host authentication Once again, it all begins with a source host establishing a SA with a destination host Then the source host can send secured datagrams to the destination host As shown in Figure 7.8-2, a secured datagram is created by surrounding the original IP datagram data with header and trailer fields, and then inserting this encapsulated data into the data field of an IP datagram For the protocol field in the header of the IP datagram, the value 50 is used to indicate that the datagram includes an ESP header and trailer When the destination host recieves the IP datagram, it takes note of the 50 in the protocol field, and processes the datagram using the ESP protocol As shown in Figure 7.8-2, the original IP datagram data along with the ESP Trailer field are encrypted Secrecy is provided with DES-CBC encryption [RFC 2405] The ESP header consists of a 32bit field for the SPI and 32-bit field for the sequence number, which have exactly the same role as in the AH protocol The trailer includes the Next Header field, which also has exactly the same role Note that because the Next Header field is encrypted along with the original data, an intruder will not be able to determine the transport protocol that is being used Following the trailer there is the Authentication Data field, which again serves the same role as in the AH protocol Further details about the AH protocol can be found in [RFC 2406] file:///D|/Downloads/Livros/computaỗóo/Computer%20Net own%20Approach%20Featuring%20the%20Internet/IPsec.htm (3 of 5)20/11/2004 15:53:10 What is Network Security? Figure 7.8-2: The ESP fields in the IP datagram SA and Key Management For sucessful deployment of IPsec, a scalable and automated SA and key management scheme is necessary Several protocols have been defined for these tasks, including: q q The Internet Key Exchange (IKE) algorithm [RFC 2409] is the default key management protocol for IPsec The Internet Security Assoication and Key Management Protocol (ISKMP) defines procedures for establishing and tearing down SAs [RFC 2407] [RFC 2408] ISKMP's security association is completely separate from IKE key exchange This wraps up our summary of IPsec We have discussed IPsec in the context of IPv4 and the "transport mode" IPsec also defines a "tunnel mode," in which routers introduce the security functionality rather than the hosts Finally, IPsec describes encryption procedures for IPv6 as well as IPv4 References [Kessler] G.C Kessler, An Overview of Cryptography, May 1998, Hill Associates, http://www.hill.com/ TechLibrary/index.htm [RFC 2104] H Krawczyk, M.Bellare, R Canetti, HMAC: Keyed-Hashing for Message Authentication, [RFC 2104], February 1997 [RFC 2401] S Kent and R Atkinson, Security Architecture for the Internet Protocol, [RFC 2401], November 1998 file:///D|/Downloads/Livros/computaỗóo/Computer%20Net own%20Approach%20Featuring%20the%20Internet/IPsec.htm (4 of 5)20/11/2004 15:53:10 What is Network Security? [RFC 2402] S Kent and R Atkinson, IP Authentication Header, [RFC 2402], November 1998 [RFC 2405] C Madson and N.Doraswamy, The ESP DES-CBC Cipher Algorithm with Explicit IV, [RFC 2405], November 1998 [RFC 2406] S Kent and R Atkinson, IP Authentication Header, [RFC 2406], November 1998 [RFC 2407] D Piper, The Internet IP Security Domain of Interpretation for ISAKMP, [RFC 2407], November 1998 [RFC 2408] D Maughan, M Schertler, M Schneider and J Turner, Internet Security Association and Key Management Protocol (ISAKMP), [RFC 2408], November 1998 [RFC 2409] D Harkins and D Carrel, The Internet Key Exchange (IKE), [RFC 2409], November 1998 [RFC 2411] R Thayer, N Doraswamy and R Glenn, "IP Security Document Road Map," [RFC 2411], November 1998 Copyright 1999-2000 Keith W Ross and Jim Kurose All rights reserved file:///D|/Downloads/Livros/computaỗóo/Computer%20Net own%20Approach%20Featuring%20the%20Internet/IPsec.htm (5 of 5)20/11/2004 15:53:10 Chapter summary 7.9 Summary In this chapter, we've examined the various mechanisms that our secret lovers, Bob and Alice, can use to communicate "securely." We've seen that Bob and Alice are interested in secrecy (so that they alone are able to understand the contents of a transmitted message), authentication (so that they are sure that they are talking with each other), and message integrity (so that they are sure that their messages are not altered in transit) Of course, the need for secure communication is not confined to secret lovers Indeed, we saw in section 7.1 that security is needed at various layers in a network architecture to protect against "bad guys" who may sniff packets, remove packets from the network, or inject falsely addressed packets into the network The first part of this chapter presented various principles underlying secure communication We covered cryptographic techniques for coding and decoding data in Section 7.2, including both symmetric key cryptography and public key cryptography DES and RSA were examined as specific case studies of these two major classes of cryptographic techniques in use in today's networks In section 7.3 we turned our attention to authentication, and developed a series of increasingly sophisticated authentication protocols to ensure that a conversant is indeed who he/she claims to be, and is "live." We saw that both symmetric key cryptography and public key cryptography can play an important role not only in disguising data (encryption/decryption), but also in performing authentication Techniques for "signing" a digital document in a manner that is verifiable, non-forgible, and non-repudiable were covered in Section 7.4 Once again, the application of cryptographic techniques proved essential We examined both digital signatures and message digests - a shorthand way of signing a digital document In section 7.5 we examined key distribution protocols We saw that for symmetric key encryption, a key distribution center - a single trusted network entity - can be used to distribute a shared symmetric key among communicating parties For public key encryption, a certification authority distributes certificates to validate public keys Armed with the techniques covered in sections 7.2 through 7.5, Bob and Alice can communicate securely (one can only hope that they are networking students who have learned this material and can thus avoid having their tryst uncovered by Trudy!) In the second part of this chapter we thus turned our attention to the use of various security techniques in networks In section 7.6, we used e-mail as a case study for application-layer security, designing an e-mail system that provided secrecy, sender authentication and message integrity We also examined the use of pgp as a public-key e-mail encryption scheme Our cases studies continued as we headed down the protocol stack and examined the secure sockets layer (SSL) and secure electronic transactions, the two primary protocols in use today for secure electronic commerce Both are based on public key techniques Finally, in section 7.8 we examined a suite of security protocols for the IP layer of the Internet - the so-called IPsec protocols These can be used to provide secrecy, authentication and message integrity between two communication IP devices file:///D|/Downloads/Livros/computaỗóo/Computer%20Networki Approach%20Featuring%20the%20Internet/security_summary.htm20/11/2004 15:53:10 Network Security - Homework Problems Homework Problems and Discussion Questions Review Questions 1.) What are the differences between message secrecy and message integrity? Can you have one without the other? Justify your answer 2.) What is the difference between an active and a passive intruder? 3.) What is an important difference between a symmetric key system and a public key system? 4.) Suppose that an intruder has an encrypted message as well as the decrypted version of that message Can the intruder mount a cipher-text only attack, a known-plaintext or a chosen-plaintext attack? 5.) Suppose N people want to communicate with each of the N-1 other people using symmetric key encryption All communication between any to people, i and j, is visible to all other people, and no other person should be able to decode their communication How many keys are required in the system as a whole? Now suppose that public key encryption is used How many keys are required in this case? 6.) What is the purpose of a nonce in an authentication protocol? 7.) What does it mean to say that a nonce is a once-in-a-lifetime value? In whose lifetime? 8.) What is the man-in-the-middle attack? Can this attack occur when symmetric keys are used? 9.) What does it mean for a signed document to be verifiable, non-forgible, and non-repudiable? 10.) In what way does a message digest provide a better message integrity check than a checksum such as the Internet checksum? 11.) In what way does a message digest provide a "better" digital signature than using a public key digital signature? 12.) Is the message associated with a message digested encrypted? Since either "yes" or "no" are acceptable answers here, you should explain your answer 13.) What is a key distribution center? What is a certification authority? 14.) Summarize the key differences in the services provided by the Authentication Header protocol and file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw ach%20Featuring%20the%20Internet/security_homework.htm (1 of 3)20/11/2004 15:53:11 Network Security - Homework Problems the Encapsulation Security Payload (ESP) protocol in IPsec Problems 1.) Using the monoalphabetic cipher in Figure 7-3 Encode the message "This is an easy problem." Decode the message "rmij'u uamu xyj." 2.) Show that Eve's known plaintext attack in which she knows the (ciphertext, plaintext) translation pairs for seven letters reduces the number of possible substitutions to be checked by approximately 109 3.) Consider the Vigenere system shown in Figure 7-4 Will a chosen plaintext attack that is able to get the plaintext encoding of the message, "The quick fox jumps over the lazy brown dog" be sufficient to decode all messages? Why? 4.) Using RSA, choose p = and q = 11, and encode the phrase "hello" Apply the decryption algorithm, to the encrypted version to recover the original plaintext message 5.) In the man-in-the-middle attack in Figure 7.3-7, Alice has not authenticated Bob If Alice were to require Bob to authenticate himself using ap5.0, would the man-in-the-middle attack be avoided? Explain your reasoning 6.) The Internet BGP routing protocol uses the MD5 message digest rather than public key encryption to sign BGP messages Why you think MD5 was chosen over public key encryption? 7.) Compute a third message, different than the two messages in Figure 7.4-5, that has the same checksum as the messages in Figure 7.4-5 8.) Augment the KDC protocol shown in Figure 7.5-1 to include the necessary authentication messages Be sure to show the use of nonces and indicate which key values are used to encrypt which messages 9.) In the protocol and discussion of Figure 7.5-1, why doesn't Alice have to explicitly authenticate Bob? 10.) In the protocol in Figure 7.5-2, Alice did not include her own identity in the message to the CA Anyone could thus spoof a message from Alice to the CA Does this compromise the integrity of the CA's public key distribution? Justify your answer 11.) Why is there no explicit authentication in the protocol in Figure 7.5-2 ? Is authentication needed? Why? 12.) Consider the KDC and the CA servers Suppose a KDC goes down? What is the impact on the ability of parties to communicate securely, i.e., who can, and can not, communicate? Justify your file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw ach%20Featuring%20the%20Internet/security_homework.htm (2 of 3)20/11/2004 15:53:11 Network Security - Homework Problems answer Suppose now that a CA goes down What is the impact of this failure? Discussion Questions 1.) Suppose that an intruder could both insert and remove DNS messages into the network Give three scenarios showing the problems that such an intruder could cause 2.) No one has formally "proven" that 3-DES or RSA are "secure." Given this, what evidence we have they are indeed secure? 3.) If IPsec provides security at the network layer, why is it that security mechanisms are still needed at layers above IP? 4.) Go to the International PGP homepage (http://www.pgpi.org/) What version of pgp are you legally allowed to download, given the country you are in? file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw ach%20Featuring%20the%20Internet/security_homework.htm (3 of 3)20/11/2004 15:53:11 Network Managment - Introduction 8.1 What is Network Management? Having made our way through the first seven chapters of this text, we're now well aware that a network consists of many complex, interacting pieces of hardware and software - from the links, bridges, routers, hosts and other devices that comprise the physical components of the network to the many protocols (in both hardware and software) that control and coordinate these devices When hundreds or thousands of such components are cobbled together by an organization to form a network, it is not surprising that components will occasionally malfunction, that network elements will be misconfigured, that network resources will be overutilized, or that network components will simply "break" (e.g., a cable will be cut, a can of soda will be spilled on top of router) The network administrator, whose job it is to keep the network "up and running," must be able to respond to (and better yet, avoid) such mishaps With potentially thousands of network components spread out over a wide area, the network administrator in a network operations center (NOC) clearly needs tools to help monitor, manage, and control the network In this chapter, we'll examine the architecture, protocols, and information base used by a network administrator in this task Before diving in to network management itself, let's first consider a few illustrative "real-world" nonnetworking scenarios in which a complex system with many interacting components must monitored, managed, and controlled by an administrator Electrical power-generation plants (at least as portrayed in the popular media, e.g., movies such as the China Syndrome) have a control room where dials, gauges, and lights monitor the status (temperature, pressure, flow) of remote valves, pipes, vessels, and other plant components These devices allow the operator to monitor the plant's many components, and may alert the operator (the famous flashing red warning light) when trouble is imminent Actions are taken by the plant operator to control these components Similarly, an airplane cockpit is instrumented to allow a pilot to monitor and control the many components that make up an airplane In these two examples, the "administrator" monitors remote devices and analyzes their data to ensure that they are operational and operating within prescribed limits (e.g., that a core meltdown of a nuclear power plant is not imminent, or that the plane is not about to run out of fuel), reactively controls the system by making adjustments in response the changes within the system or its environment, and proactively manages the system, e.g., by detecting trends or anomalous behavior that allows action to be taken before serious problems arise In a similar sense, the network administrator will actively monitor, manage and control the system with which s/he is entrusted In the early days of networking, when computer networks were research artifacts rather than a critical infrastructure used by millions of people a day, "network management" was an unheard of thing If one encountered a network problem, one might run a few pings to locate the source of the problem and then modify system settings, reboot hardware or software, or call a remote colleague to so (A very readable discussion of the first major "crash" of the ARPAnet on October 27, 1980, long before network management tools were available, and the efforts taken to recover from and understand the crash is [RFC 789]) As the public Internet and private intranets have grown from small networks into a large global infrastructure, the need to more systematically manage the huge number of hardware and file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw pproach%20Featuring%20the%20Internet/netman_intro.html (1 of 5)20/11/2004 15:53:11 A Mail User Agent in Java Command DATA HELO MAIL FROM QUIT RCPT TO Reply Code 354 250 250 221 250 The above table also lists the accepted reply codes for each of the SMTP commands you need to implement For simplicity, you can assume that any other reply from the server indicates a fatal error and abort the sending of the message In reality, SMTP distinguishes between transient (reply codes 4xx) and permanent (reply codes 5xx) errors, and the sender is allowed to repeat commands that yielded in a transient error See Appendix E of RFC 821 for more details In addition, when you open a connection to the server, it will reply with the code 220 Note: RFC 821 allows the code 251 as a response to a RCPT TO-command to indicate that the recipient is not a local user You may want to verify manually with the telnet command what your local SMTP server replies Hints Most of the code you will need to fill in is similar to the code you wrote in the WebServer lab You may want to use the code you have written there to help you To make it easier to debug your program, not, at first, include the code that opens the socket, but use the following definitions for fromServer and toServer This way, your program sends the commands to the terminal Acting as the SMTP server, you will need to give the correct reply codes When your program works, add the code to open the socket to the server fromServer = new BufferedReader(new InputStreamReader(System in)); toServer = System.out; The lines for opening and closing the socket, i.e., the lines connection = in the constructor and the line connection.close() in function close(), have been commented out by default Start by completing the function parseReply() You will need this function in many places In the file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Approach%20Featuring%20the%20Internet/MailClient.html (3 of 8)20/11/2004 15:53:19 A Mail User Agent in Java function parseReply(), you should use the StringTokenizer-class for parsing the reply strings You can convert a string to an integer as follows: int i = Integer.parseInt(argv[0]); In the function sendCommand(), you should use the function writeBytes() to write the commands to the server The advantage of using writeBytes() instead of write() is that the former automatically converts the strings to bytes which is what the server expects Do not forget to terminate each command with the string CRLF You can throw exceptions like this: throw new Exception(); You not need to worry about details, since the exceptions in this lab are only used to signal an error, not to give detailed information about what went wrong Optional Exercises You may want to try the following optional exercises to make your program more sophisticated For these exercises, you will need to modify also the other classes (MailClient, Message, and Envelope) q q q q Verify sender address Java's System-class contains information about the username and the InetAddress-class contains methods for finding the name of the local host Use these to construct the sender address for the Envelope instead of using the user-supplied value in the From-header Additional headers The generated mails have only four header fields, From, To, Subject, and Date Add other header fields from RFC 822, e.g., Message-ID, Keywords Check the RFC for the definitions of the different fields Multiple recipients Currently the program only allows sending mail to a single recipient Modify the user interface to include a Cc-field and modify the program to send mail to both recipients For a more challenging exercise, modify the program to send mail to an arbitrary number of recipients More error checking The provided code assumes that all errors that occur during the SMTP connection are fatal Add code to distinguish between fatal and non-fatal errors and add a mechanism for signaling them to the user Check the RFC to see what the different reply codes mean This exercise may require large modifications to the send(), sendCommand(), and parseReply() functions file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Approach%20Featuring%20the%20Internet/MailClient.html (4 of 8)20/11/2004 15:53:19 A Mail User Agent in Java Querying the DNS The Domain Name System (DNS) stores information in resource records Normal name to IP-address mappings are stored in type A (Address) resource records Type NS (NameServer) records hold information about nameservers and type MX (Mail eXchange) records tell which server is handling the mail delivery of the domain The server you need to find is the server handling the mail for the domain to which you are sending mail, i.e., the MX-host of that domain First, you must find the nameserver of the target domain and then query this nameserver for the MX-host Assuming you were sending mail to the address user@someschool.edu you would the following: Find the address of a nameserver for the top-level domain edu (NS query) Query the nameserver for edu about the nameserver for the domain someschool.edu to get the address of Someschool's nameserver (NS query) Query Someschool's nameserver for MX-records for the domain someschool.edu (MX query) Ask your local system administrator how to perform DNS queries manually Under Unix you can query DNS manually with the nslookup-command The syntax of the nslookup-command is as follows Note that the argument host can also be a domain Normal query Normal query using a given server NS-query MX-query nslookup host nslookup host server nslookup -type=NS host nslookup -type=MX host For the first step, finding the nameserver of the top-level domain, you will need to send your query to one of the 13 DNS root nameservers You can find more information about the DNS root servers in Section DNS - The Internet's Directory Service The root servers are listed in the file root-servers.txt, available from Internic The reply to the MX-query may contain multiple mail exchangers Each of them is preceded by a number which is the preference value for this server Lower preference values indicate preferred servers so you should use the server with the lowest preference value file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Approach%20Featuring%20the%20Internet/MailClient.html (5 of 8)20/11/2004 15:53:19 A Mail User Agent in Java SMTPConnection.java This is the code for the SMTPConncetion class that you will need to complete The code for the other three classes is provided in import java.net.*; import java.io.*; import java.util.*; /** * Open an SMTP connection to a remote machine and send one mail * */ public class SMTPConnection { /* The socket to the server */ private Socket connection; /* Streams for reading and writing the socket */ private BufferedReader fromServer; private DataOutputStream toServer; private static final int SMTP_PORT = 25; private static final String CRLF = "\r\n"; /* Are we connected? Used in close() to determine what to */ private boolean isConnected = false; /* Create an SMTPConnection object Create the socket and the associated streams Initialize SMTP connection */ public SMTPConnection(Envelope envelope) throws IOException { // connection = /* Fill in */; fromServer = /* Fill in */; toServer = /* Fill in */; /* Fill in */ /* Read a line from server and check that the reply code is 220 If not, throw an IOException */ /* Fill in */ /* SMTP handshake We need the name of the local machine Send the appropriate SMTP handshake command */ file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Approach%20Featuring%20the%20Internet/MailClient.html (6 of 8)20/11/2004 15:53:19 A Mail User Agent in Java String localhost = /* Fill in */; sendCommand( /* Fill in */ ); isConnected = true; } /* Send the message Write the correct SMTP-commands in the correct order No checking for errors, just throw them to the caller */ public void send(Envelope envelope) throws IOException { /* Fill in */ /* Send all the necessary commands to send a message Call sendCommand() to the dirty work Do _not_ catch the exception thrown from sendCommand() */ /* Fill in */ } /* Close the connection First, terminate on SMTP level, then close the socket */ public void close() { isConnected = false; try { sendCommand( /* Fill in */ ); // connection.close(); } catch (IOException e) { System.out.println("Unable to close connection: " + e); isConnected = true; } } /* Send an SMTP command to the server Check that the reply code is what is is supposed to be according to RFC 821 */ private void sendCommand(String command, int rc) throws IOException { /* Fill in */ /* Write command to server and read reply from server */ /* Fill in */ /* Fill in */ /* Check that the server's reply code is the same as the parameter rc If not, throw an IOException */ file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Approach%20Featuring%20the%20Internet/MailClient.html (7 of 8)20/11/2004 15:53:19 A Mail User Agent in Java /* Fill in */ } /* Parse the reply line from the server Returns the reply code */ private int parseReply(String reply) { /* Fill in */ } /* Destructor Closes the connection if something bad happens */ protected void finalize() throws Throwable { if(isConnected) { close(); } super.finalize(); } } file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Approach%20Featuring%20the%20Internet/MailClient.html (8 of 8)20/11/2004 15:53:19 Lab: Implementting a reliable transport protocol Lab: Implementing a reliable transport protocol Overview In this laboratory programming assignment, you will be writing the sending and receiving transport-level code for implementing a simple reliable data transfer protocol There are two versions of this lab, the Alternating-Bit-Protocol version and the Go-Back-N version This lab should be FUN since your implementation will differ very little from what would be required in a real-world situation Since you probably don't have standalone machines (with an OS that you can modify), your code will have to execute in a simulated hardware/software environment However, the programming interface provided to your routines, i.e., the code that would call your entities from above and from below is very close to what is done in an actual UNIX environment (Indeed, the software interfaces described in this programming assignment are much more realistic that the infinite loop senders and receivers that many texts describe) Stopping/starting of timers are also simulated, and timer interrupts will cause your timer handling routine to be activated The routines you will write The procedures you will write are for the sending entity (A) and the receiving entity (B) Only unidirectional transfer of data (from A to B) is required Of course, the B side will have to send packets to A to acknowledge (positively or negatively) receipt of data Your routines are to be implemented in the form of the procedures described below These procedures will be called by (and will call) procedures that I have written which emulate a network environment The overall structure of the environment is shown in Figure Lab.3-1: Figure Lab.3-1: structure of the emulated environment file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Featuring%20the%20Internet/programming_assignment.htm (1 of 6)20/11/2004 15:53:20 Lab: Implementting a reliable transport protocol The unit of data passed between the upper layers and your protocols is a message, which is declared as: struct msg { char data[20]; }; This declaration, and all other data structure and emulator routines, as well as stub routines (i.e., those you are to complete) are in the file, prog2.c, described later Your sending entity will thus receive data in 20-byte chunks from layer5; your receiving entity should deliver 20-byte chunks of correctly received data to layer5 at the receiving side The unit of data passed between your routines and the network layer is the packet, which is declared as: struct pkt { int seqnum; int acknum; int checksum; char payload[20]; }; Your routines will fill in the payload field from the message data passed down from layer5 The other packet fields will be used by your protocols to insure reliable delivery, as we've seen in class The routines you will write are detailed below As noted above, such procedures in real-life would be part of the operating system, and would be called by other procedures in the operating system r r r r A_output(message), where message is a structure of type msg, containing data to be sent to the B-side This routine will be called whenever the upper layer at the sending side (A) has a message to send It is the job of your protocol to insure that the data in such a message is delivered in-order, and correctly, to the receiving side upper layer A_input(packet), where packet is a structure of type pkt This routine will be called whenever a packet sent from the B-side (i.e., as a result of a tolayer3() being done by a B-side procedure) arrives at the Aside packet is the (possibly corrupted) packet sent from the B-side A_timerinterrupt() This routine will be called when A's timer expires (thus generating a timer interrupt) You'll probably want to use this routine to control the retransmission of packets See starttimer() and stoptimer() below for how the timer is started and stopped A_init() This routine will be called once, before any of your other A-side routines are called It can be used to any required initialization file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Featuring%20the%20Internet/programming_assignment.htm (2 of 6)20/11/2004 15:53:20 Lab: Implementting a reliable transport protocol r r B_input(packet),where packet is a structure of type pkt This routine will be called whenever a packet sent from the A-side (i.e., as a result of a tolayer3() being done by a A-side procedure) arrives at the Bside packet is the (possibly corrupted) packet sent from the A-side B_init() This routine will be called once, before any of your other B-side routines are called It can be used to any required initialization Software Interfaces The procedures described above are the ones that you will write I have written the following routines which can be called by your routines: r r r r starttimer(calling_entity,increment), where calling_entity is either (for starting the A-side timer) or (for starting the B side timer), and increment is a float value indicating the amount of time that will pass before the timer interrupts A's timer should only be started (or stopped) by A-side routines, and similarly for the B-side timer To give you an idea of the appropriate increment value to use: a packet sent into the network takes an average of time units to arrive at the other side when there are no other messages in the medium stoptimer(calling_entity), where calling_entity is either (for stopping the A-side timer) or (for stopping the B side timer) tolayer3(calling_entity,packet), where calling_entity is either (for the A-side send) or (for the B side send), and packet is a structure of type pkt Calling this routine will cause the packet to be sent into the network, destined for the other entity tolayer5(calling_entity,message), where calling_entity is either (for A-side delivery to layer 5) or (for B-side delivery to layer 5), and message is a structure of type msg With unidirectional data transfer, you would only be calling this with calling_entity equal to (delivery to the B-side) Calling this routine will cause data to be passed up to layer The simulated network environment A call to procedure tolayer3() sends packets into the medium (i.e., into the network layer) Your procedures A_input() and B_input() are called when a packet is to be delivered from the medium to your protocol layer The medium is capable of corrupting and losing packets It will not reorder packets When you compile your procedures and my procedures together and run the resulting program, you will be asked to specify values regarding the simulated network environment: q q q Number of messages to simulate My emulator (and your routines) will stop as soon as this number of messages have been passed down from layer 5, regardless of whether or not all of the messages have been correctly delivered Thus, you need not worry about undelivered or unACK'ed messages still in your sender when the emulator stops Note that if you set this value to 1, your program will terminate immediately, before the message is delivered to the other side Thus, this value should always be greater than Loss You are asked to specify a packet loss probability A value of 0.1 would mean that one in ten packets (on average) are lost Corruption You are asked to specify a packet loss probability A value of 0.2 would mean that one in five packets (on average) are corrupted Note that the contents of payload, sequence, ack, or checksum fields can be corrupted Your checksum should thus include the data, sequence, and ack fields file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Featuring%20the%20Internet/programming_assignment.htm (3 of 6)20/11/2004 15:53:20 Lab: Implementting a reliable transport protocol q q Tracing Setting a tracing value of or will print out useful information about what is going on inside the emulation (e.g., what's happening to packets and timers) A tracing value of will turn this off A tracing value greater than will display all sorts of odd messages that are for my own emulator-debugging purposes A tracing value of may be helpful to you in debugging your code You should keep in mind that real implementors not have underlying networks that provide such nice information about what is going to happen to their packets! Average time between messages from sender's layer5 You can set this value to any non-zero, positive value Note that the smaller the value you choose, the faster packets will be be arriving to your sender The Alternating-Bit-Protocol Version of this lab You are to write the procedures, A_output(),A_input(),A_timerinterrupt(),A_init(),B_input (), and B_init() which together will implement a stop-and-wait (i.e., the alternating bit protocol, which we referred to as rdt3.0 in the text) unidirectional transfer of data from the A-side to the B-side Your protocol should use both ACK and NACK messages You should choose a very large value for the average time between messages from sender's layer5, so that your sender is never called while it still has an outstanding, unacknowledged message it is trying to send to the receiver I'd suggest you choose a value of 1000 You should also perform a check in your sender to make sure that when A_output() is called, there is no message currently in transit If there is, you can simply ignore (drop) the data being passed to the A_output() routine You should put your procedures in a file called prog2.c You will need the initial version of this file, containing the emulation routines we have writen for you, and the stubs for your procedures You can obtain this program from http://gaia.cs.umass.edu/kurose/transport/prog2.c This lab can be completed on any machine supporting C It makes no use of UNIX features (You can simply copy the prog2.c file to whatever machine and OS you choose) We recommend that you should hand in a code listing, a design document, and sample output For your sample output, your procedures might print out a message whenever an event occurs at your sender or receiver (a message/ packet arrival, or a timer interrupt) as well as any action taken in response You might want to hand in output for a run up to the point (approximately) when 10 messages have been ACK'ed correctly at the receiver, a loss probability of 0.1, and a corruption probability of 0.3, and a trace level of You might want to annotate your printout with a colored pen showing how your protocol correctly recovered from packet loss and corruption Make sure you read the ``helpful hints'' for this lab following the description of the Go_Back-N version of this lab The Go-Back-N version of this lab You are to write the procedures, A_output(),A_input(),A_timerinterrupt(),A_init(),B_input (), and B_init() which together will implement a Go-Back-N unidirectional transfer of data from the A-side to the B-side, with a window size of Your protocol should use both ACK and NACK messages Consult the alternating-bit-protocol version of this lab above for information about how to obtain the network emulator file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Featuring%20the%20Internet/programming_assignment.htm (4 of 6)20/11/2004 15:53:20 Lab: Implementting a reliable transport protocol We would STRONGLY recommend that you first implement the easier lab (Alternating Bit) and then extend your code to implement the harder lab (Go-Back-N) Believe me - it will not be time wasted! However, some new considerations for your Go-Back-N code (which not apply to the Alternating Bit protocol) are: r r A_output(message), where message is a structure of type msg, containing data to be sent to the B-side Your A_output() routine will now sometimes be called when there are outstanding, unacknowledged messages in the medium - implying that you will have to buffer multiple messages in your sender Also, you'll also need buffering in your sender because of the nature of Go-Back-N: sometimes your sender will be called but it won't be able to send the new message because the new message falls outside of the window Rather than have you worry about buffering an arbitrary number of messages, it will be OK for you to have some finite, maximum number of buffers available at your sender (say for 50 messages) and have your sender simply abort (give up and exit) should all 50 buffers be in use at one point (Note: using the values given below, this should never happen!) In the ``real-world,'' of course, one would have to come up with a more elegant solution to the finite buffer problem! A_timerinterrupt() This routine will be called when A's timer expires (thus generating a timer interrupt) Remember that you've only got one timer, and may have many outstanding, unacknowledged packets in the medium, so you'll have to think a bit about how to use this single timer Consult the Alternating-bit-protocol version of this lab above for a general description of what you might want to hand in You might want to hand in output for a run that was long enough so that at least 20 messages were successfully transfered from sender to receiver (i.e., the sender receives ACK for these messages) transfers, a loss probability of 0.2, and a corruption probability of 0.2, and a trace level of 2, and a mean time between arrivals of 10 You might want to annotate parts of your printout with a colored pen showing how your protocol correctly recovered from packet loss and corruption For extra credit, you can implement bidirectional transfer of messages In this case, entities A and B operate as both a sender and receiver You may also piggyback acknowledgments on data packets (or you can choose not to so) To get my emulator to deliver messages from layer to your B_output() routine, you will need to change the declared value of BIDIRECTIONAL from to Helpful Hints and the like q q q Checksumming You can use whatever approach for checksumming you want Remember that the sequence number and ack field can also be corrupted We would suggest a TCP-like checksum, which consists of the sum of the (integer) sequence and ack field values, added to a character-by-character sum of the payload field of the packet (i.e., treat each character as if it were an bit integer and just add them together) Note that any shared ``state'' among your routines needs to be in the form of global variables Note also that any information that your procedures need to save from one invocation to the next must also be a global (or static) variable For example, your routines will need to keep a copy of a packet for possible retransmission It would probably be a good idea for such a data structure to be a global variable in your code Note, however, that if one of your global variables is used by your sender side, that variable should NOT be accessed by the receiving side entity, since in real life, communicating entities connected only by a communication channel can not share global variables There is a float global variable called time that you can access from within your code to help you out with your diagnostics msgs file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Featuring%20the%20Internet/programming_assignment.htm (5 of 6)20/11/2004 15:53:20 Lab: Implementting a reliable transport protocol q q q START SIMPLE Set the probabilities of loss and corruption to zero and test out your routines Better yet, design and implement your procedures for the case of no loss and no corruption, and get them working first Then handle the case of one of these probabilities being non-zero, and then finally both being non-zero Debugging We'd recommend that you set the tracing level to and put LOTS of printf's in your code while your debugging your procedures Random Numbers The emulator generates packet loss and errors using a random number generator Our past experience is that random number generators can vary widely from one machine to another You may need to modify the random number generation code in the emulator we have suplied you Our emulation routines have a test to see if the random number generator on your machine will work with our code If you get an error message: It is likely that random number generation on your machine is different from what this emulator expects Please take a look at the routine jimsrand() in the emulator code Sorry then you'll know you'll need to look at how random numbers are generated in the routine jimsrand(); see the comments in that routine Q&A When we've taught this lab in our introductory neworking course, students have posed versious questions If you are interested in looking at the questions we've received (and answers), check out http://gaia.cs.umass.edu/kurose/ transport/programming_assignment_QA.htm file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 0Featuring%20the%20Internet/programming_assignment.htm (6 of 6)20/11/2004 15:53:20 CMPSCI 653/491G: On-line class audio/notes On-line class audio and notes It is possible for you to use your WWW browser (with the Real Audio plugin) to listen to the recorded audio of in-class lectures, with synchronized display and highlighting of the class notes In order to begin viewing/listening: q q Click here to register You need only register once You not have to be a student to register We only ask that you tell us who you are (once) Click here if you have already registered Click here to begin viewing/listening For more information: q q q hardware and software requirements, including the Real Audio WWW plugin instructions for navigating through the on-line audio/notes credit where credit is due kurose@cs.umass.edu file:///D|/Downloads/Livros/computaỗóo/Computer%20Network -Down%20Approach%20Featuring%20the%20Internet/listen.html20/11/2004 15:53:20 Internet Lectures on Demand Internet Protocols Lectures on Demand Lectures on demand consist of RealAudio audio clips coupled with graphical Web pages r Overview s s s s s s s s r Link Layer: Ethernet and Transparent Bridges s s s s s s s s s r Ethernet Basics CSMA/CD Ethernet Performance Ethernet Technologies LAN Design Problem Transparent Bridges Do You Have Backbone Designing a Building Area Network Switched Ethernet Transport Layer s s s s s s s r The Internet Circuit Switching vs Packet Switching Packet Switching vs Message Switching Connectionless and Connection-Oriented Services Virtual Circuits Network Taxonomy Protocol Stacks Packet-Switched Networks Classified by Extent Transport Layer Terminology Summary TCP/IP Encapsulation UDP - User Datagram Protocol TCP (Transmission Control Protocol) TCP Receive Window Round-Trip Time Estimation TCP Congestion Control Application Layer s s s Clients and Servers Hypertext Transfer Protocol (HTTP) FTP - File Transfer Protocol file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 20Approach%20Featuring%20the%20Internet/lod_title.html (1 of 2)20/11/2004 15:53:21 Internet Lectures on Demand s s s r SMTP NNTP Telnet Internet Commerce s s s s s s Introduction Fundamentals of Cryptography The Commerce Server Visa and MasterCard's Solution: The SET Protocol Digital Cash Email Verification Text: The Internet: Protocols, Technology, and Commerce file:///D|/Downloads/Livros/computaỗóo/Computer%20Netw 20Approach%20Featuring%20the%20Internet/lod_title.html (2 of 2)20/11/2004 15:53:21 ... original data field, and this augmented data field is encapsulated as a standard IP datagram For the protocol field in the IP header, the value 51 is used to indicate that the datagram includes an... by the SA, such as DES, MD5 or SHA When the destination host receives an IP datagram with an AH header, it determines the SA for the packet and then authenticates the integrity of the datagram... into the data field of an IP datagram For the protocol field in the header of the IP datagram, the value 50 is used to indicate that the datagram includes an ESP header and trailer When the destination