An election office wants to harden eBGP sessions to external ISPs against multihop spoofed BGP packets. Which mechanism fits?
Select an answer to reveal the explanation.
Short Explanation
TTL security is checking that the BGP packet still has nearly a full hop count—meaning it didn’t wander in from across the Internet pretending to be your ISP. Direct peers pass; random multihop spoofs fail the TTL test.
Full Explanation
Generalized TTL Security Mechanism (GTSM), also called BGP TTL security, expects eBGP packets to arrive with a TTL near 255 for directly connected peers, causing multihop spoofed packets to fail the check. An election office that wants to harden eBGP sessions to external ISPs against multihop spoofed BGP packets should enable GTSM/TTL security so packets must arrive with an expected high TTL from a directly adjacent peer. GTSM complements—not replaces—TCP Authentication Option or MD5 and other control-plane protections on civic ISP edges.
Disabling TCP MD5/AO so TTL checks alone authenticate the peer weakens session security rather than hardening it. Setting eBGP multihop TTL to 255 on both sides without matching GTSM hop-count expectations can be inconsistent with directly connected security assumptions. Relying on OSPF Hello authentication to protect the eBGP TCP port confuses IGP adjacency authentication with BGP TCP session protection.
Exam caveat: GTSM fits directly connected eBGP best; multihop eBGP needs carefully matched TTL or hop-count allowances if GTSM is used at all. Operational check: enable TTL security on ISP-facing sessions, confirm sessions stay up, verify spoofed multihop packets would be dropped, and keep TCP AO or MD5 enabled as complementary authentication.