CCNA 1 and 2 Companion Guide, Revised (Cisco Networking Academy Program) part 86 pdf

Figure 19-4 TCP Segment Format Transport Internet Network Interface Application TCP UDP Bit 0 Header Length 4 Sequence Number 32 Destination Port 16 Source Port 16 Bit 31 Bit 16 Bit 15 O

■ User Datagram Protocol (UDP)—A connectionless and unreliable protocol that

is responsible for transmitting messages but provides no software checking for segment delivery The advantage that UDP provides is speed Because UDP pro-vides no acknowledgments, less control traffic is sent across the network, making the transfer faster

Figure 19-3 Transport Layer Protocols

TCP and UDP Segment Format

TCP is known as a connection-oriented protocol Connection-oriented means that the

end stations are aware of each other and are constantly communicating about the

con-nection A classic example of a non-technical connection-oriented communication is a

telephone conversation between two people A good example of a connectionless

con-versation is the U.S postal service where once you place the letter in the mail you hope

that the mailing process gets the package delivered Figure 19-4 illustrates the TCP

seg-ment header format, the field definitions of which are described in the following list

Figure 19-4 TCP Segment Format

Transport Internet Network Interface

Application

TCP UDP

Bit 0

Header Length (4)

Sequence Number (32)

Destination Port (16) Source Port (16)

Bit 31 Bit 16

Bit 15

Options (0 or 32 if Any) Data (Varies)

Bytes

■ Source port—The number of the source (port) for this segment.

■ Destination port—The number of the destination (port) for this segment.

data It is the number assigned to the first octet in the user data field

■ Code bits—The control functions (for example, setup and termination of a

session)

■ Window—The number of octets that the sender is willing to accept.

■ Urgent—Indicator of the end of the urgent data.

When using UDP, application layer protocols must provide for reliability if it is neces-sary UDP uses no windowing or acknowledgments It is designed for applications that

do not need to put sequences of segments together Figure 19-5 shows the UDP header

Figure 19-5 UDP Header Format

TCP Operation

IP addresses allow for the routing of packets between networks However, IP makes no guarantees about delivery The transport layer is responsible for the reliable transport and regulation of data flow from source to destination This reliability is accomplished

by using sliding windows, sequencing numbers, and a synchronization process that ensures each host is ready and willing to communicate, as shown in Figure 19-6

Figure 19-6 TCP Operation

Source Port (16) DestinationPort (16) Length (16) Checksum(16) Data(Variable)

I am busy now.

Send data slowly.

Hello!

How fast can

I send data?

To understand reliability and flow control, think of two people engaged in a

conversa-tion First, they meet and maybe shake hands to acknowledge to each other that a

con-versation is about to take place and information is about to be sent While they are

talking and exchanging information, if a word or phrase is inaudible or unreachable to

the other person, one person might simply ask the person to repeat their words (for

reliability) so he or she can catch the words (flow control) The transport layer, Layer 4

of the OSI model, provides these services to Layer 3 via TCP

Three-Way Handshake

TCP is a connection-oriented protocol Prior to data transmission the two

communi-cating hosts go through a synchronization process to establish a virtual connection

This synchronization process ensures that both sides are ready for data transmission

and enables the devices to determine the initial sequence numbers (ISNs) This process

is known as a three-way handshake.

Synchronization is accomplished by exchanging packets carrying the ISNs and a

con-trol bit called SYN, which stands for synchronize (Packets carrying the SYN bit are

also called SYNs.) Successful connection requires a suitable mechanism for choosing

an initial sequence and a slightly involved handshake to exchange the ISNs

Synchroni-zation requires that each side send its own ISN and receive a confirmation and ISN

from the other side of the connection

Each side must receive the other side’s ISN and send a confirming acknowledgment

(ACK) in a specific order A three-way handshake uses the following three-step process

to establish a virtual connection between the two devices:

1. One host initiates a connection by sending a SYN packet indicating its initial

sequence number of x with a certain bit in the header set to indicate a connection request This bit is set in the code field of the TCP header

2. The other host receives the packet, records the sequence number of x, replies

with an acknowledgment of x + 1, and includes its own initial sequence number

of y The acknowledgment number of x + 1 means the host has received all octets

up to and including x and is expecting x + 1 next

3. The initiating host responds with a simple acknowledgement (ACK) of y + 1 (the

sequence number of the second host + 1), indicating it received the previous ACK, which finalizes the connection process

Because the second and third steps are combined in a single message, the exchange is

called a three-way handshake/open connection As illustrated in Figure 19-7, both

ends of a connection are synchronized with a three-way handshake/open connection

sequence

Figure 19-7 Three-Way Handshake

It is important to understand that sequence numbers are a part of initiating communi-cation between the two devices Sequence numbers act as reference starting numbers between the two devices The sequence numbers give each host a way to ACK the SYN, so that the receiver knows the sender is responding to the proper connection request

A three-way handshake is necessary because TCPs might use different mechanisms for picking the ISN The receiver of the first SYN has no way of knowing if the segment was an old delayed one unless it remembers the last sequence number used on the con-nection, which is not always possible So, it must ask the sender to verify this SYN At this point, either side can begin communicating, and either side can break the commu-nication because TCP is a peer-to-peer (balanced) commucommu-nication method

Denial-of-Service Attacks During Synchronization

Denial-of-service (DoS) attacks are designed to deny services to legitimate hosts attempting to establish connections DoS attacks are a common method that hackers utilize to halt system response One type of DoS is known as SYN flooding, which occurs during the three-way handshake synchronization process utilized by TCP During the three-way handshake, the initiating host sends a SYN packet The SYN packet includes the source IP address and the destination IP address, just like any other packet The recipient uses this source and destination address information to send the SYN/ACK packet back to the initiating device

In a DoS attack, the hacker initiates a synchronization but falsifies the source IP address The receiving device replies to a non-existent, unreachable IP address and then is placed on hold while waiting to receive the final ACK from the initiator The waiting request is placed in a connection queue or a holding area in memory This waiting state requires the attacked device to commit system resources, such as memory,

HOST

Send SYN (seq = x)

Receive SYN (seq = y, ACK = x+1) Send ACK (ack = y+1)

Receive SYN (seq = x) Send SYN (seq = y, ACK = x+1) Receive ACK (ack = y+1)

to the waiting process until the connection timer times out Hackers flood the attacked

host with these false SYN requests, utilizing all of its connection resources to respond

and wait for bogus connections, preventing it from responding to legitimate

connec-tion requests

To defend against these attacks, administrators can decrease the connection timeout

period and increase the connection queue size Also, software is available that can

detect these types of attacks and initiate defensive measures Figure 19-8 shows a DoS

attack during synchronization

Figure 19-8 DoS Attack

Windowing and Window Size

In many instances, the amount of data that needs to be transmitted is too large to be

sent in a single data segment When this occurs, the data must be broken into smaller

pieces to allow for proper data transmission TCP is responsible for breaking data into

segments This process is similar to feeding a child Because most small children cannot

eat extremely large bites, the person feeding them often cuts their food into smaller

pieces that their mouths can accommodate Additionally, receiving machines might not

be able to receive data as quickly as the source can send data Sometimes discrepancy

exists because the receiving device is busy with other tasks; other times the sender is

simply a stronger device

After the data is segmented, it must be transmitted to the destination device One of the

services provided by TCP is flow control, which regulates how much data is sent

dur-ing a given transmission period The process of flow control is known as windowing

SYN SYN ACK ACK

SYN SYN ACK

SYN Flooding

SYN SYN ACK SYN

SYN ACK SYN

SYN ACK SYN

SYN ACK

Server

Server

Window size determines the amount of data that can be transmitted at one time before receiving an acknowledgment from the destination After a host transmits the window-sized number of bytes, the host must receive an acknowledgment that the data has been received before it can send any more messages For example, with a window size

of one, each individual segment must be acknowledged before the next segment can be sent as shown in Figure 19-9

Figure 19-9 Window Size of 1

TCP utilizes a sliding window when determining transmission size A sliding window enables devices to negotiate a window size to allow for more than one byte to be sent during a single transmission, as shown in Figure 19-10 This sliding window also enables the destination device to communicate with the source The destination device,

if it is incapable of dealing with that much data, can indicate a need to decrease the amount of data being sent Conversely, the destination device can instruct the source

to increase the amount of data being sent if it can process more data than is currently being sent

Send 1 Sender

Window Size = 1

Receiver

Receive ACK 2 Send 2

Receive 1 Send ACK 2

Receive 2 Send ACK 3 Receive ACK 3

Send 3

Receive ACK 4

Receive 3 Send ACK 4

Figure 19-10 Larger Window Size

Sequencing Numbers

TCP breaks data into segments The data segments are then transported from sender

to receiver Data transportation follows the synchronization process and the

negotia-tion of a window size that dictates the number of bytes that can be transmitted at once

The data segments being transmitted must be reassembled once all of the data is received

No guarantee exists that the data will arrive in the order that it was transmitted, so

TCP addresses this problem by using sequence numbers TCP applies sequence

num-bers to the data segments it is transmitting so that the receiver will be able to properly

reassemble the bytes in their original order Sequencing numbers indicate to the

desti-nation device the correct order in which to put the bytes when they are received

These sequencing numbers also act as reference numbers so that the receiver knows

if it has received all of the data and can identify the missing data pieces to the sender

so it can retransmit the missing data as shown in Figure 19-11 This feature offers

increased efficiency because the sender is required to retransmit only the missing

seg-ments instead of retransmitting the entire set of data

Send 1 Send 2 Send 3

Receive 1 Receive 2 Receive 3 Send ACK 4

Receive 4 Receive 5 Receive 6 Send ACK 7

Receive ACK 4 Send 4 Send 5 Send 6

Receive ACK 7

Window Size = 3

Figure 19-11 Sequence Acknowledgment Numbers

Each TCP segment is numbered before transmission Figure 19-4 from earlier in the chapter showed the TCP segment format Notice that the Sequence number portion follows the Destination port in the segment format At the receiving station, TCP uses the sequence numbers to reassemble the segments into a complete message If

a sequence number is missing in the series, that segment is retransmitted

Positive ACK

Acknowledgement is a common step in the synchronization process, sliding windows, and the sequencing of data In a TCP segment, the Sequence number field is followed

by the Acknowledgement field, also referred to as the Code field This field is where ACKs and SYNs are indicated

One problem with the unreliable IP protocol is that no verification method exists in it for determining that data segments actually reached their destination Therefore, data segments might be forwarded with no knowledge as to whether or not they were actu-ally received TCP utilizes positive acknowledgement and retransmission to control data flow and confirm data delivery

Positive acknowledgment and retransmission (PAR) is a common technique many pro-tocols use to provide reliability With PAR, the source sends a packet, starts a timer, and waits for an acknowledgment before sending the next packet If the timer expires before the source receives an acknowledgment, the source retransmits the packet and restarts the timer TCP uses expectant acknowledgments in which the acknowledgment number refers to the next octet that is expected

Windowing is a flow control mechanism During windowing, the source device is required to receive an acknowledgment from the destination after transmitting a cer-tain amount of data With a window size of three, the source device can send three

Receive #10.

Now send #11.

Here is #10.

1028 23 10 1

Source Des Seq Ack.

1028 23 11 2

Source Des Seq Ack 23 1028 1 11

Source Des Seq Ack.

Source Port Destination Port Sequence Number

Acknowledgment

octets to the destination It must then wait for an acknowledgment If the destination

receives the three octets, it sends an acknowledgment to the source device, which can

now transmit three more octets If the destination does not receive the three octets, due

to overflowing buffers or some other reason, it does not send an acknowledgment If

the source does not receive an acknowledgment, it knows that the octets must be

retransmitted and that the transmission rate should be slowed

UDP Operation

The TCP/IP protocol stack contains many different protocols, and each protocol is

designed to perform a specific task IP provides Layer 3 connectionless transport

through an internetwork TCP enables connection-oriented, reliable transmission of

packets at Layer 4 of the OSI model UDP provides connectionless, non-guaranteed

transmission of packets at Layer 4 of the OSI model

Both TCP and UDP use IP as their underlying Layer 3 protocol In addition, TCP and

UDP are used by various application layer protocols TCP provides services for

appli-cations such as FTP, HTTP, SMTP, and DNS UDP is the transport layer protocol used

by DNS, TFTP, SNMP, and DHCP Figure 19-12 illustrates the relationship between

TCP/IP application, transport, and network layer protocols

Figure 19-12 TCP/IP Application, Transport, and Network Layer Protocols

TCP must be used when applications need to guarantee that a packet arrives intact, in

sequence, and unduplicated However, the overhead associated with ensuring delivery

of the packet is sometimes a problem when using TCP Not all applications need to

guarantee delivery of the data packet, and therefore, some use the faster,

connection-less delivery mechanism offered by UDP The UDP standard, described in RFC 768, is

a simple protocol that exchanges segments without acknowledgments or guaranteed

FTP HTTP SMTP DNS DNS TFTP

IP

Internet YourLAN Many LANsand WANs

delivery As an example, TFTP can be used to transfer a configuration file or a Cisco IOS Software image from a TFTP server to a router on an Ethernet network TFTP uses the efficient UDP transport protocol because the quality of physical connections is usually very good and the acknowledgement and retransmission capabilities of TCP are not necessary

UDP does not use windowing or acknowledgments Therefore, application layer pro-tocols provide error detection UDP is designed for applications that do not need to put sequences of segments together

Figure 19-5 earlier in this chapter displayed the UDP segment format The Source Port field is an optional field, used only if information needs to return to the sending host The Destination Port field specifies the application to which UDP must pass the proto-col A DNS request from a host to a DNS server has a Destination Port field of 53,

th UDP port number for DNS The Length field identifies the number of octets in the UDP segment The UDP checksum is optional, but should be used to ensure that the data has not been damaged during transmission For transport across the network, UDP is encapsulated within the IP packet

After a UDP segment arrives at the destination IP address, a mechanism must exist that allows the receiving host to determine the destination application of the segment Ports are used for this purpose If a host is running both TFTP and DNS services, it must be able to determine what service the arriving UDP segments need The Destination Port field in the UDP header determines the application to which a UDP segment is delivered

Overview of Transport Layer Ports

Transport layer ports are 16-bit numbers used to identify the connection end points on either side of the connecting devices A particular network connection is then identified

by a four-part (source address, source port, destination address, destination port) sequence In principle, this scheme allows for unique UDP connections between any two hosts UDP is still connectionless and unreliable To support connection-oriented applications that require reliable, in-sequence data streams, TCP is used Like UDP, TCP also uses ports to identify connection endpoints

Multiple Conversations Between Hosts

At any given moment, thousands of packets providing hundreds of different services are traveling through a modern network In many cases, servers provide several differ-ent services simultaneously, which causes unique problems for the addressing of pack-ets For example, if a server is running both SMTP and World Wide Web services, a client cannot construct a packet destined for the IP address of the server just using TCP