Which of the following protocols is not vulnerable to address spoofing attacks if implemented correctly?

Address spoofingfakes a source address (e.g., IP, MAC) to impersonate or amplify attacks. Analyzing protocol resilience:

C. TCP (Transmission Control Protocol):

Mechanism: Three-way handshake (SYN, SYN-ACK, ACK) verifies both endpoints.

Client SYN (Seq=X), Server SYN-ACK (Seq=Y, Ack=X+1), Client ACK (Ack=Y+1).

Spoofing Resistance: Spoofer must predict the server’s sequence number (randomized in modern stacks) and receive SYN-ACK, impractical without session hijacking or MITM.

Correct Implementation: RFC 793-compliant, with anti-spoofing (e.g., Linux tcp_syncookies).

A. UDP:

Connectionless (RFC 768), no handshake. Spoofed packets (e.g., source IP 1.2.3.4) are accepted if port is open, enabling reflection attacks (e.g., DNS amplification).

B. ARP (Address Resolution Protocol):

No authentication (RFC 826). Spoofed ARP replies (e.g., fake MAC for gateway IP) poison caches, enabling MITM (e.g., arpspoof).

D. IP:

No inherent validation at Layer 3 (RFC 791). Spoofed source IPs pass unless filtered (e.g., ingress filtering, RFC 2827).

Security Implications:TCP’s handshake makes spoofing harder, though not impossible (e.g., blind spoofing with sequence prediction, mitigated since BSD 4.4). CNSP likely contrasts this with UDP/IP’s vulnerabilities in DDoS contexts.

Why other options are incorrect:

A, B, D:Lack handshake or authentication, inherently spoofable.

Real-World Context:TCP spoofing was viable pre-1990s (e.g., Mitnick attack); modern randomization thwarts it.References:CNSP Official Documentation (Protocol Security); RFC 793 (TCP), RFC 2827 (BCP 38).