IPsec/IKE manual
- Daniel Gollub
Generic IKE control-plane settings
IKE SA limit
Sets the global maximum number of IKE SAs for the entire IKE control-plane. The limit applies to the sum of all IKE SAs across all IKE-based features, regardless of the IKE version or the feature profile. (This is not a per feature/profile limit).
This setting is essential for all IPsec RA VPN server deployments, to not exceed their available resources.
Log-message (mgr = 1):
ignoring <message-type>, hitting IKE_SA limit (<configured ikesa-limit>) |
Default: 0 (no limit)
# set security vpn ike ikesa-limit <10..4294967295> |
Worker threads
The IKE control-plane tries to split as many tasks of the IKE management as possible into small jobs with different priorities. To allow efficient and parallel processing of many IKE exchanges at the same time. Five (5) worker threads are permanent occupied by dedicated jobs (network receiver, scheduler, job dispatcher, ...).
Default: 16
# set security vpn ike worker-threads <10-32> |
IKE SA hash table parameters
ikesa-table-size
Configures the hash table size to store IKE SAs.
Each hash table entry holds a linked-list used to store the IKE SAs. By default the hash table size is one and only holds one linked-list, which results in one single linked-list holding all IKE SAs. This is acceptable for small setups with a small amount of IKE SAs installed.
Setups with many IKE SAs can partiton the linked-list by creating multiple linked-list. This is done by enhancing the hash table size. The key of the hash table are based on the IKE SPIs.
During the hash table look a lock of the hash table is held. The ikesa-table-segements option can be used to divide the table in segments, so only partially segments get locked. The value should be a power of two, otherwise it gets rounded to the next higher of power of two.
# set security vpn ike ikesa-table-size <1..4096> |
ikesa-table-segments
Configures the (lock) segments of the hash table to store IKE SAs. The IKE SA hash table gets divided in multiple segements, which then gets individually locked during a lookup or manipulation. The value should be a power of two, otherwise it gets rounded to the next higher of power of two.
Default: 1
# set security vpn ike ikesa-table-segments <1..4096> |
Interfaces
Interface while-list the IKE control-plane should listen to.
Default: any
# set security vpn ike interface [.. list of interfaces ...] |
Make-before-break
By default reauthentication in IKEv2 is performed in a break-before-make way. The make-before-break option allows to reauthenticate by establishing overlapping IKE SAs. This is not supported by all IKE implementations and might cause interoperability issues.
IKEv2 specific option.
# set security vpn ike make-before-break |
IKE retransmits
Configures retransmission of IKE protocol messages.
The formula of the retransmission for each attempt (n):
Relative retransmission timeout = timeout * base ^ (n - 1)
Example with default values: tries 5, timeout 4.0, base 1.8
#1 retransmission (n=1) after: 4.0 * 1.8 ^ (1 - 1) = 4.0s
#2 retransmission (n=2) after: 4.0 * 1.8 ^ (2 - 1) = 7.2s
#3 retransmission (n=3) after: 4.0 * 1.8 ^ (3 - 1) = 12.96s
#4 retransmission (n=4) after: 4.0 * 1.8 ^ (4 - 1) = 23.328s
#5 retransmission (n=5) after: 4.0 * 1.8 ^ (5 - 1) = 41.99040s
Last retransmission times out : 4.0 * 1.8 ^ (6 - 1) = 75.582720s |
Retransmission configuration changes will have no impact on existing IKE SA.
Manual reset of IKE SA required instead.
# set security vpn ike retransmit base <1.0..4.0>
# set security vpn ike retransmit timeout <1.0..32.0>
# set security vpn ike retransmit tries <1..32> |
Log message (ike=1):
# IKEv1
sending retransmit <retransmit-count> of request message ID <mid>, seq <fragment no.>
sending retransmit <retransmit-count> of response message ID <mid>, seq <fragment no.>
received retransmit of DPD request, ....
received retransmit of request with ID <mid>, ....
received retransmit of response with ID <mid>, ....
# IKEv2
retransmit <retransmit-count> of request with message ID <mid>
received retransmit of request with ID <mid>, retransmitting response
# IKEv1 & IKEv2
giving up after <ike-retransmit-tries> retransmits |
Denial-of-Service protection
Following DoS protection is available for the IKE control-plane to reduce the impact of malicious peers or misbehaving clients cause a CPU/memory exhaustion. This might also limit the exploitation of IKE DoS amplification attacks, where the IKE control-plane is used as amplifier.
Reducing or disabling any DoS related settings might lead to outages of the IKE control-plane if confronted with misbehaving clients or malicious peers.
Depending on the service deployment, the default values might not provide the required protection. IPsec RA VPN server deployments SHOULD set upper limits for: IKE SA half-open limit, IKE SA limit
Block threshold
Sets the maximum number of simultaneously ongoing connection attempts ("half-open" IKE SAs) for an individual peer IP address. If this threshold is exceeded by an individual IP address the IKE_SA_INIT packets gets dropped by the IKE control-plane, no IKE error response is sent.
Log message (net = 1):
ignoring IKE_SA setup from <peer address> peer too aggressive |
Default: 5
# set security vpn ike block-threshold <0..4294967295> |
IKE SA half-open limit
Sets the global maximum number of simultaneously ongoing connection attempts ("half-open" IKE SAs), apply to all peers. If this threshold is exceeded the IKE_SA_INIT packgets get dropped by the IKE control-plane, no IKE error response is sent.
Log message (net = 1):
ignoring IKE_SA setup from <peer address>, half open IKE_SA count of <half-open IKE SAs> exceeds limit of <configured threshold> |
Default: 0 (disabled)
# set security vpn ike init-limit-half-open <10..4294967295> |
IKE SA half-open timeout
The IKE SA half-open timeout allows to control the lifetime of an ongoing connection attempt ("half-open" IKE SA), before the incomplete IKE SA gets deleted inside the IKE control-plane. The intention is to release resources quickly of half-open IKE SAs, which might be a result of a malfunctioning peers or malicious peers performing a DoS trying to exhaust resources or slowing down the service. Bogus IKE SA entries in the IKE control-plane can have strong performance impact on the IKE SA lookup, which might slow down the overall IKE control-plane performance.
Log message (job = 1):
deleting half open IKE_SA with <peer address> after timeout |
Default: 30 seconds
# set security vpn ike half-open-timeout <15..60> |
Cookie threshold
To mitigate DDoS from many different peer addresses, IKEv2 is able to enable a cookie mechanism, if the number of ongoing connection attempts ("half-open" IKE SAs), of all peers, exceeds the cookie threshold.
The IKE control-plane will response with a IKE_SA_INIT message, including a Cookie payload. The peer needs to resend the exact same IKE_SA_INIT message as initially, including the returned Cookie payload. This proofs that the request is not send from a forge source address and that the peer is actually able to receive and process IKE messages.
Each cookie payload is unique. The cookie includes a randomly generated secret, which will be reused for up to 10000 and then regenerated. The individually generated cookies have a lifetime of 10 seconds.
If a peer sends an old cookie (cookie lifetime expired, old cookie secret), the IKE control-plane will handle this as no cookie was provided and responses as if this would be the first IKE_SA_INIT request from the peer.
There is a cookie mechanism calm down period of 10 seconds, which will keep the cookie mechanism for 10 seconds since the last generated cookie. This means there needs to be a period of 10 seconds of no new connection attempts, to get the cookie mechanism turned off again.
Cookie calm down period, cookie secret reuse limit, cookie secret length and cookie lifetime are fixed parameters, not configurable.
Log message (net = 2):
# when cookie payload gets send as response to a IKE_SA_INIT.
# Only indication in the logs that the cookie mechanism got active. (Unless IKE payloads logging is enabled as well)
sending COOKIE notify to <peer address>
# received cookie is older then then 10 seconds:
received cookie lifetime expired, rejecting
# invalid cookie received (e.g. old cookie secret, spoofed IKE packet, ...):
found cookie, but content invalid |
Log message (net = 1):
# New cookie secret gets generated, if used more then 10000 times:
generating new cookie secret after <times of secreted used> uses
# Systems Random Number Generator (RNG) was not able to generate a new secret (memory pressure, low on system entropy, ...)
failed to allocated cookie secret, keeping old |
Default: 10
# set security vpn ike cookie-threshold <0..4294967295> |
By default reauthentication in IKEv2 is performed in a break-before-make way. The make-before-break option allows to reauthenticate by establishing overlapping IKE SAs. This is not supported by all IKE implementations and might cause interoperability issues. IKEv2 specific option.