Theoretical foundations and architecture

The lessons on VPN isolation and control-plane protection answer "what to close", while this one covers the four mechanisms that close it at the operator edge. The TTL propagation mode decides whether a customer sees the addresses of P routers in traceroute and how an ICMP time-exceeded reaches the source through an LSP. uRPF (RFC 3704, BCP 84) drops packets with a spoofed source address: strict mode suits customers and loose mode suits links to several providers, while a default route easily makes the check meaningless. GTSM (RFC 5082) accepts only packets with TTL 255 from a directly connected neighbor and cuts off a remote attack on eBGP and LDP sessions. Finally, authentication: TCP-AO (RFC 5925) instead of the weak MD5, HMAC keys for OSPF and IS-IS, LDP passwords, and key rotation without session resets with the typical traps around clocks and lifetimes. The lesson assumes that you have already covered VPN isolation, CoPP and BGP filtering and want to bring the protection to an operational level.

TTL in MPLS: two modes and their price

An MPLS label carries its own 8-bit TTL, and the ingress chooses its value when it pushes the label. In uniform mode (RFC 3443) the label TTL is copied from the IP, decremented at every hop and copied back at the exit (checking that the value does not grow): the core is visible in traceroute and the customer gets a single counter. In pipe mode (on Cisco no mpls ip propagate-ttl, on Junos no-propagate-ttl, on Huawei undo ttl propagate) the label gets TTL 255, the IP TTL is not decremented in the core and at the exit it is decremented by only 1 hop; the core is invisible to the customer. This hides the addressing of P routers (fewer targets for attacks and scanning, core addresses do not leak into traces) but complicates diagnosis at the customer: traceroute shows PE1 and PE2 as neighbors. On Cisco the forwarded variant hides only transit traffic, while traffic originated locally by the operator stays in uniform mode, so a traceroute from the PE itself still shows the core.

Consequences for diagnosis. When the label TTL expires on a P router it builds an ICMP time-exceeded, but the P has no route into the private address space of the customer: the message is sent further along the same LSP, reaches the egress PE and returns to the source only from there (RFC 3032, ICMP tunneling). The RTT of all hops inside the core therefore equals the RTT to the egress, and a problem segment cannot be found by hop delays. If the core is visible, a traceroute that supports RFC 4950 additionally shows the label stack from the ICMP extension, including VPN labels: in normal operation you must decide whether you are ready to show them to customers. For internal diagnosis the operator has LSP ping/traceroute (RFC 8029), which works regardless of the TTL mode. With a routing loop in pipe mode a packet with label TTL 255 circulates for up to 255 hops, so loop protection is provided by the protocols and not by the TTL.

uRPF: strict, loose, feasible paths

Reverse Path Forwarding (RFC 3704, BCP 84) checks the packet source address on ingress. Strict mode: the best route to the source must lead through the interface the packet arrived on. It suits customer interfaces with symmetric routing. Loose mode (Cisco reachable-via any, Junos mode loose): any route to the source in the FIB is enough, so only addresses without a route are dropped (bogons, unannounced space). Feasible path (RFC 3704 section 2.4): the check admits any route to the source from the RIB, even a non-best one; this suits multihoming when customer traffic may arrive over the backup link too (on Junos forwarding-table unicast-reverse-path feasible-paths). The practical choice: single-link customers - strict; customers with several links and BGP - feasible or loose plus an ACL; provider and IXP links - loose plus an ACL for bogon prefixes (RFC 6890).

Traps. The default route: if the FIB has 0.0.0.0/0, any source address has a "route" and loose mode passes everything. That is why by default the default route is not counted in the check (Cisco allow-default includes it deliberately, Huawei allow-default-route), and where a default is needed on the customer it makes the check useless: on such interfaces strict mode works only when the default does not point to that interface. Asymmetry: if customer traffic leaves over one link and returns over another, strict mode drops legitimate traffic. ECMP: with several equal paths strict mode must accept any of them (platforms differ). VRF: the check is done against the FIB of that VRF, so for a customer interface in a VRF the customer routes must be in its VRF and routes imported from other VRFs must not widen the permitted set. Counters: count the dropped packets per interface, otherwise you will not see that the check breaks legitimate traffic.

GTSM (RFC 5082)

The Generalized TTL Security Mechanism uses the fact that TTL is decremented at every router. The sender sends packets with TTL 255, and the receiver accepts them only if the TTL is not lower than 255 minus the number of permitted hops plus 1: with hops 1 only 255 is accepted, that is a packet from a directly connected neighbor. An attacker in another network cannot send a packet that arrives with TTL 255. The check is done before TCP parsing and is therefore cheaper than cryptography: out-of-range packets are dropped before they spend CPU resources (ideally in hardware). Scope: eBGP between directly connected nodes (Cisco neighbor ... ttl-security hops 1, Huawei valid-ttl-hops), LDP (RFC 6720), OSPF and other protocols on one-hop adjacency. Limitations: GTSM is incompatible with ebgp-multihop (one of the two is used), does not protect against an attacker on the link itself (a shared segment, an IXP), does not work through tunnels and MPLS with TTL decrement, and for eBGP via loopbacks needs hops equal to the hop count. It protects against remote attacks and does not replace authentication.