Address spoofing fakes 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.