Cart
Hello Everyone,
This is my first blog post and I am going to take a closer look at Dead Peer Detection and Invalid SPI Recovery features.
Simple site-to-site tunnel has been configured between R6 and R8 and loopback networks are the ones being protected. Here’s the topology :
R6’s F0/0 – 6.6.6.6
R8’s F0/0 – 8.8.8.8
R6’s Loopback0 – 10.6.6.6
R8’s Loopback0 – 10.8.8.8
There are two kinds of DPD messages : periodic and on-demand. The first option relies on periodic messages that have to be sent with considerable frequency. The result of sending frequent messages is that the communicating peers must encrypt and decrypt more packets. This allows for earlier detection of dead peers. On-demand approach allows to send DPD_R_U_THERE message only if two requirements are met : The DPD timer has elapsed and there is traffic to be sent. If a peer is dead, and router never has any traffic to send to the peer, the liveliness of the peer is unimportant. On the other hand, however, if the traffic is freely flowing in both directions, DPD messages are not needed.
Let’s see what happens if we enable DPD on R6 only. Please note that the second value is in seconds and it specifies the timeout between subsequent keepalive messages, not the number of retries :
R6(config)# cry isa keepalive 10 2 on-demand
R6#ping 10.8.8.8 so l0
R6#sh cry isa sa de
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
T - cTCP encapsulation, X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA
C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.
1001 6.6.6.6 8.8.8.8 ACTIVE des sha psk 1 23:57:24 D
Engine-id:Conn-id = SW:1
Wait some time and take a look at the “Last_received” timer. The “Last_received” parameter tells us how much time elapsed since the last DPD message ACK was received. It can only be reset by DPD ACK message (return data also confirms the liveliness of the peer, but this will not be reflected by the Last_received value, however).
R6#sh cry isa peers de
Peer: 8.8.8.8 Port: 500 Local: 6.6.6.6
Phase1 id: 8.8.8.8
flags:
NAS Port: 0 (Normal) DPD information, struct 0x49725E70:
Last_received: 145, dpd threshold (elapsed) 0
my_last_seq_num: 0x15E8C362, peers_last_seq_num: 0x0
sent_and_waiting: FALSE
IKE SAs: 1 IPSec SA bundles: 1
last_locker: 0x43F69448, last_last_locker: 0x0
last_unlocker: 0x0, last_last_unlocker: 0x0
Now take a look at the debugs. First on R6, then on R8 :
R6 :
Feb 2 20:35:02.087: ISAKMP: DPD received KMI message.
Feb 2 20:35:02.087: ISAKMP: set new node 861956653 to QM_IDLE
Feb 2 20:35:02.087: ISAKMP:(1001):Sending NOTIFY DPD/R_U_THERE protocol 1
spi 1218169912, message ID = 861956653
Feb 2 20:35:02.087: ISAKMP:(1001): seq. no 0x15E8C367
Feb 2 20:35:02.087: ISAKMP:(1001): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE
Feb 2 20:35:02.087: ISAKMP:(1001):Sending an IKE IPv4 Packet.
Feb 2 20:35:02.087: ISAKMP:(1001):purging node 861956653
Feb 2 20:35:02.099: ISAKMP (1001): received packet from 8.8.8.8 dport 500 sport 500 Global (I) QM_IDLE
R6#
Feb 2 20:35:02.099: ISAKMP: set new node -1309733009 to QM_IDLE
Feb 2 20:35:02.099: ISAKMP:(1001): processing HASH payload. message ID = -1309733009
Feb 2 20:35:02.099: ISAKMP:(1001): processing NOTIFY DPD/R_U_THERE_ACK protocol 1
spi 0, message ID = -1309733009, sa = 498273E8
Feb 2 20:35:02.099: ISAKMP:(1001): DPD/R_U_THERE_ACK received from peer 8.8.8.8, sequence 0x15E8C367
Feb 2 20:35:02.099: ISAKMP:(1001):deleting node -1309733009 error FALSE reason "Informational (in) state 1"
Feb 2 20:35:02.099: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
Feb 2 20:35:02.099: ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
R8 :
Feb 2 20:35:03.971: ISAKMP (1001): received packet from 6.6.6.6 dport 500 sport 500 Global (R) QM_IDLE
Feb 2 20:35:03.975: ISAKMP: set new node 861956653 to QM_IDLE
Feb 2 20:35:03.975: ISAKMP:(1001): processing HASH payload. message ID = 861956653
Feb 2 20:35:03.975: ISAKMP:(1001): processing NOTIFY DPD/R_U_THERE protocol 1
spi 0, message ID = 861956653, sa = 484997D4
Feb 2 20:35:03.975: ISAKMP:(1001):deleting node 861956653 error FALSE reason "Informational (in) state 1"
Feb 2 20:35:03.975: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
Feb 2 20:35:03.975: ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
Feb 2 20:35:03.975: ISAKMP:(1001):DPD/R_U_THERE received from peer 6.6.6.6, sequence 0x15E8C367
Feb 2 20:35:03.975: ISAKMP: set new node -1309733009 to QM_IDLE
Feb 2 20:35:03.975: ISAKMP:(1001):Sending NOTIFY DPD/R_U_THERE_ACK protocol 1
spi 1224937472, message ID = -1309733009
Feb 2 20:35:03.975: ISAKMP
Feb 2 20:35:03.975: ISAKMP:(1001): sending packet to 6.6.6.6 my_port 500 peer_port 500 (R) QM_IDLE
Feb 2 20:35:03.975: ISAKMP:(1001):Sending an IKE IPv4 Packet.
Feb 2 20:35:03.979: ISAKMP:(1001):purging node -1309733009
Feb 2 20:35:03.979: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_MESG_KEEP_ALIVE
Feb 2 20:35:03.979: ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
First, note that to send DPD replies (DPD_R_U_THERE_ACK), “crypto isakmp keepalive” command does not have to be enabled. This command only enables sending DPD_R_U_THERE messages, replies are always turned on by default. This means that we don’t necessarily have to enable ISAKMP Keepalives on both ends. This is not the best practice, however, which will be explained in a moment.
Now let’s see what happens if DPD replies are blocked somewhere in the return path. It is important to note that DPD messages are using ISAKMP, not IPSec (data) tunnel.
R6:
ip access-list ext OUTSIDE_IN
deny udp any any eq 500
permit ip any any
int f0/0
ip access-gr OUTSIDE_IN in
R6#ping 10.8.8.8 so l0 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 10.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 10.6.6.6
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 12/12/12 ms
R6#
Feb 2 20:41:42.243: ISAKMP: DPD received KMI message.
Feb 2 20:41:42.243: ISAKMP: set new node -426028058 to QM_IDLE
Feb 2 20:41:42.243: ISAKMP:(1001):Sending NOTIFY DPD/R_U_THERE protocol 1
spi 1218169912, message ID = -426028058
Feb 2 20:41:42.243: ISAKMP:(1001): seq. no 0x15E8C368
Feb 2 20:41:42.243: ISAKMP:(1001): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE
Feb 2 20:41:42.243: ISAKMP:(1001):Sending an IKE IPv4 Packet.
Feb 2 20:41:42.243: ISAKMP:(1001):purging node -426028058
R6#
Feb 2 20:41:44.243: ISAKMP:(1001):DPD incrementing error counter (1/5)
Feb 2 20:41:44.243: ISAKMP: set new node -537001878 to QM_IDLE
Feb 2 20:41:44.243: ISAKMP:(1001):Sending NOTIFY DPD/R_U_THERE protocol 1
spi 1228750056, message ID = -537001878
Feb 2 20:41:44.243: ISAKMP:(1001): seq. no 0x15E8C369
Feb 2 20:41:44.243: ISAKMP:(1001): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE
Feb 2 20:41:44.243: ISAKMP:(1001):Sending an IKE IPv4 Packet.
Feb 2 20:41:44.243: ISAKMP:(1001):purging node -537001878
Feb 2 20:41:44.243: ISAKMP:(1001):Input = IKE_MESG_FROM_TIMER, IKE_TIMER_PEERS_ALIVE
R6#
Feb 2 20:41:44.243: ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
Feb 2 20:41:50.243: ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
...
R6#
Feb 2 20:41:52.243: ISAKMP:(1001):DPD incrementing error counter (5/5)
Feb 2 20:41:52.243: ISAKMP:(1001):peer 8.8.8.8 not responding!
Feb 2 20:41:52.243: ISAKMP:(1001):Input = IKE_MESG_FROM_TIMER, IKE_TIMER_PEERS_ALIVE
Feb 2 20:41:52.243: ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
Feb 2 20:41:52.247: ISAKMP (1001): No more ipsec tunnels for this SA.
Feb 2 20:41:52.247: ISAKMP: set new node -498348067 to QM_IDLE
Feb 2 20:41:52.251: ISAKMP:(1001): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE
Feb 2 20:41:52.251: ISAKMP:(1001):Sending an IKE IPv4 Packet.
Feb 2 20:41:52.251: ISAKMP:(1001):purging node -498348067
Feb 2 20:41:52.251: ISAKMP:(1001):Input = IKE_MESG_FROM_IPSEC, IKE_PHASE2_DEL
Feb 2 20:41:52.251: ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
Feb 2 20:41:52.251: ISAKMP: set new node -321941634 to QM_IDLE
Feb 2 20:41:52.251: ISAKMP:(1001): sending packet to 8
R6#.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE
Feb 2 20:41:52.251: ISAKMP:(1001):Sending an IKE IPv4 Packet.
Feb 2 20:41:52.255: ISAKMP:(1001):purging node -321941634
Feb 2 20:41:52.255: ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
Feb 2 20:41:52.255: ISAKMP:(1001):Old State = IKE_P1_COMPLETE New State = IKE_DEST_SA
Feb 2 20:41:52.255: ISAKMP:(1001):deleting SA reason "No reason" state (I) QM_IDLE (peer 8.8.8.8)
Feb 2 20:41:52.255: ISAKMP: Unlocking peer struct 0x496F7F08 for isadb_mark_sa_deleted(), count 0
Feb 2 20:41:52.255: ISAKMP: Deleting peer node by peer_reap for 8.8.8.8: 496F7F08
Feb 2 20:41:52.259: ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Feb 2 20:41:52.259: ISAKMP:(1001):Old State = IKE_DEST_SA New State = IKE_DEST_SA
R6 torn down both the tunnels.
R8:
Feb 2 20:45:06.659: ISAKMP:(1002):DPD/R_U_THERE received from peer 6.6.6.6, sequence 0x7950C76E
Feb 2 20:45:06.663: ISAKMP: set new node -474901432 to QM_IDLE
Feb 2 20:45:06.663: ISAKMP:(1002):Sending NOTIFY DPD/R_U_THERE_ACK protocol 1
Finally, R6 notifies R8 that SA has been destroyed. R8 also frees up its resources :
R8#ISAKMP:(1002):deleting SA reason "No reason" state (R) QM_IDLE (peer 6.6.6.6)
Feb 2 20:45:14.671: ISAKMP:(1002):deleting node -119033128 error FALSE reason "Informational (in) state 1"
Feb 2 20:45:14.671: ISAKMP: set new node 116233501 to QM_IDLE
Feb 2 20:45:14.671: ISAKMP:(1002): sending packet to 6.6.6.6 my_port 500 peer_port 500 (R) QM_IDLE
Feb 2 20:45:14.671: ISAKMP:(1002):Sending an IKE IPv4 Packet.
Feb 2 20:45:14.675: ISAKMP:(1002):purging node 116233501
Feb 2 20:45:14.675: ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
Feb 2 20:45:14.675: ISAKMP:(1002):Old State = IKE_P1_COMPLETE New State = IKE_DEST_SA
Now let’s see what happens if R8 cannot receive DPD & ISAKMP messages from R6. Remember that DPD is not enabled on R8. First remove the filter from R6 and set up the tunnel again. Now apply the same ACL on R8 and see what happens :
R8:
int f0/0
ip access-gr OUTSIDE_IN in
R6#ping 10.8.8.8 so l0 rep 1
R6 has destroyed the SA :
R6(config-if)#
Feb 2 20:53:36.279: ISAKMP:(1003):DPD incrementing error counter (5/5)
Feb 2 20:53:36.279: ISAKMP:(1003):peer 8.8.8.8 not responding!
Feb 2 20:53:36.279: ISAKMP:(1003):Input = IKE_MESG_FROM_TIMER, IKE_TIMER_PEERS_ALIVE
Feb 2 20:53:36.279: ISAKMP:(1003):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
Feb 2 20:53:36.283: ISAKMP (1003): No more ipsec tunnels for this SA.
Feb 2 20:53:36.283: ISAKMP: set new node -466199712 to QM_IDLE
Feb 2 20:53:36.283: ISAKMP:(1003): sending packet to 8.8.8.8 my_port 500 peer_port 500 (I) QM_IDLE
Feb 2 20:53:36.283: ISAKMP:(1003):Sending an IKE IPv4 Packet.
Feb 2 20:53:36.283: ISAKMP:(1003):purging node -466199712
Feb 2 20:53:36.283: ISAKMP:(1003):Input = IKE_MESG_FROM_IPSEC, IKE_PHASE2_DEL
Feb 2 20:53:36.283: ISAKMP:(1003):Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
Look on R8. It still has the SAs (DPD & ISAKMP messages have been blocked) :
R8(config-if)#do sh cry isa pe
Peer: 6.6.6.6 Port: 500 Local: 8.8.8.8
Phase1 id: 6.6.6.6
Initiate some traffic from R8 :
R8#ping 10.6.6.6 so l0 rep 2
R6(config-if)#
Feb 2 20:54:50.519: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=6.6.6.6, prot=50, spi=0x26BFA9D3(650095059), srcaddr=8.8.8.8
Feb 2 20:54:50.519: ISAKMP: ignoring request to send delete notify (no ISAKMP sa) src 6.6.6.6 dst 8.8.8.8 for SPI 0x26BFA9D3
Now let’s move on to the “Invalid SPI Recovery” feature. With Invalid SPI Recovery enabled, R6 will try to rebuild the IPSec tunnel by initiating a new ISAKMP connection (new SPIs will be used for IPSec). Note that router configured with this command initiates an IKE SA to notify an IPSec peer of an “Invalid SPI”. Under specific circumstances (large amount of “Invalid SPI” traffic) this may result in a DoS attack.
R6(config)#cry isakmp invalid-spi-recovery
R8#ping 10.6.6.6 so l0 rep 2
Feb 2 20:55:59.663: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=6.6.6.6, prot=50,
spi=0x26BFA9D3(650095059), srcaddr=8.8.8.8
Feb 2 20:55:59.667: ISAKMP: Created a peer struct for 8.8.8.8, peer port 500
Feb 2 20:55:59.667: ISAKMP: New peer created peer = 0x48DFCDF8 peer_handle = 0x80000005
Feb 2 20:55:59.667: ISAKMP: Locking peer struct 0x48DFCDF8, refcount 1 for ike_initiate_sa_for_inv_spi_recovery
Feb 2 20:55:59.667: ISAKMP: local port 500, remote port 500
Feb 2 20:55:59.667: ISAKMP:(0):found peer pre-shared key matching 8.8.8.8
Feb 2 20:55:59.667: ISAKMP:(0): Unknown DOI 0
Feb 2 20:55:59.667: ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID
Feb 2 20:55:59.667: ISAKMP:(0): constructed NAT-T vendor-07 ID
Feb 2 20:55:59.667: ISAKMP:(0): constructed NAT-T vendor-03 ID
…
As you can now imagine, enabling ISAKMP Keepalives (DPD) only on one side of the connection might not be a good idea. Depending on the situation, one of the peers may not be fully aware of the other’s state. Keep in mind that this is especially important for IPSec HA scenarios.
Piotr Kaluzny
CCIE #25665 (Security)
Sr. Support Engineer IPexpert, Inc.
URL: http://www.IPexpert.com
