The Position of SSL in TCP/IP Protocol Suite

SSL can be conceptually considered as an additional layer in the TCP/IP protocol suite. The SSL layer is located between the application layer and the transport layer, as shown in Figure

As such, the communication between the various TCP/IP protocol layers is now as shown in Fig. Above

As we can see, the application layer of the sending computer (X) prepares the data to be sent to the receiving computer (Y), as usual. However, unlike what happens in the normal case, the application layer data is not passed directly to the transport layer now. Instead, the application layer data is passed to the SSL layer.

Here, the SSL layer performs encryption on the data received from the application layer (which is indicated by a different color), and also adds its own encryption information header, called as SSL Header (SH) to the encrypted data.

After this, the SSL layer data (L5) becomes the input for the transport layer. It adds its own header (H4), and passes it on to the Internet layer, and so on. This process happens exactly the way it happens in the case of a normal TCP/IP data transfer. Finally, when the data reaches the physical layer, it is sent in the form of voltage pulses across the transmission medium.

At the receiver's end, the process happens pretty similar to how it happens in the case or a normal TCP/IP connection, until it reaches the new SSL layer. The SSL layer at the receiver's end removes the SSL Header (SH), decrypts the encrypted data, and gives the plain text data back to the application layer of the receiving computer.

Thus, only the application layer data is encrypted by SSL. The lower layer headers are not encrypted.

This is quite obvious: if SSL has to encrypt all the headers, it must be I positioned below the data link layer. That would serve no purpose at all. In fact, it would lead to problems. If SSL encrypted all the lower layer headers, even the IP and physical i addresses of the computers (sender, receiver, and intermediate nodes) would be encrypted, and become unreadable. Thus, where to deliver the packets would be a big question. To understand the problem, imagine what would happen if we put the address of the sender and the receiver of a letter inside the envelope! Clearly, the postal service would not know where to send the letter! This is also why there is no point in encrypting the lower layer headers.

Therefore, SSL is required between the application and the transport layers.

How SSL Works?

SSL has three sub-protocols, namely:

1. The Handshake Protocol,
2. The Record Protocol and
3. The Alert Protocol.

These three sub-protocols constitute the overall working of SSL.

0.8 The TCP header:

Segment

The unit of data transfer between two devices using TCP is a segment. The format of a segment is shown in Figure.

 

TCP Header

The segment consists of a 20-byte to 60-byte header, followed by data from the application program. The header is 20 bytes if there are no options and up to 60 bytes if it contains options. We will discuss some of the header fields in this section.

1. Source port address. This is a 16-bit field that defines the port number of the application program in the host that is sending the segment.

2. Destination port address. This is a 16-bit field that defines the port number of the application program in the host that is receiving the segment.

3. Sequence number. This 32-bit field defines the number assigned to the first byte of data contained in this segment. As we said before, TCP is a stream transport protocol. To ensure connectivity, each byte to be transmitted is numbered. The sequence number tells the destination which byte in this sequence comprises the first byte in the segment.

4. Acknowledgment number. This 32-bit field defines the byte number that the sender of the segment is expecting to receive from the other party. If the byte numbered x has been successfully received, x + 1 is the acknowledgment number.

5. Header length. This 4-bit field indicates the number of 4-byte words in the TCP header. The length of the header can be between 20 and 60 bytes. Therefore, the value of this field can be between 5 (5 x 4 = 20) and 15 (15 x 4 = 60).

6. Reserved. This is a 6-bit field reserved for future use.

7. Control. This field defines 6 different control bits or flags, as shown in One or more of these bits can be set at a time. These bits enable flow control.

UDP Header

 

UDP Header
0.9 What is Connection Oriented?

0.9 What is Connectionless?

What is connection oriented v/s connectionless deliveries Parameter Connection oriented Connectionless Definition A characteristic of a network system that requires a pair of computers to establish a connection before sending data. Example Telephone line A characteristic of network system that allows a computer to send data to any other computer at any time without any prerequisite of destination connection Example: Postal system PDU movement Sequential To transmit data in such a way that each PDU is treated independently of all prior PDUs Three way handshake Connection establishment requires “three-way hand shake” Nothing of this sort Modus Operandi Three simple steps: ·         Connection  establishment Agree on : o   Syntax, o   Semantics & o   Timing ·         Data Transfer & ·         Connection termination Nothing of this sort Decision on path Only at the beginning At every node Sequence Keeps the sequence Can arrive out of sequence Example TCP UDP Reliable Reliable Unreliable

0.10 Distinguish between TCP and UDP. Parameter TCP UDP Common in both UDP and TCP are transport-layer protocols that create a process-to-process communication Reliability Reliable UDP is an unreliable protocol Connection orientation Connection oriented Connectionless Overheads Considerable Little Speed Slower Faster Protocol Data unit The TCP packet is called a segment. The UDP packet is called a user datagram. Expand the acronym Transmission Control Protocol User Datagram Protocol Flow control mechanism TCP uses a sliding window mechanism for flow control. UDP has no flow control mechanism at all. Error Detection and correction Mechanism Error detection is handled in TCP by the checksum, CRC acknowledgment, and time-out. UDP has no Error control mechanism at all. No Acknowledgement, No guaranteed delivery No sequence guarantee Timers TCP uses four timers—retransmission, persistence, keep-alive, and time-waited—in its operation. Nothing of this sort. Preference & Use TCP is preferred & used for: reliable, byte-stream delivery between processes. UDP is preferred & Used for one-shot, client-server type request-reply queries, Example: DNS Where prompt delivery is more important than accurate delivery, such as: Transmitting speech or video Headers & Overheads: The TCP header is much larger than the UDP header The UDP header is much smaller than the TCP header Example of application TELNET DNS Connection Required to have explicit connection between the hosts. Three Way Handshake No prior connection at all: It is connectionless