Softwire Security Analysis and Requirements
Extracted elements (31)
EAP SHOULD be used (instead of pre-shared keys or certificates alone) in nomadic cases requiring both machine and user authentication, because pre-shared keys and certificates only support machine authentication and cannot segregate traffic per user.
IKEv2 is preferred over IKEv1 because it is more reliable (better replay-protection and DoS-protection mechanisms), integrates NAT-traversal natively, and supports EAP authentication enabling user-level (not just machine-level) authentication for nomadic scenarios.
Pre-shared keys for IPsec authentication are acceptable only when the number of SI and SC nodes is small; as scale grows, certificate-based authentication is preferred because group pre-shared keys are vulnerable to MITM attacks and per-pair key management becomes unmanageable.
RFC 3193 (Securing L2TP using IPsec) MUST be supported for time-to-market deployments; however, new implementations SHOULD use IKEv2 (RFC 4306) instead of IKEv1 (RFC 2409). Appendix A provides legacy SPD examples for IKEv1-based deployments.
When ESP transport mode is used, the UDP header carrying L2TP will have an incorrect checksum after NAT address translation. The recommended fix is the 'do not check' approach (option 3 of RFC 3948) rather than incremental update, since IKEv2 lacks the NAT-OA payload required for the latter.
A softwire concentrator SHOULD NOT change its IP address or port number in the SCCRP response; if an address change is required (e.g., for load balancing), a new IKE_SA and CHILD_SA MUST be established to the new IP address.
A softwire implementation MUST NOT use the 'incremental update of checksum' option (option 1 of RFC 3948) because IKEv2 does not have the NAT-OA payload information required to compute that checksum.
All softwire-security-compliant implementations MUST implement IPsec ESP (RFC 4303) in transport mode and MUST support IKE (RFC 4306) for authentication, SA negotiation, and key management.
Authentication with binding between the legitimate address and the authenticated identity MUST be implemented (e.g., via IPsec between SC and SI) to provide protection against address spoofing.
For dynamic softwire mesh IPsec tunnel creation, automated key distribution MUST be performed by IKEv2 (RFC 4306) with either pre-shared key or public key management.
For softwire control packets, authentication, integrity, and replay protection MUST be supported; confidentiality SHOULD be supported. For data packets, authentication, integrity, and replay protection SHOULD be supported; confidentiality MAY be supported.
For the softwire mesh data plane, softwire MUST support IPsec tunnel; the implementation MUST support ESP with null encryption (RFC 4303) or AH (RFC 4302). If no PKI is available, the IPsec Tunnel Authentication sub-TLV (RFC 5566) MUST be used before SA establishment.
Group pre-shared keys MUST NOT be used in IPsec because of their vulnerability to man-in-the-middle attacks; whenever possible, authentication with certificates is preferred.
In Case 2 (nomadic SI through visited access network), authentication from SI to SC MUST be performed together with that from SC to SI, i.e., mutual authentication is required.
L2TPv2 tunnel authentication MUST NOT be used unprotected on a public IP network, subject to the same restriction as PPP CHAP.
New softwire implementations SHOULD use IKEv2 as the key management protocol for IPsec because it is more reliable than IKEv1 and integrates required protocols into a single platform.
PPP CHAP authentication MUST NOT be used unprotected on a public IP network since it does not provide per-packet authentication, integrity, or replay protection.
Softwire MUST support mutual authentication so that the SI can verify the identity of the SC when connecting through a public network.
The softwire security protocol MUST support NAT traversal; UDP encapsulation of IPsec ESP packets (RFC 3948) and negotiation of NAT-traversal in IKE (RFC 3947) MUST be supported when IPsec is used.
The softwire security protocol MUST support: protection of control messages against eavesdropping and spoofing; replay attack protection; device-identifier protection; authenticated-session-to-device binding; and protection of disconnect/revocation messages.
The visited AAA server MUST have a trust relationship with the home AAA server and the communication between them MUST be secured in order to properly perform agreed roaming services.
When L2TPv2 is used in an unprotected network it MUST be protected by an appropriate security protocol such as IPsec as described in RFC 3193.
In the mesh solution, BGP is used to exchange softwire encapsulation sets and routing information among AFBRs. TCP-MD5 (RFC 2385) is the baseline BGP authentication mechanism; IPsec ESP may additionally be used for confidentiality and integrity of BGP sessions.
L2TPv2 is used in the Hubs and Spokes solution in a voluntary tunnel model only. The SI acts as an L2TP Access Concentrator (LAC) and PPP endpoint; the L2TPv2 tunnel is always initiated from the SI.
Three deployment cases are defined: Case 1 (SI connects to SC via home access network under same administrative domain), Case 2 (nomadic SI connects to home SC via visited public access network), and Case 3 (nomadic SI connects to a visited SC with roaming agreement to the home AAA).
A rogue softwire concentrator can impersonate the legitimate SC when no prior trust relationship is established, enabling denial-of-service via packet blackholing and full eavesdropping of all SI traffic. Mutual authentication is the primary countermeasure.
BGP used in the softwire mesh control plane is vulnerable to confidentiality violations, replay attacks, insertion/deletion/modification of messages, MITM attacks, and DoS attacks as analyzed in RFC 4272.
Even when softwire packets are encrypted, an adversary may perform traffic analysis by examining packet amounts, timing, sizes, and source/destination addresses visible in outer IP headers. This threat is noted specifically for the mesh scenario.
Without ingress filtering at the SC decapsulator, an attacker can inject false packets into the softwire, enabling DoS or using the ISP's tunneling infrastructure for free inner-address connectivity. Ingress filtering alone is insufficient against address spoofing; binding of address to authenticated identity is also required.
For IPv4-over-IPv6 softwire, the on-wire packet layering is: IPv6 header (SI to SC), ESP header, UDP header (src/dst port 1701), L2TPv2 header, PPP header, IPv4 header, payload, ESP ICV. ESP operates in transport mode.
For IPv6-over-IPv4 softwire, the on-wire packet layering is: IPv4 header (SI to SC), ESP header, UDP header (src/dst port 1701), L2TPv2 header, PPP header, IPv6 header, payload, ESP ICV. ESP operates in transport mode.