A YANG Data Model for IPsec Flow Protection Based on Software-Defined Networking (SDN)
Extracted elements (30)
Proactive mode (installing IPsec policies and SAs simultaneously at configuration time) is identified as a way to reduce latency and alleviate performance issues in the IKE-less case, as an alternative to reactive mode (waiting for sadb-acquire notifications before creating SAs).
The IKE case offloads IPsec SA lifecycle management to IKEv2 in the NSF, with the controller only providing initial configuration. This reduces controller overhead and avoids controller involvement in per-SA rekeying, improving scalability compared to the IKE-less case where every rekey requires a round-trip to the controller.
The IKE-less case was designed to support resource-constrained NSFs that cannot run IKEv2 (memory/computation savings), and to enable centralized IPsec SA management for gateway-to-gateway or host-to-host scenarios under the same controller without requiring IKEv2 between NSFs. The tradeoff is greater complexity in the controller and potential scalability/performance issues at scale.
Only the Encapsulating Security Payload (ESP, RFC 4303) is supported as the IPsec protocol; Authentication Header (AH) is not supported. The ipsec-protocol-params typedef is defined as an enumeration with only 'esp', but noted as extensible in the future.
The host-to-gateway scenario is explicitly out of scope because the host may not be under I2NSF Controller control. Only gateway-to-gateway and host-to-host scenarios are addressed; however, the document notes the models can serve as a starting point for analyzing the host-to-gateway case.
Before an NSF can operate in the system, it MUST be registered in the I2NSF Controller. Additionally, the I2NSF Controller MUST discover certain capabilities of the NSF (supported cryptographic suites, authentication method, IKE/IKE-less support) either during registration or when the NSF first connects.
For the IKE-less case, a YANG data model for SPD and SAD configuration data and SAD state data MUST be defined for the NSF-Facing Interface.
If neither the NSF nor the I2NSF Controller has any mechanism to detect whether a host is behind a NAT, then the IKE case MUST be used and not the IKE-less case.
In the IKE-less case, after NSF state loss, the I2NSF Controller SHOULD delete the old IPsec SAs in the non-failed nodes and MUST take the necessary actions to reestablish IPsec-protected communication once the failed node restarts.
In the IKE-less case, the I2NSF Controller MUST take care of the rekeying process. When an IPsec SA soft lifetime is about to expire, the controller MUST create a new IPsec SA and MAY remove the old one (e.g., when the old SA lifetime has not been defined).
IPsec transport mode MUST NOT be used when NAT traversal is required. UDP or TCP encapsulation for ESP packets (RFC 3948, RFC 8229) is required in that case; only tunnel mode is compatible with the NAT traversal support defined in this specification.
The end port number in a port-range grouping MUST be equal to or greater than the start port number; this constraint is enforced as a YANG 'must' expression with an error message.
The pre-shared key secret leaf and the private-key leaf carry 'nacm:default-deny-all' to prevent read access. The YANG module states that the NSF MUST prevent read access to the PSK value for security reasons, and the secret MUST be set if EAP uses PSK or PSK authentication is chosen.
The seq-overflow flag (permitting sequence number rollover) MUST be false when AEAD encryption is used. Setting this flag to true is strongly discouraged in general.
RFC 9061 defines three YANG modules for SDN-based IPsec management: 'ietf-i2nsf-ikec' (common typedefs and groupings), 'ietf-i2nsf-ike' (IKE case: IKEv2, SPD, PAD configuration), and 'ietf-i2nsf-ikeless' (IKE-less case: SPD and SAD configuration). These modules cover the I2NSF NSF-Facing Interface and do not define any new protocol.
The autostartup-type enumeration controls when IKE/IPsec SAs are established after configuration is loaded: 'add' (load config only, no SA started), 'on-demand' (load policies, establish SA on ACQUIRE notification), or 'start' (immediately establish SAs without waiting for traffic). Default is 'add'.
The ESP algorithms configuration supports a list of encryption algorithms (encr-alg-t, uint16 from IANA, default ENCR_AES_GCM_16=20 with 128-bit key) and a list of integrity algorithms (intr-alg-t, uint16 from IANA), plus a TFC padding flag. When AEAD is used, the integrity leaf is not used.
The IKE case architecture places IKEv2 and IPsec (PAD, SPD) in the NSF. The I2NSF Controller provisions the NSF with IKEv2 configuration, PAD entries (credentials), and SPD entries via the NSF-Facing Interface; thereafter the NSF autonomously establishes IPsec SAs via IKEv2 negotiation without further controller involvement.
The IKE-less case removes IKEv2 from the NSF entirely. The I2NSF Controller performs all key management functions including IV generation, SPI generation, prevention of counter resets, cryptographic key generation, IPsec SA creation on sadb-acquire notifications, rekeying on expire notifications, and NAT traversal discovery.
The IKEv2 connection entry ('conn-entry' list) configures autostartup policy, initial-contact, IKE SA soft/hard lifetimes, integrity and encryption algorithm lists (ordered by priority), DH group, half-open SA timer and cookie threshold, local/remote PAD references, ESP encapsulation type, SPD entries, Child SA lifetimes, and state data (SPIs, NAT detection, rekey/reauth times).
The lifetime grouping defines four expiry triggers for IPsec SAs: time (seconds since SA addition), bytes processed, packets processed, and idle time (seconds without traffic). Value 0 means infinite for each. When bytes or packets limits are reached, the SA SHOULD be rekeyed; when idle limit is reached, the SA SHOULD be removed.
The PAD (Peer Authorization Database) YANG model ('pad-entry' list in ietf-i2nsf-ike) stores per-peer identity (IPv4/IPv6 address, FQDN, RFC822 email, DER-encoded X.509 DN/GeneralName, opaque key, or null), the authentication protocol (IKEv2), and peer-authentication credentials (pre-shared key, EAP method, or digital signature with certificate/raw-public-key/CRL/OCSP).
The SPD (Security Policy Database) YANG model uses an 'ipsec-policy-grouping' containing a traffic-selector (local/remote IP prefix, inner protocol, local/remote port ranges) and processing-info (action: protect/bypass/discard; ipsec-sa-cfg with mode, ESP algorithms, PFP flag, extended sequence numbers, tunnel endpoints, and DSCP mapping).
Three IANA YANG namespace registrations are created: 'urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikec' (module ietf-i2nsf-ikec@2021-07-14), 'urn:ietf:params:xml:ns:yang:ietf-i2nsf-ike' (module ietf-i2nsf-ike@2021-07-14), and 'urn:ietf:params:xml:ns:yang:ietf-i2nsf-ikeless' (module ietf-i2nsf-ikeless@2021-07-14) in the IETF XML Registry and YANG Module Names registry.
In the IKE-less case, the I2NSF Controller is responsible for IV generation and prevention of counter resets for the same key — functions that IKEv2 would otherwise handle locally in the NSF. Failure in the controller to manage these correctly can lead to IV reuse, which is catastrophic for confidentiality.
The IKE case provides better security properties than the IKE-less case because NSFs generate their own session keys. In the IKE-less case, the I2NSF Controller generates and distributes cryptographic keys, making the controller a high-value target whose compromise affects all IPsec SAs it manages.
The YANG modules contain sensitive data including pre-shared keys and private keys. Access to these modules via NETCONF or RESTCONF MUST be restricted using NETCONF Access Control Model (NACM, RFC 8341). The 'nacm:default-deny-all' extension is applied to the PSK secret and private-key leaves.
ESP encapsulation type (esp-encap) is an enumeration with three values: 'espintcp' (ESP in TCP per RFC 8229), 'espinudp' (ESP in UDP per RFC 3948), or 'none'. Source and destination ports default to 4500. An optional 'oaddr' leaf-list records the original pre-NAT IP address(es).
The encryption algorithm identifier (encr-alg-t) is a uint16 value drawn from the IANA IKEv2 Transform Type 1 registry. Acceptable values MUST follow the requirement levels in RFC 8221 (ESP/AH) and RFC 8247 (IKEv2). The integrity algorithm identifier (intr-alg-t) is similarly a uint16 from the IANA IKEv2 Transform Type 3 registry.
The tunnel-grouping encodes IPsec tunnel mode endpoints: mandatory local and remote IP addresses, a df-bit enumeration (clear/set/copy, ignored for IPv6), a bypass-dscp boolean (copy inner DSCP to outer if true), and an ordered dscp-mapping list for inner-to-outer DSCP translation when bypass-dscp is false.