Many implementations send eBGP packets with a TTL of 1; why, what does multihop eBGP change, and what does GTSM check instead?

## Where the TTL of 1 comes from RFC 4271 does not specify a TTL for BGP packets. It distinguishes an external peer "one IP hop away" from one "multiple IP hops away (aka multihop EBGP)", and gives each its own `NEXT_HOP` rules. The TTL of 1 is an **implementation default** built on the first case: an eBGP neighbour usually sits on the other end of one link, so packets sent with TTL 1 reach it and go no farther. If the configured neighbour address is behind another router, the packets expire there and the session never forms. Implementations do not usually apply the same limit to iBGP, whose peers are often several routers apart. ## Multihop eBGP and loopback peering Two common reasons to peer eBGP beyond one hop: - **Parallel links.** AS 64500 and AS 64501 connect two routers with two links. Rather than two sessions, they run one session between loopbacks (`192.0.2.1` and `198.51.100.1`), each side holding a static route to the other's loopback over both links. Losing one link keeps the session up. - **A peer genuinely several hops away**, where the operators accept the wider exposure. What the session needs: 1. A route to the peer's loopback on each side, typically static, since the two ASes do not share an IGP. 2. The session sourced from the local loopback, so the peer sees the address it expects. 3. Permission to peer beyond one hop: a TTL larger than 1 or, between directly connected routers, relaxing the implementation's connected-subnet check described below. With multihop, `NEXT_HOP` by default is the address used for the session (RFC 4271 section 5.1.3, rule 3), here the loopback, which each side reaches through its static routes. One precise point: if the two routers are directly connected, a TTL-1 packet addressed to the neighbour's loopback actually arrives, because RFC 1812 section 4.2.2.9 says a router MUST NOT discard a datagram addressed to itself merely because its TTL is 1. In that case what blocks the session is usually an implementation's check that an eBGP peer address lies on a directly connected subnet, which implementations let you relax under various names. ## Why TTL 1 is weak protection Setting your outgoing TTL to 1 controls where **your** packets go. It says nothing about packets **arriving** at TCP port 179: an attacker many hops away can forge the peer's source address and still deliver segments that the router must process, such as SYN floods aimed at the control plane or attempts to reset the session. Multihop widens the reachable area further. ## GTSM: checking the arriving TTL The **Generalized TTL Security Mechanism** (RFC 5082) turns the field into an inbound check: - **Send:** every packet of a GTSM-enabled session MUST carry TTL **255**, the maximum, and that TTL MUST NOT be decremented on the way out. - **Receive:** each router on a path decrements TTL, so a packet from a directly connected peer arrives with 255, and RFC 5082 notes that engineering a TTL of 255 from a non-directly connected location is not possible, assuming the neighbours are not compromised and nothing is tunnelled. - **Classify:** packets for a GTSM session are *Trusted* when their TTL is in the expected range and *Dangerous* when not; how dangerous packets are treated is left configurable, typically dropped or given low priority. Its limits, from the RFC itself: - It SHOULD NOT be enabled by default for a protocol like BGP that did not build it in, so both peers must be configured to use it. - It "will not protect against attackers who are as close to the protected station as its legitimate peer", for example another device on the same link. - The RFC describes only the single-hop case; with multihop sessions the protection is "small, though difficult to quantify". - It does not authenticate anything. It filters by distance and is usually paired with authentication of the TCP session. ## Side by side | | Outgoing TTL 1 | Multihop eBGP | GTSM | |---|---|---|---| | Defined by | implementation default | named in RFC 4271, TTL set by implementation | RFC 5082 | | Checks inbound packets | no | no | yes, expects 255 | | Reaches a peer behind another router | no | yes | only with a widened range, weakly | | Needs both sides configured | no | yes | yes |