Day 45 — BGP TTL Security and GTSM

1. Opening

BGP peers exposed across routed infrastructure can receive spoofed packets that appear to target a valid session. GTSM uses the received TTL or Hop Limit as an additional plausibility check: legitimate packets from nearby peers should arrive with a value close to the maximum.

A session-engineering problem should be solved from the bottom up. Before modifying route policy, prove endpoint reachability, source address, TCP behavior, TTL/security controls, authentication and negotiated BGP parameters. An Established session is the result of all of those layers agreeing.

2. Concept and standards behavior

RFC 5082 standardizes GTSM and explicitly states that it is not a substitute for authentication. For BGP, speakers send with a high TTL and reject packets whose received TTL indicates they originated farther away than the configured hop allowance. This raises the difficulty of off-path spoofing from distant sources.

The engineering boundary matters: RFC behavior defines interoperable protocol rules, while dynamic-neighbor syntax, password configuration, peer templates and some security commands are implementation-specific. Exact syntax and feature support must therefore be verified on the actual IOS XE platform and release used in the lab or production network.

3. Scenario

Two eBGP loopback peers are separated by one routed hop. Configure a GTSM/TTL-security allowance appropriate to the lab topology and verify the real peer is accepted while a simulated farther source fails the TTL check.

Success criteria

1. The intended TCP endpoints and source addresses are explicit.
2. BGP reaches Established without weakening unrelated security controls.
3. Negotiated capabilities match the required address families/features.
4. A negative test proves an unauthorized or incorrectly formed session fails.
5. Rollback returns the neighbor relationship to the captured baseline.

4. Topology diagram

A matching editable SVG and PNG are stored under media/diagrams/.

5. Prerequisites

• Cisco IOS XE 17.18.x documentation baseline.
• Documentation-safe IPv4 addressing only.
• Stable underlay reachability before BGP troubleshooting.
• Independent management access.
• Time synchronization and logging for authentication/failure analysis.
• Pre-change capture of neighbor state and relevant TCP/BGP diagnostics.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

router bgp 65010
 neighbor 192.0.2.20 remote-as 65020
 neighbor 192.0.2.20 update-source Loopback0
 ! Apply the exact IOS XE TTL-security command supported
 ! by the lab platform after verifying release syntax.

Any authentication secret shown in a lab must be a non-production placeholder. Never copy a tutorial key into production.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors
show tcp brief all
show ip route
show logging

When the session does not reach Established, identify the last successful layer: IP reachability, TCP establishment, BGP OPEN exchange, capability negotiation, or post-OPEN KEEPALIVE.

8. Controlled modification

Replace a permissive multihop-only design with a validated TTL-security configuration. Verify the legitimate peer remains Established.

Capture the expected state transition before changing configuration. If the modification is expected to reset the TCP session, state that explicitly and preserve logs.

9. Fault injection

Illustrative lab — not a real incident.

Increase the routed path length beyond the permitted hop allowance without changing the GTSM setting. The session should fail the TTL plausibility expectation even though IP reachability may remain.

Inject only one fault at a time. A failed session is useful evidence only if the experiment can identify which layer rejected it.

10. Step-by-step troubleshooting

1. Confirm the configured neighbor address or dynamic range.
2. Confirm local and remote source addresses.
3. Verify a valid route exists to the remote endpoint.
4. Verify return-path reachability.
5. Inspect TCP state and port 179 behavior.
6. Validate TTL, multihop and GTSM assumptions.
7. Validate authentication configuration and key-selection state where used.
8. Inspect BGP FSM state.
9. Inspect OPEN message parameters and negotiated capabilities.
10. Read the NOTIFICATION/error evidence rather than repeatedly clearing the session.
11. Correct the smallest proven cause.
12. Re-run both positive and negative tests.

11. Root cause and correction

The configured hop allowance no longer matches the routed path. Correct either the path/design or the GTSM allowance; do not disable the security control as the first fix.

12. Post-fix verification

Confirm TCP stability, BGP Established state, expected AFI/SAFI activation, route exchange, absence of recurring NOTIFICATION messages, and intended rejection of the negative test.

13. Rollback

Restore the exact prior neighbor/session configuration. Authentication or TTL changes need a synchronized rollback plan on both peers. Roll back if the session cannot be restored within the approved change window, if another peer is affected, or if the security posture is weakened beyond the approved design.

14. Deep-dive engineering notes

Received TTL is evidence

GTSM relies on the fact that routers decrement TTL. A legitimate nearby peer begins with a high TTL, so the receiver expects a correspondingly high remaining value.

Security limitations

An attacker located on-path or sufficiently close can still satisfy the TTL test. RFC 5082 therefore warns that GTSM does not replace cryptographic authentication.

Operations

Routing changes can increase hop count and unexpectedly break a tightly configured GTSM policy. Monitor topology changes when using strict hop allowances across changing underlays.

IPv6

The same principle applies to IPv6 Hop Limit in supported implementations, but exact syntax and support must be checked on the chosen platform.

15. Production lessons

• Treat transport, security and BGP negotiation as separate diagnostic layers.
• Never weaken authentication or TTL controls merely to force Established state.
• Feature support is platform/release specific; standards support does not guarantee identical CLI support.
• Capture negative tests as part of session acceptance.
• Document which side initiates, what source address is expected, and what capabilities are required.

16. Knowledge check

1. Why can successful IP reachability coexist with a failed BGP session?
2. Which evidence distinguishes TCP failure from an OPEN/capability failure?
3. Why is temporarily removing authentication a poor troubleshooting default?

Answers

1. Reachability proves only IP forwarding; TCP, TTL controls, authentication, FSM parameters and capabilities can still fail.
2. TCP state plus BGP neighbor/error/NOTIFICATION evidence.
3. It changes the security boundary and can hide the actual mismatch instead of proving it.

17. Sources

• RFC 5082 — Generalized TTL Security Mechanism (GTSM)
• RFC 7454 — BGP Operations and Security
• Cisco IOS XE 17.x BGP security/configuration guidance