Authentication/Confidentiality for OSPFv3
Extracted elements (24)
IKE is based on Diffie-Hellman and works only for two communicating parties, making it unsuitable for OSPFv3's 'one to many' multicast authentication over broadcast interfaces. Manual keying with shared SA parameters (same SPI and keys for all routers) is therefore mandated; future protocols like KINK/GSAKMP may be explored when widely available.
OSPFv2 and OSPFv3 share IP protocol type 89 and are normally distinguished by the OSPF header version field. However, IPsec selectors cannot use arbitrary protocol-specific header fields, so the IP header version field (IPv4 vs. IPv6) is used instead to differentiate OSPFv3 from OSPFv2 in SPD rules.
Because IPsec does not support arbitrary fields in the protocol header as selectors, it is not possible to use different SAs for different OSPFv3 instances running over the same interface. All OSPFv3 instances on the same interface share the same SA; SAs are per-link, not per-interface in OSPFv3 RFC terminology.
A different SA than the SA of the underlying interface MUST be provided for virtual links, because virtual link packets use unicast non-link-local IPv6 source addresses while other interfaces use multicast and unicast link-local addresses.
A three-step rekeying procedure SHOULD be followed: (1) create additional inbound SA with new SPI/key on all routers, (2) replace outbound SA atomically on all routers, (3) remove original inbound SA on all routers. All routers must complete each step before any begin the next.
All implementations conforming to this specification MUST support transport mode SA to provide required IPsec security to OSPFv3 packets. Tunnel mode SA MAY also be supported.
Authentication and encryption keys SHOULD be changed at least every 90 days to maintain link security. This recommendation is based on analysis of the weakest security case: NULL encryption with HMAC-MD5 authentication.
Implementations conforming to this specification MUST support authentication for OSPFv3. To provide this authentication, implementations MUST support ESP and MAY support AH.
Implementations conforming to this specification SHOULD support confidentiality for OSPFv3. If confidentiality is provided, ESP MUST be used.
Implementations MUST allow the administrator to configure cryptographic and authentication keys in hexadecimal format rather than restricting to a subset of ASCII characters, as a restricted character set reduces key entropy significantly.
Implementations MUST use manually configured keys with the same SA parameters (SPI, keys, etc.) for both inbound and outbound SAs. This is required because OSPFv3 uses multicast and IKE cannot provide 'one to many' authentication.
The implementation MUST be able to tag inbound packets with the ID of the interface (physical or virtual) via which they arrived, and manually configured keys MUST be able to secure the specified traffic.
The implementation MUST NOT allow the user to choose stream ciphers as the encryption algorithm for securing OSPFv3 packets, since stream ciphers are not suitable for manual keys.
The IPsec implementation MUST support multiple SPDs with an SPD selection function that provides the ability to choose a specific SPD based on interface, and MUST be able to use source address, destination address, protocol, and direction as selectors.
The IPsec implementation MUST support the establishment and maintenance of multiple SAs with the same selectors between a given sender and receiver to support QoS with different DSCPs.
The routing module SHOULD be able to configure, modify, and delete IPsec rules on the fly, which is needed mainly for securing virtual links. IP encapsulation of ESP packets MUST be supported; UDP encapsulation of ESP packets SHOULD NOT be used.
When IPsec is enabled, routers MUST use the first IPv6 address with the 'LA-bit' set from intra-area-prefix-LSAs in the transit area as source and destination addresses for virtual link packets, making these addresses predictable for SPD/SAD installation.
When OSPFv3 authentication is enabled, OSPFv3 packets not protected with AH or ESP MUST be silently discarded, and packets that fail authentication checks MUST be silently discarded.
When OSPFv3 confidentiality is enabled, OSPFv3 packets not protected with ESP MUST be silently discarded, and packets that fail confidentiality checks MUST be silently discarded.
SPD rules for OSPFv3-secured interfaces consist of five entries: rule 1 (bypass) for disabled interfaces; rules 2-3 covering fe80::/10 source for link-local unicast/multicast traffic (outbound protect and inbound ESP/AH decrypt); rules 4-5 covering /128 src/dst pairs for virtual links installed after endpoint address discovery.
The IPsec protection barrier MUST surround the OSPF protocol so all inbound and outbound OSPF traffic goes through IPsec processing. For interfaces with OSPFv3 security disabled, an SPD rule bypasses OSPF traffic; for enabled interfaces, rules protect link-local (fe80::/10) and virtual-link (src/128, dst/128) OSPF traffic.
Manual key limitations include: (1) sequence numbers cannot be negotiated so replay protection is absent; (2) manual keys are usually long-lived giving attackers time to discover them; (3) administrators may configure weak keys (known weak keys exist for DES/3DES).
Since it is not possible using current standards to provide complete replay protection while using manual keying, the proposed solution does not protect against replay attacks. Replay of OSPF packets can disrupt adjacencies causing DoS, trigger continuous database exchange causing CPU overload, and create micro-loops.
Using the same key on all OSPF routers connected to a link leaves all routers insecure against impersonating attacks if any one router is compromised, malfunctioning, or misconfigured, because any router with the shared key can masquerade as any other.