Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"
Extracted elements (25)
The failover mechanism is designed as a middle path between full active-standby state mirroring and complete tunnel re-establishment. Full mirroring adds significant performance and complexity overhead; full re-establishment increases service loss time as scale grows. The protocol recovers only the volatile stateful information (sequence numbers) that is hardest to reconstruct.
The Tie Breaker AVP scope for recovery tunnels is intentionally restricted to recovery tunnels for the same old tunnel being recovered, and must not affect non-recovery tunnels or recovery tunnels for other old tunnels. This scoping prevents a race condition where simultaneous failover by both peers would otherwise establish duplicate recovery tunnels.
For L2TPv3 recovered tunnels, the nonce values used for Control Message authentication MUST be reset to those exchanged during the recovery tunnel handshake, ensuring the recovered tunnel's authentication context is consistent between endpoints and not stale from the pre-failure connection.
When a session ID mismatch exists (e.g., Sid=A paired with Remote=B on one side, but B paired with C on the other), clearing the local session immediately upon receiving a mismatched FSR could leave its counterpart stale. The protocol instead marks the session stale and generates a subsequent FSQ to allow the peer to discover and clear its end, as illustrated in Appendix C.
After the recovery tunnel is established, sessions not in an established state MUST be silently cleared (without sending CDN) by each endpoint. An FSQ message MUST include at least one FSS AVP. Before session synchronization completes, if an endpoint receives an ICRQ for an already-established session, it MUST respond with a CDN.
An endpoint MUST NOT use any old Tunnel ID for the recovery tunnel; old tunnels MUST remain valid until the recovery process concludes. The endpoint MUST use the Tie Breaker AVP in recovery tunnel setup to ensure only a single recovery tunnel is established when both endpoints attempt simultaneous failover.
An endpoint MUST terminate the recovery tunnel if the Recover Tunnel ID or Recover Remote Tunnel ID is unknown, if the prior endpoint had not indicated failover capability, or if the L2TP version of the recovery tunnel differs from the old tunnel.
An LCCE MUST follow L2TPv2 or L2TPv3 procedures to establish a recovery tunnel, and the recovery tunnel MUST use the same L2TP version and establishment procedures that were used for the old tunnel being recovered.
Any control packet received on the recovered tunnel before control channel reset MUST be silently discarded. An endpoint MUST prevent the establishment of new sessions until non-established sessions have been silently cleared (Step I of Section 3.3).
During data channel reset, if an endpoint receives 'n' out-of-order but in-sequence packets, it MUST set the Nr value based on the Ns value of incoming packets as suggested in Appendix C of L2TPv3. If an endpoint lacks the D-bit capability, data channels using sequence numbers are non-recoverable and SHOULD be torn down via CDN.
If the recovery endpoint did not receive the Suggested Control Sequence (SCS) AVP in the SCCRP, it MUST reset Ns and Nr values to zero. If the remote endpoint chose not to send the SCS AVP, it MUST also reset its Ns and Nr values to zero on the recovered tunnel.
The SCCRQ for a recovery tunnel MUST include the Tunnel Recovery AVP to identify the old tunnel being recovered, and MUST NOT include the Failover Capability AVP in its SCCRQ or SCCRP messages.
To authenticate a peer during recovery tunnel establishment, an endpoint MUST use the same shared secret that authenticated the old tunnel, following L2TPv2 Section 5.1.1 or L2TPv3 Section 4.3 procedures. If recovery tunnel establishment fails for any reason, the endpoint MUST silently clear the old tunnel and all sessions within it.
When an endpoint receives an FSQ message, it MUST include an FSS AVP in the FSR for each FSS AVP in the FSQ. When responding, if an FSS AVP is invalid (session non-existing or paired with a different remote Session ID), the Session ID field in the FSR FSS AVP MUST be set to zero.
The Failover Session Query (FSQ) control message (Vendor ID 0, Attribute Type 21) is used to query session state from a peer. It MUST contain Message Type and at least one Failover Session State AVP; the M-bit on the Message Type AVP MUST be set to 0.
The Failover Session Response (FSR) control message (Vendor ID 0, Attribute Type 22) is sent in response to an FSQ message. It MUST contain Message Type and Failover Session State AVPs; one FSR may respond to multiple FSQs, or multiple FSRs may respond to one FSQ. The M-bit on the Message Type AVP MUST be set to 0.
This document assigns four Control Message Attribute Value Pair types from the L2TPv3 IANA registry: Failover Capability (76), Tunnel Recovery (77), Suggested Control Sequence (78), and Failover Session State (79).
This document assigns two Message Type (Attribute Type 0) values from the L2TPv3 IANA registry: Failover Session Query (21) and Failover Session Response (22).
A spoofed SCCRQ with a Tunnel Recovery AVP can cause control channel termination if the authentication measures from Section 3.2.1 are not applied. Even with authentication, an attacker can enumerate operational tunnel IDs via repeated spoofed failover requests that fail authentication, with success probability 1/(2^16-1) for L2TPv2 and 1/(2^32-1) for L2TPv3.
If the Suggested Control Sequence AVP is not used during failover, sequence numbers reset to zero, making the receive window predictable and increasing susceptibility to control message injection. As a mitigation, endpoints may be configured with an allowlist of permitted recovery endpoint addresses.
The failover protocol operates in three sequential phases: (1) Failover Capability Negotiation during normal tunnel setup, (2) Failover Recovery triggered by control channel failure (recovery tunnel establishment, control channel reset, data channel reset), and (3) Session State Synchronization using FSQ/FSR messages to reconcile inconsistent session states.
The Failover Capability AVP (Attribute Type 76) is a 12-byte AVP containing a Vendor ID field (0), two flag bits (C for control channel recovery, D for data channel Nr-reset capability), and a 32-bit Recovery Time field in milliseconds. The M-bit MUST be 0; the H-bit MAY be set.
The Failover Session State AVP (Attribute Type 79) carries a Session ID and Remote Session ID, each 32 bits for L2TPv3 or 16 bits with Reserved prefix for L2TPv2. The M-bit is 1 (mandatory) and it MAY be hidden. It MUST only appear in FSQ and FSR messages.
The Suggested Control Sequence AVP (Attribute Type 78) carries a 16-bit Suggested Ns and 16-bit Suggested Nr field. It is optional (M-bit = 0) and MAY be hidden. When present in an SCCRP during recovery tunnel establishment, the recovery endpoint MUST adopt these Ns/Nr values for the recovered tunnel.
The Tunnel Recovery AVP (Attribute Type 77) carries a Recover Tunnel ID and Recover Remote Tunnel ID, each 32 bits for L2TPv3 and 16 bits (with Reserved prefix) for L2TPv2. The H-bit MUST be 0 and the M-bit MUST be 1 (mandatory). This AVP MUST appear only in SCCRQ messages establishing a recovery tunnel.