Vinod H Bachelor of Computer Application Semester - 5 BC0055 TCP/IP Protocol Suite

Fall 2012 Assignment Set 2 Roll No: 521110833 Center Code: 03011

BC0055 TCP/IP Protocol Suite Set -2 1. What do you mean by OPTION NEGOTIATION? Explain with an example Using internal commands, Telnet is able to negotiate options in each host. The starting base of negotiation is the NVT capability: Each host to be connected must agree to this minimum. Every option can be negotiated by the use of the four command codes WILL, WONT, DO, and DONT. In addition, some options have sub options.

The communication between client and server is handled with internal commands, which are not accessible by users. All internal Telnet commands consist of 2- or 3-byte sequences, depending on the command type. The Interpret As Command (IAC) character is followed by a command code. If this command deals with option negotiation, the command will have a third byte to show the code for the referenced option. See Fig above for more details. Table below shows some of the possible command codes

2. Explain the principle of operation of REXEC protocol.

Remote Execution Command Daemon (REXECD) is a server that allows the execution of jobs submitted from a remote host over the TCP/IP network. The client uses the REXEC or Remote Shell Protocol (RSH)

BC0055 TCP/IP Protocol Suite Set -2 command to transfer the job across to the server. Any standard output or error output is sent back to the client for display or further processing. Principle of operation REXECD is a server (or daemon). It handles commands issued by foreign hosts and transfers orders to subordinate virtual machines for job execution. The daemon performs automatic login and user authentication when a user ID and password are entered. The REXEC command is used to define the user ID, password, host address, and the process to be started on the remote host. However, RSH does not require you to send a user name and password; it uses a host access file instead. Both server and client are linked over the TCP/IP network. REXEC uses TCP port 512 and RSH uses TCP port 514. See below figure for more details.

3. List and explain the generic SNMP traps. Traps are asynchronous notifications of events occurring within an SNMP community. They can be generated both by SNMP agents and SNMP subagents. Additionally, they can be RFC architected (called a generic trap type) or they can be proprietary (called enterprise-specific). Architected traps, defined in RFC 1215, are as follows: coldStartEvent Notifies managers that the SNMP agent is reinitializing and that the configuration might have been altered. This trap belongs to the RFC 1213-architected System group, and is therefore supported by the SNMP agent. warmStartEvent Notifies managers that the SNMP agent is reinitializing, but there has been no alteration of the configuration. This trap belongs to the RFC 1213-architected System group, and is therefore supported by the SNMP agent. linkDownEvent Notifies managers that an interface has been deactivated. Information identifying the interface is included in the trap. This trap belongs to the RFC 1213-architected Interface group and is usually supported by a TCP/IP specific subagent. linkUpEvent Notifies managers that an interface has been activated. Information identifying the interface is included in the trap. This trap belongs to the RFC 1213-architected Interface group and is

BC0055 TCP/IP Protocol Suite Set -2 usually supported by a TCP/IP-specific subagent, or by an SNMP agent that manages its own TCP/IP MIBs. snmpAuthenFailureEvent Notifies managers that a user attempting to access the SNMP community did not provide the credentials needed to gain authorization by the SNMP agent. This trap belongs to the RFC 1213-architected SNMP group, and therefore is supported by the SNMP agent. egpNeighborLossEvent Notifies manages that a relationship with an EGP neighbor no longer exists. Information identifying the EGP neighbor is included in the trap. This trap belongs to the RFC 1213architected EGP group, and therefore is usually supported by an EGP-specific subagent or a TCP/IP specific-subagent. entSpecificEvent This trap is a placeholder that allows SNMP agent or subagent implementations to create enterprise-specific traps. Traps generated by an SNMP agent are usually delivered to managers using well-known UDP port 162. However, SNMP implementations might provide a configuration option to allow traps to be sent to other user-determined ports. If a subagent generates a trap, the trap is not sent directly from the subagent to a manager. Instead, the trap is passed over the DPI connection to the agent, who then sends out the trap to the managers (See below figure).

4. Discuss FTP proxy transfer through firewall FTP provides the ability for a client to have data transferred from one FTP server to another FTP server. Several justifications for such a transfer exist, including: To transfer data from one host to another when direct access to the two hosts are not possible. To bypass a slow client connection. To bypass a firewall restriction. To reduce the amount of traffic within the clients network

The process of setting up a proxy transfer begins with the use of a proxy open command. Any FTP command can then be sent to the proxy server by preceding the command with proxy. For example, executing the dir command lists the files on the primary FTP server. Executing the proxy dir command

BC0055 TCP/IP Protocol Suite Set -2 lists the files on the proxy server. The proxy get and proxy put commands can then be used to transfer data between the two hosts.

In the above figure: 1) The FTP client opens a connection and logs on to the FTP server A. 2) The FTP client issues a proxy open command, and a new control connection is established with FTP server B. 3) The FTP client then issues a proxy get command (though this can also be a proxy put). 4) A data connection is established between server A and server B. Following data connection establishment, the data flows from server B to server A.

5. Differentiate between getNextRequest and getBulkRequest taking an appropriate example. The SNMP manager, also referred to as a Network Management Station (NMS), provides a user interface through which network administrators can monitor and manage their network. The manager fulfills the role of a client in the client/server model and is available in a variety of formats including command-line interfaces, graphical user interface (GUI) applications, and fully automated applications. The SNMP manager is responsible for issuing requests to the SNMP agent. These requests can be queries to obtain the value of a MIB object, or they can be requests to set the value of a MIB object. SNMP managers also can listen for notifications or alerts, called traps, generated by components in the SNMP community An SNMP manager can make the following types of requests to the SNMP agent: getRequest Requests that the agent return the value of the specified object. getNextRequest Requests that the agent return the first valid value following the specified object. For example, assume a getNext is executed for ifType (1.3.6.1.2.1.2.2.1.3). Assuming the first valid instance of ifType is ifType.1 (1.3.6.1.2.1.2.2.1.3.1), this is the value that the SNMP agent will return.

BC0055 TCP/IP Protocol Suite Set -2 getBulkRequest performs the same function as the get request, but allows the manager to query more than one object per request. This is only valid using the SNMPv2c security model. setRequest Requests that the SNMP agent set the value of the specified object. walk Implements a series of getNext requests such that an entire sequence of objects is returned to the manager. In each iteration of the getNext series, the last object returned becomes the next object on which a getNext is executed. The walk ends when an object is returned that is beyond the scope of the request. An example of this is provided in Fig. 10.6. Note that the walk request is not architected in the SNMP communication that occurs between the SNMP manager and SNMP agent. Instead, it is a convention widely used by most SNMP managers. 6. What is content negotiation? Discuss its types. In order to find the best handling for different types of data, the correct representation for a particular entity body should be negotiated. There are three types of negotiation: Server-driven negotiation: The representation for a response is determined according to the algorithms located at the server. Agent-driven negotiation: The representation for a response is determined according to the algorithms located. Transparent negotiation: This is a combination of both server-driven and agent-driven negotiation. It is accomplished by a cache that includes a list of all available representations.

HTTP caching: One of the most important features of HTTP is caching capability. Because HTTP is a distributed information-based protocol, caching can improve the performance significantly. There are a number of functions that come with the HTTP 1.1 protocol to use caching efficiently and properly. In most cases, client requests and server responses can be stored in a cache within a reasonable amount of time to handle the corresponding future requests. If the response is in the cache and is accurate, there is no need to request another response from the server. This approach not only reduces the network bandwidth requirement, but also increases the speed. There is a mechanism that the server estimates a minimum time in which the response message will be valid. That means, an expiration time is determined by the server for that particular response message. Therefore, within this time, the message can be used without referring to the server. Consider that this time is exceeded and there is a need for that response message. The data inside the message might have been changed (or not) after the expiration date. To be able to ensure whether the data is changed or not, a validation mechanism is defined as follows: Expiration mechanism: In order to decide whether the data is fresh or not, an expiration time is determined. In most cases, the origin server explicitly defines the expiration time for a particular response message within that message. If this is the case, the cached data can be used to send from cache for subsequent requests within the expiration time. If the origin server did not define any expiration time, there are some methods to estimate/calculate a reasonable expiration time (such as the Last-Modified time). Because this is not originated from the server, use this cautiously. Validation mechanism: When the expiration time is exceeded, there is a possibility that the data is stale. In order to ensure the validation of the response message, the cache has to check with the origin server (or possibly an intermediate cache with a fresh response) whether the response

BC0055 TCP/IP Protocol Suite Set -2 message is still usable. HTTP 1.1 provides conditional methods for this purpose. When an origin server sends a full response, it attaches some sort of validator to the message. This then is used as a cache validator by the user agent or the proxy cache. The client (user agent or the proxy cache) generates a conditional request with a cache validator attached to it. The server then evaluates the message and responds with a special code (usually 304, Not Modified) and no entity body. Otherwise, the server sends the full response (including the entity body). This approach avoids an extra round-trip if the validator does not match and also avoids sending the full response if the validator matches. 7. List and explain various fields of HTTP messages. HTTP messages consist of the following fields: Message types: A HTTP message can be either a client request or a server response. The following string indicates the HTTP message type:

HTTP-message = Request | Response Message header :The HTTP message header field can be one of the following: o General header o Request header o Response header o Entity header Message body: Message body can be referred to as entity body if there is no transfer coding has been applied. Message body simply carries the entity body of the relevant request or response. Message length Message length indicates the length of the message body if it is included. General header field: General header fields can apply both request and response messages. Currently defined general header field options are as follows: Cache-Control Connection Date Pragma Transfer-Encoding Upgrade Via

Request: A request message from a client to a server includes the method to be applied to the resource, the identifier of the source, and the protocol version in use. A request message field is as follows: Request = Request-Line *(general-header | request-header | entity-header) CRLF [Message-body] Response: An HTTP server returns a response after evaluating the client request. A response message field is as follows:

8 Request = Request-Line *(general-header | request-header | entity-header) CRLF [Message-body]

BC0055 TCP/IP Protocol Suite Set -2

Entity: Either the client or server might send Entity in the request message or the response message, unless otherwise indicated. Entity consists of the following: Entity header fields Entity body

Persistent connections: A significant difference between HTTP 1.1 and earlier versions of HTTP is that HTTP 1.1 uses a persistent connection as the default. In earlier version implementations, a separate TCP connection is established for each URL and clients have to make multiple requests for images and associated data on the same URL. This approach was causing congestion and performance problems in the network. Persistent HTTP connections have a number of advantages, most notably the reduction in TCP connections and subsequently, of waiting times. Method definitions: Currently defined methods are as follows: Safe and idempotent methods: Methods considered not to cause side effects are referred to as safe. Idempotent methods are GET, HEAD, PUT, and DELETE. OPTIONS: This method allows the client to determine the options or requirements associated with a source or capabilities of a server without any resource retrieval. GET: This method allows the client to retrieve the data that was determined by the request URI. HEAD: This method allows the client to retrieve Meta information about the entity that does not require you to transfer the entity body. POST: The post function is determined by the server. PUT: This method is similar to the post method with one important difference: The URI in post request identifies the resource that will handle enclosed entity. DELETE: This methods requests that the server delete the source determined by the request URI. TRACE: This method allows the client to see how the message was retrieved at the other side for testing and diagnostic purposes.

Status code definitions: The status code definitions are as follows: Informational (1xx) :Informational status codes indicate a provisional response. Currently defined codes are as follows: - 100 Continue - 101 Switching Protocols Successful (2xx): This class of codes indicates that a particular request was successfully received, understood, and accepted. Currently defined codes are as follows: - 200 OK - 201 Created - 202 Accepted - 203 Non-Authoritative Information

9 204 No Content -205 Reset Content 206 Partial Content

BC0055 TCP/IP Protocol Suite Set -2

Redirection (3xx): This class of codes indicates that an action is required from the user agent in order to complete the request. Currently defined codes are as follows: 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 303 See Other 304 Not Modified 305 Use Proxy

Client error (4xx): This class of codes indicates client errors. Currently defined codes are as follows:

- 400 Bad Request - 401 Unauthorized - 402 Payment Required - 403 Forbidden -404 Not Found - 405 Method Not Allowed - 406 Not Acceptable - 407 Proxy Authentication Required - 408 Request Timeout - 409 Conflict - 410 Gone - 411 Length Required - 412 Precondition Failed - 413 Request Entity Too Large - 414 Request-URI Too Long - 415 Unsupported Media Type Server error (5xx): This class of codes indicates client errors. Currently defined codes are as follows: - 500 Internal Server Error - 501 Not Implemented - 502 Bad Gateway - 503 Service Unavailable - 504 Gateway Timeout - 505 HTTP Version Not Supported

Access authentication: HTTP provides an authentication mechanism to allow servers to define access permissions on resources and clients to use these resources. The authentication method can be one of the following: Basic authentication scheme: Basic authentication is based on user IDs and passwords. In this authentication scheme, the server permits the connection only if the user ID and password are validated. In basic authentication, user IDs and passwords are not encrypted. They are encoded in Base64 format

10

BC0055 TCP/IP Protocol Suite Set -2 Digest authentication scheme: Digest authentication scheme is an extension to HTTP and described in RFC 2617. In this authentication scheme, the user ID and a digest containing a hash value of the password are sent to the server. The server computes a similar digest and grants access to the protected resources if the two digests are equal. Notice that if the digest authentication is enabled, what is sent over the network is not simply an encrypted form of the password, which could be decrypted if one had the correct key, but is a onehash value of the password, which cannot be decrypted. So, digest authentication provides a higher level of security than the Base64 encoded password. Unfortunately, digest authentication is not yet supported by all browsers