TTL Security Mechanism uses the IP TTL field to bind a BGP session to the directly connected neighbor, so the router only accepts BGP TCP connections that come from a one-hop path. By configuring the session to require a TTL value of 1, any attempt to form a BGP session from a remote network (i.e., more than one hop away) is dropped, because the packet would have traversed at least one router and its TTL would not match the expected value. This significantly reduces the risk of remote spoofed connections where an attacker tries to impersonate a neighbor by forging the source IP to hijack or misrepresent routes. TTLS does not encrypt BGP updates, nor does it involve TTL proxies or a TTL-based path vector; its purpose is specifically to guard against spoofed, non-direct-neighbor session attempts by leveraging the hop-count constraint.

In BGP, three attributes are required in every route update because they provide essential, universally-needed information about how the route arrived and how to reach it. The AS_PATH lists the sequence of autonomous systems the route has traversed. This helps prevent routing loops and supports policy decisions because you can see the path the update took across the Internet. The NEXT_HOP tells you the IP address of the next router to reach the destination; without this, a router wouldn’t know where to forward the packets. The ORIGIN attribute indicates how the route was learned—whether from an internal IGP, an external EGP, or if the origin is incomplete—so a router can make informed decisions when comparing multiple paths. The other attributes mentioned—Local Preference, Atomic Aggregate, Community, and Aggregator—are useful for shaping routing policies and route handling, but they’re not required to be present on every update. Local Preference is a local policy knob within an AS, Atomic Aggregate and Aggregator relate to how routes are summarized or who performed aggregation, and Community is a tagging mechanism for policy purposes.

An Update message in BGP communicates changes to the routing table. It consists of three parts: Withdrawn Routes (prefixes to remove), Path Attributes (metadata like AS_PATH, NEXT_HOP, ORIGIN, etc.), and NLRI (the new or announced prefixes). Withdrawn Routes removes previously advertised paths, Path Attributes apply to the routes being announced, and NLRI lists the prefixes that are now reachable. The Version, Hold Time, and Router ID belong to the OPEN message, not Update, and an Update message is not just NLRI alone.

TCP-MD5 secures the BGP session by authenticating the underlying TCP connection with a shared secret. It adds an MD5-based hash to TCP segments so both peers can verify that the other side knows the secret, preventing unauthorized peers from establishing or hijacking the BGP session. It does not encrypt BGP messages or sign them at the application layer, so confidentiality and per-message integrity beyond the TCP connection aren’t provided by TCP-MD5 itself. Enable TCP-MD5 when the route between peers traverses untrusted networks or there is a higher risk of spoofing, such as across the public Internet or between operators with potential misconfigurations. Configuration requires sharing the same secret on both ends; if the secret mismatches or one side doesn’t support it, the session will fail to establish. In short, TCP-MD5 protects the integrity of the TCP session used by BGP, not the content of BGP messages themselves, and is most useful where the risk of spoofed TCP connections is nontrivial.