HP 6125XLG R2306-HP 6125XLG Blade Switch Security Configuration Guide - Page 240

Enabling invalid SPI recovery, Setting the limit on the number of IKE SAs

Page 240 highlights

4. If the local device receives no response after two retries, the device considers the peer is dead, and deletes the IKE SA along with the IPsec SAs it negotiated. 5. If the local device receives a response from the peer during the detection process, the peer is considered alive. The local device performs a DPD detection again when the triggering interval is reached or it has traffic to send, depending on the DPD mode. Follow these guidelines when you configure the IKE DPD function: • When DPD settings are configured in both IKE profile view and system view, the DPD settings in IKE profile view apply. If DPD is not configured in IKE profile view, the DPD settings in system view apply. • It is a good practice to set the triggering interval longer than the retry interval so that a DPD detection is not triggered during a DPD retry. To configure IKE DPD: Step 1. Enter system view. 2. Enable sending IKE DPD messages. Command Remarks system-view N/A ike dpd interval interval-seconds [ retry seconds ] { on-demand | periodic } By default, IKE DPD is disabled. Enabling invalid SPI recovery An IPsec "black hole" occurs when one IPsec peer fails (for example, a peer can fail if a reboot occurs). One peer fails and loses its SAs with the other peer. When an IPsec peer receives a data packet for which it cannot find an SA, an invalid SPI is encountered. The peer drops the data packet and tries to send an SPI invalid notification to the data originator. This notification is sent by using the IKE SA. Because no IKE SA is available, the notification is not sent. The originating peer continues sending the data by using the IPsec SA that has the invalid SPI, and the receiving peer keeps dropping the traffic. The invalid SPI recovery feature enables the receiving peer to set up an IKE SA with the originator so that an SPI invalid notification can be sent. Upon receiving the notification, the originating peer deletes the IPsec SA that has the invalid SPI. If the originator has data to send, new SAs will be set up. Use caution when enabling the invalid SPI recovery feature because using this feature can result in a DoS attack. Attackers can fabric a great number of invalid SPI notifications to the same peer. To enable invalid SPI recovery: Step 1. Enter system view. 2. Enable invalid SPI recovery. Command system-view ike invalid-spi-recovery enable Remarks N/A By default, the invalid SPI recovery is disabled. Setting the limit on the number of IKE SAs You can set the maximum number of half-open IKE SAs and the maximum number of established IKE SAs. 231

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276

231
4.
If the local device receives no response after two retries, the device considers the peer is dead, and
deletes the IKE SA along with the IPsec SAs it negotiated.
5.
If the local device receives a response from the peer during the detection process, the peer is
considered alive. The local device performs a DPD detection again when the triggering interval is
reached or it has traffic to send, depending on the DPD mode.
Follow these guidelines when you configure the IKE DPD function:
When DPD settings are configured in both IKE profile view and system view, the DPD settings in IKE
profile view apply. If DPD is not configured in IKE profile view, the DPD settings in system view apply.
It is a good practice to set the triggering interval longer than the retry interval so that a DPD
detection is not triggered during a DPD retry.
To configure IKE DPD:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable sending IKE DPD
messages.
ike dpd interval
interval-seconds
[
retry
seconds
]
{
on-demand
|
periodic
}
By default, IKE DPD is disabled.
Enabling invalid SPI recovery
An IPsec "black hole" occurs when one IPsec peer fails (for example, a peer can fail if a reboot occurs).
One peer fails and loses its SAs with the other peer. When an IPsec peer receives a data packet for
which it cannot find an SA, an invalid SPI is encountered. The peer drops the data packet and tries to
send an SPI invalid notification to the data originator. This notification is sent by using the IKE SA.
Because no IKE SA is available, the notification is not sent. The originating peer continues sending the
data by using the IPsec SA that has the invalid SPI, and the receiving peer keeps dropping the traffic.
The invalid SPI recovery feature enables the receiving peer to set up an IKE SA with the originator so that
an SPI invalid notification can be sent. Upon receiving the notification, the originating peer deletes the
IPsec SA that has the invalid SPI. If the originator has data to send, new SAs will be set up.
Use caution when enabling the invalid SPI recovery feature because using this feature can result in a DoS
attack. Attackers can fabric a great number of invalid SPI notifications to the same peer.
To enable invalid SPI recovery:
Step
Command
Remarks
1.
Enter system view.
system-view
N/A
2.
Enable invalid SPI recovery.
ike invalid-spi-recovery enable
By default, the invalid SPI recovery
is disabled.
Setting the limit on the number of IKE SAs
You can set the maximum number of half-open IKE SAs and the maximum number of established IKE SAs.