Skip to main content

9. Security Considerations

The L2TP protocol itself does not provide encryption or strong authentication services. This chapter discusses security considerations in L2TP deployments and available security mechanisms.

9.1 Tunnel Endpoint Security​

The trust relationship between tunnel endpoints is fundamental to L2TP security.

Endpoint Authentication:

LAC and LNS must be able to verify each other's identity. L2TP provides an optional tunnel authentication mechanism:

  • Challenge AVP: The initiator sends a random challenge value in the SCCRQ (Start-Control-Connection-Request).
  • Challenge Response AVP: The responder calculates a response based on a shared secret and returns it in the SCCRP (Start-Control-Connection-Reply).
  • Response Calculation: Uses MD5 hash function: MD5(Message Type + shared_secret + Challenge + Session_ID)

Shared Secret Management:

  • Shared secrets should have sufficient entropy (at least 128 bits recommended).
  • Shared secrets should be stored securely (encrypted storage).
  • Shared secrets should be rotated periodically.
  • Different tunnel pairs should use different shared secrets.

Tunnel Authorization:

In addition to authentication, authorization mechanisms should be implemented:

  • Verify that the peer is allowed to establish a tunnel.
  • Check if the peer has permission to access specific resources or services.
  • Use Access Control Lists (ACLs) to restrict which peers can establish tunnels.

Vulnerabilities and Mitigations:

  1. Man-in-the-Middle Attack:

    • Risk: L2TP tunnel authentication based on shared secrets is vulnerable to MITM attacks.
    • Mitigation: Use IPsec to provide end-to-end encryption and authentication.

  2. Replay Attack:

    • Risk: Attackers may replay captured control messages.
    • Mitigation: Use sequence numbers and ZLB ACK mechanisms to detect and prevent replay attacks.

  3. Denial of Service Attack:

    • Risk: Attackers may send large numbers of tunnel establishment requests.
    • Mitigation:
      • Limit the number of concurrent tunnels per source address.
      • Implement rate limiting.
      • Use Cookie mechanisms (similar to TCP SYN Cookies).

9.2 Packet Level Security​

L2TP itself does not provide packet encryption or integrity protection.

Risks of Cleartext Transmission:

  • Eavesdropping: Attackers can intercept and read PPP packet contents, including user credentials and application data.
  • Tampering: Attackers can modify packets in transit.
  • Injection: Attackers can inject malicious packets into the tunnel.

AVP Hiding Mechanism:

L2TP provides an AVP hiding mechanism to protect sensitive control information:

  • Hiding Process:

    1. Generate MD5 hash using shared secret and Random Vector.
    2. XOR the hash value with the AVP value.
    3. Repeat the process if the AVP value exceeds 16 bytes.

  • Limitations:

    • AVP hiding is obfuscation, not true encryption.
    • Does not protect the data channel, only specific AVPs in the control channel.
    • Vulnerable to dictionary attacks (if the shared secret is weak).

Recommendations:

  • Do not rely on AVP hiding as the sole security mechanism.
  • Use IPsec or other tunnel-level encryption technologies.

9.3 End to End Security​

Even when the L2TP tunnel itself is protected, end-to-end security remains important.

PPP-Level Authentication:

Independent authentication should occur between the remote system and LNS:

  • PAP (Password Authentication Protocol):

    • Simple cleartext password authentication.
    • Not recommended, as passwords are transmitted in cleartext (should be avoided even inside encrypted L2TP tunnels).

  • CHAP (Challenge Handshake Authentication Protocol):

    • Challenge-response authentication mechanism.
    • Passwords are not transmitted in cleartext.
    • Periodic re-authentication to prevent replay attacks.

  • EAP (Extensible Authentication Protocol):

    • Supports various authentication methods (EAP-TLS, EAP-TTLS, PEAP, etc.).
    • Can provide mutual authentication and key negotiation.
    • EAP-TLS is recommended for the strongest security.

End-to-End Encryption:

Application-layer encryption provides an additional security layer:

  • TLS/SSL: Used to protect application data (e.g., HTTPS).
  • VPN Client Software: Provides additional encryption layer on top of PPP.

Defense in Depth Strategy:

Remote System <--PPP Auth/Encrypt--> LNS
    |                                  |
    +--<L2TP Tunnel>--LAC-------------+
              |
         <IPsec Protection>
  • Layer 1: PPP-level authentication (CHAP/EAP)
  • Layer 2: L2TP tunnel authentication
  • Layer 3: IPsec encryption and authentication
  • Layer 4: Application-layer encryption (TLS/SSL)

9.4 L2TP and IPsec​

It is strongly recommended to use L2TP in combination with IPsec, commonly referred to as L2TP/IPsec.

Security Services Provided by IPsec:

  1. Confidentiality:

    • Provided through ESP (Encapsulating Security Payload) encryption.
    • Supports multiple encryption algorithms: AES, 3DES, ChaCha20, etc.

  2. Integrity:

    • Provided through AH (Authentication Header) or ESP authentication.
    • Uses HMAC (e.g., HMAC-SHA256) to verify data integrity.

  3. Source Authentication:

    • Verifies the authenticity of packet sources.
    • Prevents IP spoofing attacks.

  4. Anti-Replay:

    • Uses sequence numbers to prevent replay attacks.

L2TP/IPsec Architecture:

+-------------------+
|   PPP Payload     |
+-------------------+
|   L2TP Header     |
+-------------------+
|   UDP Header      |
+-------------------+
|   ESP Header      | <-- IPsec Encryption and Authentication
+-------------------+
|   IP Header       |
+-------------------+

IPsec Configuration Options:

  • Transport Mode:

    • Only encrypts and authenticates the IP payload.
    • Suitable for end-to-end communication.
    • Recommended for L2TP/IPsec.

  • Tunnel Mode:

    • Encrypts and authenticates the entire IP packet.
    • Adds a new outer IP header.
    • Suitable for gateway-to-gateway communication.

Key Management:

  • IKE (Internet Key Exchange):

    • IKEv1: Original version, two-phase negotiation.
    • IKEv2: Improved version, more streamlined and efficient.
    • IKEv2 is recommended for key negotiation.

  • Pre-Shared Key vs Certificates:

    • Pre-Shared Key (PSK): Simple to configure, but difficult to distribute keys.
    • Certificates: More secure, supports large-scale deployments, strongly recommended.

NAT Traversal (NAT-T):

When L2TP/IPsec needs to traverse NAT devices:

  • Use UDP encapsulation of ESP (UDP port 4500).
  • Send periodic NAT keepalive packets.
  • IKEv2 has built-in NAT-T support.

Performance Considerations:

  • IPsec encryption adds CPU overhead.
  • Consider using hardware acceleration (AES-NI, etc.).
  • MTU reduction must be considered (ESP header + ESP trailer + authentication data).

9.5 Proxy PPP Authentication​

L2TP allows the LAC to perform initial PPP authentication on behalf of the LNS.

Proxy Authentication Mechanism:

The LAC can negotiate LCP and perform authentication with the remote system before forwarding the call to the LNS:

  1. LAC Performs PPP Authentication:

    • LAC negotiates LCP with the remote system.
    • LAC performs PAP or CHAP authentication.
    • LAC collects authentication information (username, password hash, etc.).

  2. LAC Forwards Authentication Information to LNS:

    • Uses proxy AVPs to pass authentication information:
      • Proxy Authen Type AVP (29): Authentication type (PAP, CHAP, etc.)
      • Proxy Authen Name AVP (30): Username
      • Proxy Authen Challenge AVP (31): CHAP challenge value
      • Proxy Authen Response AVP (33): Authentication response

  3. LNS Verifies Authentication Information:

    • LNS verifies the user based on information provided by the LAC.
    • LNS can accept or reject the session.

Security Risks:

  1. LAC Compromise:

    • If the LAC is compromised, attackers can obtain user credentials.
    • Mitigation: Use IPsec to protect communication between LAC and LNS.

  2. Cleartext Password Transmission:

    • PAP passwords are transmitted in cleartext from LAC to LNS (in AVPs).
    • Mitigation: Use AVP hiding mechanism or IPsec encryption.

  3. Trust Boundary:

    • LNS must fully trust the authentication information provided by the LAC.
    • A malicious LAC can forge authentication information.
    • Mitigation:
      • Only use proxy authentication between trusted management domains.
      • Consider requiring end-to-end re-authentication.

Best Practices:

  1. Avoid Proxy PAP Authentication:

    • PAP passwords are vulnerable to attacks even when hidden.
    • If it must be used, ensure IPsec protection.

  2. Prefer End-to-End Authentication:

    • Let the remote system authenticate directly with the LNS (without proxy).
    • Use EAP methods for stronger security.

  3. Limit Proxy Authentication Use Cases:

    • Only use when necessary (e.g., fast call establishment).
    • Use in trusted network environments.

  4. Combine Multiple Authentication Methods:

    • LAC performs preliminary authentication (for quick filtering).
    • LNS performs secondary authentication (end-to-end verification).

Proxy Authentication with RADIUS Integration:

Remote System <--PAP/CHAP--> LAC <--RADIUS--> RADIUS Server
                              |
                              |
                              v
                        (Forward Auth Info)
                              |
                              v
                             LNS <--RADIUS--> RADIUS Server
  • LAC can use RADIUS to verify user credentials.
  • LNS can also independently verify using RADIUS.
  • Double verification provides an additional security layer.

Security Configuration Checklist:

  • Use IPsec between LAC and LNS
  • Use strong shared secrets or certificates for tunnel authentication
  • Use unique shared secrets for each tunnel pair
  • Enable PPP-level authentication (CHAP or EAP)
  • Avoid using PAP authentication
  • Rotate shared secrets periodically
  • Implement access control lists to restrict tunnel establishment
  • Enable logging and monitoring
  • Deploy intrusion detection systems (IDS)
  • Conduct regular security audits and penetration testing
Last updated on